Design for New Solutions
New-solution questions ask you to select resilient, secure, and cost-aware architectures from requirements. Anchor decisions in the Well-Architected pillars and the workload's availability, RPO, and RTO targets. For compute, know when to choose EC2, ECS/EKS, Lambda, or Fargate, and how Auto Scaling policies and load balancer types differ. For storage, match access patterns to S3 storage classes, EBS volume types, and EFS throughput modes. For databases, distinguish RDS Multi-AZ (availability, synchronous standby) from read replicas (read scaling, asynchronous), and know DynamoDB global tables and on-demand capacity.
Decoupling and resilience
Design for failure using multi-AZ deployments, queues (SQS) for buffering, and events (EventBridge) for routing. Understand idempotency, dead-letter queues, and backoff with jitter. For security, apply least privilege, KMS key policies, encryption in transit and at rest, and private networking via VPC endpoints.
Traps to watch
- Confusing Multi-AZ failover with read scaling; Multi-AZ standby does not serve reads.
- Choosing Lambda for long-running or stateful workloads beyond its execution limits.
- Forgetting that S3 Transfer Acceleration and multipart upload solve different problems.
- Ignoring that a single NAT gateway is a single-AZ dependency.
Worked example
An order service must survive an AZ failure, absorb bursts to 10,000 messages per minute, and never lose an order. Put the API behind an Application Load Balancer across two AZs, write orders to an SQS standard queue, and process with consumers that delete messages only after durable writes to a Multi-AZ RDS instance. Configure a dead-letter queue after five receives and use exponential backoff. If the requirement instead demanded strict ordering, choose SQS FIFO with a message group per customer. Rule of thumb: match the durability mechanism to the failure you fear, and prefer decoupled components over synchronous chains.