Securing Workloads: VPC Design, Security Groups vs NACLs, WAF and Shield

Network segmentation is the first decision in any secure workload design, and on AWS it is expressed through subnets and route tables. A subnet is not inherently public or private — its route table makes it one. A public subnet has a route to an internet gateway, so resources with public IPs in it are reachable from the internet. A private subnet has no internet gateway route; instead, its outbound internet traffic goes to a NAT gateway that sits in a public subnet, giving instances outbound access — for patches, package downloads, external APIs — while remaining unreachable from outside, because NAT permits only return traffic for connections initiated from inside. An isolated subnet takes the last step: no internet gateway route and no NAT route, so nothing in it can reach or be reached from the internet at all — the right home for databases that only ever talk to the application tier.

The design rule the exam rewards is minimal exposure: only components that must accept traffic from the internet belong in public subnets — load balancers, NAT gateways, and little else. Application servers sit behind the load balancer in private subnets; data stores sit in private or isolated subnets. When a scenario mentions "EC2 instances with public IP addresses running the application tier" or "an RDS database in a public subnet," that placement is the flaw, and the correct answer moves the tier inward and fronts it properly.

Route tables also encode intent you can read in questions. A subnet whose route table sends 0.0.0.0/0 to an internet gateway is public by definition, whatever the diagram calls it. Private subnets in multiple Availability Zones each need a NAT path — and for high availability, the standard design puts one NAT gateway per AZ so a zone failure does not sever outbound access for the survivors.

Expect the exam to probe this as placement and reachability logic: which subnet does each tier belong in, why can or can't a resource be reached, and what single route-table change exposes or protects a tier. If you can classify any subnet from its routes alone, these questions become fast points.

Two traffic filters operate inside a VPC, at different layers and with different rules, and telling them apart is among the most reliably tested facts on SAA-C03. A security group attaches to a resource's elastic network interface — an EC2 instance, an RDS database, a load balancer — and is stateful: if inbound traffic is allowed, the response is automatically allowed out, with no outbound rule needed. Security groups contain allow rules only; anything not allowed is denied, and there is no way to write an explicit deny. All rules are evaluated together — there is no rule ordering.

A network ACL attaches to a subnet and filters traffic entering or leaving it. It is stateless: return traffic must be explicitly allowed, which is why NACL configurations must open ephemeral port ranges for responses — a detail questions use to explain mysteriously broken connections. NACLs support both allow and deny rules, evaluated in rule-number order with the first match winning. That deny capability defines their role: a NACL is the tool when you must explicitly block something — a specific malicious IP address or CIDR range — because a security group simply cannot express a deny.

The design technique the exam loves is referencing security groups by ID. Instead of allowing the application tier's subnet CIDR into the database security group, you allow inbound MySQL from the application tier's security group itself. Membership becomes dynamic: any instance carrying the app-tier security group can reach the database, and nothing else can — no CIDR maintenance as instances scale in and out, no accidental inclusion of other resources sharing the subnet. Chained tier to tier (ALB SG → app SG → DB SG), this builds least-privilege networking that survives Auto Scaling.

Decision rules for the exam: filtering for a specific resource, or allowing by relationship between tiers — security group. Explicitly denying an IP or applying a coarse guardrail to an entire subnet — network ACL. And when a scenario says traffic reaches an instance but responses never come back, check statefulness: a security group would have allowed the reply, so the culprit is a stateless NACL missing its outbound (or ephemeral-port) rule.

By default, calls from your VPC to AWS services like S3 or DynamoDB resolve to public endpoints, which means instances in private subnets need a NAT gateway path just to reach AWS's own services. VPC endpoints remove that dependency: traffic to the service travels privately over the AWS network, never touching the internet, an internet gateway, or a NAT gateway. Scenarios that say "traffic to Amazon S3 must not traverse the public internet" or "instances must access DynamoDB without a NAT gateway" are endpoint questions before you finish reading them.

There are two kinds, and the split is a standing exam decision. A gateway endpoint is a route-table target: you add it to the subnet's route table, and traffic to the service flows through it. Gateway endpoints exist for exactly two services — Amazon S3 and DynamoDB — and they carry no charge. An interface endpoint (powered by AWS PrivateLink) is an elastic network interface with a private IP placed in your subnet, protected by a security group like any ENI; it supports most other AWS services, and it bills per hour and per GB processed.

