CloudFront VPC origins add dual-stack IPv6, but private subnets still need IPv4

What changed with this announcement?

On October 15, 2026, AWS announced end-to-end IPv6 traffic support for CloudFront VPC origins. Application Load Balancers (ALBs), Network Load Balancers (NLBs), and EC2 instances can stay in VPC private subnets while CloudFront connects to them.

Before this launch, CloudFront supported dual-stack for public origins, but connected to VPC origins over IPv4 only. The new option means teams that need an IPv6 path no longer have to expose an origin publicly just to deliver IPv6 traffic.

Check Region, origin, and subnet requirements first

AWS says the feature is available in AWS Commercial Regions that support VPC origins. The Region list can change, so check the current CloudFront Developer Guide before implementation. “Commercial Regions” does not mean every AWS Region worldwide.

The supported origin types are ALBs, NLBs, and EC2 instances in private subnets. The origin resource must be fully deployed and in Active status, and the VPC must meet the prerequisites for an eligible Region.

Keep at least one available IPv4 address in the subnet for the service-managed elastic network interface (ENI) CloudFront creates. This does not require a public IPv4 address on the origin; AWS says the subnet address can be private.

Dual-stack does not mean you can remove subnet IPv4

Dual-stack lets this CloudFront-to-origin path carry IPv6 traffic; it does not remove the IPv4 prerequisite for creating a VPC origin ENI. If you are making a broader IPv6-first change, check available IPv4 capacity in the target subnet before assessing whether the rest of the network is ready too.

The VPC also needs an internet gateway to indicate that it can receive internet traffic. AWS says the gateway is not used to route traffic to the private origin, and you do not need to change route policies for this requirement. That detail is easy to confuse with a claim that the origin must be publicly reachable.

What are the security-group and load-balancer limits?

The origin resource needs a security group. Inbound rules can allow the CloudFront managed prefix list; after the VPC origin is created, the documentation also describes using the AWS-created service-managed security group. Do not edit that managed group or use AWS’s reserved CloudFront-VPCOrigins-Service-SG name prefix for your own group.

Gateway Load Balancers cannot be VPC origins, and NLBs with TLS listeners are unsupported. An NLB also needs an attached security group. If your current design depends on one of these configurations, assess a supported origin type before changing the IP address type.

Check inbound ports, the allowed security-group source, and the outbound return path together. Dual-stack alone cannot fix IAM permissions, blocked ports, or an unhealthy origin.

How can you reduce risk on an existing distribution?

Create or update the VPC origin in CloudFront and wait until its status is Deployed. AWS notes that this can take up to 15 minutes; a still-pending origin is not evidence of an IPv6 connectivity failure.

For an existing distribution, AWS documents a staging-distribution path: add the VPC origin to the staging configuration, check requests and origin responses there, and then promote the configuration to the primary distribution. This lets you test the actual setup while preserving a rollback choice.

During the test, verify the client-to-CloudFront IPv6 request, the response from the private origin, application logs, and error rates. Check cache behavior, TLS, health checks, and security groups before expanding the change.

Cost and final checks

AWS says dual-stack VPC origins add no feature charge. That does not make CloudFront, traffic, origin compute, or other AWS resources free; their existing service and usage charges still apply.

This change adds IPv6 delivery from CloudFront to private VPC origins. It does not replace Region eligibility, routing, origin-health, or security-group checks. Confirm the current AWS Region list, resource status, and network policy before switching.