Alexey Baltacov

Posted on Feb 16

Making Amazon Bedrock AgentCore Gateway Accessible (Only Through CloudFront)

#architecture #security #ai #aws

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:
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-custom-domains.html

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:

https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/resource-based-policies.html

These policies 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.

However, 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.

As a result, 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 becomes a critical gap.

Compare This to S3 + CloudFront (OAI / OAC)

Amazon S3 provides a native enforcement primitive:

Only CloudFront can access this bucket.

With CloudFront 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.

An additional boundary must therefore be introduced.

Architecture for Enforcing CloudFront-Only Access

To enforce CloudFront-only reachability, the following architecture can be implemented:

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 publicly reachable.

Inbound traffic can be restricted using AWS Managed Prefix Lists for CloudFront:

https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html

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

This ensures:

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.

This creates a true network enforcement boundary.

Where AWS WAF and DDoS Protection Fit

This design enables layered protection.

CloudFront (Edge Layer)

CloudFront is automatically protected by AWS Shield Standard, which provides DDoS mitigation at the edge.

AWS WAF at CloudFront can provide:

Rate-based rules (anti-abuse and 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 can be filtered before reaching the infrastructure.

ALB (Ingress Layer)

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

Verification of 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.

This results in three enforcement layers:

Edge (Shield + WAF)
Network (managed prefix list restriction)
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, for example:
ext-clients-api-57x9abc.mycompany.com
Downstream routing may require a different HTTP Host header, for example:
gw-abc123.gateway.bedrock-agentcore.us-east-1.amazonaws.com

These belong to different protocol layers:

TLS SNI hostname controls certificate validation.
HTTP Host header controls routing logic.

AgentCore does not support accepting arbitrary custom domains inbound.

This mismatch must be resolved before traffic reaches AgentCore.

The Solution: CloudFront Origin Modification

CloudFront Functions allow modification of:

domainName (origin connection hostname for TLS/SNI)
hostHeader (HTTP Host header sent to the origin)

Example:

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

This 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 ALB
Private connectivity via VPC endpoint
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.

DEV Community