TranscendCode

Skip the Lambda: A Simpler Pattern for Akamai → ALB → Private API Gateway

Bryce Mc Williams •
#aws#cloud#devops#api-gateway#application-load-balancer#akamai#networking#architecture#tutorial

Introduction

I’m only AWS Certified Cloud Practitioner, but in a previous role I designed and implemented a production architecture that routed traffic from Akamai through an AWS Application Load Balancer (ALB) to a private API Gateway endpoint.

While researching this pattern, I kept finding examples that used a Lambda function as a reverse proxy between ALB and API Gateway. After implementing and operating the system, my conclusion is simple: for many use cases, that Lambda layer is unnecessary complexity. This article walks through the cleaner pattern I used in production—based on DNS, private endpoints, and certificates—without any proxy Lambda.

If you understand VPCs, load balancers, and basic DNS, you can implement this pattern even without advanced AWS certifications.

The Use Case and Requirements

The pattern solves a concrete problem:

High-level flow:

Client → Akamai (public) → ALB (public subnets) → VPC Endpoint (private) → API Gateway (private endpoint)

No reverse-proxy Lambda in the middle, no extra application code to maintain.

Common Approach: Lambda as a Reverse Proxy

When I researched this pattern, I found many tutorials suggesting this architecture:

Akamai → ALB → Lambda (reverse proxy) → API Gateway

On paper, it sounds flexible. In reality, it has some real drawbacks:

For complex request transformations or protocol bridging, that might be justified. For simple “send this HTTP request from ALB to API Gateway privately,” it is over-engineering.

Simpler Pattern: ALB + Private Endpoint + DNS

Instead of using Lambda as a reverse proxy, you can use pure networking and DNS:

This gives you:

The rest of this article walks through how to implement this step by step.

Architecture Diagram

[Internet Users]
       ↓
[Akamai CDN/WAF]
       ↓ (HTTPS to custom domain)
[Application Load Balancer]
  (public subnets)
       ↓ (HTTPS via target group)
[VPC Endpoint for API Gateway]
  (private subnets)
       ↓ (private network)
[API Gateway - Private Endpoint]
       ↓
[Backend Services/Lambda/etc]

Step 1: Configure Private API Gateway

First, create or convert your API Gateway to use private endpoints.

Key Configuration Points

  1. Set endpoint type to Private when creating your API
  2. Create a custom domain name in API Gateway (e.g., api.example.com)
  3. Request an ACM certificate for your custom domain in the appropriate AWS region
  4. Associate the custom domain with your API stages
  5. Configure the resource policy to restrict access to your VPC endpoint

Resource Policy Example

