← Design Secure Architectures

▶ Play from here · 260 min

Starts this lesson and continues through 23 more to the end of certification prep.

Network security controls and where they sit

Why this lesson matters

Task statement 1.2 lists, under skills: "Designing VPC architectures with security components (for example, security groups, route tables, network ACLs, NAT gateways)" and "Determining network segmentation strategies (for example, using public subnets and private subnets)".

Domain 1's networking questions are not really networking questions. They are placement questions. Every control in this lesson sits at exactly one point on the traffic path, and the exam tests whether you know which point. Put the control in the wrong place and it does nothing — which is worse than not having it, because you believe you're protected.

So the frame for this lesson is a single sentence: what path does the packet take, and what sits on that path?

Security groups vs network ACLs — the table

This is the highest-yield table in Domain 1. It is reproduced verbatim from Infrastructure security in Amazon VPC (verified 2026-09-21):

Five rows, five exam questions. The two that decide most of them:

Stateful vs stateless. A security group that allows inbound port 443 automatically allows the response out. A network ACL does not — you must also allow the outbound ephemeral port range, or the response is dropped and the connection hangs. "TCP handshake completes but nothing comes back" is almost always a stateless NACL missing its return rule.

Allow-only vs allow-and-deny. If a requirement says block a specific IP address, a security group cannot do it — "You can specify allow rules, but not deny rules." (Security group rules) A network ACL can. This is the one thing NACLs are uniquely good for, and it is why they exist on the exam at all.

AWS's own guidance on which to reach for first:

"Use security groups as the primary mechanism for controlling network access to your VPCs. When necessary, use network ACLs to provide stateless, coarse-grain network control. Security groups are more versatile than network ACLs, due to their ability to perform stateful packet filtering and create rules that reference other security groups. Network ACLs can be effective as a secondary control (for example, to deny a specific subset of traffic) or as high-level subnet guard rails. Also, because network ACLs apply to an entire subnet, they can be used as defense-in-depth in case an instance is ever launched without the correct security group."

That last sentence is the real argument for NACLs: they catch the instance somebody launched with the wrong security group.

Security group defaults and behaviours

All verbatim from Security group rules, verified 2026-09-21:

• "When you first create a security group, it has no inbound rules. Therefore, no inbound traffic is allowed until you add inbound rules to the security group."
• "When you first create a security group, it has an outbound rule that allows all outbound traffic from the resource. You can remove the rule and add outbound rules that allow specific outbound traffic only. If your security group has no outbound rules, no outbound traffic is allowed."
• "When you associate multiple security groups with a resource, the rules from each security group are aggregated to form a single set of rules."
• "When you add, update, or remove rules, your changes are automatically applied to all resources associated with the security group."

Security group referencing is the pattern the exam wants you to recognise. Instead of a CIDR block, the source of a rule can be another security group's ID. AWS's worked three-tier example:

• "Add rules to the load balancer security group to allow HTTP and HTTPS traffic from the internet. The source is 0.0.0.0/0."
• "Add rules to the security group for the web servers to allow HTTP and HTTPS traffic only from the load balancer. The source is the security group for the load balancer."
• "Add rules to the security group for the database servers to allow database requests from the web servers. The source is the security group for the web servers."

That chain — internet → ALB SG → web SG → db SG — is the canonical secure three-tier answer. If an option offers CIDR ranges where a security group reference would do, it is usually the weaker answer, because CIDRs don't follow instances when they scale.

Referencing has boundaries worth knowing: you can reference a security group in an inbound rule if the groups are in the same VPC, or there's a peering connection, or there's a transit gateway. For outbound rules, only same VPC or peering — not transit gateway.

Rule-count arithmetic, which catches people at scale:

⚠️ Two limitations that are genuinely surprising.

"Security groups cannot block DNS requests to or from the Route 53 Resolver" — the VPC+2 address. To filter DNS you need Route 53 Resolver DNS Firewall. A question about blocking DNS exfiltration has exactly one right answer and it isn't a security group.

And with a middlebox appliance in the path: "If you reference the security group of the other instance as the source, this does not allow traffic to flow between the instances." You must reference the private IP or the subnet CIDR instead. Security group referencing breaks when routing sends traffic through an appliance.

Finally, stale rules: if you reference a security group in a peer or shared VPC and that group or the peering connection is deleted, "the rule is marked as stale". Stale rules are a real audit finding and you delete them like any other rule.

NAT gateways — outbound only, and AZ-bound

From NAT gateways, verified 2026-09-21:

"You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services can't initiate a connection with those instances."

The two connectivity types, quoted:

⚠️ The private NAT gateway silently drops internet-bound traffic. AWS: "You can attach an internet gateway to a VPC with a private NAT gateway, but if you route traffic from the private NAT gateway to the internet gateway, the internet gateway drops the traffic." Dropped, not rejected. That's a debugging session you don't want to have unprepared.

The rule that defines the whole service: "Connections must always be initiated from within the VPC containing the NAT gateway." A NAT gateway is never an inbound path. If a question asks how to let the internet reach private instances, a NAT gateway is always wrong — that's a load balancer.

On IPv6: "A NAT gateway is for use with IPv4 or IPv6 traffic (using DNS64 and NAT64). Another option for enabling outbound-only internet communication over IPv6 is using an egress-only internet gateway." So egress-only internet gateway is the IPv6-native answer, and it is a distractor worth recognising in both directions.

