Exam Room · Cloud Practitioner

Cheat Sheet: Cloud Concepts

· 22 min read

Cloud Fundamentals · part of The Exam Room

Domain 1 is 24% of the scored content. It covers the value proposition, the Well-Architected design principles, migration strategy and cloud economics. Most of it is vocabulary, held precisely: elasticity against scalability, a pillar against a perspective, rehost against replatform.

The value proposition

AWS words the benefits of cloud in six lines. The first one has shifted wording over the years, and now reads fixed expense where older material said capital expense.

  • Trade fixed expense for variable expense. Pay when you consume, and only for what you consume, instead of investing before you know the shape of the demand.
  • Benefit from massive economies of scale. Usage from hundreds of thousands of customers aggregates, so pay-as-you-go prices land lower than one organisation reaches alone.
  • Stop guessing capacity. Take as much or as little as you need, on a few minutes’ notice, rather than sizing a year ahead.
  • Increase speed and agility. New resources arrive in minutes rather than weeks, so an experiment takes an afternoon.
  • Stop spending money running and maintaining data centres. Racking, stacking and powering servers stop being your work.
  • Go global in minutes. Deploy into Regions worldwide, which lowers latency for customers in a new market.

Elasticity, scalability, agility, availability

  • Elasticity. Capacity grows and shrinks automatically to match current demand. It gets confused with scalability, which covers only the growing part.
  • Scalability. The system can be made bigger to carry more load, vertically (a larger instance) or horizontally (more instances).
  • Agility. Speed of experimentation. Resources in minutes means an idea can be tried and dropped inside an afternoon.
  • High availability. The workload keeps serving through the failure of a component, usually by spreading across Availability Zones.
  • Fault tolerance. The stronger promise: it keeps serving with no degradation at all.
  • Reliability. The workload does what it is meant to do, consistently, and recovers when it does not. Availability is one contributor.
  • Durability. Stored data survives. S3 Standard is designed for 99.999999999% durability, eleven nines, and 99.99% availability over a year.

Elasticity is the one to hold precisely. Traffic that falls away overnight, and a bill that falls with it, is elasticity. A system that can be made bigger on request is scalability.

The six Well-Architected pillars

Pillar What it asks Signals to look for
Operational Excellence Can we run this, watch it, and improve it? Runbooks, small reversible changes, learning from failure
Security Are identity, data and traffic protected? Least privilege, encryption, traceability, security at every layer
Reliability Does it recover, and does it meet demand? Recovery testing, horizontal scaling, managing change
Performance Efficiency Are these the right resources, still? Instance type fit, serverless where it suits, going global in minutes
Cost Optimization Is the spend delivering value? Consumption model, measuring efficiency, stopping idle resources
Sustainability Are we minimising environmental impact? Carbon footprint, utilisation, efficient hardware, downstream device impact

Sustainability was added last, so a count other than six is the usual wrong one. The framework also ships lenses, sets of questions for a particular workload type. The AWS Well-Architected Tool is free in the console. It runs a workload through a lens and produces an improvement plan, with the Framework lens applied automatically and official lenses available from the Lens Catalog.

Two pillar boundaries worth holding:

  • Reliability against Performance Efficiency. Reliability is surviving and recovering. Performance Efficiency is 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 against Sustainability. They point the same way most of the time. The split is what you are asked to minimise: money, or environmental impact.

Six general design principles sit alongside the pillars, and they get quoted too: stop guessing your capacity needs, test systems at production scale, automate with architectural experimentation in mind, consider evolutionary architectures, drive architectures using data, improve through game days.

The AWS Cloud Adoption Framework

CAF describes the capabilities an organisation builds in order to adopt 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 What it covers
Business Strategy, portfolio, innovation and product management, data monetisation
People Culture, leadership, workforce skills, organisational design, change acceleration
Governance Programme and risk management, benefits realisation, data governance
Platform Architecture, data engineering, provisioning, modernisation, CI/CD
Security Identity, threat detection, vulnerability management, data protection, incident response
Operations Observability, incident and change management, performance, business continuity

Stakeholders run high in the Business perspective: CEO, CFO, COO, CIO and CTO.

CAF also names four transformation domains (technology, process, organisation, product) and four phases (envision, align, launch, scale). Its four business outcomes are worth recognising verbatim: reduced business risk, improved environmental, social and governance (ESG) performance, increased revenue, and increased operational efficiency.

The seven migration strategies

The 7 Rs, roughly from least to most change.

  • Retire. Turn it off. Discovery flags zombie applications, averaging under 5% CPU and memory, and idle ones between 5% and 20% over 90 days.
  • Retain. Leave it where it is for now, because a dependency has to move first, or specialised hardware has no cloud equivalent.
  • Rehost. Lift and shift. The server moves with no change to the application.
  • Relocate. Move a platform’s workloads wholesale to a cloud version of that platform, with no new hardware and no rewrite. It also covers moving instances or objects to a different VPC, Region or account.
  • Repurchase. Drop and shop. Replace the application with a different product, usually SaaS.
  • Replatform. Lift, tinker and shift. Small optimisations on the way, such as a self-managed Microsoft SQL Server database moving to Amazon RDS for SQL Server.
  • Refactor (or re-architect). Rewrite to use cloud-native features. AWS calls this the most complex and costly of the seven, and advises modernising after a large migration rather than during it.

