Domain 1 is 24% of the scored content and the only domain with almost no service names in it. It rewards precise vocabulary: the difference between elasticity and scalability, between a pillar and a perspective, between rehost and replatform. Skim the tables, then drill the traps at the bottom.
The value proposition at a glance
| Benefit | What it means | The phrase that signals it |
|---|---|---|
| Trade capital expense for variable expense | Pay for what you use, when you use it, instead of buying hardware up front | “no upfront investment”, “stop guessing capacity” |
| Benefit from massive economies of scale | Aggregated demand across millions of customers gives a lower per-unit price than any one customer can reach | “lower variable cost than we could achieve ourselves” |
| Stop guessing capacity | Scale up and down on actual demand rather than a forecast made a year earlier | “idle at 2am, short at Christmas” |
| Increase speed and agility | New resources in minutes, so experiments cost an afternoon rather than a procurement cycle | “time to market”, “fail fast and cheaply” |
| Stop spending money running and maintaining data centres | Racking, stacking, powering and cooling stop being your job | “focus on customers, not infrastructure” |
| Go global in minutes | Deploy into Regions worldwide from one console or one API call | “low latency for a new market”, “global footprint” |
Elasticity, scalability, agility, high availability
The four get used loosely in conversation and precisely in scored questions.
| Term | Definition | Wrong answer it gets confused with |
|---|---|---|
| Elasticity | Capacity grows and shrinks automatically to match current demand | Scalability, which only promises the growing part |
| Scalability | The system can be made bigger to handle more load, vertically (a larger instance) or horizontally (more instances) | Elasticity, which adds the automatic shrink |
| Agility | Speed of experimentation: new resources in minutes, so a bad idea is cheap to abandon | Elasticity, when the question is about developer speed rather than capacity |
| High availability | The workload keeps serving through the failure of a component, usually by spreading across Availability Zones | Fault tolerance, which tolerates failure with no degradation at all |
| Reliability | The workload does what it is meant to do, correctly and consistently, and recovers when it does not | High availability, which is one contributor to it |
| Durability | Stored data survives; the S3 figure is eleven nines of durability | Availability, which is about being able to reach the data right now |
Elasticity is the one to hold precisely. A question describing traffic that falls away overnight and a bill that falls with it is describing elasticity; a question describing a system that can be made bigger on request is describing scalability.
The six Well-Architected pillars
| Pillar | The question it asks | Signals in a scenario |
|---|---|---|
| Operational Excellence | Can we run and monitor this, and improve it over time? | Runbooks, small reversible changes, automated deployment, learning from failure |
| Security | Are identity, data and traffic protected, and can we prove it? | Least privilege, encryption, traceability, security at every layer |
| Reliability | Does it recover, and does it scale to meet demand? | Recovery from failure, testing recovery procedures, horizontal scaling, managing change |
| Performance Efficiency | Are we using the right resources, and still the right ones a year from now? | Right instance type, serverless where it fits, experimenting, going global in minutes |
| Cost Optimization | Are we spending on things that deliver value? | Consumption model, measuring efficiency, stopping idle resources, analysing spend |
| Sustainability | Are we minimising the environmental impact of running this? | Carbon footprint, maximising utilisation, choosing efficient hardware and Regions, reducing downstream device impact |
Six pillars, and Sustainability is the one added most recently, which makes it a common distractor when a question asks how many there are. The framework also ships lenses for particular workload types, and the Well-Architected Tool in the console runs a workload through the questions and produces an improvement plan.
Two pillar boundaries worth holding:
- Reliability vs Performance Efficiency. Reliability is about surviving and recovering. Performance Efficiency is about whether the resource is the right shape for the job. Auto scaling for resilience is Reliability; picking a compute-optimised instance is Performance Efficiency.
- Cost Optimization vs Sustainability. They point the same way most of the time, and a question distinguishes them by what it asks you to minimise: money, or environmental impact.
The AWS Cloud Adoption Framework
AWS CAF describes what an organisation needs to build in order to adopt the cloud, grouped into six perspectives. Note the word: pillars belong to Well-Architected, perspectives belong to CAF, and swapping them is the classic trap.
| Perspective | Who owns it | What it covers |
|---|---|---|
| Business | CFO, CIO, business unit leads | Strategy, business case, portfolio management, product management |
| People | CIO, HR, people managers | Culture, leadership, workforce skills, organisational design, change acceleration |
| Governance | CIO, programme managers, enterprise architects | Portfolio, programme and project management, benefits management, risk management, data governance |
| Platform | CTO, architects, engineers | Architecture, data engineering, provisioning, modernisation, CI/CD |
| Security | CISO, security architects, analysts | Identity, threat detection, vulnerability management, infrastructure and data protection, incident response |
| Operations | Infrastructure and operations leads, SRE | Observability, event and incident management, change management, performance and capacity, business continuity |
The outcomes CAF is written to deliver are worth recognising by their wording: reduced business risk, improved environmental, social and governance (ESG) performance, increased revenue, and increased operational efficiency. A question that lists those four is asking about CAF.
CAF also names four transformation domains (technology, process, organisation, product) and four phases (envision, align, launch, scale).
The seven migration strategies
The 7 Rs. They run roughly from least to most change.
| Strategy | What happens | Pick it when |
|---|---|---|
| Rehost | Lift and shift; move the server as it is | A deadline is driving, and the application cannot be changed in time |
| Replatform | Lift, tinker and shift; small optimisations on the way, such as self-managed MySQL to Amazon RDS | A managed service removes operational work without touching application code |
| Repurchase | Drop the application and buy a SaaS equivalent | An off-the-shelf product covers the need, such as moving a CRM to a subscription product |
| Refactor | Rewrite, often to a cloud-native or serverless architecture | The current design blocks a business need, and the rewrite is funded |
| Relocate | Move infrastructure wholesale without buying new hardware or rewriting, such as VMware Cloud on AWS | The estate is virtualised already and should move as a unit |
| Retain | Leave it where it is, for now | Something else depends on it, or the business case is not there yet |
| Retire | Turn it off | Discovery shows nobody has used it in a year |
Discovery is what tells the retire and retain cases apart from the rest, which is why a portfolio assessment comes before the strategies.
Supporting services to recognise by name:
| Service | Job |
|---|---|
| AWS Migration Hub | Single place to track the progress of a migration across tools and accounts |
| AWS Application Discovery Service | Inventories on-premises servers, dependencies and utilisation before the move |
| AWS Application Migration Service (MGN) | Block-level replication for a rehost; cuts over servers with minimal downtime |
| AWS Database Migration Service (DMS) | Moves databases with the source staying online; supports homogeneous and heterogeneous moves |
| AWS Schema Conversion Tool (SCT) | Converts schema and code between engines; pairs with DMS for a heterogeneous move |
| AWS DataSync | Moves file data over the network between on-premises storage and AWS |
| AWS Snowball / Snowball Edge | Physical devices for bulk data when the network would take too long |
| AWS Transfer Family | Managed SFTP, FTPS and FTP endpoints into S3 and EFS |
DMS moves the data; SCT converts the schema. A heterogeneous migration (Oracle to Aurora PostgreSQL) needs both. A homogeneous one (Oracle to Oracle on RDS) needs only DMS.
Cloud economics at a glance
| Concept | What it means |
|---|---|
| Fixed cost | Paid whether or not the resource is used: a data centre lease, a purchased server, a Reserved Instance commitment |
| Variable cost | Scales with consumption: On-Demand instance hours, S3 storage, data transfer out |
| Capital expenditure (capex) | Buying an asset up front and depreciating it |
| Operational expenditure (opex) | Paying for a service as it is consumed |
| Total cost of ownership (TCO) | Everything an environment costs, including the parts an invoice never shows |
| Rightsizing | Matching instance type and size to actual measured utilisation, continuously |
| Economies of scale | AWS aggregates demand across customers and passes part of the lower per-unit cost on as price reductions |
The on-premises costs that are easy to forget, and that a TCO comparison is usually testing: hardware purchase and refresh cycles, data centre space, power, cooling, network hardware and circuits, physical security, the staff who rack and patch, over-provisioned capacity that sits idle, and the software licences attached to it all.
Licensing. Bring Your Own License (BYOL) means an existing licence moves with the workload, which suits an enterprise agreement already paid for and often needs a Dedicated Host to satisfy per-socket or per-core terms. License-included means the licence cost is folded into the hourly rate, which suits a workload with no existing entitlement. AWS License Manager tracks entitlements and stops an accidental breach of the terms.
Automation shows up here as an economic argument rather than a technical one: fewer manual steps means fewer errors, faster delivery, less rework and less staff time on repeated tasks.
Deployment models
| Model | What it is |
|---|---|
| Cloud | Everything runs in the cloud, whether built there or migrated to it |
| Hybrid | Some workloads in the cloud, some on-premises, connected over VPN or Direct Connect |
| On-premises | Everything in your own data centre; “private cloud” when virtualisation and self-service are layered on it |
AWS Outposts, Local Zones and Wavelength are the services that put AWS hardware or capacity closer to a specific place, which is the shape of most hybrid answers.
Traps
- Elasticity is not scalability. Elasticity includes scaling back down automatically. A question about capacity shrinking overnight is elasticity.
- Pillars are Well-Architected; perspectives are CAF. Six of each, and the words are not interchangeable.
- Sustainability is a pillar, not a lens. There are six pillars and Sustainability is one of them.
- High availability is not fault tolerance, and neither is disaster recovery. Availability means it keeps serving; fault tolerance means it keeps serving with no degradation; disaster recovery is the plan for getting back after a larger failure.
- Agility means speed of experimentation, not speed of a server. A question about being able to try an idea in an afternoon is agility.
- Replatform is not refactor. Moving MySQL on EC2 to Amazon RDS is a replatform; rewriting the application onto Lambda and DynamoDB is a refactor.
- Repurchase means buying a different product, usually SaaS, not buying more AWS.
- Reserved Instances are a fixed cost. A commitment that is paid whether or not the instance runs behaves like a fixed cost, even though everything around it is variable.
- TCO comparisons include the invisible on-premises costs. Power, cooling, floor space and the staff hours are the ones a question expects you to add.
- CAF has perspectives, domains and phases. Six perspectives, four transformation domains, four phases; do not merge the counts.