Network Security Mental Model

Goal

The previous networking chapters explain how VPCs, subnets, routing, hybrid connectivity, and transit architecture let systems connect. This chapter asks the next question: once connectivity exists, how do you make it safe?

The goal of this section is to give you a placement model for network security. You do not need to memorize every AWS security service first. Start by deciding where traffic is allowed, where it is inspected, where public entry points are protected, and where private access should replace public routing.

The Short Version

The quick question is:

Which AWS network security service should we use?

The better architecture question is:

What traffic path are we protecting, and which layer is the right place to make that decision?

AWS network security is easiest to reason about in layers:

This is a teaching model, not a claim that every design needs every layer. A small internal workload may need only security groups and private endpoints. A public API platform may need edge protection, workload-level access rules, private database access, egress inspection, and DDoS planning.

A Layered Traffic Path

Use this mental model for public application traffic:

Internet client
  -> edge and application protection
  -> public entry point
  -> workload boundary
  -> private application tier
  -> private data tier
  -> private service endpoints or inspected egress

Each arrow is a decision point. The edge decides whether the request looks acceptable before it reaches the application. The public entry point decides which listener, route, or API method receives traffic. The workload boundary decides whether one tier may talk to another. The private data tier should not become public simply because the application is public. Outbound traffic should be just as intentional as inbound traffic.

For private or hybrid traffic, the shape changes but the questions stay familiar:

On-premises or another VPC
  -> transit or peering path
  -> inspection or routing decision
  -> workload boundary
  -> private service or data tier

The important habit is to avoid treating "inside the network" as trusted. AWS designs often span accounts, VPCs, subnets, managed services, endpoints, and automation. A useful network security design assumes that different paths deserve different controls.

What Each Layer Is Good At

Security groups are usually the first place to express workload intent. They say, in effect, "this application tier accepts HTTPS from the load balancer" or "this database accepts traffic only from the application security group." Because they attach to resources, they are good for service-to-service boundaries.

Network ACLs sit at the subnet level. They are useful as broad guardrails, especially when a team wants another layer beyond security groups. They are not usually where you express detailed application relationships, because subnet-level rules can become blunt and hard to operate.

Inspection services belong where routing can force the right traffic through them. AWS Network Firewall is not a magic overlay on every packet in every VPC. You design subnets and route tables so traffic that needs inspection crosses firewall endpoints.

Edge protection belongs before the application has to spend effort on bad traffic. AWS WAF helps with HTTP and HTTPS request filtering. AWS Shield helps with DDoS protection. These controls are especially important for public websites, APIs, and applications with high exposure.

Private access belongs where a workload needs to call AWS services, partner services, or provider services without using a public internet path. VPC endpoints and AWS PrivateLink let you make service access feel local to the VPC, while still keeping the service managed or owned elsewhere.

Example: Different Controls for Different Questions

Imagine a public order API. Customers reach it from the internet. The API tier calls a private order service. The order service writes to a database and publishes messages to an AWS service. The platform team also wants outbound traffic from private subnets to be inspected.

A layered design might use AWS WAF at the edge for web request filtering, Shield for DDoS protection, a load balancer or API front door for public entry, security groups between tiers, no public route to the database, VPC endpoints for selected AWS service calls, and AWS Network Firewall for traffic that must be centrally inspected.

None of those controls is "the network security solution" by itself. Each answers a different placement question.

Common Mistakes

• Treating a private subnet as secure by itself.

• Opening broad security group rules because the subnet feels internal.

• Using network ACLs for detailed application relationships that belong in security groups.

• Adding a firewall without designing the route tables that force traffic through it.

• Letting private workloads call AWS services through public internet paths when a private endpoint would be clearer.

• Thinking WAF, Shield, security groups, and Network Firewall are interchangeable because they all sound like security controls.

If Someone Asks You

How do you explain defense in depth for AWS networking?

A good answer is:

I start by mapping the traffic path. Security groups protect workload boundaries, network ACLs add subnet-level guardrails, Network Firewall can inspect traffic that is routed through it, WAF protects HTTP and HTTPS entry points, Shield helps with DDoS protection, and VPC endpoints or PrivateLink keep service access private. The design is not about using every service. It is about putting the right decision at the right layer.

What You Should Remember

Network security is a placement problem before it is a product choice.

Questions to Check Your Understanding

1. Why is a private subnet not the same thing as a complete security design?

2. Which control is usually best for workload-to-workload allow-listing?

3. Why does an inspection service also require routing design?