Relocate used to be taught with VMware Cloud on AWS. AWS stopped reselling that in 2024, and Broadcom now owns the relationship. The AWS-native equivalent today is Amazon Elastic VMware Service (EVS), which runs VMware Cloud Foundation on EC2 bare metal inside your VPC.

Discovery is what separates the retire and retain cases from the rest, which is why portfolio assessment comes before strategy selection.

Services on the migration path

Three long-standing names on this list have closed to new customers. They still lead older study material, so know what replaced them.

  • AWS Transform MGN. Block-level replication for a rehost, cutting servers over in minutes. This is AWS Application Migration Service under its current name.
  • AWS Database Migration Service (DMS). Moves relational databases, warehouses and other data stores, and can replicate ongoing changes so source and target stay in step.
  • DMS Schema Conversion, and the downloadable AWS Schema Conversion Tool (SCT). Convert schema and code between engines.
  • AWS DataSync. Moves file and object data over the network between on-premises NFS, SMB, HDFS or object storage and S3, EFS or FSx.
  • AWS Transfer Family. Managed SFTP, FTPS, FTP, AS2 and browser-based transfers into S3 and EFS.
  • AWS Data Transfer Terminal. A physical location you book a slot at, to plug your storage devices into a high-bandwidth link to AWS.
  • AWS Migration Hub. Tracked migration progress across tools and accounts. Closed to new customers on 7 November 2025; AWS Transform covers the same ground.
  • AWS Application Discovery Service. Inventoried on-premises servers, dependencies and utilisation. Also closed to new customers, with AWS Transform again the named replacement.
  • AWS Snowball Edge. Shipped bulk data on a rugged physical device. Closed to new customers; DataSync handles the online route and a Data Transfer Terminal the physical one.

DMS moves the data, and the schema conversion step 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

  • Fixed cost. Incurred 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 what no invoice lists.
  • Rightsizing. Matching instance type and size to measured utilisation, continuously.
  • Economies of scale. Aggregated demand lowers the per-unit cost, and part of that reaches customers as price reductions.

A TCO comparison usually turns on the on-premises costs no invoice lists. Hardware refresh cycles, floor space, power, cooling, network circuits, physical security, the staff who rack and patch, over-provisioned capacity sitting idle, and the licences attached to all of it.

Licensing. Bring Your Own License (BYOL) moves an existing entitlement with the workload. Per-socket, per-core and per-VM terms usually need an EC2 Dedicated Host, which exposes socket and core counts and supports BYOL in full. License-included folds the licence into the hourly rate, which suits a workload with no entitlement to carry over. AWS License Manager tracks entitlements across accounts and Regions and applies hard or soft limits on consumption, which reduces the risk of an overage.

Automation appears here as an economic argument rather than a technical one, and the guide asks you to identify its benefits. Four show up in scenarios. Automated provisioning removes the build time and the configuration drift that comes from doing it by hand twice. Auto scaling and scheduled start/stop remove idle spend without anyone watching a graph. Automated patching and backups remove staff hours from work that has to happen whether or not someone remembers. And repeatability removes the class of incident that starts with a human typing the wrong thing. The through-line is that the saving is in people’s time and in errors not made, not only in the instance hours.

Deployment models

Cloud means everything runs in the cloud, whether built there or migrated to it. Hybrid keeps some workloads on-premises, connected over VPN or Direct Connect. On-premises means your own data centre, and gets called private cloud once virtualisation and self-service are layered on it. AWS Outposts (42U racks, or 1U and 2U servers), Local Zones and Wavelength Zones put AWS capacity closer to a specific place, and a hybrid scenario usually points at one of them.

Traps

  • Elasticity is not scalability. Elasticity includes scaling back down automatically. Capacity shrinking overnight is elasticity.
  • Pillars are Well-Architected; perspectives are CAF. Six of each, and the words do not swap.
  • Sustainability is a pillar, not a lens. Six pillars, with Sustainability among them.
  • Availability, fault tolerance and disaster recovery are three things. Availability keeps serving. Fault tolerance keeps serving with no degradation. Disaster recovery is the plan for coming back after a larger failure.
  • Agility means speed of experimentation, not speed of a server. Trying an idea in an afternoon is agility.
  • Replatform is not refactor. MySQL on EC2 moving to Amazon RDS is a replatform. Rewriting onto Lambda and DynamoDB is a refactor.
  • Repurchase means a different product, usually SaaS, not more AWS.
  • A Reserved Instance commitment behaves as a fixed cost. The charge lands whether or not the instance runs.
  • TCO includes what no on-premises invoice shows. Power, cooling, floor space and staff hours.
  • CAF has perspectives, domains and phases. Six, four and four. Do not merge the counts.
  • Migration Hub, Application Discovery Service and Snowball Edge are closed to new customers. AWS Transform is the named successor for the first two.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.