Perimeter security - AWS Prescriptive Guidance
Deploying perimeter services in a single Network accountDeploying perimeter services in individual Application accountsAdditional AWS services for perimeter security configurations

Perimeter security

Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey.

This section extends the AWS SRA guidance to provide recommendations for building a secure perimeter on AWS. It dives deep into AWS perimeter services and how they fit into the OUs that are defined by the AWS SRA.

In the context of this guidance, a perimeter is defined as the boundary where your applications connect to the internet. The security of the perimeter includes secure content delivery, application-layer protection, and distributed denial of service (DDoS) mitigation. AWS perimeter services include Amazon CloudFront, AWS WAF, AWS Shield, Amazon Route 53, and AWS Global Accelerator. These services are designed to provide secure, low-latency, high-performance access to AWS resources and content delivery. You can use these perimeter services with other security services such as Amazon GuardDuty and AWS Firewall Manager to help build a secure perimeter for your applications.

Multiple architecture patterns for perimeter security are available to support different organizational needs. This section focuses on two common patterns: deploying perimeter services in a central (Network) account, and deploying some of the perimeter services into individual workload (Application) accounts. The section covers the benefits of both architectures and their key considerations.

Deploying perimeter services in a single Network account

The following diagram builds on the baseline AWS SRA to illustrate the architecture where perimeter services are deployed into the Network account.

Deploying perimeter services into Network account

Deploying the perimeter services into a single Network account has several benefits:

  • This pattern supports use cases such as highly regulated industries, where you want to restrict the administration of perimeter services across your organization to a single specialized team.

  • It simplifies the configuration required to limit the creation, modification, and deletion of networking components.

  • It simplifies detection, because inspection happens in a single place, which leads to fewer log aggregation points.

  • You can create custom best practice resources such as CloudFront policies and edge functions, and share these across distributions in the same account.

  • It simplifies the management of business-critical resources that are sensitive to configuration errors, such as content delivery network (CDN) cache settings or DNS records, by reducing the locations where that change is implemented.

The following sections dive into each service and discuss architectural considerations.

Amazon CloudFront

Amazon CloudFront is a content delivery network (CDN) service that’s built for high performance, security, and developer convenience. For public, internet-facing HTTP endpoints, we recommend that you use CloudFront to distribute your internet-facing content. CloudFront is a reverse proxy that serves as a single point of entry for your application globally. It can also be combined with AWS WAF and edge functions such as Lambda@Edge and CloudFront functions to help create secure and customizable solutions for content delivery.

In this deployment architecture, all CloudFront configurations, including edge functions, are deployed into the Network account and managed by a centralized networking team. Only authorized employees on the networking team should have access to this account. Application teams that want to make changes to their CloudFront configuration or web access control list (web ACL) for AWS WAF should request those changes from the networking team. We recommend that you establish a workflow such as a ticketing system for application teams to request configuration changes.

In this pattern, both dynamic and static origins are located in the individual Application accounts, so accessing these origins requires cross-account permissions and cross-account roles. Logs from CloudFront distributions are configured to be sent to the Log Archive account.

AWS WAF

AWS WAF is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to your protected web application resources. This service can help protect your resources against common web exploits and volumetric threats, as well as against more sophisticated threats such as account creation fraud, unauthorized access to user accounts, and bots that attempt to evade detection. AWS WAF can help protect the following resource types: CloudFront distributions, Amazon API Gateway REST APIs, Application Load Balancers, AWS AppSync GraphQL APIs, Amazon Cognito user pools, AWS App Runner services, and AWS Verified Access instances.

In this deployment architecture, AWS WAF is attached to the CloudFront distributions that are configured in the Network account. When you configure AWS WAF with CloudFront, the perimeter footprint is extended to CloudFront edge locations instead of the application VPC. This pushes the filtering of malicious traffic closer to the source of that traffic and helps restrict malicious traffic from entering your core network.

Although web ACLs are deployed in the Network account, we recommend that you use AWS Firewall Manager to centrally manage web ACLs and make sure that all resources are compliant. Set the Security Tooling account as the administrator account for Firewall Manager. Deploy Firewall Manager policies with auto-remediation to enforce that all (or selected) CloudFront distributions in your account have a web ACL attached.

You can send full AWS WAF logs to an S3 bucket in the Log Archive account by configuring cross-account access to the S3 bucket. For more information, see the AWS re:Post article on this topic.

AWS Shield and AWS Route 53 health checks

