Protecting your origin (BP1, BP5)
If you are using Amazon CloudFront with an origin that is inside of your VPC, you may want to
ensure that only your CloudFront distribution can forward requests to your origin. With
Edge-to-Origin Request Headers, you can add or override the value of existing request
headers when CloudFront forwards requests to your origin. You can use the Origin Custom
Headers, for example, the X-Shared-Secret header, to help validate
that the requests made to your origin were sent from CloudFront.
For more information about protecting your origin with an Origin Custom Headers, refer to Adding custom headers to origin requests and Restricting access to Application Load Balancers.
For a guide on implementing a sample solution to automatically rotate the value of
Origin Custom Headers for the origin access restriction, refer to
How to enhance Amazon CloudFront origin security with AWS WAF and Secrets Manager
Alternatively, you can use an
AWS Lambda
For more information about how to protect your origin by automatically updating your
security groups, and the X-Shared-Secret header, refer to How to Automatically Update Your Security Groups for Amazon CloudFront and AWS WAF by Using
AWS Lambda
However, the solution involves additional configuration and the cost of running Lambda functions. To simplify this, we have now introduced an AWS-managed prefix list for CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the CloudFront origin-facing IP addresses. AWS-managed prefix lists are created and maintained by AWS and are available to use at no additional cost. You can reference the managed prefix list for CloudFront in your (Amazon VPC) security group rules, subnet route tables, common security group rules with AWS Firewall Manager, and any other AWS resources that can use a managed prefix list.
For more information about using AWS-managed prefix list for
Amazon CloudFront, refer to
Limit
access to your origins using the AWS-managed prefix list for
Amazon CloudFront
Note
As discussed in other sections of this document, relying on security groups to protect your origin can add security-group connection tracking as a potential bottle-neck during a request flood. Unless you are able to filter malicious requests at CloudFront using a caching policy that enables caching, it may be better to rely on the Origin Custom Headers, discussed previously, to help validate that the requests made to your origin were sent from CloudFront, rather than use security groups. Using a custom request header with an Application Load Balancer listener rule prevents throttling due to tracking limits that may affect establishing new connections to a load balancer, thus allowing Application Load Balancer to scale based on the increase in traffic in an event of an DDoS attack.