The decision rule: for S3 and DynamoDB from inside the VPC, use the gateway endpoint — it is free and purpose-built, and a question qualified with MOST cost-effective makes the interface option a deliberate distractor. Interface endpoints earn their keep everywhere else: private access to SQS, Secrets Manager, Systems Manager, KMS, and the rest — and in the narrower cases where a gateway endpoint cannot reach, such as accessing S3 from on premises over VPN or Direct Connect, since gateway endpoints only serve routes within their own VPC.

Endpoints also carry endpoint policies — resource-style policies restricting what can be done through them, such as limiting an S3 gateway endpoint to specific buckets. Combined with a bucket policy that requires access via the endpoint, this yields the fully private S3 pattern: data reachable only from inside the VPC, over private routes, to approved buckets. Expect endpoint questions to be qualified by cost or by "no internet traversal," and answer by service name first, economics second.

Assemble the pieces into the architecture SAA-C03 assumes as its default: a web application across two Availability Zones with web, application, and database tiers. The VPC spans both AZs with three subnet tiers in each — six subnets total.

Public subnets (tier 1) hold exactly two things: an internet-facing Application Load Balancer and one NAT gateway per AZ. The ALB's security group allows inbound 443 from 0.0.0.0/0 — it is the single designed entry point for user traffic. The route table sends 0.0.0.0/0 to the internet gateway.

Private subnets (tier 2) hold the application instances in an Auto Scaling group. Their security group allows inbound only from the ALB's security group, on the application port — referenced by ID, so scaling events change nothing. Instances have no public IPs; their route table sends 0.0.0.0/0 to the NAT gateway in their own AZ, giving them outbound access for patches and external APIs while remaining unreachable from the internet. Calls to S3 and DynamoDB flow through free gateway endpoints in the route table instead of the NAT path — cheaper and fully private.

Isolated subnets (tier 3) hold the RDS database (multi-AZ). The DB security group allows inbound only from the application tier's security group on the database port. The route table has no internet gateway or NAT route at all: the database cannot initiate or receive internet traffic under any misconfiguration short of re-routing the subnet. NACLs stay at their defaults unless a requirement demands an explicit deny — the security-group chain is the working control.

Administrative access is where an older pattern gets retired. The classic approach — a bastion host in the public subnet, port 22 open, SSH keys distributed — is exposed infrastructure that must itself be patched, monitored, and key-managed. The modern answer is AWS Systems Manager Session Manager: the SSM agent on each instance connects outbound to the service, so administrators start shell sessions through IAM-authenticated, fully logged channels with no inbound ports open, no bastion host, and no SSH keys. When a question asks for instance access that is MOST secure or LEAST overhead — or explicitly "without opening inbound ports" — Session Manager beats the bastion every time; hardening the bastion is the distractor.

When the users in a scenario are customers of an application rather than employees of the company, the identity service is Amazon Cognito — not IAM, and not IAM Identity Center, which serves the workforce. Cognito has two components with confusable names, and distinguishing them is a recurring exam point.

A user pool is a user directory that handles authentication: sign-up, sign-in, password policies, MFA, and account recovery for your app's users, plus social and enterprise sign-in through external identity providers such as Google, Facebook, Apple, or a SAML/OIDC IdP. After sign-in, the user pool issues JSON Web Tokens the application uses to prove identity — typically to authorize API calls, and Cognito user pools integrate directly with API Gateway and ALB as an authorizer. If the requirement is "add sign-up and sign-in to a web or mobile app" or "let users log in with their social accounts," the answer is a user pool.

An identity pool handles authorization to AWS itself: it exchanges an identity token — from a user pool, a social provider, or a SAML IdP — for temporary AWS credentials via STS, letting the app call AWS services directly under an IAM role you define. Identity pools also support unauthenticated (guest) identities, granting anonymous users a deliberately narrow role. If the requirement is "the mobile app must upload images to S3" or "grant guest users limited access to AWS resources," the answer is an identity pool; the alternative — shipping access keys inside the app — is the anti-pattern being tested.

