How to implement AWS HTTP API Gateway with Private Link Integration to Internal ALB with 443 Listener (aka Private Integration)

As more applications move to the cloud, the need for secure and reliable APIs is increasingly important. AWS HTTP API Gateway is a popular service that enables developers to build and manage APIs in a scalable and cost-effective manner.

One of the key challenges in using APIs is ensuring that they are secure and that traffic is routed through a private network to prevent unauthorized access. In this blog post, we will explore how to integrate AWS HTTP API Gateway with Private Link to an Internal Application Load Balancer (ALB) with a 443 listener and an imported certificate.

First, it’s important to note that APIGW is an AWS Public Service and does not belong to your VPC. Therefore, APIGW sends all incoming traffic to your AWS Resources via the Public Internet, which prevents it from accessing resources inside a Private Subnet.

Fortunately, VPC Link exists. Essentially, VPC Link creates a direct connection from your APIGW to your VPC via Private Link. In this way, APIGW uses AWS Backbone instead of the Public Internet. Additionally, VPC Link establishes a connection to your VPC, allowing you to access specific resources within your private or public subnets.

When you integrate your API Gateway with VPC Link, you gain several additional benefits. One of the most significant benefits is that your application load balancers no longer need to reside in public subnets. Instead, they can be placed in private subnets within your Virtual Private Cloud (VPC). This ensures that your load balancer endpoints are not accessible directly from the internet, providing an additional layer of security for your system. All incoming requests must first pass through the API Gateway service before reaching the load balancer endpoints.

Additionally, you can also set up authentication and authorization protocols within your API Gateway to further protect your system from potential threats.

Another significant benefit of using an API Gateway with VPC Link is that it allows you to monitor and analyze incoming traffic to your system. With the help of AWS CloudWatch, you can easily monitor and track your system’s performance, identify potential issues, and quickly resolve them. This can help to improve the overall reliability and performance of your system and ensure that your customers have a smooth experience when interacting with your services.

This will serve as our basic reference architecture. As you can see, unlike the REST APIGW, the HTTP APIGW type can directly reach the Application Load Balancer (ALB), eliminating the need for an NLB in front of your ALB. This way, you can create Private Clusters for your containers while securely exposing your APIs to the public.

The HTTP APIGW is both cheaper and faster than the REST APIGW. However, using the HTTP APIGW comes with some limitations. For instance, REST APIGW provides more security controls, such as Resource Policies that restrict access to your API to specific IPs or Users. Moreover, the HTTP APIGW cannot be directly integrated with AWS WAF. If you want to use a WAF with your HTTP APIGW, you will need to create a Cloudfront distribution and put your APIGW as an Origin. Then, you can add the WAF to your Cloudfront.

If you do not mind sacrificing these security controls and you value speed and cost-effectiveness, then the HTTP APIGW is the way to go. Here is a brief tutorial on how to create the APIGW HTTP, ALB, and a 443 Listener.

I will not delve too much into the details, as you probably have a lot of experience with AWS at this point.

First, import your certificate to Certificate Manager following this guide: https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html. It is important to note that if you are using an intermediary CA, you must add the “optional” certificate chain; otherwise, the APIGW will show errors later.

Once you successfully imported, it should look like this:

Once you have successfully imported the certificate, proceed to create an ALB. The type could be internal or external. Create a 443 listener, select your previously imported certificate, and choose your desired Target Group. When you finish, the ALB Listeners section should look like this.

Next, create an APIGW HTTP Type. You can leave the fields blank.

You can leave the fields blank

You can leave the fields blank

After creating the APIGW, go to APIGW -> VPC Links and create a VPC Link. Select VPC Link for HTTP API and select your VPC. The VPC Link will create ENIs in the chosen subnets. Choose your subnets and select a Security Group.

You can create a new security group just for the VPC Link, this new security group doesn't need any ingress rules, but it will require http/https outbound rules. You also will need to add an ingress rule in the ALB SG to allow incoming traffic from this new SG.

Select VPC Link for HTTP API and select your VPC

The VPC Link will create ENIs in the chosen subnets.

Choose your subnets

Select a Security Group

After creating the VPC Link, go to APIGW, select your APIGW, and go to the routes section.

You will need to add /{proxy+} if you want to pass all requests as they are to your ALB.

After creating the route, select it and click on “attach an integration.” In integration type, select “Private Resource,” then click on “select manually” and select your desired ALB and 443 listener.

After you create the route, select it and click on attach an integration

IMPORTANT POINTS:

1. You need to click on advanced settings
2. In the secure server name you will need to add the name of the domain you previously imported to ACM.

By default, APIGW will use port 80 to call your ALB. To change this behavior and use port 443, you will need to add your domain here.

Once you have finished, proceed to your API and make a request to your Invoke URL. The ALB should respond at this point.

Troubleshooting

If your APIGW is not functioning, here is a mini troubleshooting guide. Start by enabling the APIGW logs to identify any errors in the request. Here is a guide on how to do it: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-logging.html

Customize the logs to see more advanced details: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-logging-variables.html

• First, try calling your ALB DNS. Verify that you are receiving correct responses from the ALB Internal DNS. To do this, spin up an EC2 within the same ALB subnet and attempt to call it from the EC2
• Check the Security Group of your ALB. Verify that you have allow ingress rules HTTP/HTTPS from the VPC Link SG.
• Verify your NACLs. Ensure that the necessary ports are open from the ingress and egress rules.
• If you get Internal Server Error 500. Check that you are adding the Intermediate Certificate Chain in Certificate Manager. (The field that says is optional, sometimes it is NOT OPTIONAL)
• Enable FlowLogs for your VPC. Check the traffic coming at your VPC, check that you are not getting any REJECT in the logs. Get the Network Interface ID of your ALB and filter the flowlogs.
• If you are getting error 400 Bad Request with the message “The plain HTTP request was sent to HTTPS port”, confirm that you added the correct secure server name in your VPC Link configuration. It should be the same domain name as the one you imported in Certificate Manager and the same one you added in your 443 ALB Listener. Go to Integrations, advanced settings and fulfill secure server name.
• Confirm that your certificate does not have an intermediary CA. In plain English, ensure that you do not need to add the “Optional” Certificate Chain field when you imported your certificate.
• Ensure that the DEFAULT certificate in the Application Load Balancer (ALB) matches the secure server name specified in the API Gateway Integration Configuration (Secure Server Name).
• Check backend service logs: Investigate the logs of the backend services, such as EC2 instances or containers, for any errors or issues that could be causing the VPC Link integration problems.
• Check VPC Link status: Ensure that the VPC Link is in the “Available” state. A “Pending” or “Failed” state indicates issues with the creation of the VPC Link.
• Verify target resources: Make sure that the target resources, such as Network Load Balancers or Application Load Balancers, are correctly configured and associated with the VPC Link. Confirm that the target resources are in a healthy state and have registered instances or containers.
• 503 integration error and service unavailable message, please follow these steps: Verify intercommunication between subnets, ensure that the subnets involved in the integration have the necessary settings to allow communication between them. Check route table entries, confirm that the route tables contain local entries required for proper communication between the services.

Thank you for taking the time to read my blog post. I hope you found some value in this guide. As always, I am open to feedback and suggestions for future topics. :)