AWS Cloud Adoption Framework (CAF) in Practice: MAP, Landing Zones, and Well-Architected

The AWS Cloud Adoption Framework (AWS CAF) is how AWS packages lessons from large-scale customer transformations into six perspectives and, as of CAF 3.0, 47 discrete capabilities—up from 31 in version 2.0. Jeff Barr announced CAF 3.0 on November 23, 2021, emphasizing four transformation domains (Technology, Process, Organization, Product) and four iterative phases: Envision, Align, Launch, and Scale (AWS News Blog, Nov 23, 2021). The overview whitepaper’s publication date is November 22, 2021 (AWS CAF overview).

This article is for executives, enterprise architects, and platform leads who already know the CAF posters exist but need a practical link between CAF and the programs you actually fund: landing zones (often via AWS Control Tower), the Migration Acceleration Program (MAP), and AWS Well-Architected reviews. It is not a Control Tower click path—use our Control Tower setup guide for that.

Need hands-on delivery? AWS migration consulting and AWS managed services engagements from an AWS Partner can anchor MAP phases to your CAF backlog.

What CAF is (and is not)

CAF is not a migration runbook. It is a stakeholder model:

• Business — outcomes, investment, value measures
• People — skills, org design, culture
• Governance — portfolio, risk, compliance, FinOps hooks
• Platform — landing zone, hybrid connectivity, shared services
• Security — identity, data protection, detection, IR readiness
• Operations — observability, incident management, capacity

CAF 3.0 explicitly expands from 31 to 47 capabilities so digital transformation and analytics-driven operations have room on the same roadmap as migration (same Nov 23, 2021 announcement).

From CAF phases to funded work

AWS states the CMA uses 77 stakeholder-driven questions across the six perspectives and scores maturity on five levels from initial to optimized (AWS Public Sector Blog, operationalizing CMA). That is the closest thing AWS publishes to an “objective spreadsheet” for Align—use it before buying more governance SKUs.

MAP: the migration engine that plugs into Launch

MAP is documented as a three-phase methodology: Assess, Mobilize, and Migrate & Modernize—with tooling, training, partner engagement, and financial mechanisms described on AWS MAP and in service-specific guides such as MAP tagging under AWS Transform.

Opinionated take: treat MAP Mobilize as the funding and accountability wrapper for the Platform + Security capabilities you need before wave migrations—not as “the month we install Control Tower.” If Mobilize completes without a written standard for VPC patterns, identity propagation, and tag enforcement, Migrate & Modernize becomes rework.

AWS markets directional outcomes for MAP participants (for example ~31% average infrastructure cost savings, ~62% more efficient IT ops management, and ~69% fewer unplanned downtime events on their MAP overview page). Treat those figures as AWS-reported portfolio statistics, not a guarantee for your workload—your Assess phase exists to replace averages with your TCO model.

Landing zones and Control Tower — Platform, not “the whole framework”

Control Tower implements guardrails and account vending on top of AWS Organizations. That is squarely Platform work with Governance and Security prerequisites (OU design, SCP strategy, log archive account).

What broke — A team deployed Control Tower with default OUs, then Finance required CostCenter tags for chargeback. Tag policies were added late; every service pipeline needed emergency exceptions because sandbox accounts predated the mandatory keys. Rollback was messy because production workloads had already landed in the “wrong” OU path. Fix: pause deployments, run Align again, remap OUs with exception accounts codified—not ad-hoc.

Well-Architected — the workload lens after the platform exists

After the landing zone can support standard logging, backups, and identity patterns, run AWS Well-Architected reviews on pilot workloads during Launch/Scale. CAF without Well-Architected becomes strategy without design feedback; Well-Architected without CAF becomes isolated heroics that do not scale.

What to do this week

1. Download the AWS CAF overview PDF and mark which of the 47 capabilities are out of scope for the next 12 months—explicit “won’t do” is as valuable as “must do.”
2. Run—or re-run—the Cloud Maturity Assessment and attach owners to the bottom three maturity scores by perspective.
3. Map your MAP phase (if applicable) to CAF Align/Launch deliverables on one slide; if the slide does not work, your PMO and partner are misaligned.
4. Schedule Well-Architected only for workloads that already inherit central logging and SSO from the landing zone.

Reproduce this baseline reading

Reproduce this — Start from the authoritative AWS CAF overview whitepaper (publication November 22, 2021; links localized PDFs). Pair it with the CAF 3.0 announcement for the 47 capability count and four phases. For MAP mechanics (including tagging expectations), use MAP in the AWS Transform launch guide.

What this post does not cover

• Step-by-step Control Tower installation (see the dedicated guide).
• Industry-specific regulatory playbooks (FSI, healthcare) beyond pointing at CAF Security capabilities—you still need legal interpretation.
• SAP or large ERP migration-specific CAF tailoring.
• Partner contracts or MAP funding negotiation—your AWS account team and authorized partner own those terms.

If you only do one thing: Complete Align with named owners on three capability gaps surfaced by CMA or MAP Assess before you expand account vending or migration waves.