SEC05-BP01 Create network layers
Segment your network topology into different layers based on logical groupings of your workload components according to their data sensitivity and access requirements. Distinguish between components that require inbound access from the internet, such as public web endpoints, and those that only need internal access, such as databases.
Desired outcome: The layers of your network are part of an integral defense-in-depth approach to security that complements the identity authentication and authorization strategy of your workloads. Layers are in place according to data sensitivity and access requirements, with appropriate traffic flow and control mechanisms.
Common anti-patterns:
-
You create all resources in a single VPC or subnet.
-
You construct your network layers without consideration of data sensitivity requirements, component behaviors, or functionality.
-
You use VPCs and subnets as defaults for all network layer considerations, and you don't consider how AWS managed services influence your topology.
Benefits of establishing this best practice: Establishing network layers is the first step in restricting unnecessary pathways through the network, particularly those that lead to critical systems and data. This makes it harder for unauthorized actors to gain access to your network and navigate to additional resources within. Discrete network layers beneficially reduce the scope of analysis for inspection systems, such as for intrusion detection or malware prevention. This reduces the potential for false positives and unnecessary processing overhead.
Level of risk exposed if this best practice is not established: High
Implementation guidance
When designing a workload architecture, it is common to separate
components into different layers based on their responsibility.
For example, a web application can have a presentation layer,
application layer, and data layer. You can
take a similar approach when designing your network topology.
Underlying network controls can help enforce your workload's data
access requirements. For example, in a three-tier web application
architecture, you can store your static presentation layer files
on Amazon S3
Similar to modeling network layers based on the functional purpose of your workload's components, also consider the sensitivity of the data being processed. Using the web application example, while all of your workload services may reside within the application layer, different services may process data with different sensitivity levels. In this case, dividing the application layer using multiple private subnets, different VPCs in the same AWS account, or even different VPCs in different AWS accounts for each level of data sensitivity may be appropriate according to your control requirements.
A further consideration for network layers is the behavior consistency of your workload's components. Continuing the example, in the application layer you may have services that accept inputs from end-users or external system integrations that are inherently riskier than the inputs to other services. Examples include file uploads, code scripts to run, email scanning and so on. Placing these services in their own network layer helps create a stronger isolation boundary around them, and can prevent their unique behavior from creating false positive alerts in inspection systems.
As part of your design, consider how using AWS managed services
influences your network topology. Explore how services such as
Amazon VPC Lattice
Implementation steps
-
Review your workload architecture. Logically group components and services based on the functions they serve, the sensitivity of data being processed, and their behavior.
-
For components responding to requests from the internet, consider using load balancers or other proxies to provide public endpoints. Explore shifting security controls by using managed services, such as CloudFront, Amazon API Gateway
, Elastic Load Balancing, and AWS Amplify to host public endpoints. -
For components running in compute environments, such as Amazon EC2 instances, AWS Fargate
containers, or Lambda functions, deploy these into private subnets based on your groups from the first step. -
For fully managed AWS services, such as Amazon DynamoDB
, Amazon Kinesis , or Amazon SQS , consider using VPC endpoints as the default for access over private IP addresses.
Resources
Related best practices:
Related videos:
Related examples:
