AWS Cloud Adoption Framework (CAF): Perspectives, Capabilities, and Phases

The AWS Cloud Adoption Framework (AWS CAF) is a set of AWS guidance and organisational capabilities that helps an organisation plan and execute a cloud transformation. It addresses more than servers and applications: business goals, people, governance, platform engineering, security, operations, and measurable value all have to move together.

The central idea is:

Business outcomes
        ↑
Cloud transformation
        ↑
Organisational capabilities
        ↑
Six CAF perspectives

AWS CAF helps an organisation identify transformation opportunities, assess cloud readiness, find capability gaps, create workstreams, and evolve its roadmap incrementally. It is a framework for organisational change and cloud adoption, not an individual AWS service and not an architecture diagram.

This is Part 67 of the AWS Cloud Practitioner Study Notes. Part 65 explains the 7 Rs for deciding what to do with each workload, while this article explains the broader organisational framework that makes cloud adoption sustainable.

AWS CAF at a glance

AWS CAF
├── Four transformation domains
│   ├── Technology
│   ├── Process
│   ├── Organization
│   └── Product
│
├── Six perspectives
│   ├── Business
│   ├── People
│   ├── Governance
│   ├── Platform
│   ├── Security
│   └── Operations
│
└── Four transformation phases
    ├── Envision
    ├── Align
    ├── Launch
    └── Scale

The transformation domains describe where transformation creates value. The perspectives describe which organisational capabilities and stakeholders must participate. The phases describe how the organisation moves from strategy to measurable delivery.

Do not confuse these CAF phases with the separate AWS migration-process phases:

AWS CAF transformation journey → Envision, Align, Launch, Scale
AWS migration process           → Assess, Mobilize, Migrate and modernize

Both models can be used together. CAF is broader than a migration project.

Why cloud adoption needs more than migration

A company can move virtual machines to AWS and still fail to adopt the cloud effectively. It may have:

• No clear business outcome for the migration
• Teams that do not know how to operate cloud services
• No account or identity governance
• Uncontrolled cloud spending
• Insecure permissions and inconsistent network patterns
• No incident, backup, or disaster-recovery procedures
• No product ownership or way to measure value
• A platform team that becomes a bottleneck for every application team

AWS CAF makes these gaps visible. It encourages business and technical stakeholders to agree on the target state, prioritise capability improvements, deliver pilots, and scale what works.

The four AWS CAF transformation domains

AWS CAF describes a value chain in which one kind of transformation enables the next. The domains are connected rather than isolated.

1. Technology transformation

Technology transformation uses cloud capabilities to migrate and modernise infrastructure, applications, data, and analytics platforms.

Examples include:

• Moving workloads from a data centre to AWS
• Replacing physical servers with elastic cloud infrastructure
• Adopting managed databases and storage
• Creating data lakes and analytics platforms
• Modernising a monolith or legacy application
• Automating provisioning through Infrastructure as Code
• Improving resilience across Availability Zones or Regions

Technology transformation is often the most visible part of cloud adoption, but it is only the first link in the value chain. New technology does not produce business value unless people, processes, and products change in useful ways.

2. Process transformation

Process transformation digitises, automates, and optimises business and IT processes.

Examples include:

• Automating manual approval and provisioning workflows
• Using analytics to improve forecasting and decisions
• Applying machine learning to customer service or fraud detection
• Replacing ticket-driven operations with self-service platforms
• Automating testing, deployment, patching, and compliance checks
• Using event-driven workflows to connect business systems

The question is not only “How do we move this process to AWS?” It is “Can the process be redesigned so it is faster, safer, easier to measure, and less dependent on manual work?”

3. Organisational transformation

Organisational transformation changes how teams are structured, how they make decisions, and how they work together to create customer value.

Examples include:

• Organising teams around products and value streams
• Creating cross-functional product teams
• Giving teams clearer ownership of services and outcomes
• Establishing a Cloud Center of Excellence (CCoE)
• Moving from large handoffs to smaller, autonomous teams
• Creating communities of practice for cloud, security, and operations
• Updating roles, skills, incentives, and career paths

Cloud technology often exposes organisational bottlenecks. A team cannot release frequently if every small change requires approval from several disconnected departments. Organisational transformation addresses that operating model.

4. Product transformation

Product transformation reimagines products, services, customer experiences, and revenue models using cloud-enabled capabilities.

Examples include:

• Launching a new digital service
• Personalising a customer experience using data
• Creating an API or platform as a product
• Entering a new market through a scalable online service
• Turning internal data into a measurable business capability
• Moving from project delivery to continuous product improvement