AWS Shield Standard and AWS Shield Advanced provide protections against distributed denial of service (DDoS) attacks for AWS resources at the network and transport layers (layers 3 and 4) and the application layer (layer 7). Shield Standard is automatically included at no extra cost beyond what you already pay for AWS WAF and your other AWS services. Shield Advanced provides expanded DDoS event protection for your Amazon EC2 instances, Elastic Load Balancing load balancers, CloudFront distributions, and Route 53 hosted zones. If you own high-visibility websites or your applications are prone to frequent DDoS events, consider the additional features that Shield Advanced provides.

This section focuses on Shield Advanced configurations, because Shield Standard isn’t user configurable.

To configure Shield Advanced to protect your CloudFront distributions, subscribe the Network account to Shield Advanced. In the account, add Shield Response Team (SRT) support and provide the necessary permissions for the SRT team to access your web ACLs during a DDoS event. You can contact the SRT at any time to create and manage custom mitigations for your application during an active DDoS event. Configuring access in advance give the SRT the flexibility to debug and revise the web ACLs without having to manage permissions during an event.

Use Firewall Manager with auto-remediation to add your CloudFront distributions as protected resources. If you have other internet-facing resources such as Application Load Balancers, you might consider adding them as Shield Advanced protected resources. However, if you have multiple Shield Advanced protected resources in the data flow (for example, your Application Load Balancer is the origin to CloudFront), we recommend that you use only the entry point as a protected resource to reduce duplicate data transfer out (DTO) fees for Shield Advanced.

Enable the proactive engagement feature to allow the SRT to proactively monitor your protected resources and contact you as required. To configure the proactive engagement feature effectively, create Route 53 health checks for your application and associate them with CloudFront distributions. Shield Advanced uses the health checks as an additional data point when it evaluates an event. Health checks should be properly defined to reduce false positives with detection. For more information about identifying the correct metrics for health checks, see Best practices for using health checks with Shield Advanced in the AWS documentation. If you detect a DDoS attempt, you can contact the SRT and choose the highest severity available for your support plan.

AWS Certificate Manager and AWS Route 53

AWS Certificate Manager (ACM) helps you provision, manage, and renew public and private SSL/TLS X.509 certificates. When you use ACM to manage certificates, certificate private keys are securely protected and stored by using strong encryption and key management best practices.

ACM is deployed in the Network account in order to generate a public TLS certificate for CloudFront distributions. TLS certificates are needed to establish a HTTPS connection between viewers and CloudFront. For more information, see the CloudFront documentation. ACM provides DNS or email validation to validate domain ownership. We recommend that you use DNS validation instead of email validation, because by using Route 53 to manage your public DNS records, you can update your records through ACM directly. ACM automatically renews DNS-validated certificates for as long as a certificate remains in use and the DNS record is in place.

CloudFront access logs and AWS WAF Logs

By default, CloudFront access logs are stored in the Network account and AWS WAF logs are aggregated in the Security Tooling account by using the Firewall Manager logging option. We recommend that you replicate these logs in the Log Archive account so that centralized security teams can access them for monitoring purposes.

Design considerations

  • In this architecture, the large number of dependencies on a single networking team can affect your ability to make changes quickly.

  • Monitor the service quotas for each account. Service quotas, also referred to as limits, are the maximum number of service resources or operations for your AWS account. For more information, see AWS service quotas in the AWS documentation.

  • Providing specific metrics to workload teams might introduce complexities.

  • Application teams have restricted access to configurations, which might result in an overhead of waiting for the networking teams to implement changes on their behalf.

  • Teams that share resources in a single account might compete for the same resources and budgets, which might lead to resource allocation challenges. We recommend that you put mechanisms in place to charge back from the application teams that use the perimeter services deployed in the Networking account.

Deploying perimeter services in individual Application accounts

The following diagram illustrates the architecture pattern where the perimeter services are deployed and managed independently in individual Application accounts.

Deploying perimeter services into individual Application accounts

There are several benefits of deploying the perimeter services into Application accounts:

  • This design provides the autonomy for individual workload accounts to customize service configurations based on their needs. This approach removes the dependency on a specialized team to implement changes to resources in a shared account, and enables developers in each team to manage configurations independently.

  • Each account has its own service quotas, so application owners don’t have to work within the quotas of a shared account.

  • This design helps contain the impact of malicious activity by limiting it to a particular account and preventing the attack from spreading to other workloads.

  • It removes the risks of change, because the scope of impact is limited to just the workload in question. You can also use IAM to limit the teams that can implement changes, so there’s a logical separation between workload teams and the central networking team.

  • By decentralizing the implementation of network ingress and egress, but having common logical controls (by using services such as AWS Firewall Manager) you can tune network controls to specific workloads while continuing to meet a minimum standard of control objectives.

The following sections dive into each service and discuss architectural considerations.

Amazon CloudFront

