DEV Community: Frank Pimienta

CloudFront VPC Origins: Integrating Private API Gateway

Frank Pimienta — Sun, 06 Jul 2025 11:55:21 +0000

On November 20, 2024, AWS announced VPC Origins. This new feature enables the use of CloudFront with applications hosted in private subnets, either through a load balancer (ALB or NLB) or EC2 instances.

This excellent news was very well received, as user requests passing through CloudFront to AWS applications or services no longer needed to be exposed to the public internet. Additionally, it optimizes security management and facilitates the use of CloudFront as a single entry point for applications.

While the primary use of VPC Origins is to establish private and secure communication with applications behind an ELB, such as ECS/EKS clusters or EC2 instances, we can leverage this new resource and go beyond the recommended usage.

Private API Gateway Integration

A key advantage of VPC Origins is establishing communication between CloudFront and a Private Endpoint of Amazon API Gateway REST type. The most well-known options are between CloudFront and a Regional or Edge API Gateway Endpoint, but additional security elements need to be applied for it to work correctly.

I have observed that the Edge API Gateway offers better global latencies (5-12ms), but the Private API Gateway with VPC Origins wins on security due to improved isolation. However, this solution has a 7 times higher cost and significantly higher operational complexity (CF, ALB, VPC Endpoint, API Gateway). The decision depends on whether your use case requires critical enterprise systems or global public applications where latency is a top priority concern.

Recommended Use Cases

Critical enterprise systems where security is prioritized over latency.
Internal applications that require complete isolation from the public network.
Multi-account architectures that require centralized access through CloudFront.

Technical Implementation Considerations

Currently, the only way to establish this private communication is by adding the "x-apigw-api-id" header to the CloudFront origin configuration and using VPC Origins, an ALB, a VPC Endpoint, and the private Default Endpoint of an API Gateway.

But why can't I use the private Custom Domain Name that API Gateway provides? For two reasons: AWS doesn't allow us to modify the "Host" header in CloudFront's origin configuration, and VPC Origins doesn't support header rewriting with Lambda@Edge. To use the private Custom Domain Name, we need to send the "Host" header in the request. Due to the limitations of CloudFront and VPC Origins, we can only use the private Default Endpoint.

There are some essential details I must mention for the implementation to work:

We must use an ALB. Why not an NLB? There are three main reasons. First, we must establish communication with the HTTPS protocol from the ALB to the VPC Endpoint. VPC Origins allows establishing HTTP communication to the ALB; however, we can't use this protocol because the ALB will attempt to maintain the same protocol and send the request to the Endpoint, resulting in a failed response. Second, when you configure VPC Origins with HTTPS, the load balancer requires a certificate. Currently, VPC Origins doesn't support an NLB with TLS, and in TCP passthrough, the NLB can't present one. However, we can configure the listener port number as desired; it doesn't have to be 443 (default for HTTPS). The third reason is that with an ALB, we can leverage forwarding rules to redirect to different target groups in case of more complex architectures.
The ALB must have a certificate signed by a trusted certificate authority, such as GlobalSign, DigiCert, or Symantec. The reason we can't use a self-signed certificate is that CloudFront, when communicating via HTTPS with its origin, verifies that a trusted certificate authority has issued the certificate. If the origin (ALB) returns an expired, invalid, or self-signed certificate, CloudFront interrupts the TCP connection and returns HTTP status code 502.
The ALB must be created in the same account as the CloudFront distribution. Currently, AWS doesn't allow creating the ALB in another account.
The target group must be of the IP type with the Health Check protocol set to HTTPS and the Success codes set to 403 when pointing to the root path (/).
Security group configuration. When a VPC Origins is created for the first time, a security group called "CloudFront-VPCOrigins-Service-SG" is created simultaneously. You must allow the security group created by VPC Origins to be included in the load balancer's security group.

Implemented Architectures

Architecture 1: Single-Account Deployment
This basic architecture encompasses all components deployed within a single AWS account, making it ideal for simple use cases or development environments.

Architecture 2: Two or more Environments with Multi-Account Deployment
In this configuration, we use one VPC Origins and one ALB to serve applications in two different environments, distributed across multiple AWS accounts. For this architecture to work and route traffic to various target groups, rules must be created in the ALB, using the "Host" header with the hostname of each CloudFront as the value.

Architecture 3: Multi-Application Architecture
The most complex architecture includes multiple applications in two or more environments, with numerous CloudFronts, VPC Origins, ALBs, and across multiple AWS accounts. For this case, we must create some origins (one per application) and establish the corresponding behaviors that match each application/origin.