The compressed rule: user pool = who are you (authentication, JWTs); identity pool = what can you touch in AWS (temporary credentials, IAM roles). Real architectures often chain them — user pool authenticates, identity pool trades the token for credentials — and answer options exploit the naming: a question about signing in to an application answered with "identity pool," or S3 access from a mobile app answered with "user pool," is wrong on this one distinction. Read for what the user ultimately needs: an app session, or AWS credentials.

A large share of Task 1.2 questions name a threat and ask which service answers it. The layer of the attack picks the service.

DDoS splits by OSI layer. AWS Shield Standard defends against common network and transport layer (layer 3/4) attacks — SYN floods, UDP reflection — automatically and at no cost for every AWS customer. AWS Shield Advanced is the paid tier: enhanced protections for higher-volume and more sophisticated attacks, near-real-time visibility, 24/7 access to the Shield Response Team, and cost protection against scaling charges incurred during an attack. When a scenario demands DDoS response support or protection from attack-driven bills, Shield Advanced is being described. AWS WAF operates at layer 7: a web application firewall attached to CloudFront, an Application Load Balancer, API Gateway, or AppSync, filtering HTTP(S) requests with managed and custom rules — SQL injection, cross-site scripting, IP reputation lists, geographic match, and rate-based rules that throttle abusive clients. "SQL injection" or "filter malicious web requests" means WAF, full stop; Shield does not inspect HTTP, and WAF does not stop SYN floods.

Detection services split by what they watch. Amazon GuardDuty is intelligent threat detection for the account and workloads: it continuously analyzes CloudTrail events, VPC Flow Logs, and DNS query logs for signals like cryptocurrency-mining traffic, credential exfiltration, or API calls from known-malicious hosts — with nothing to install. Amazon Macie watches data, not behavior: it uses machine learning and pattern matching to discover and classify sensitive data in S3 — PII, credentials, financial records — and flags buckets that are public or unencrypted. "Detect compromised instances or anomalous account activity" is GuardDuty; "identify where PII is stored in S3" is Macie.

Exam answers follow this table almost mechanically — the traps are cross-layer swaps: WAF offered for a layer 3 flood, GuardDuty offered for finding PII, Macie offered for detecting intrusions. Match the layer and the watched surface, and the distractors eliminate themselves.

The exam's baseline for application credentials is absolute: no secrets in code, configuration files, environment files checked into repositories, or AMIs. Two habits satisfy it. For AWS API access, compute gets IAM roles — instance profiles, Lambda execution roles, ECS task roles — so there are no access keys to store at all. For everything else — database passwords, third-party API keys, certificates — the application fetches the secret at runtime from a managed store, over an interface endpoint if it lives in a private subnet.

AWS Secrets Manager is purpose-built for secrets. Its defining feature is automatic rotation: managed, scheduled rotation with native integration for RDS, Redshift, and DocumentDB credentials, and Lambda-backed rotation for anything else. Secrets are encrypted with KMS, retrieval is IAM-controlled and audited via CloudTrail, and secrets support resource policies for cross-account access. It is priced per secret per month plus per API call.

AWS Systems Manager Parameter Store is a general configuration store that also holds secrets as SecureString parameters, KMS-encrypted. The standard tier is free, which makes it the MOST cost-effective answer for configuration values and for secrets that do not need managed rotation — Parameter Store has no native rotation; rotating a SecureString is your own scheduled job. It is also the natural home for plain configuration — feature flags, endpoints, AMI IDs — that Secrets Manager would be overkill for.

The decision rule: the words "automatic rotation" (or cross-account secret sharing) select Secrets Manager; "most cost-effective" storage of configuration or static secrets selects Parameter Store. Scenario shapes to expect: a database password hard-coded in application source — move it to Secrets Manager with rotation enabled and grant the instance role permission to read it; an application needing hundreds of configuration values cheaply — Parameter Store. A subtle trap inverts the qualifier: choosing Secrets Manager "because it is more secure" when the requirement was cost and no rotation was demanded — both stores encrypt with KMS and gate access with IAM; the differentiators are rotation, cross-account sharing, and price.

Hybrid architectures need a secure path between on-premises networks and the VPC, and Task 1.2 tests the two options plus their combination. AWS Site-to-Site VPN establishes IPsec-encrypted tunnels over the public internet between your customer gateway device and a virtual private gateway (or transit gateway) on the AWS side. It is quick to set up, inexpensive, and encrypted end to end by construction — but it rides the internet, so bandwidth and latency are variable. Each VPN connection provides two tunnels for redundancy across AWS endpoints.

