The IAM page covered who can act. This page covers where they can act from, what the network in front of a workload looks like, and how data at rest is encrypted in the major AWS storage services. Most AWS breaches that aren't IAM failures are network configuration failures — an exposed port, an open security group, an unencrypted volume.
VPC — the boundary around your workloads
A Virtual Private Cloud (VPC) is your own logically isolated network in AWS. Every new account gets a default VPC; serious deployments build dedicated VPCs with explicit subnets, route tables, and gateways. The minimal mental model:
The three-tier pattern (public / private-app / private-data) is the default for new VPCs because it maps the principle of least exposure to AWS primitives. Internet-facing things sit in public subnets; application logic in private subnets behind a load balancer; databases in subnets with no route to the internet at all.
Security Groups vs Network ACLs
Two layers of network filtering exist. They look similar; they behave very differently. Knowing which is which is one of the most common AWS interview questions and the source of most "why is my traffic blocked?" debugging.
Security Groups
Stateful, per-resource, allow-only. Attached to an ENI (EC2, RDS, Lambda-in-VPC, etc.). Define which inbound and outbound connections are permitted.
- Stateful: return traffic for an allowed flow is automatically permitted without an explicit rule.
- Allow only: no Deny statements; what isn't allowed is denied.
- Default outbound rule: allow all egress. Default inbound: deny all.
- Can reference other security groups (
sg-12345) as the source — "allow from any instance in sg-app."
Network ACLs
Stateless, per-subnet, allow and deny. Attached to a subnet. Filter packets entering and leaving the subnet regardless of which instance they're going to.
- Stateless: you must explicitly allow return traffic, often via ephemeral port range (1024–65535).
- Allow + Deny: evaluated in numbered order. Lowest-numbered rule that matches wins.
- Useful as a coarse second layer (e.g., "no subnet may talk to 192.0.2.0/24 ever").
- Most teams set permissive NACLs and rely on security groups for the real work.
| Aspect | Security Group | Network ACL |
|---|---|---|
| Scope | Per resource (ENI) | Per subnet |
| State | Stateful | Stateless |
| Rule types | Allow only | Allow and Deny |
| Evaluation | All rules at once | In numeric order, first match wins |
| Default in | Deny all | Allow all (default NACL) |
| Default out | Allow all | Allow all (default NACL) |
| Reference other | Yes (sg-IDs) | No (CIDR only) |
S3 Block Public Access — the safety switch
S3 has had so many "public bucket" breaches that AWS added an account-level kill switch in 2018: S3 Block Public Access (BPA). When enabled at the account level, it overrides every individual bucket setting that might otherwise allow public access. As of April 2023, BPA is on by default for all new buckets — but verify it for your account, especially if it was created before then.
BPA controls four settings independently. The pattern that matters: turn all four on at the account level unless you have a documented exception.
| Setting | What it blocks |
|---|---|
| BlockPublicAcls | Refuses any future ACL change that would make a bucket or object public |
| IgnorePublicAcls | Treats existing public ACLs as if they were private |
| BlockPublicPolicy | Refuses any bucket policy that grants public access |
| RestrictPublicBuckets | Limits a bucket with a public policy to access only by the AWS service principal and authorized AWS users |
aws:SourceVpce condition on bucket policies that need to be reachable: on. None of those would have stopped the underlying SSRF, but they would have blocked the data exfiltration step that made the breach catastrophic.KMS — encryption that you can audit
AWS Key Management Service (KMS) is the encryption-key system used by every storage service in AWS. Each KMS key has a key policy (an identity-policy-like document) that controls who can use it. Every use of a KMS key is logged to CloudTrail. The auditability is the point: even if an attacker steals an encrypted file, they cannot decrypt it without a KMS key call, and that call shows up in your logs.
- AWS-managed keys — the default. Convenient. Can't apply custom policies; can't rotate on demand.
- Customer-managed keys (CMKs) — you control the policy. You can disable them, rotate them, share across accounts. Use these for anything sensitive.
- SSE-KMS for S3, EBS, RDS, etc. — tells the service to encrypt with a specific KMS key. The service calls KMS on your behalf; you control access via the key policy.
- Envelope encryption — KMS encrypts a data key; the data key encrypts the data. Standard pattern; means KMS never sees the actual data, just the key wrapping it.
Defaults to flip on a new account
If you inherit an AWS account and have one afternoon to harden it, these are the levers that move the most:
- S3 Block Public Access at the account level — all four flags.
- Default EBS encryption on (Account Attributes → Data protection).
- IMDSv2 required for every EC2 instance (so the IMDS-via-SSRF path is closed).
- CloudTrail on in every region with a multi-region trail to a locked S3 bucket in a separate account.
- GuardDuty enabled in every region (cheap; broad threat detection).
- Security Hub with AWS Foundational Security Best Practices and CIS benchmarks enabled.
- Root account: hardware MFA, no access keys, used only for billing.
AWS network and data security is largely a story about which defaults are correct, and which require you to flip a switch. Modern AWS is dramatically safer than 2017 AWS — most footguns now require you to opt in rather than out — but the legacy defaults still bite teams who built their accounts when the defaults were different.
The recurring lesson: turn on the account-level guardrails, then let the team build inside them. BPA, default encryption, IMDSv2, CloudTrail, GuardDuty — these are not advanced features. They are the floor.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Amazon Web Services. (n.d.-a). Block public access to your Amazon S3 storage. Amazon S3 User Guide. https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
- Amazon Web Services. (n.d.-b). Comparison of security groups and network ACLs. Amazon VPC User Guide. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html
- Amazon Web Services. (n.d.-c). What is AWS Key Management Service? AWS Key Management Service Developer Guide. https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
- Amazon Web Services. (2023, April 28). Amazon S3 now enables block public access and disables access control lists for all new buckets by default. AWS News Blog. https://aws.amazon.com/blogs/aws/amazon-s3-update-block-public-access-and-disable-access-control-lists-by-default/