Infrastructure Security
Defense in depth means putting each control on the layer a packet actually crosses
A request to an AWS workload travels through three places, and infrastructure security is mostly about defending each one with the control that owns it. First it hits the internet edge, where CloudFront, AWS WAF, and AWS Shield judge and shape traffic before it ever reaches you. If it survives, it lands inside your network, the VPC, where security groups and network ACLs decide where it may flow. Finally it reaches the compute workload itself, the EC2 instance, container, or function that has to be hardened, patched, and reachable only through audited paths. The classic exam trap dresses one layer's problem in another layer's clothing: a question that sounds like a firewall change is really about closing port 22 with Session Manager on the compute layer, or a "block this one IP at the subnet edge" scenario is a network-ACL deny, not a security group. Name the layer a control sits on and the right service usually follows.
The page is organized Edge, Compute, Network, even though a packet crosses them edge then network then compute
Read this page as a map, then follow the three subtopics, each owning one layer of the defense. The reading order below is Edge, Compute, Network because that is how the subtopics and the table beside this overview are laid out; it is a teaching order, not the packet path. A live request still crosses the layers in the order the first principle describes: edge, then the network inside the VPC, then the compute host. Edge Security covers the internet boundary: CloudFront for TLS and caching, AWS WAF for the OWASP Top 10 at L7, and AWS Shield for L3/L4 DDoS, plus origin access control (OAC) that stops attackers bypassing the edge. Compute Security hardens the workload: golden images from EC2 Image Builder, roles instead of long-lived keys, Amazon Inspector and Patch Manager for continuous scan-and-patch, keyless admin access through Systems Manager Session Manager, and Amazon Bedrock Guardrails for generative-AI workloads. Network Security Controls governs traffic inside and across the VPC: stateful security groups versus stateless network ACLs, AWS Network Firewall for deep packet and domain-name filtering, segmentation with isolated subnets and Transit Gateway route domains, and AWS Verified Access for VPN-free zero-trust reach. Each subtopic carries the mechanisms, the worked examples, and the traps; this overview just shows how they relate.
When in doubt, prefer the managed, identity-aware, least-exposed path
Across all three layers the exam rewards the same instinct: shrink the attack surface and let AWS rotate the secrets. On the edge that means managed WAF rule groups over hand-written signatures and OAC so the origin answers only to CloudFront. On compute it means a role with auto-rotated temporary credentials over an embedded access key, and a logged Session Manager shell over an open SSH port. On the network it means the narrowest path that works: a private subnet with no internet route, PrivateLink for one-way service exposure, and Verified Access evaluating every request instead of a VPN that grants broad reach once connected. You rarely need to memorize an exception; the managed, verifiable default is the right answer far more often than not.
The three infrastructure-security layers (and where each is covered)
| Layer | Defends | Key controls | Drill into |
|---|---|---|---|
| Edge | The internet request before it reaches you | CloudFront, AWS WAF, AWS Shield, OAC | Edge Security |
| Compute | The workload host or function itself | Image Builder, roles, Inspector, Patch Manager, Session Manager, Bedrock Guardrails | Compute Security |
| Network | Where traffic may flow inside the VPC | Security groups, network ACLs, AWS Network Firewall, segmentation, Verified Access | Network Security Controls |