In this deployment architecture, Amazon CloudFront configurations, including edge functions, are managed and deployed in the individual Application accounts. This verifies that each application owner and workload account has the autonomy to configure perimeter services based on the needs of their application.

The dynamic and static origins are located in the same Application account, and CloudFront distributions have account-level access to these origins. Logs from CloudFront distributions are stored locally in each Application account. Logs can be replicated to the Log Archive account to support compliance and regulatory needs.

AWS WAF

In this deployment architecture, AWS WAF is attached to the CloudFront distributions that are configured in the Application account. As with the previous pattern, we recommend that you use AWS Firewall Manager to centrally manage web ACLs and make sure that all resources are compliant. Common AWS WAF rules such as the AWS managed core rule set and the Amazon IP reputation list should be added as default. These rules are automatically applied to any eligible resource in the Application account.

In addition to the rules enforced by Firewall Manager, each application owner can add AWS WAF rules that are relevant to their application security to the web ACL. This allows for flexibility in each Application account while still retaining overall control in the Security Tooling account.

Use the Firewall Manager logging option to centralize logs and send them to an S3 bucket in the Security Tooling account. Each application team is provided access to review the AWS WAF dashboards for their application. You can set up the dashboard by using a service such as Amazon QuickSight. If any false positives are identified or other updates to the AWS WAF rules are needed, you can add application-level AWS WAF rules to the web ACL that’s deployed by Firewall Manager. The logs are replicated to the Log Archive account and archived for security investigations.

AWS Global Accelerator

AWS Global Accelerator lets you create accelerators to improve the performance of your applications for local and global users. Global Accelerator provides you with static IP addresses that serve as fixed entry points to your applications that are hosted in one or more AWS Regions. You can associate these addresses with regional AWS resources or endpoints, such as Application Load Balancers, Network Load Balancers, EC2 instances, and Elastic IP addresses. This enables traffic to ingress to the AWS global network as close to your users as possible.

Global Accelerator doesn’t currently support cross-account origins. Therefore, it is deployed into the same account as the origin endpoint. Deploy the accelerators in each Application account and add them as protected resources for AWS Shield Advanced in the same account. Shield Advanced mitigations will allow only valid traffic to reach the Global Accelerator listener endpoints.

AWS Shield Advanced and AWS Route 53 health checks

To configure AWS Shield Advanced to help protect your CloudFront distributions, you need to subscribe each Application account to Shield Advanced. You should configure features such as access to the Shield Response Team (SRT) and proactive engagement at the account level, because they should be configured in the same account as the resource. Use Firewall Manager with auto-remediation to add your CloudFront distributions as protected resources, and apply the policy to each account. Route 53 health checks for each CloudFront distribution should be deployed in the same account and associated with the resource.

Amazon Route 53 zones and ACM

When you use services such as Amazon CloudFront, the Application accounts require access to the account that hosts the root domain in order to create custom subdomains and to apply certificates issued by Amazon Certificate Manager (ACM) or a third-party certificate. You can delegate a public domain from the central Shared Services account to individual Application accounts by using Amazon Route 53 zone delegation. Zone delegation gives each account the ability to create and manage application-specific subdomains such as API or static subdomains. The ACM in each account allows each Application account to manage the certificate vetting and verification processes (organization validation, extended validation, or domain validation) according to their needs.

CloudFront access logs, Global Accelerator flow logs, and AWS WAF Logs

In this pattern, we configure CloudFront access logs and Global Accelerator flow logs in S3 buckets in individual Application accounts. Developers who want to analyze the logs for performance tuning or false positive reduction will have direct access to these logs without having to request access to a central log archive. Locally stored logs can also support regional compliance requirements such as data residency or PII obfuscation.

Full AWS WAF logs are stored in the S3 buckets in the Log Archive account by using Firewall Manager logging. Application teams can view logs by using dashboards that are set up by using a service such as Amazon QuickSight. In addition, each application team has access to the sampled AWS WAF logs from their own account for quick debugging.

We recommend that you replicate logs to a centralized data lake that’s located in the Log Archive account. Aggregating the logs in a centralized data lake gives you a comprehensive view of all the traffic to your AWS WAF resources and distributions. This helps security teams centrally analyze and respond to global security threat patterns.

Design considerations

  • This pattern shifts the responsibility of network and security administration to account owners and developers, which could add overhead to the development process.

  • There can be inconsistencies in decision-making. You should establish effective communications, templates, and training to make sure that the services are configured correctly and follow security recommendations.

  • There is a dependency on automation and clear expectations on the baseline security controls combined with the application-specific controls.

  • Use services such as Firewall Manager and AWS Config to make sure that the deployed architecture is compliant with security best practices. In addition, configure AWS CloudTrail monitoring to detect any misconfigurations.

  • Aggregating logs and metrics in a central place for analysis might introduce complexities.

