Making Amazon Bedrock AgentCore Gateway Accessible (Only Through CloudFront)

Source: Dev.to

Tags: aws, architecture, genai, cloud, security

Amazon Bedrock AgentCore Gateway makes it straightforward to expose GenAI‑powered APIs.
AWS provides an official pattern for attaching a custom domain using CloudFront:

Client → CloudFront → AgentCore Gateway

Official documentation:

For many use cases, this approach is sufficient.
But what if the requirement is stronger?

This endpoint must only be reachable through a specific CloudFront distribution.

That is where architectural boundaries matter.

The Hidden Exposure Problem

Even when:

• CloudFront is placed in front
• AWS WAF is attached
• A custom domain is configured

the underlying AgentCore Gateway service endpoint remains publicly accessible. CloudFront functions as a reverse proxy, not a strict isolation boundary.

AgentCore supports resource‑based policies that primarily control who can invoke the gateway (IAM principals, AWS accounts, and supported condition keys). This model works well for internal service‑to‑service communication, but for public‑facing APIs:

• External consumers do not authenticate using IAM.
• Authentication typically relies on OAuth, JWT, API keys, or custom headers.
• The endpoint must remain internet‑reachable for legitimate users.

Consequently, even if legitimate traffic flows through CloudFront, the underlying Gateway endpoint may still be reachable directly from the internet unless additional controls are introduced. IAM‑based restrictions do not remove that exposure because the service endpoint itself remains public. For environments with strict ingress‑isolation requirements, this is a critical gap.

Compare This to S3 + CloudFront (OAI / OAC)

Amazon S3 provides a native enforcement primitive: Only CloudFront can access the bucket. With Origin Access Identity (OAI) or Origin Access Control (OAC), an S3 bucket can be made private and restricted to a specific CloudFront distribution.

Example S3 bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontAccessOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E123ABC456XYZ"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-private-bucket/*"
    }
  ]
}

In this model:

• The bucket is not public.
• Direct internet access fails.
• Only the CloudFront identity is permitted.

AgentCore does not currently provide an equivalent isolation construct, so an additional boundary must be introduced.

Architecture for Enforcing CloudFront‑Only Access

Example:

• Public entry point: ext-clients-api-57x9abc.mycompany.com
• Required Host header downstream: gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

Enforcing CloudFront‑Only at the Network Layer

The Application Load Balancer (ALB) is publicly addressable, but it does not need to be reachable from the open internet. Inbound traffic can be restricted using AWS Managed Prefix Lists for CloudFront:

AWS maintains a managed prefix list containing CloudFront origin‑facing IP ranges. Attach this managed prefix list to the ALB security group and allow inbound HTTPS only from:

com.amazonaws.global.cloudfront.origin-facing

What this achieves

• Only CloudFront edge locations can establish TCP connections to the ALB.
• Direct internet traffic to the ALB is blocked at the security‑group level.
• IP spoofing cannot bypass the restriction.

Without CloudFront, the ALB is not reachable, creating a true network enforcement boundary.

Where AWS WAF and DDoS Protection Fit

CloudFront (Edge Layer)

CloudFront is automatically protected by AWS Shield Standard, providing DDoS mitigation at the edge. AWS WAF attached to CloudFront can provide:

• Rate‑based rules (anti‑abuse & scraping protection)
• IP reputation filtering
• Geo restrictions
• AWS Managed Rule Groups
• AWS Bot Control
• Account Takeover Prevention (ATP)
• Authentication field inspection
• Header validation
• Payload size limits

Malicious traffic is filtered before it reaches the infrastructure.

ALB (Ingress Layer)

AWS WAF can also be attached to the ALB to enforce:

• Verification of required custom headers (e.g., a secret header injected by CloudFront)
• Additional rate limiting or bot control closer to the service
• Protection against application‑layer attacks that bypass CloudFront rules

Together, these layers provide a defense‑in‑depth posture that satisfies the “CloudFront‑only” requirement while still exposing a public‑facing API to legitimate users.

A secret header injected by CloudFront

• Strict Host header validation
• Additional managed rule groups
• Authentication flow inspection

Even if the ALB DNS name is discovered:

• Direct connection attempts fail due to managed prefix‑list restrictions.
• Spoofed requests fail due to header validation and WAF rules.

Enforcement Layers

1. Edge – Shield + WAF
2. Network – Managed prefix‑list restriction
3. Application – ALB WAF + listener rules

The Technical Challenge: TLS vs Host Header

When placing an ALB in front of AgentCore:

• The ALB must terminate TLS using a certificate for a custom domain, e.g.:

  ext-clients-api-57x9abc.mycompany.com

• Downstream routing may require a different HTTP Host header, e.g.:

  gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

These belong to different protocol layers:

AgentCore does not support accepting arbitrary custom domains inbound, so this mismatch must be resolved before traffic reaches AgentCore.

The Solution: CloudFront Origin Modification

CloudFront Functions can modify:

• domainName – the origin connection hostname for TLS/SNI
• hostHeader – the HTTP Host header sent to the origin

Example function

import cf from 'cloudfront';

const ORIGIN_DOMAIN_NAME = 'ext-clients-api-57x9abc.mycompany.com';
const OVERRIDE_HOST_HEADER = 'gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com';

function handler(event) {
  const request = event.request;

  cf.updateRequestOrigin({
    domainName: ORIGIN_DOMAIN_NAME,
    hostHeader: OVERRIDE_HOST_HEADER
  });

  return request;
}

This allows:

• TLS validation against the ALB certificate.
• ALB routing based on the required Host header.
• External clients to interact only with the custom domain.
• AgentCore to remain accessible only through the controlled CloudFront → ALB → PrivateLink path.

Final Outcome

The architecture provides:

• Custom‑domain support
• Edge‑level DDoS protection (Shield Standard)
• Advanced WAF protections (rate limiting, ATP, bot control, managed rules)
• Network‑level CloudFront‑only enforcement
• Ingress validation at the ALB
• Private connectivity via VPC endpoint (PrivateLink)
• Strong ingress isolation for GenAI workloads

The default AWS pattern is well‑suited for standard deployments.
When strict CloudFront‑only reachability is required, an architectural boundary is necessary.

CloudFront + managed prefix lists + ALB + PrivateLink + layered WAF provides that boundary.