Practical Implementation

This guide will walk you through the step-by-step process of implementing VPC Origins with a private API Gateway using the AWS console.

Step 1: Verify base infrastructure
Objective: Validate that you have the necessary network infrastructure.
Actions:

Access the VPC console.
Verify that you have at least two private subnets in different AZs. While it's technically possible to create the ALB in public subnets, to maintain completely private communication, it's recommended to deploy it in private subnets.

Step 2: Create a VPC Endpoint for API Gateway
Objective: Establish private connectivity to the API Gateway.
Actions:

Go to VPC → Endpoints → Create Endpoint
Configure the following parameters:

Service category: AWS services
Service name: com.amazonaws.[region].execute-api
VPC: Select your VPC
Subnets: Select private subnets
Security groups: Create a new one temporarily
- Inbound: HTTPS (443) from the ALB's security group or subnets. If they're in different accounts, I recommend adding the CIDR blocks of the private subnets where the ALB is located. I don't recommend adding only IP addresses because they can change over time.
- Outbound: All traffic

Step 3: Create a private API Gateway
Objective: Configure the API Gateway that will receive requests.
Actions:

Go to API Gateway → Create API → REST API Private
Configure:

API name: your-private-api
Endpoint type: Private
VPC endpoints: Select the VPC endpoint created in the previous step
Configure Resource Policy
Deploy to a stage (e.g., /dev)
Enable logs (Errors and Info)

Step 4: Create Target Group
Objective: Configure the target group that will connect the ALB with the VPC Endpoint.
Actions:

Go to EC2 → Target Groups → Create target group
Configure:

Target type: IP addresses
Protocol: HTTPS
Port: 443
VPC: Your VPC
Health check protocol: HTTPS
Health check path: /
Success codes: 403
In Register targets, add the VPC Endpoint IPs:
- Go to VPC → Endpoints → [your-endpoint] → Network interfaces
- Copy the private IPs and add them as targets

Step 5: Create Application Load Balancer
Objective: Configure the ALB that will act as a "proxy" to the VPC Endpoint.
Actions:

Go to EC2 → Load Balancers → Create load balancer → Application Load Balancer.
Basic configuration:

Scheme: Internal
IP address type: IPv4
VPC: Your VPC
Subnets: Select private subnets (minimum 2 AZs)
Security groups: Create a new one:
- Inbound: HTTPS (443). Temporarily add the CloudFront managed prefix list "com.amazonaws.global.cloudfront.origin-facing". This rule will be changed later once the VPC Origins is created.
- Outbound: All traffic
Listener: HTTPS:443
SSL certificate: Select your valid certificate
Default action: Forward to target group (created in step 4)

Validation: Wait for the ALB to be "Active" and the target group to be "Healthy".

Step 6: Create VPC Origin
Objective: Establish the connection between CloudFront and your VPC.
Actions:

Go to CloudFront → VPC origins → Create VPC origin
Configure:

Origin domain: ARN of the ALB created in the previous step
Protocol: HTTPS only
Port: 443

Validation: The VPC Origin should display a "Deployed" status within 5–10 minutes.

Step 7: Update ALB's Security Groups
Objective: Allow communication between CloudFront and the ALB.
Actions:

Go to EC2 → Security Groups
Edit the ALB's security group:

Inbound rules: Modify the previously created rule and add the source "CloudFront-VPCOrigins-Service-SG"

Step 8: Create CloudFront distribution
Objective: Configure CloudFront to use the VPC Origin.
Actions:

Go to CloudFront → Create distribution
Origin settings:

Origin domain: Select your VPC origin
Protocol: HTTPS only
Custom headers: Add
Header name: "x-apigw-api-id"
Value: [API-ID from step 3]
Origin path: /dev (or your stage)
Default cache behavior:
- Viewer protocol policy: HTTPS only
- Cache policy: Managed-CachingDisabled (for testing)
- Origin request policy: If you're going to implement Architecture 2, add the Managed-AllViewer policy so you can capture the hostname in ALB rules.

Settings:

Alternate domain name (CNAME): your-domain.com (optional)
SSL certificate: Use ACM certificate if you have a CNAME

Step 9: Testing and validation
Objective: Verify that the entire integration works correctly.
Basic connectivity test:

curl -v https://[cloudfront-domain]/[your-resource]
Expected result:
- Response data from your API
- "x-amz-apigw-id" header in the response
- No 502 or 503 errors

