CloudFront-to-VPC adventure continues... How to update EC2 ARN when using ASG?

Hello.

I recommend creating a custom resource or creating an EventBridge rule that detects when an EC2 instance is launched by AutoScaling and then creating a state machine that rewrites the target of the VPC origin from StepFunctions.
The following document contains examples of AutoScaling events, so why not try creating an EventBridge rule based on this content?
It is possible to create this using Lambda instead of StepFunctions, but in this case, since we are only switching the VPC origin target when starting EC2, I recommend creating a StepFunction that only executes the AWS API.
https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-event-reference.html

CloudFront’s VPC origin requires a static ARN (ALB, NLB, or EC2 instance). With an Auto Scaling Group, EC2 instance ARNs change, so CloudFront can’t track them automatically.

There’s no native way to make this dynamic — the only practical options are:

Use a Network Load Balancer as a stable endpoint for CloudFront.

Or make the app public and restrict access to CloudFront using OAC or prefix lists.

Without an ALB/NLB, CloudFront can’t reliably reach a private ASG-managed instance.

To solve your challenge of using CloudFront VPC Origins with an Auto Scaling Group (ASG) managing a single EC2 spot instance without using load balancers, you'll need to address the dynamic nature of EC2 instance ARNs. Here's how you can approach this:

The fundamental issue is that CloudFront VPC Origins requires a stable endpoint (ARN) to connect to within your private subnet, but your EC2 instance is dynamically provisioned by an ASG, resulting in changing ARNs when instances are replaced.

Since you've ruled out ALB/NLB due to cost concerns and need to use CloudFormation, here are your options:

1. Custom Resource Approach: This is likely your best option. Create a CloudFormation Custom Resource that:

• Monitors your ASG for instance changes
• Updates the CloudFront VPC Origin configuration with the new EC2 instance ARN whenever the instance changes
• Handles the lifecycle events of your CloudFormation stack

2. Cloud Map with Lambda Integration: Since you mentioned you're already using Cloud Map for service discovery:

• Set up a Lambda function that triggers when your ASG launches a new instance
• Have the Lambda update your CloudFront VPC Origin configuration with the new instance ARN
• This can be integrated into your CloudFormation template as a custom resource

3. EC2 Instance Connect Endpoint: For SSH access to your instance in the private subnet (for deployments), you can use EC2 Instance Connect Endpoint, which doesn't require public IPs.

Prerequisites to ensure your setup works correctly:

• Your VPC must have an internet gateway
• Configure appropriate inbound and outbound rules in your network ACLs
• Update security groups to allow the CloudFront managed prefix list
• Ensure you have at least one available IPv4 address in your private subnet
• Grant access to the AWSServiceRoleForCloudFrontVPCOrigin service-linked role

The Custom Resource approach, while requiring some additional code, provides the most native integration with CloudFormation while addressing the dynamic nature of your EC2 instances managed by ASG.
Sources
CloudFront VPC Origin with ECS-EC2 (non-Fargate) Service | AWS re:Post
Best Practices for Protecting EC2 Behind CloudFront | AWS re:Post
Use CloudFront VPC origins to secure applications | AWS re:Post

I'm pursuing an option where the EC2 self-registers into Cloud Map by invoking a Lambda over IPv6 to bypass the need for IPv4 VPC Endpoints ($$$). Will update this answer if I get it working.