Additional AWS services for perimeter security configurations

Dynamic origins: Application Load Balancers

You can configure Amazon CloudFront to use Application Load Balancer origins for dynamic content delivery. This setup allows you to route requests to different Application Load Balancer origins based on various factors such as the request path, hostname, or query string parameters.

Application Load Balancer origins are deployed in the Application account. If your CloudFront distributions are in the Network account, you must set up cross-account permissions for the CloudFront distribution to access the Application Load Balancer origin. The logs from the Application Load Balancer are sent to the Log Archive account.

To help prevent users from directly accessing an Application Load Balancer without going through CloudFront, complete these high-level steps:

  • Configure CloudFront to add a custom HTTP header to requests that it sends to the Application Load Balancer, and configure the Application Load Balancer to forward only the requests that contain the custom HTTP header.

  • Use an AWS-managed prefix list for CloudFront from the Application Load Balancer security group. This limits the inbound HTTP/HTTPS traffic to your Application Load Balancer from only the IP addresses that belong to CloudFront's origin-facing servers.

For more information, see Restricting access to Application Load Balancers in the CloudFront documentation.

Static origins: Amazon S3 and AWS Elemental MediaStore

You can configure CloudFront to use Amazon S3 or AWS Elemental MediaStore origins for static content delivery. These origins are deployed in the Application account. If your CloudFront distributions are in the Network account, you must set up cross-account permissions for the CloudFront distribution in the Network account to access the origins.

To verify that your static origin endpoints are accessed only through CloudFront and not directly through the public internet, you can use origin access control (OAC) configurations. For more information about restricting access, see Restricting access to an Amazon S3 origin and Restricting access to a MediaStore origin in the CloudFront documentation.

AWS Firewall Manager

AWS Firewall Manager simplifies administration and maintenance tasks across multiple accounts and resources, including AWS WAF, AWS Shield Advanced, Amazon VPC security groups, AWS Network Firewall, and Amazon Route 53 Resolver DNS Firewall, for a variety of protections.

Delegate the Security Tooling account as the Firewall Manager default administrator account and use it to centrally manage AWS WAF rules and Shield Advanced protections across your organization accounts. Use Firewall Manager to centrally manage common AWS WAF rules while giving each application team flexibility to add application-specific rules to the web ACL. This helps enforce organization-wide security policies such as protection against common vulnerabilities while allowing application teams to add AWS WAF rules that are specific to their application.

Use Firewall Manager logging to centralize AWS WAF logs to an S3 bucket in the Security Tooling account, and replicate the logs to the Log Archive account so you can archive it for security investigations. In addition, integrate Firewall Manager with AWS Security Hub to centrally visualize configuration details and DDoS notifications in Security Hub.

For additional recommendations, see AWS Firewall Manager in the Security Tooling account section of this guide.

AWS Security Hub

The integration between Firewall Manager and Security Hub sends four types of findings to Security Hub:

  • Resources that aren’t properly protected by AWS WAF rules

  • Resources that aren’t properly protected by AWS Shield Advanced

  • Shield Advanced findings that indicate that a DDoS attack is under way

  • Security groups that are being used incorrectly

These findings from all organization member accounts are aggregated into the Security Hub delegated administrator (Security Tooling) account. The security tooling account aggregates, organizes, and prioritizes your security alerts or findings in a single place. Use Amazon CloudWatch Events rules to send the findings to ticketing systems or create auto-remediations such as blocking malicious IP ranges.

For additional recommendations, see AWS Security Hub in the Security Tooling account section of this guide.

Amazon GuardDuty

You can use the threat intelligence provided by Amazon GuardDuty to automatically update web ACLs in response to GuardDuty findings. For example, if GuardDuty detects suspicious activity, the automation can be used to update the entry in the AWS WAF IP sets and apply the AWS WAF web ACLs to affected resources to block communication from the suspicious host while you perform additional investigation and remediation. The Security Tooling account is the delegated administrator account for GuardDuty. Therefore, you should use an AWS Lambda function with cross-account permissions to update the AWS WAF IP sets in the Application account.

For additional recommendations, see Amazon GuardDuty in the Security Tooling account section of this guide.

AWS Config

AWS Config is a prerequisite for Firewall Manager and is deployed in AWS accounts, including the Network account and Application account. In addition, use AWS Config rules to verify that deployed resources are compliant with security best practices. For example, you could use an AWS Config rule to check if every CloudFront distribution is associated with a web ACL, or enforce all CloudFront distributions to be configured to deliver access logs to an S3 bucket.

For general recommendations, see AWS Config in the Security Tooling account section of this guide.