Verify API Gateway logs:
- Go to CloudWatch → Log groups → API-Gateway-Execution-Logs_[api-gateway-ID]/[stage]
- Look for the "x-apigw-api-id" header in the logs
- Confirm that requests are coming from CloudFront

I hope this article is of great help to you. Best regards, and I look forward to seeing you next time. Thank you!

CI/CD + AWS CloudFormation + Multi-Account

Frank Pimienta — Sat, 17 Sep 2022 19:09:16 +0000

I want to share a practical example of how you can deploy and update your infrastructure on AWS with a CI/CD pipeline, AWS CloudFormation, and from a root account to multiple accounts.

If your organization has several AWS accounts, I recommend that the deployment and updating of the infrastructure be done from an account that it delegates and belongs to the organization or from its central account (Root) to the other accounts that they have according to its purpose (production, development, test, etc.) In addition, I recommend using native AWS services such as CodeCommit (private Git repository), CodeBuild (continuous integration service), CodePipeline (continuous delivery service), and CloudFormation (Infrastructure as Code).

Pipeline Description:

AWS CloudFormation templates should be stored in a Git repository on CodeCommit, to perform workflows that include code revisions and modifications, pull requests, and merge branches.
The CodePipeline service should be used for the CI/CD pipeline and to automate the environment deployment process.
The templates will be uploaded to a bucket in S3 so they can be accessed by the CloudFormation stacks in the destination accounts.
AWS CloudFormation (Stack Set) service will be used in the central account ID:111111111111 to provision and manage the resources in the target accounts: dev-ID:222222222222, prod-ID:333333333333
CodeBuild service must be used to perform a test and thus be able to check the availability of the deployed environment.

AWS CloudFormation templates:

I make available some AWS CloudFormation templates that I created for this DEMO. You can get them from the following repository on GitHub:

https://github.com/frankpimienta/DEMO-CICD

There is a root template called kloudpepper-ROOT.yml, which is used to define the parameters that will be inserted in the infrastructure to be deployed, and in turn, calls the other separate templates by types of resources or services. The templates are made this way to have an organization when modifying values or data in that particular resource. I explain it better in the previous article:

https://dev.to/frankpimienta/aws-cloudformation-nested-stacks-9k5

Also, you're going to look at a JSON file called parameters-test.json. This file contains the parameters that will be used in the environment to be deployed. For example, the CIDR of the VPC, the name of the environment, if it is a production or non-production environment type, and others. We will carry out the DEMO simulating a non-productive environment.

And finally, the buildspec.yml file, which we will use to define a set of build commands in CodeBuild and check that the environment was deployed correctly.

CI/CD Configuration

1.In the delegate or Root account that will be use to configure CI/CD pipeline, must be created S3 bucket to deposit the templates that will be called later from the CloudFormation stacks of each destination account. To better understand, you can go back to Figure 1 and look at the pipeline. To create the repository, they must put the same name they defined for the environment. This step is essential since, in the templates, there is a parameter that refers to this name. Therefore, they can't put different names on the templates' parameters and in the bucket.

Example:

2.Insert the following policy in the bucket created. Have to change the IDs 111111111111 and 222222222222 with the correct IDs that they have in their accounts:

{ "Version": "2012-10-17", "Id": "Policy1644732224428", "Statement": [ { "Sid": "Stmt1644732214596", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111111111111:root", "arn:aws:iam::222222222222:root" ] }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::kloudpepper-test/*" } ] }

3.It's necessary to create two (2) roles to delegate the administration permissions of the destination accounts to the account where the CI/CD pipeline will be configured (Cross-Account IAM Role) AWS has created two (2) AWS CloudFormation templates to create the roles and permissions in the accounts. I share the templates in the Git repository. So if you know to do the manual configuration, you can do it without problems. There is a lot of documentation that talks about it.

3.1.In the delegate or main (Root) account, you can execute the following template in AWS CloudFormation:
AWSCloudFormationStackSetAdministrationRole.yml

You don't have to insert parameters.

3.2.On the target accounts, execute the following template in AWS CloudFormation:
AWSCloudFormationStackSetExecutionRole.yml

When you execute this template in AWS CloudFormation, it will insert the ID of the parent or delegate account (Root).

4.Create a CodeCommit repository:
I like configuring the repository with approval rules and branches to make pull requests and control the modification of the templates. However, we won't be making those settings for this demo. Create the repository in CodeCommit and upload the templates found on GitHub: https://github.com/frankpimienta/DEMO-CICD

