Design for New Solutions

Assuming you already know the core AWS compute, storage, database, and networking services, by the end of this domain you will be able to assemble them into an architecture that satisfies a scenario's stated business and technical requirements; this domain is graded on exactly that, so read the scenario for the constraints first and pick services to fit them. Map each requirement to a measurable target: an RTO/RPO (recovery-time and recovery-point objectives, defined in Business continuity) for recovery, a p99 latency for performance, a monthly budget for cost, a data-residency or compliance rule for security, and let the strictest target drive the choice. The SAP-C02 trap is the answer that is technically impressive but misses one explicit constraint (an option that meets the latency goal but blows the budget, or meets the budget but cannot hit the stated RPO). When two options both meet every requirement, the simpler / more managed one wins.

AWS evaluates a new solution against the AWS Well-Architected Framework, whose six pillars are operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability (sustainability was added as the sixth pillar in 2021). Five of this domain's subtopics map almost one-to-one onto pillars (business continuity and reliability to the reliability pillar, and performance, cost, and security to their namesakes) while the remaining subtopic, deployment strategy, serves operational excellence; so treat each pillar as a separate question the answer must satisfy rather than a single overall score. The framework's general design principles (stop guessing capacity, test at production scale, automate, allow evolutionary architectures, and drive decisions with data) are the reasoning AWS expects you to apply. A well-architected design rarely maximizes one pillar; it makes an explicit, defensible trade-off among them.

Almost every realistic design forces a trade-off: synchronous multi-AZ replication buys a lower RPO but adds write latency and cost; a single-Region design is cheaper but cannot survive a Regional event; strong consistency costs throughput that eventual consistency does not. The professional-level skill the exam tests is naming which pillar you are spending to buy another, then confirming the spend is justified by a stated requirement. Resist gold-plating: do not engineer a multi-Region active/active topology for a workload whose RTO is several hours, and do not under-build a single-AZ database for a workload that states zero tolerance for downtime. Match the engineering effort to the requirement, no more and no less.

When a managed or serverless service meets the requirements, it is almost always the better SAP-C02 answer because it removes undifferentiated operational work (AWS Lambda, AWS Fargate for containers, Aurora Serverless v2 and DynamoDB on-demand for data) and shifts patching, scaling, and capacity planning to AWS, which improves reliability, security, and operational excellence at once. Reserve self-managed EC2 for the cases that demand it (specialized hardware, a license, an OS-level dependency). Design new solutions to evolve: provision everything as infrastructure as code so environments are reproducible, decouple components through queues and events (Amazon SQS, Amazon EventBridge) so they can change independently, and prefer loosely coupled APIs over tight integrations.