Your API Gateway needs a resource policy that allows access only from your VPC endpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:REGION:ACCOUNT_ID:API_ID/*",
      "Condition": {
        "StringEquals": {
          "aws:sourceVpce": "vpce-xxxxxxxxxx"
        }
      }
    }
  ]
}

Replace REGION, ACCOUNT_ID, API_ID, and the VPC endpoint ID with your actual values.

Verification Checklist

Step 2: Create VPC Endpoint for API Gateway

Next, expose API Gateway privately inside your VPC via an interface endpoint.

Setup Steps

  1. Go to VPC → Endpoints in the AWS console
  2. Click Create Endpoint
  3. Select AWS Services
  4. Search for and select com.amazonaws.REGION.execute-api
  5. Choose your VPC
  6. Select private subnets where your ALB target group will route traffic
  7. Create a security group for the VPC endpoint

Security Group Configuration

The VPC endpoint security group should:

DNS Configuration

Important Details

Result: from within the VPC, you can reach your private API Gateway via the endpoint’s private DNS name.

Step 3: Set Up the Application Load Balancer

Now set up the ALB that will receive traffic from Akamai.

Create the ALB

  1. Navigate to EC2 → Load Balancers
  2. Click Create Load Balancer → Application Load Balancer
  3. Name your ALB
  4. Scheme: Internet-facing
  5. Select public subnets (at least two AZs for high availability)

Configure HTTPS Listener

  1. Add a listener on port 443
  2. Select the ACM certificate for your public-facing domain (the one Akamai will call)
  3. Default action: forward to your target group (created in next step)

Create Target Group for VPC Endpoint

This is the critical piece that replaces the Lambda proxy:

  1. Target type: IP addresses
  2. Protocol: HTTPS
  3. Port: 443
  4. VPC: Select your VPC
  5. Health check: Configure to hit a valid API Gateway endpoint path

Register VPC Endpoint IPs as Targets

  1. After creating the target group, click Register targets
  2. Enter the private IP addresses of your VPC endpoint ENIs
  3. Port: 443
  4. Click Include as pending below and then Register

How to find VPC endpoint IPs:

ALB Security Group

Configure the ALB security group:

Target Group Settings

Key settings to configure:

Step 4: Configure CNAME and Certificate Mapping

This step ensures proper hostname resolution and TLS termination throughout the chain.

Domain Setup

You need two domains properly configured:

  1. Public domain (for Akamai → ALB): api.example.com
  2. Internal/API Gateway custom domain: Could be the same or different

CNAME Configuration

In your DNS provider (Route 53, Cloudflare, etc.):

  1. Create a CNAME record for your public API domain
  2. Point it to your ALB DNS name (e.g., my-alb-123456.us-east-1.elb.amazonaws.com)
  3. Example: api.example.com CNAME → my-alb-123456.us-east-1.elb.amazonaws.com

Certificate Requirements

You need two separate ACM certificates:

  1. ALB certificate: For the public domain Akamai calls (api.example.com)

    • Requested in the same region as your ALB
    • Attached to the ALB HTTPS listener

  2. API Gateway certificate: For the custom domain in API Gateway

    • Requested in the same region as your API Gateway
    • Attached to the API Gateway custom domain configuration

Why Two Certificates

Host Header Considerations

Configure your ALB listener rule to pass through or rewrite the Host header appropriately:

Step 5: Configure Akamai Origin

Finally, configure Akamai to route traffic to your ALB.

Akamai Property Configuration

  1. Set the origin hostname to your ALB’s public DNS name or the CNAME you created
  2. Configure origin SSL certificate verification if required
  3. Set origin protocol to HTTPS
  4. Configure appropriate caching rules based on your API behavior

Origin Settings

Key Akamai configuration:

Testing Akamai Configuration

Use Akamai’s staging network first:

  1. Configure your property on Akamai staging
  2. Add the Akamai staging hostname to your /etc/hosts file for testing
  3. Make requests and verify they reach API Gateway correctly
  4. Check ALB access logs and API Gateway logs for successful routing
  5. Once verified, activate on production

Security Considerations

Security Group Rules

This architecture requires careful security group configuration:

ALB Security Group:

VPC Endpoint Security Group:

API Gateway Resource Policy

The resource policy should restrict access to only your VPC endpoint:

"Condition": {
  "StringEquals": {
    "aws:sourceVpce": "vpce-xxxxxxxxxx"
  }
}

This ensures even if someone discovers your API Gateway ID, they cannot access it without going through the VPC endpoint.

Network Isolation

Benefits of this architecture:

IAM and Authentication

Additional security layers you should consider:

Troubleshooting Common Issues

Problem: 503 Service Unavailable from ALB

Cause: ALB cannot reach the VPC endpoint targets.

Solutions:

Problem: Certificate Validation Errors

Cause: Certificate mismatch between ALB or API Gateway domains.

Solutions:

Problem: API Gateway Returns 403 Forbidden

Cause: Resource policy is blocking the request.

Solutions:

Problem: Target Health Checks Failing

Cause: Health check configuration doesn’t match API Gateway behavior.

Solutions:

Problem: Intermittent Timeouts

Cause: Backend processing time exceeds ALB timeout settings.

Solutions:

Cost Analysis

Understanding the costs of this architecture compared to alternatives.

Components and Pricing

Application Load Balancer:

VPC Endpoint:

API Gateway:

ACM Certificates:

Cost Comparison: This Pattern vs Lambda Proxy

Lambda Reverse Proxy Costs:

This Pattern (ALB + VPC Endpoint):

Break-even analysis:

For APIs with high traffic (>1 million requests/month), the ALB + VPC endpoint pattern is typically cheaper because:

For very low traffic APIs (<100K requests/month), a Lambda proxy might be marginally cheaper due to lower fixed costs.

Cost Optimization Tips

  1. Use single VPC endpoint across multiple AZs instead of multiple endpoints
  2. Right-size ALB by monitoring LCU usage and adjusting listener rules
  3. Enable ALB access logs only when troubleshooting (S3 storage costs)
  4. Use API Gateway caching to reduce backend calls
  5. Configure Akamai caching aggressively to reduce origin requests

Performance and Latency

Real-world performance observations from production use.

Latency Breakdown

Typical request flow latency:

Total overhead: ~12-35ms before backend processing.

Comparison to Lambda Proxy Pattern

Lambda proxy adds:

The DNS-based pattern eliminates these overheads.

Throughput Considerations

This architecture can handle:

Monitor these CloudWatch metrics:

When Lambda Might Still Make Sense

Despite advocating for the DNS/certificate approach, there are valid use cases for Lambda:

Request Transformation

If you need to:

Protocol Bridging

When you need to:

Multi-Backend Routing

For scenarios with:

In these cases, Lambda adds genuine value. For simple proxying, it is overkill.

Why This Pattern Excels

After operating this architecture in production for several months, the benefits were clear:

Simplicity: Configuration-driven, no custom code to maintain, easy to reason about.

Performance: Lower latency than Lambda proxy pattern, no cold starts, predictable behavior.

Cost-effective: At scale, fixed infrastructure costs beat per-invocation pricing.

Debuggable: Standard AWS networking tools (VPC Flow Logs, ALB access logs, API Gateway logs) cover the entire path.

Secure: Private API Gateway, multiple security layers, no public exposure.

Next Steps and Extensions

Once you have the basic pattern working, consider:

Monitoring and Observability

High Availability

CI/CD Integration

Multi-Region Setup

For global applications:

Conclusion

You don’t need a Lambda reverse proxy to route ALB traffic to a private API Gateway endpoint. The CNAME + certificate + VPC endpoint pattern provides a simpler, faster, and more maintainable solution for most use cases.

This architecture proves that understanding fundamentals (VPCs, load balancing, DNS, certificates) matters more than advanced certifications. I built this with just Cloud Practitioner knowledge by focusing on solving the actual problem rather than over-engineering.

If you’re implementing a similar pattern, start simple: get the networking right, verify security groups, ensure DNS resolves correctly, and test thoroughly before adding Akamai into the mix. The result is a production-ready, scalable API architecture without unnecessary complexity.

Now go build your secure, performant API infrastructure—no Lambda proxy required.

← Back to Blog