- Newest
- Most votes
- Most comments
Since you cannot modify your third-party application running on ECS, you need a mechanism that intercepts the request before it reaches the application container, while still operating entirely within the VPC.
Regarding the ALB Authentication approach, it is highly effective but has strict technical boundaries you should be aware of: ALB natively supports authentication via Amazon Cognito or OpenID Connect (OIDC) Identity Providers. It automatically handles the token exchange, validates the JWT signature, and passes the claims to the backend via HTTP headers.
- The constraint: ALB Authentication cannot execute custom code. If your signature validation requires a bespoke external API call, or if you need to dynamically fetch and inject arbitrary secrets from AWS Secrets Manager mid-flight, native ALB Authentication alone will not cover those custom steps.
- Reference: Authenticate users using an Application Load Balancer
The Airtight Workaround: The Sidecar Proxy Pattern on ECS To perfectly replicate your Lambda@Edge logic (custom API calls + fetching secrets) without touching the third-party app, the standard architectural solution is to deploy a Sidecar container within your existing ECS Task Definition.
- How it works: You create a very lightweight custom proxy container (e.g., a simple Node.js, Python FastAPI, or Go server) that contains the exact processing logic you previously ran in Lambda@Edge.
- Routing: You configure the ALB target group to route incoming traffic to the port of this Sidecar container.
- Execution: The Sidecar receives the request, fetches the required AWS Secrets via the AWS SDK, and makes the external API call to validate the signature.
- Forwarding: If the validation is successful, the Sidecar proxies the request to the third-party application container. Because both containers run in the same Fargate task, they share the same network namespace and can communicate securely over
localhost:<app-port>.
Why this fits your constraints:
- It allows you to use CloudFront VPC Origins, keeping your ALB completely private.
- It requires absolutely zero modifications to the third-party application.
- You retain full programmatic control to run your specific logic.
References for the Sidecar pattern:
- AWS Blog: Setting up an Envoy front proxy on Amazon ECS - While this uses Envoy, the exact same networking principles apply to a custom proxy container written in Node/Python.
- Task definition parameters (Containers) - Explains how to run multiple containers in one task.
You're correct that CloudFront VPC origins currently do not support Lambda@Edge functions. This is a known limitation of the VPC origin feature at this time.
For your use case where you need to fetch AWS secrets and validate signatures via external API calls while using VPC origins, here are some recommended architectural alternatives:
Move Lambda@Edge Logic to Your Application Layer: The most straightforward approach is to relocate your current Lambda@Edge functionality into your ECS Fargate application itself. Your application can:
- Fetch AWS Secrets Manager secrets directly using the AWS SDK
- Make external API calls to validate signatures
- Handle this processing before responding to requests
This approach maintains the security benefits of VPC origins (keeping your ALB private) while preserving your existing business logic.
Hybrid Approach with Application Load Balancer Authentication: Consider implementing authentication and validation at the ALB level using ALB's built-in authentication features, combined with application-level logic in your ECS tasks for the remaining processing.
Regarding future roadmap plans, I cannot provide information about unreleased features or future AWS service developments. I recommend monitoring AWS announcements and the CloudFront documentation for any updates to VPC origin capabilities.
The application-layer approach is generally the most robust solution for your requirements, as it consolidates your business logic and maintains the security posture you're seeking with private origins.
Sources
Using cross-account CloudFront VPC origins for multi-account private API Gateway architecture | Networking & Content Delivery
answered a month ago
Hello.
What specific processing is performed by Lambda@Edge?
Is it limited to executing external APIs and retrieving secrets from AWS Secrets Manager?
If that is the case, since CloudFront Functions cannot be used for those tasks, I believe the only option is to implement the logic within the application itself.
Use cases and other details regarding CloudFront Functions are described in the following documentation, so please take a look.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-choosing.html
The error message indicates that the restriction applies to "origin request/response hooks." Since "viewer request" and "viewer response" events operate independently of origin-side communication, it is possible that the process will work there (though please note this is unverified information, so be sure to test it in a validation environment before implementation).
If it works within the "viewer request" event, it may be worth considering moving tasks such as secret retrieval or signature verification to that stage. However, keep in mind that "viewer request" functions execute with every request—regardless of whether there is a cache hit or miss—so the impact on latency and cost will be significant.
Lambda@Edge is incompatible with CloudFront VPC Origins today, and there’s no public roadmap for this capability. Best path forward: Move secrets fetching and signature validation into your ECS/Fargate app — it can access Secrets Manager natively and call external APIs via a NAT Gateway, eliminating Lambda@Edge entirely and enabling a fully private ALB with VPC Origins. If migration isn’t feasible immediately, keep the public ALB but lock it down using a security group that only allows CloudFront’s managed prefix list, combined with AWS WAF validating a custom origin header. This provides near-equivalent security while retaining Lambda@Edge for now
Relevant content
asked 2 years ago
For the first option: Move Lambda@Edge Logic to Your Application Layer, unfortunately the image processing service is a third-party application running on Amazon ECS and we have a limited control. But the second option - Hybrid Approach with Application Load Balancer Authentication, might be a work around approach that we can try. Can you please extend this a bit more with references? Thank you very much.