Product transformation is the furthest link in the value chain. It connects cloud investment to new or improved customer value and business models.

The six AWS CAF perspectives

The six perspectives group related capabilities and stakeholders. The first three are commonly associated with business capabilities, while the last three focus more heavily on technical capabilities.

Perspective	Main question	Typical stakeholders
Business	Why are we adopting cloud and what value should it create?	CEO, CFO, COO, CIO, CTO, strategy leaders
People	Do we have the culture, leadership, skills, and roles to change?	CIO, COO, CTO, HR, cloud leaders, people managers
Governance	How do we control risk, cost, portfolio, and benefits?	CIO, CFO, programme and portfolio managers, risk leaders
Platform	What scalable cloud foundation will teams build on?	CTO, architects, platform and engineering teams
Security	How will we protect identities, data, applications, and infrastructure?	CISO, compliance, audit, security architects and engineers
Operations	How will we run, monitor, support, and recover workloads?	Operations managers, SREs, support, service managers

1. Business perspective

The Business perspective ensures that cloud investments support strategic business outcomes instead of becoming an isolated IT exercise.

Its capabilities are:

• Strategy management — connect cloud adoption to long-term business goals, technical-debt reduction, operating efficiency, new services, and revenue opportunities.
• Portfolio management — prioritise cloud initiatives and applications according to value, risk, capacity, schedule, and the 7 Rs.
• Innovation management — create a repeatable way to propose, test, evaluate, and scale new ideas.
• Product management — manage cloud-enabled products through their entire lifecycle with product owners, customer journeys, roadmaps, and value streams.
• Strategic partnership — use the AWS relationship, partners, marketplace, funding, and technical resources to support business outcomes.
• Data monetisation — turn data into measurable internal or external business value, such as better decisions, customer insight, or new products.
• Business insights — use analytics to understand performance and support decisions connected to business KPIs.
• Data science — apply experimentation, machine learning, and advanced analytics to meaningful business problems.

Business perspective example

Suppose a retailer wants to migrate its order platform. A technology-only plan might choose EC2 instance types. The Business perspective asks broader questions:

• Is the goal lower cost, faster releases, better customer experience, or expansion into new markets?
• Which product journeys matter most to customers?
• Which workloads should be retired or modernised?
• How will success be measured?
• Does the data support new forecasting or personalisation capabilities?

Exam memory

If the question mentions business outcomes, strategy, portfolio prioritisation, innovation, product value, or data-driven decisions, think Business perspective.

2. People perspective

The People perspective addresses culture, leadership, organisational change, skills, workforce planning, and team design. Cloud adoption changes how people work, not just where servers run.

Its capabilities are:

• Culture evolution — encourage agility, ownership, experimentation, continuous learning, and customer focus.
• Transformational leadership — secure visible executive sponsorship and leaders who can make cross-functional decisions.
• Cloud fluency — build the knowledge needed to use cloud technologies, data, security, and modern delivery practices effectively.
• Workforce transformation — develop, hire, retain, and organise a workforce with the required digital capabilities.
• Change acceleration — manage communication, training, impact, risks, resistance, and adoption of new ways of working.
• Organisation design — align team structures, reporting lines, roles, decision rights, and operating models with the target state.
• Organisational alignment — create shared understanding and coordinated action across business and technology functions.

People perspective example

An organisation may buy a managed Kubernetes platform but lack engineers who can secure, monitor, and operate it. The People perspective creates a skills plan, defines ownership, provides training, uses mentoring or partners where needed, and changes team responsibilities so the platform can be operated sustainably.

Cloud Center of Excellence

A Cloud Center of Excellence (CCoE) is one possible organisational mechanism for coordinating cloud adoption. It can provide reusable patterns, guardrails, enablement, training, and standards. It should help teams move faster and improve consistency rather than becoming a permanent approval bottleneck for every deployment.

Exam memory

If the question mentions training, skills, culture, leadership, change management, workforce, or team structure, think People perspective.

3. Governance perspective

The Governance perspective helps the organisation coordinate cloud initiatives, manage risk, control spending, manage the application portfolio, and measure benefits.

Its capabilities are:

• Programme and project management — coordinate workstreams, dependencies, milestones, risks, and delivery decisions.
• Benefits management — define expected benefits and measure whether cloud initiatives actually produce them.
• Risk management — identify, assess, treat, and monitor technology, operational, financial, compliance, and transformation risks.
• Cloud financial management — establish cost visibility, budgets, forecasts, allocation, optimisation, and accountability.
• Application portfolio management — inventory applications, understand dependencies and value, and decide whether to migrate, modernise, replace, retain, or retire them.
• Data governance — define ownership, quality, access, lifecycle, classification, and compliance for data.
• Data curation — make data discoverable, understandable, trusted, and usable for its intended consumers.