5.Create a building project in CodeBuild. Add the following parameters:

Once the project is created, it should look like this:

5.1.When you finish creating the project, a role is automatically created for its execution. It's necessary to enter the project and search for this role. A policy must then be inserted to assume the role of the target account. Follow the next steps:

5.2.Insert the following policy inside the role. Enter the valid ID of the destination account:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": [ "arn:aws:iam::222222222222:role/AWSCloudFormationStackSetExecutionRole" ], "Action": [ "sts:AssumeRole" ] } ] }

6.Create a pipeline in CodePipeline. Enter the following parameters:

6.1.Once you finish configuring and saving the creation of the pipeline, it will automatically start its execution. Next, stop execution so you can continue configuring the pipeline:

6.2.Edit the pipeline:

6.3.After the Source stage, add a new stage and enter a name:

6.4.Add an action in the Upload_S3 stage:

6.5.Add the following parameters in the Upload_S3 action:

6.6.Once you save the configuration in the Upload_S3 action, you have to save the stage:

6.7.After the Deploy stage, add a new stage and enter a name:

6.8.Add an action in the Test stage:

6.9.Enter the following parameters in the Test action:

6.10.Once you save the configuration in the Test action, you have to save the stage:

6.11.Finally, save the pipeline:

Run CI/CD
7.Once you have created the pipeline in CodePipeline, the next step is to run it. Remember that we configured the pipeline so that CloudWatch Events automatically run the pipeline every time there is a change in the CodeCommit repository. To disable this automatic process, you can go to EventBridge and disable the rule.

7.1.Run the pipeline:

7.2.Wait for the execution to finish and perform the validations:

7.3.In the delegated or root account, review the StackSets operations:

7.4.Finally, in the destination account, check the stacks:

I hope that this article will be of great help to you. A big hug and see you another time. Thank you!

AWS CloudFormation + Nested Stacks

Frank Pimienta — Fri, 16 Sep 2022 01:32:54 +0000

I want to share with you a current topic, which is the process of managing and provisioning IT infrastructures with IaC (Infrastructure as Code). The main goal of IaC is to automate much of the architecture and management of the IT infrastructure. In addition, it allows you to quickly replicate your infrastructure, record resource changes in detail, and establish a flexible workflow that facilitates the collaboration of all those involved in the development process.

This concept did not arise with the cloud and DevOps, as some belief but instead has its roots in managing on-premises systems. Many tools, such as Terraform, Ansible, Chef Infra, and Puppet, fulfill the provisioning and automation capabilities. Still, since the blog will mainly focus on Amazon Web Services, I will talk about the native service of AWS for IaC: AWS CloudFormation.

I'm not going to talk about the structure of an AWS CloudFormation template, there's quite a lot of documentation about it, but today I'm going to talk about Nested Stacks.

For many people, the simplest way to use AWS CloudFormation is to create a single template in which you define all the resources you want to make. But as your infrastructure or project grows, your templates grow in resources, which means more lines of code. Having such a large template, it becomes difficult to manage.

In this case, I recommend dividing your templates into smaller ones to manage them more efficiently; that is where Nested Stack comes in.

But you should know that AWS CloudFormation provides two different methods to manage your templates: Cross-stack and Nested Stacks.

Cross-stack

The concept is straightforward: you manage your stacks separately, export output from one stack, and import it into another.

For example: In the VPC stack, you want to export the ID, and in the Load Balancer stack, you want to import that exported ID.

Example code:
Export VPC ID:

Import VPC ID:

Nested Stacks
Nested Stacks are composed of a root template, the main stack for the first-level stacks. This root template contains the references to the rest of the templates. For those familiar with Terraform, it works like a parent template that calls your public or local modules.

You can upload the individual templates to AWS CloudFormation, but Nested Stacks require templates to be held in an S3 bucket. This is a prerequisite for the Nested Stack to work.

You can also pass Outputs from one Nested Stack to another in a root template using the Fn::GetAtt intrinsic function. Output values can only be used between Nested Stacks, while Export (Cross-stack) values can be imported into other templates outside the nesting.

Example code:
The stack, named VPCStack, contains the output of the VPC ID.

Stack called NACLStack, gets the VPC ID with the GetAtt function.

Can Nested Stack and Cross-stack be mixed?
Yes, it is usual to mix them in large infrastructures, where there are several types of services, and each service is represented by a root template and its set of nested stacks.

I hope that this article will be of great help to you. A big hug and see you another time. Thank you!