AWS Direct Connect is a dedicated private physical connection from your network into AWS. It bypasses the internet entirely, delivering consistent latency and high bandwidth — the choice when scenarios emphasize large steady data transfer or predictable network performance. The security nuance the exam checks: Direct Connect traffic is private, but it is not encrypted by default. Private does not mean encrypted, and compliance-driven questions exploit exactly that gap.

When a requirement says data between the data center and AWS must be encrypted in transit and Direct Connect is in the picture, the standard answer is to run a Site-to-Site VPN over the Direct Connect link — IPsec encryption riding the dedicated connection, combining private consistent transport with encryption. This composite is a classic correct answer precisely because neither service alone satisfies both halves: VPN alone lacks Direct Connect's performance, and Direct Connect alone lacks encryption. A related pairing uses VPN as a failover path for a Direct Connect link when the requirement is connectivity that survives the dedicated line failing — cheaper than a second Direct Connect connection, at reduced performance during failover.

Read these questions by extracting two axes: performance/consistency (favors Direct Connect) and encryption/compliance (requires IPsec — VPN, alone or over Direct Connect). Cost-sensitive, quick-to-establish, encryption-required scenarios resolve to plain Site-to-Site VPN; high-bandwidth private connectivity resolves to Direct Connect; both at once resolve to VPN over Direct Connect. Options claiming Direct Connect "is encrypted because it is private" are the designated trap.

Scenario 1. A company runs a two-tier application: EC2 instances with public IP addresses host the web application, and an RDS MySQL database runs in the same public subnet, its security group allowing inbound 3306 from 0.0.0.0/0 "so the app can always reach it." Security requires the database to be inaccessible from the internet with the LEAST disruptive redesign. What do you recommend?

Reasoning: Two exposures compound here: the database's subnet placement and its wide-open security group. The fix follows the reference architecture. Move the RDS instance into a private (ideally isolated) subnet with no internet gateway or NAT route, and replace the 0.0.0.0/0 rule with an inbound rule allowing 3306 from the web tier's security group by ID. Now reachability derives from the security-group relationship, not from IP math, and it survives instance scaling. Options that keep the database public but "tighten the CIDR," or that reach for a NACL while leaving the SG open, reduce the exposure without eliminating it — the subnet move plus SG reference is the design-level answer. Fronting the web tier with an ALB and removing its public IPs is the natural follow-on the fuller redesign options describe.

Scenario 2. A public-facing application behind an Application Load Balancer is being disrupted by two simultaneous problems: volumetric floods at the network layer, and requests containing SQL injection attempts reaching the application. The company also wants 24/7 access to AWS DDoS experts during attacks and protection against Auto Scaling costs incurred while absorbing one. Which combination addresses all requirements?

Reasoning: Decompose by layer. The volumetric layer 3/4 floods are Shield's territory — and the two extra requirements, a response team and cost protection, are the exact differentiators of Shield Advanced over the free Standard tier. SQL injection is a layer 7 payload problem no amount of Shield addresses: it needs AWS WAF attached to the ALB (or a CloudFront distribution in front of it) with SQL-injection managed rules, plus a rate-based rule for abusive clients. The correct combination is Shield Advanced + WAF; single-service options fail one layer each, and GuardDuty in an option is a detector, not a blocker — it would report the attack, not stop it.

Scenario 3. Instances in a private subnet process confidential objects from S3. Compliance requires that this traffic never traverse the public internet, and finance wants the NAT gateway data-processing charges gone. The team also SSHes to these instances through a bastion host the auditors have flagged. What changes satisfy everyone?

Reasoning: S3 from inside a VPC with "no internet" and "lower cost" in the same sentence is the signature of a gateway VPC endpoint — free, private, added to the subnet's route table; an interface endpoint would work but fails the cost qualifier, and the S3 traffic stops flowing through the NAT gateway entirely. For the auditors, replace the bastion with SSM Session Manager: IAM-authenticated, logged sessions with no inbound ports and no keys — with an interface endpoint for Systems Manager if the subnet must stay fully offline. The pattern to internalize: each named constraint (no internet, cost, audited access) maps to one specific mechanism, and the correct option is the one that hits all three without adding exposed infrastructure.