The AWS Security Reference Architecture - AWS Prescriptive Guidance

The AWS Security Reference Architecture

The following diagram illustrates the AWS SRA. This architectural diagram brings together all the AWS security-related services. It is built around a simple, three-tier web architecture that can fit on a single page. In such a workload, there is a web tier through which users connect and interact with the application tier, which handles the actual business logic of the application: taking inputs from the user, doing some computation, and generating outputs. The application tier stores and retrieves information from the data tier. The design is purposefully modular and provides the high-level abstraction for many modern web applications.


        AWS Security Reference Architecture

For this reference architecture, the actual web application and data tier are deliberately represented as simply as possible, through Amazon Elastic Compute Cloud (Amazon EC2) instances and an Amazon Aurora database, respectively. Most architecture diagrams focus and dive deep on the web, application, and data tiers. For readability, they often omit the security controls. This diagram flips that emphasis to show security wherever possible, and keeps the application and data tiers as simple as necessary to show security features meaningfully.

The AWS SRA contains most of the AWS security-related services that were generally available at publication. (See Document history.) Not every workload or environment needs to deploy every security service, but our goal is to provide a reference for all possible options, including descriptions of how these services fit together architecturally.

The following sections walk through each OU and account to understand its objectives and the individual AWS security services associated with it. For each element (typically an AWS service), this document provides the following information:

  • Brief overview of the element and its security purpose in the AWS SRA. For more detailed descriptions and technical information about individual services, see the Appendix.

  • Recommended placement to most effectively enable and manage the service. This is captured in the individual architecture diagrams for each account and OU.

  • Configuration, management, and data sharing links to other security services. How does this service rely on, or support, other security services?

  • Design considerations. First, the document highlights optional features or configurations that have important security implications. Second, where our teams’ experience includes common variations in the recommendations we make—typically as a result of alternate requirements or constraints—the document describes those options.