Week 3: AWS Security Cloud Foundations.

I am continuing to work through AWS Cloud Security Foundations, and this week's module shifted from identity and access management into the network itself: Securing Your Infrastructure. If Module 3 was about who gets to do what, this one is about building the walls, gates, and checkpoints around where everything actually lives.

The module opens with the three-tier web application AWS uses: a presentation layer, a business logic layer, and a data layer, all sitting inside a Virtual Private Cloud (VPC) spread across two Availability Zones. That structure is what almost everything else in the module gets hung on.

A VPC is a virtual network that's logically isolated from everyone else's, dedicated to your own account, tied to a single AWS Region, but able to stretch across multiple Availability Zones for redundancy. Once you have one, you carve it into subnets which are ranges of IP addresses, each pinned to a single Availability Zone, and each classified as public or private depending on whether it needs direct internet access.

Getting traffic in and out is where internet gateways and NAT gateways come in, and I'd been fuzzy on the difference until this module laid it out plainly. An internet gateway is what you attach to the VPC itself to let traffic reach the internet at all; it also handles the network address translation for any instance that's been given a public IPv4 address. A NAT gateway solves a narrower problem: it lets instances sitting in a private subnet reach the internet (for something like patching) without ever being reachable from the outside. It has to live in a public subnet, needs its own Elastic IP, and the private subnet's route table has to be pointed at it afterward.

The CIDR math was a good refresher too. A VPC can be as large as a /16 block (65,536 addresses) or as small as a /28 (16 addresses), and whatever size you pick for a subnet, AWS quietly reserves five of those addresses for itself: the network address, the VPC router, DNS resolution, a reserved-for-future-use address, and the broadcast address. So a /24 subnet with 256 addresses on paper only ever gives you 251 you can actually assign.

One detail I liked: public IP addresses are dynamic, i.e., stop and restart an instance and you get a new one while an Elastic IP is static and stays tied to your account until you release it (and you get charged if you leave one sitting unassigned). There is also a small forensics trick tucked into the elastic network interface section: you can attach a second network interface to an EC2 instance and move it over to a dedicated forensic instance to keep tracking something suspicious without touching the original instance's primary interface.

Route tables tie it together: every one carries a local route for traffic inside the VPC that you can't delete, and any subnet that isn't explicitly tied to its own route table just falls back to the VPC's main route table by default.

The real centerpiece of the module, though, is the contrast between security groups and network ACLs, and it's a nice echo of the identity-based versus resource-based split from last module. A security group sits at the instance level and is stateful — if your instance sends a request out, the reply is let back in automatically, regardless of what the inbound rules say. By default it denies all inbound traffic and allows all outbound traffic, and it only ever works with "allow" rules. A network ACL sits a level up, at the subnet, and it's stateless — inbound and outbound traffic are each checked against their own separate rule set, so a reply to traffic you let in doesn't get a free pass. NACL rules are numbered and evaluated in order, and unlike security groups, you can write explicit "deny" rules, with a mandatory, unremovable final rule that drops anything not already matched.

Elastic Load Balancing spreads traffic across targets, runs health checks, and comes in Application, Network, and Classic varieties. Two protection details stood out: ELB can terminate TLS right at the load balancer instead of making every instance behind it handle encryption on its own, and if SSE-S3 is turned on for the access-log bucket, ELB encrypts every log file before it's stored.

Protecting compute resources introduced Amazon Inspector, which runs automated security assessments against EC2 instances and applications and flags vulnerabilities before and after deployment, leaning on the same Systems Manager agent that gives visibility and patch control across a whole fleet.

The lab attached to this module has you working through the VPC and subnet settings on an existing environment, testing HTTP access, tightening it first by IP address and then by referencing a security group instead (which scales better), adding a network ACL restriction on top, and finally reaching a private-subnet instance two different ways: through a bastion host over SSH, and directly through Session Manager. I have run, rather, walked through it and it was such an enlightening exercise.

And that is onto the next!