Governance perspective example

If teams create AWS accounts without ownership, tags, budgets, or security baselines, the organisation may lose cost and risk control. Governance establishes account and resource policies, application ownership, cost allocation, portfolio priorities, and benefit measures.

Governance does not mean preventing all change. Effective governance makes safe change repeatable through guardrails, automation, policy as code, approved patterns, and clear accountability.

Exam memory

If the question mentions risk, compliance governance, budgets, cost allocation, portfolio decisions, project management, or measuring benefits, think Governance perspective.

4. Platform perspective

The Platform perspective focuses on creating a secure, scalable, enterprise-grade cloud foundation that allows teams to deliver workloads efficiently.

Its capabilities are:

• Platform architecture — design the target architecture, accounts, networking, environments, resilience, and integration patterns.
• Platform engineering — build and operate reusable internal platforms and paved roads for application teams.
• Data architecture — design data stores, data flows, integration, analytics, security, and lifecycle patterns.
• Data engineering — ingest, transform, store, move, and prepare data reliably for applications and analytics.
• Provisioning and orchestration — automate the creation, configuration, and lifecycle of cloud resources.
• Modern application development — use suitable cloud-native practices, managed services, containers, serverless components, and modern delivery methods.
• Continuous integration and continuous delivery (CI/CD) — automate build, test, security checks, deployment, and release processes.

Platform perspective example

A platform team may provide Terraform modules, account baselines, networking patterns, CI/CD templates, logging, observability, and secure service defaults. Application teams then consume these capabilities without rebuilding the foundation for every service.

The Platform perspective is not simply “choose EC2.” It includes the architecture and engineering systems that let an organisation build, deploy, and evolve workloads repeatedly.

Exam memory

If the question mentions landing zones, architecture, provisioning, orchestration, CI/CD, platform engineering, data architecture, or modern application development, think Platform perspective.

5. Security perspective

The Security perspective ensures that cloud workloads meet confidentiality, integrity, availability, resilience, compliance, and risk requirements.

Its capabilities are:

• Security governance — define security policies, standards, roles, risk tolerance, and compliance expectations.
• Security assurance — evaluate whether controls work through audits, assessments, evidence, and continuous improvement.
• Identity and access management — manage human and machine identities, authentication, authorisation, least privilege, and access lifecycle.
• Threat detection — identify suspicious activity, anomalies, and potential attacks.
• Vulnerability management — discover, prioritise, remediate, and track vulnerabilities.
• Infrastructure protection — protect networks, compute, endpoints, configurations, and infrastructure boundaries.
• Data protection — classify, encrypt, back up, retain, and control access to data.
• Application security — build security into code, dependencies, pipelines, design, and runtime behaviour.
• Incident response — prepare for, detect, contain, investigate, recover from, and learn from security incidents.

Security perspective example

Before migrating a customer database, the organisation defines data classification, encryption, key management, access roles, network boundaries, audit logging, vulnerability scanning, incident procedures, and evidence requirements. Security is designed into the landing zone and workload delivery process rather than added only after deployment.

AWS CAF does not replace the AWS Shared Responsibility Model. It helps the organisation build the capabilities to fulfil its responsibilities in the cloud.

Exam memory

If the question mentions IAM, encryption, threat detection, vulnerabilities, infrastructure protection, data protection, or incident response, think Security perspective.

6. Operations perspective

The Operations perspective ensures that cloud services are delivered and supported at the required level of health, reliability, performance, and continuity.

Its capabilities are:

• Observability — collect and use metrics, logs, traces, events, and useful service health signals.
• Event management and AIOps — detect, correlate, prioritise, and respond to operational events.
• Incident and problem management — restore service, investigate root causes, and prevent recurring failures.
• Change and release management — make changes safely, consistently, and with appropriate risk controls.
• Performance and capacity management — measure demand, performance, quotas, and capacity before they become incidents.
• Configuration management — know what resources, versions, dependencies, and settings exist.
• Patch management — apply, verify, and report operating system and software patches.
• Availability and continuity management — design and operate resilience, backup, disaster recovery, and continuity processes.
• Application management — manage application health, support, lifecycle, ownership, and operational requirements.

Operations perspective example

An application is not operationally ready merely because it is deployed. The team needs dashboards, alerts, runbooks, on-call ownership, backup verification, incident procedures, deployment rollback, capacity plans, patching, and disaster-recovery tests.

Exam memory

If the question mentions monitoring, logging, incidents, patching, performance, capacity, releases, availability, or continuity, think Operations perspective.

