Cloud Concepts
One value proposition runs through the whole domain
Every topic in Cloud Concepts is a different lens on a single idea: with AWS you stop owning infrastructure and consume it as a metered service, trading the up-front fixed (capital) expense, CapEx, of buying capacity before you need it for on-demand, variable spending, OpEx, on only what you use. That one shift is what makes the six advantages of cloud computing (trade capital for variable expense, benefit from economies of scale, stop guessing capacity, increase speed and agility, stop spending on data centers, and go global in minutes) hang together rather than read as a list. The benefits subtopic states the proposition, the economics subtopic prices it, and the design and migration subtopics are how you realize and capture it, so a stem about 'why move to the cloud' is testing the proposition itself, not any one service.
Benefits are realized through Well-Architected design, not granted automatically
Elasticity, high availability, and agility are capabilities the cloud makes possible, but a workload only earns them if it is built to use them. The AWS Well-Architected Framework turns the abstract benefits into design decisions, and it has two parts: six pillars that each carry their own design principles, plus a short list of cloud-general design principles (stop guessing capacity, test at production scale, automate, allow evolutionary architectures) that apply across all six, the same ideas the benefits subtopic frames as advantages. A single oversized server is not high availability; deploying across multiple Availability Zones is. The framework names that distinction, so a stem asking how to make a workload resilient or cost-aware is pointing at a design principle, not a benefit slogan.
Adoption is organizational; migration is per-application
Moving to the cloud is two separate decisions the exam keeps distinct. The AWS Cloud Adoption Framework (CAF) addresses readiness at the organization level through its six perspectives and four phases, aiming at outcomes like reduced business risk, ESG, revenue, and operational efficiency. The 7 Rs operate at the application level, classifying how each workload moves: Rehost, Replatform, Repurchase, Refactor, Relocate, Retain, or Retire. A stem about company-wide cloud strategy or governance is CAF; a stem about how to move one particular application is the 7 Rs.
Economics is the scorecard for every other choice in the domain
Cost optimization is both a Well-Architected pillar and the reason the value proposition is compelling, which is why economics ties the domain together rather than standing apart. The savings come from matching resources to actual demand (rightsizing), eliminating the undifferentiated heavy lifting of running data centers, and pairing the right migration strategy with the right pricing, so the choice of a migration strategy is itself an economic one (see the lift-and-shift caution below). Because the cloud lets capacity change in minutes, the economic question shifts from 'how much hardware do we buy' to 'are we paying only for what we use', which is exactly what rightsizing and automation answer.
Four lenses on the same cloud value proposition
| Subtopic | Core question it answers | Exam-stem signal | Anchor concept |
|---|---|---|---|
| Benefits of the AWS Cloud | Why move to the cloud at all? | Avoid buying hardware, faster innovation, reach new geographies | Six advantages; elasticity vs. scalability |
| Cloud design principles | How do we build to actually get the benefits? | Make it resilient, performant, cost-aware, or sustainable | Well-Architected six pillars + general design principles |
| Cloud migration strategies | How do we adopt and move what we have? | Company-wide strategy vs. moving one application | AWS CAF (organization) + the 7 Rs (per app) |
| Cloud economics | Does it pay off, and how do we keep it efficient? | Fixed vs. variable cost, on-prem drivers, rightsizing | CapEx to OpEx; economies of scale; rightsizing & automation |