This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

# Attack surface reduction
<a name="attack-surface-reduction"></a>

 Another important consideration when architecting an AWS solution is to limit the opportunities an attacker has to target your application. This concept is known as attack *surface reduction*. Resources that are not exposed to the internet are more difficult to attack, which limits the options an attacker has to target your application’s availability. 

 For example, if you do not expect users to directly interact with certain resources, make sure that those resources are not accessible from the internet. Similarly, do not accept traffic from users or external applications on ports or protocols that aren’t necessary for communication. 

 In the following section, AWS provides best practices to guide you in reducing your attack surface and limiting your application’s internet exposure. 

# Obfuscating AWS resources (BP1, BP4, BP5)
<a name="obfuscating-aws-resources-bp1-bp4-bp5"></a>

 Typically, users can quickly and easily use an application without requiring that AWS resources be fully exposed to the internet. 

# Security groups and network ACLs (BP5)
<a name="security-groups-and-network-acls-bp5"></a>

 Amazon Virtual Private Cloud (Amazon VPC) allows you to provision a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. 

 Security groups and network ACLs are similar in that they allow you to control access to AWS resources within your VPC. But security groups allow you to control inbound and outbound traffic at the instance level, while network ACLs offer similar capabilities at the VPC subnet level. There is no additional charge for using security groups or network ACLs. 

 You can choose whether to specify security groups when you launch an instance or associate the instance with a security group at a later time. All internet traffic to a security group is implicitly denied unless you create an *allow* rule to permit the traffic. 

 For example, when you have Amazon EC2 instances behind an Elastic Load Balancer, the instances themselves should not need to be publicly accessible and should have private IPs only. Instead, you could provide the Elastic Load Balancer access to the required target listener ports using a Security Group rule that allows access to 0.0.0.0/0 (to avoid connection tracking issues) in conjunction with a Network Access Control List (NACL) on the target group subnet to allow only the Elastic Load Balancing IP ranges to communicate with the instances. This ensures that internet traffic can’t directly communicate with your Amazon EC2 instances, which makes it more difficult for an attacker to learn about and impact your application. 

 When you create network ACLs, you can specify both allow and deny rules. This is useful if you want to explicitly deny certain types of traffic to your application. For example, you can define IP addresses (as CIDR ranges), protocols, and destination ports that are denied access to the entire subnet. If your application is used only for TCP traffic, you can create a rule to deny all UDP traffic, or vice versa. This option is useful when responding to DDoS attacks because it lets you create your own rules to mitigate the attack when you know the source IPs or other signature. 

 If you are subscribed to AWS Shield Advanced, you can register Elastic IP addresses as protected resources. DDoS attacks against Elastic IP addresses that have been registered as protected resources are detected more quickly, which can result in a faster time to mitigate. When an attack is detected, the DDoS mitigation systems reads the network ACL that corresponds to the targeted Elastic IP address and enforces it at the AWS network border, rather than at the subnet level. This significantly reduces your risk of impact from a number of infrastructure layer DDoS attacks. 

 For more information about configuring security groups and network ACLs to optimize for DDoS resiliency, refer to [How to Help Prepare for DDoS Attacks by Reducing Your Attack Surface](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/). 

 For more information about using Shield Advanced with Elastic IP addresses as protected resources, refer to the steps to [Subscribe to AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html). 

# Protecting your origin (BP1, BP5)
<a name="protecting-your-origin-bp1-bp5"></a>

 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](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) [custom headers to origin requests](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) and [Restricting access to Application Load Balancers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html). 

 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](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/). 

 Alternatively, you can use an [AWS Lambda](https://aws.amazon.com/lambda/) function to automatically update your security group rules to allow only CloudFront traffic. This improves your origin’s security by helping to ensure that malicious users cannot bypass CloudFront and AWS WAF when accessing your web application. 

 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](https://aws.amazon.com/blogs/security/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](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) 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](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html). 

 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](https://aws.amazon.com/blogs/networking-and-content-delivery/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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) 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. 

# Protecting API endpoints (BP4)
<a name="protecting-api-endpoints-bp4"></a>

When you must expose an API to the public, there is a risk that the API frontend could be targeted by a DDoS attack. To help reduce the risk, you can use [Amazon API Gateway](https://aws.amazon.com/api-gateway/) as an entryway to applications running on Amazon EC2, AWS Lambda, or elsewhere. By using Amazon API Gateway, you don’t need your own servers for the API frontend and you can obfuscate other components of your application. By making it harder to detect your application’s components, you can help prevent those AWS resources from being targeted by a DDoS attack. 

 When you use Amazon API Gateway, you can choose from two types of API endpoints. The first is the default option: edge-optimized API endpoints that are accessed through an Amazon CloudFront distribution. The distribution is created and managed by API Gateway, however, so you don’t have control over it. The second option is to use a regional API endpoint that is accessed from the same AWS Region in which your REST API is deployed. AWS recommends that you use the second type of endpoint and associate it with your own Amazon CloudFront distribution. This gives you control over the Amazon CloudFront distribution and the ability to use AWS WAF for application layer protection. This mode provides you with access to scaled DDoS mitigation capacity across the AWS global edge network. 

 When using Amazon CloudFront and AWS WAF with Amazon API Gateway, configure the following options: 
+  Configure the cache behavior for your distributions to forward all headers to the API Gateway regional endpoint. By doing this, CloudFront will treat the content as dynamic and skip caching the content. 
+  Protect your API Gateway against direct access by configuring the distribution to include the origin custom header x-api-key, by setting the [API key](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) value in API Gateway. 
+  Protect the backend from excess traffic by configuring standard or burst rate limits for each method in your REST APIs. 

 For more information about creating APIs with Amazon API Gateway, refer to [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [Getting Started](https://aws.amazon.com/api-gateway/getting-started/).