2.3 - Secure, decoupled application design (WAF, Secrets Manager, VPC endpoints)
AWS Solutions Architect Professional objective 2.3 covers designing secure, serverless, and decoupled new solutions. You run containers without managing hosts on the AWS Fargate launch type, let authenticated mobile users upload straight to S3 with a Cognito identity pool that issues scoped temporary credentials, and protect a public REST API with an AWS WAF web ACL plus usage plans and API keys for per-client throttling. A microservice fetches a database password at runtime from AWS Secrets Manager with automatic rotation, and an app in a private subnet with no internet route reaches S3 and DynamoDB through VPC gateway endpoints. End-to-end encryption uses an HTTPS listener forwarding to an HTTPS target group, spiky relational load fits Aurora Serverless v2, an IoT pipeline pairs Firehose for buffered S3 delivery with Kinesis Data Streams for replayable multi-read, and geolocation routing pins German users to eu-central-1. Expect scenarios about serverless containers, runtime secrets, or private service access, and ask which secure design fits.
Containers with no hosts to manage = AWS Fargate. Fetch and auto-rotate a DB password at runtime = Secrets Manager rotation. Private subnet reaches S3/DynamoDB with no internet route = VPC gateway endpoints.
Practice questions
1. Microservices in a VPC must call Amazon S3 and DynamoDB with no traffic leaving the AWS network and no NAT costs. What should the architect use?
- Interface VPC endpoints (PrivateLink) with an Elastic IP each
- A NAT gateway in each AZ with routes to S3 and DynamoDB
- Gateway VPC endpoints for S3 and DynamoDB (correct answer)
- A proxy fleet that signs requests and forwards them publicly
S3 and DynamoDB are reached privately through gateway VPC endpoints, which add prefix-list routes and incur no hourly/data charges or NAT. Interface endpoints exist for many services but S3/DynamoDB specifically use gateway endpoints; NAT would send traffic out and cost money.
2. A new public web app runs behind an Application Load Balancer. Architects want to centrally enforce a common WAF rule set across this and every future ALB and CloudFront distribution in the organization, automatically. Which service should the design use?
- A single AWS WAF web ACL that every team is asked to manually attach to each resource
- Amazon GuardDuty threat lists exported to each account and referenced by security groups
- AWS Firewall Manager policies applied across the AWS Organizations member accounts (correct answer)
- An AWS Config rule that flags any load balancer created without a web ACL attached
Firewall Manager applies and auto-remediates WAF web ACLs org-wide, including on resources created later, from a single policy. Manual attachment does not scale and is easy to forget; GuardDuty lists are for detection, not inline filtering; a Config rule only detects and reports drift, it does not enforce the rules.
3. A new gaming API on a Network Load Balancer is a likely DDoS target. Design goals: absorb large layer 3/4 floods, get a dedicated response team, and receive cost protection for scaling caused by an attack. What should the architecture include?
- Only the always-on protections that AWS Shield Standard provides to all customers by default
- AWS Shield Advanced enabled on the endpoint with the SRT engaged and cost protection (correct answer)
- A larger NLB instance type with connection draining and generous idle timeouts configured
- A fleet of NAT gateways in front of the NLB to absorb and rate-limit inbound flood traffic
Shield Advanced adds enhanced layer 3/4 mitigation, access to the Shield Response Team (SRT), and cost protection that refunds scaling charges from a covered attack. Shield Standard lacks the SRT and cost protection; NLBs have no instance type to resize; NAT gateways are for outbound traffic and cannot absorb inbound DDoS.
4. A team is containerizing a web API and wants to run it on Amazon ECS without provisioning, patching, or scaling any EC2 hosts, paying only for the vCPU and memory each task uses. Which launch type fits?
- The EC2 launch type with a managed Auto Scaling group of container instances
- The EC2 launch type using an ECS-optimized AMI and cluster capacity providers
- An external launch type running the tasks on registered on-premises servers
- The AWS Fargate launch type running tasks serverlessly (correct answer)
Fargate runs ECS tasks without any EC2 hosts to manage and bills per task vCPU and memory, matching the no-server, pay-per-task requirement. All EC2 launch options still require you to own and scale the underlying instances, and the external type targets your own hardware.
5. An organization has invested heavily in Kubernetes tooling and wants that ecosystem on AWS, but its platform team refuses to manage worker nodes for a set of bursty, short-lived jobs. Which approach honors both constraints?
- Run a self-managed Kubernetes cluster on EC2 across multiple Availability Zones
- Use Amazon EKS with Fargate profiles so those pods run without managed nodes (correct answer)
- Migrate the jobs off Kubernetes entirely and rewrite them as plain EC2 batch scripts
- Use Amazon ECS on EC2 with a cluster Auto Scaling group for the bursty jobs
EKS keeps the Kubernetes API and tooling the team relies on, and Fargate profiles schedule matching pods onto serverless capacity so no worker nodes are managed for those bursty jobs. Self-managed or ECS-on-EC2 still means running nodes, and abandoning Kubernetes discards the existing investment.
6. An ECS batch workload is fault-tolerant and cost-sensitive, but a small portion of tasks must always keep running to serve latency-sensitive requests. The team wants ECS to place most tasks on cheap interruptible capacity and a baseline on stable capacity. What should they configure?
- Only Fargate Spot capacity for every single task to minimize the total compute bill
- Only On-Demand EC2 instances so no task is ever interrupted at all
- A single Reserved Instance purchase covering the entire batch fleet
- A capacity provider strategy mixing Fargate Spot with a Fargate on-demand base (correct answer)
A capacity provider strategy lets you set a base of on-demand Fargate for the always-on latency-sensitive tasks and a weight that sends the bulk to cheaper Fargate Spot, balancing cost and reliability. All-Spot risks interrupting the critical baseline, all-On-Demand wastes money, and a single RI does not steer ECS task placement.