CAF capability count and classification

The AWS CAF whitepaper groups 47 foundational capabilities across the six perspectives:

Perspective	Capability count
Business	8
People	7
Governance	7
Platform	7
Security	9
Operations	9
Total	47

The number is useful for exam recognition, but the main lesson is that cloud readiness is multidimensional. An organisation does not become cloud-ready by improving only its infrastructure team.

The four AWS CAF transformation phases

The CAF transformation journey is iterative. An organisation can revisit earlier phases as it learns.

1. Envision

The Envision phase demonstrates how cloud can accelerate business outcomes. It connects strategic goals with transformation opportunities across Technology, Process, Organisation, and Product.

Typical activities:

• Define the business vision and desired outcomes.
• Identify measurable results and key stakeholders.
• Find opportunities for migration, modernisation, automation, data, and innovation.
• Prioritise opportunities by value, feasibility, risk, and urgency.
• Connect initiatives to strategic business objectives.
• Create an initial transformation roadmap.

Example outcomes might include faster product delivery, lower operational risk, improved customer experience, new analytics capabilities, or expansion into a new market.

Exam clue: “Demonstrate how cloud accelerates business outcomes” → Envision.

2. Align

The Align phase identifies gaps across the six perspectives and addresses stakeholder concerns and cross-organisational dependencies.

Typical activities:

• Assess current cloud readiness.
• Identify skills, process, security, governance, platform, and operational gaps.
• Identify dependencies between business and technology teams.
• Clarify ownership and decision rights.
• Build alignment between executives, finance, security, operations, and delivery teams.
• Create action plans for capability improvement and change management.

The Migration Readiness Assessment (MRA) is commonly associated with this readiness work. It helps an organisation understand its current position, strengths, weaknesses, and actions required to migrate at scale.

Exam clue: “Identify capability gaps and stakeholder concerns” → Align.

3. Launch

The Launch phase delivers high-impact pilot initiatives in production and demonstrates incremental business value. The purpose is to learn with real delivery rather than planning forever.

Typical activities:

• Select a manageable but meaningful pilot.
• Establish the minimum secure and governed platform foundation.
• Deliver the workload or transformation initiative in production.
• Measure business, technical, operational, and financial results.
• Capture lessons and improve the operating model.
• Use successful pilots to build confidence and influence future direction.

A pilot should not be an isolated technical demo with no business owner. It should have a measurable outcome and a path to scale or a clear reason to stop.

Exam clue: “Deliver production pilots and demonstrate incremental value” → Launch.

4. Scale

The Scale phase expands successful pilots to the desired organisational or production scale and sustains the associated benefits.

Typical activities:

• Reuse successful architectures, patterns, automation, and training.
• Expand migration waves and product adoption.
• Improve platform self-service and guardrails.
• Standardise operating, security, and financial practices.
• Measure benefits continuously rather than only at project completion.
• Mature capabilities as the organisation grows.
• Continue discovering new transformation opportunities.

Scaling does not mean copying every pilot blindly. It means taking what has been validated, adapting it to different contexts, and improving it through feedback.

Exam clue: “Expand pilots and sustain business value at scale” → Scale.

CAF phases versus AWS migration phases

This distinction is important because AWS uses both sets of phases in related guidance.

AWS CAF transformation journey	AWS migration process
Envision	Assess
Align	Mobilize
Launch	Migrate and modernize
Scale	Ongoing expansion and value realisation

The CAF phases apply to broad cloud transformation. The migration process is more specifically about preparing and moving workloads.

Assess

Assess current readiness, inventory the application portfolio, define business outcomes, and build the migration business case and TCO view.

Mobilize

Close readiness gaps, establish the landing zone, improve security and operations, develop skills, prepare the migration factory, and gain hands-on experience with an initial wave.

Migrate and modernize

Design, migrate, validate, stabilise, and modernise workloads according to their selected migration strategy.

One way to remember the relationship is:

CAF = the organisation's complete cloud transformation journey
Migration process = the workload movement and modernisation workstream

Migration Readiness Assessment (MRA)

An MRA uses CAF perspectives to evaluate how ready an organisation is for cloud migration. It is not an exam or a simple technical scan. It is a structured conversation and analysis involving the people who own business, technology, security, finance, governance, and operations outcomes.

AWS describes three core outcomes:

1. Understand where the organisation is in its cloud journey.
2. Identify cloud-readiness strengths and weaknesses.
3. Create an action plan to close the gaps so migration can proceed at scale.

A readiness assessment process commonly includes:

Prepare scope and obtain sponsorship
        ↓
Schedule the assessment with the right stakeholders
        ↓