⚠️ I did not verify NAT gateway bandwidth figures, per-AZ placement or security-group associability from a fetched page in this pass. The commonly repeated "45 Gbps, one per AZ for HA, no security groups" figures are not sourced here — read nat-gateway-basics.html before quoting them. Note also that AWS now documents "Regional NAT gateways for automatic multi-AZ expansion", which changes the old "one per AZ" advice; check that page before answering a HA question from memory.

Keeping traffic off the internet: PrivateLink and endpoints

The value proposition, verbatim from What is AWS PrivateLink?:

"AWS PrivateLink is a highly available, scalable technology that you can use to privately connect your VPC to services and resources as if they were in your VPC. You do not need to use an internet gateway, NAT device, public IP address, Direct Connect connection, or AWS Site-to-Site VPN connection to allow communication with the service or resource from your private subnets."

And on the traffic path — the sentence that answers most compliance questions:

"Traffic between a VPC endpoint and an endpoint service or resource stays within the AWS network, without traversing the public internet." — PrivateLink concepts

The endpoint types, from the same page:

⚠️ Gateway endpoints are S3 and DynamoDB only, and they are not PrivateLink. That single quote settles a lot of exam questions. Interface endpoints are ENIs with private IPs and DNS; gateway endpoints are route table entries. Which means a gateway endpoint is reachable only from within the VPC whose route table points at it — it is not reachable from on-premises over VPN or Direct Connect, whereas an interface endpoint's private IP is. If the requirement says "our data centre must reach S3 privately over Direct Connect", the answer is an interface endpoint, not a gateway endpoint.

⚠️ I did not verify gateway-endpoint pricing in this pass (the page fetch returned no content). The widely repeated "gateway endpoints are free, interface endpoints are charged hourly plus per GB" is unverified here — check the AWS PrivateLink pricing page before relying on it in a cost question.

Endpoint policies are the access control on top: "A VPC endpoint policy is an IAM resource policy that you attach to a VPC endpoint. It determines which principals can use the VPC endpoint to access the endpoint service. The default VPC endpoint policy allows all actions by all principals on all resources over the VPC endpoint."

That default matters. Creating an endpoint does not restrict anything by itself — it changes the path, not the permissions. To stop data going to buckets outside your organization, you write an endpoint policy with an aws:PrincipalOrgID or resource condition. Two separate controls, two separate design decisions.

Hybrid connections

The exam guide asks for "Securing external network connections to and from the AWS Cloud (for example, VPN, AWS Direct Connect)". What AWS states on the VPC infrastructure-security page:

"Use AWS Virtual Private Network or Direct Connect to establish private connections from your remote networks to your VPCs."

And on monitoring, both items from the same page's control list: "Use VPC Flow Logs to monitor the traffic that reaches your instances" and "Use AWS Network Firewall to protect the subnets in your VPC from common network threats."

⚠️ I did not fetch the Site-to-Site VPN or Direct Connect pages in this pass, so this lesson makes no claim about VPN tunnel counts, Direct Connect port speeds, MACsec, or the encryption status of a Direct Connect link. That last one is the exam-relevant gap and worth closing yourself before the exam: read docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html and docs.aws.amazon.com/directconnect/latest/UserGuide/.

Check yourself

1. You must block a single abusive IP address from reaching your web tier. Security group or NACL?
2. A NACL allows inbound 443. Connections hang. What's missing?
3. A requirement says on-premises servers must reach S3 over Direct Connect without traversing the internet. Gateway endpoint or interface endpoint?
4. You create an S3 gateway endpoint. Can users still copy data to a bucket in someone else's account?
5. Private instances need outbound internet for OS patches. Internet-facing ALB, NAT gateway, or egress-only internet gateway?

Answers

1. NACL. Security groups support "allow rules, but not deny rules". Blocking a specific source requires a deny rule, so it must be a network ACL.
2. The outbound rule for the return traffic (the ephemeral port range). NACLs are stateless — "Return traffic … must be explicitly allowed".
3. Interface endpoint. A gateway endpoint works through the VPC route table, so it serves traffic originating in that VPC. An interface endpoint presents a private IP via an ENI, which on-premises networks can reach over Direct Connect.
4. Yes, by default. "The default VPC endpoint policy allows all actions by all principals on all resources over the VPC endpoint." An endpoint changes the path, not the permissions — add an endpoint policy.
5. NAT gateway for IPv4. (Egress-only internet gateway is the IPv6 equivalent; an internet-facing ALB is an inbound path and doesn't give instances outbound access.)

Teaching this section

• Draw the packet path first, then hang controls on it. Internet → IGW → route table → NACL → security group → ENI. Every control in this lesson lives at exactly one of those points, and learners who can draw the path stop guessing.
• Demo: allow inbound 443 on a NACL and not the ephemeral return range, then curl the instance and watch it hang. Five minutes, and nobody forgets statefulness afterwards.
• Best discussion prompt: "Our security group blocks port 53, so we can't be exfiltrating over DNS." Let the room believe it, then read them the Route 53 Resolver limitation.
• Watch for: learners treating a NAT gateway as a firewall. It's an address translator with a one-directional property; it filters nothing.
• Timing: 30 min presented, 20 for the three-tier security group exercise. Make them write the SG-referencing chain by hand, not with CIDRs.