Discuss CAF-aligned questions and collect evidence
        ↓
Analyse observations and identify gaps
        ↓
Debrief stakeholders
        ↓
Create actions, owners, priorities, and dates

The output should be actionable. “The organisation needs better security” is too vague. A useful action might be “define an account baseline, centralise audit logs, establish emergency access, and assign owners before the first production wave.”

What a CAF action plan should contain

For each gap, record:

Field	Example
Perspective	Governance
Capability	Cloud financial management
Current state	Teams cannot allocate AWS spend to products
Target state	Product owners see monthly cost and budget variance
Action	Establish account and tag ownership, budgets, and reporting
Owner	FinOps and platform teams
Priority	Before production migration
Measure	95% of spend allocated to an owner
Dependency	Account structure and tagging standard

This turns CAF from a checklist into a sequence of organisational workstreams.

How CAF works with a landing zone and CCoE

CAF is not itself a landing zone or a Cloud Center of Excellence.

• A landing zone is a well-architected, governed AWS environment with account structure, identity, networking, logging, security, and operating foundations.
• A CCoE is an organisational capability or team structure that helps guide and enable cloud adoption.
• AWS CAF is the framework used to identify and improve the capabilities needed across business and technical areas.

CAF can inform the design of a landing zone and the responsibilities of a CCoE, but the terms are not interchangeable.

How CAF works with the AWS Well-Architected Framework

AWS CAF focuses on organisational cloud readiness and transformation capabilities. The AWS Well-Architected Framework focuses on workload architecture and design decisions across its pillars.

AWS CAF             → Can the organisation adopt and operate cloud effectively?
Well-Architected   → Is this particular workload designed well in the cloud?

They complement one another. CAF may identify the need for an operational capability, while a Well-Architected review may identify missing alarms, backup controls, or resilience in a specific application.

Example: applying CAF to an HR platform migration

Imagine an organisation moving an HR platform from a data centre to AWS.

Business

Define whether the goal is cost reduction, faster employee self-service, better availability during payroll, or integration with new analytics.

People

Identify who can operate the target services, provide training, assign product ownership, and communicate changes to HR users and support staff.

Governance

Classify the application, define migration priority, allocate costs, document data ownership, identify compliance requirements, and select the migration strategy.

Platform

Build the account, network, deployment, database, observability, and Infrastructure as Code patterns required by the platform.

Security

Define IAM, encryption, audit logging, vulnerability management, data protection, incident response, and access reviews.

Operations

Prepare monitoring, on-call support, patching, backup verification, disaster recovery, release rollback, and capacity management.

The application migration is then only one part of a coordinated cloud adoption plan.

Common AWS CAF exam traps

CAF is not only about technology

The six perspectives deliberately include business, people, and governance. If an answer focuses only on EC2, VPC, or storage, it is probably incomplete for a CAF question.

CAF is not the AWS Shared Responsibility Model

Shared Responsibility explains which security tasks AWS and the customer perform. CAF helps the organisation build capabilities for cloud adoption. They address different questions.

CAF is not the Well-Architected Framework

CAF is organisational and transformation-focused. Well-Architected is workload-architecture-focused.

CAF phases are not the 7 Rs

Envision, Align, Launch, and Scale describe transformation progression. Rehost, replatform, refactor, repurchase, relocate, retain, and retire describe workload migration strategies.

Align is about gaps and alignment

If the question describes identifying capability gaps, dependencies, stakeholder concerns, or readiness actions, choose Align, not Launch.

Launch is about production pilots

If the question describes delivering a pilot and proving incremental business value, choose Launch.

Scale is about sustained value

If the question describes expanding successful pilots and sustaining benefits, choose Scale.

Final memory map

Four domains: Technology → Process → Organization → Product

Six perspectives:
Business   → strategy and value
People     → skills and change
Governance → risk, cost, portfolio, benefits
Platform   → architecture and delivery foundation
Security   → protect everything
Operations → run and recover everything

Four CAF phases:
Envision → define the vision and outcomes
Align    → find gaps and align stakeholders
Launch   → prove value with production pilots
Scale    → expand and sustain value

The shortest exam answer is: AWS CAF is a framework for organisational cloud transformation. It uses six perspectives—Business, People, Governance, Platform, Security, and Operations—to identify capabilities and gaps, and its transformation journey moves through Envision, Align, Launch, and Scale.

Sources

• AWS Whitepaper: An Overview of the AWS Cloud Adoption Framework
• AWS Prescriptive Guidance: Evaluating migration readiness
• AWS Prescriptive Guidance: Readiness assessment process
• AWS Prescriptive Guidance: Overview of the migration strategy