AWS Cloud Adoption Framework: Platform Perspective — Platform & Data Architecture, Platform & Data Engineering, Provisioning, Modern Apps, and CI/CD

Where this fits

The AWS Cloud Adoption Framework organises cloud-readiness into six perspectives — Business, People, Governance, Platform, Security, and Operations — each a grouping of capabilities owned by a related set of stakeholders. The Platform perspective is the one the CTO, technology leaders, architects, and engineers live in: it “focuses on accelerating the delivery of your cloud workloads via an enterprise-grade, scalable, hybrid cloud environment,” and it is decomposed into seven capabilities — platform architecture, data architecture, platform engineering, data engineering, provisioning and orchestration, modern application development, and CI/CD. Where the Governance and Security perspectives decide what is allowed, the Platform perspective builds the machine that makes the allowed thing the easy thing: the multi-account landing zone, the data platform, the self-service product catalog, and the pipelines that ship code and infrastructure. This article goes deep on all seven.

Platform architecture

What it is

Platform architecture is the capability that establishes and maintains the guidelines, principles, patterns, and guardrails for your cloud environment. It is the set of consciously-made, written-down decisions that everything else in the Platform perspective implements: how accounts are organised, how networks are laid out, how identity federates, how logging is centralised, and which workloads stay on-premises. It is architecture as consensus — enterprise standards agreed once, centrally, so that hundreds of teams do not each reinvent (and mis-implement) the foundation.

Why it matters

A well-architected cloud environment accelerates implementation, reduces risk, and drives adoption; an un-architected one produces the most expensive remediation in cloud — re-homing live production accounts, retrofitting service control policies onto running workloads, and re-IP-ing VPCs that were allocated overlapping CIDR ranges by teams who never talked to each other. The decisions made here are load-bearing and sticky: an OU hierarchy, an IP address plan, and an identity-federation model are cheap to draw on a whiteboard and brutally expensive to change after fifty accounts depend on them. Platform architecture is where you pay that cost up front, deliberately.

How to do it well

• Build consensus, then write it down. The deliverable is a set of agreed enterprise standards and reference blueprints, not a slide. Use the AWS Well-Architected Framework as the rubric and the AWS Security Reference Architecture (AWS SRA) as the canonical account/security layout to argue from.
• Separate the foundation from the workloads from day one. Decide the multi-account structure (per Organizing Your AWS Environment Using Multiple Accounts) before you mint accounts — a Security OU, an Infrastructure OU, Workloads (Prod/Non-Prod) OUs, a Sandbox OU, Suspended and Policy-staging OUs.
• Plan the network as one system. A non-overlapping IP address plan and a hub-and-spoke topology (Transit Gateway, centralised egress, shared Route 53 Resolver endpoints) per Building a Scalable and Secure Multi-VPC AWS Network Infrastructure belong to architecture, not to whichever team needs connectivity first.
• Decide what does not move. Explicitly evaluate hybrid use cases — cloud bursting, backup/DR to cloud, distributed data processing, and edge — and record which workloads stay on-premises for latency, data-processing, or data-residency reasons, and how they connect (Direct Connect, Site-to-Site VPN, Outposts, Local Zones).

Concrete artifacts, decisions, and AWS tools

The principal artifact is a target reference architecture (account model + network plan + identity model + guardrail catalog + logging design) plus a small library of best-practice blueprints that downstream platform engineering will codify.

Data architecture

What it is

Data architecture is the capability to design and evolve a fit-for-purpose data and analytics architecture. It defines, for each architectural layer — ingestion, storage, catalog, processing, and consumption — which technologies you standardise on, so that growing data volumes yield actionable insight instead of complexity, cost, and technical debt. AWS guidance here is explicit: adopt a layered and modular architecture so you can use the right tool for the right job and evolve incrementally, and lean toward a lake house pattern that lets data move freely between a central data lake and purpose-built stores (a warehouse, a search index, a graph, a key-value store).

Why it matters

Most enterprise data debt is architectural, not technical: a warehouse that became the dumping ground for semi-structured data it was never meant to hold; a dozen point-to-point extracts no one can decommission; “the report” that takes a person three days to reconcile by hand. A deliberate, layered architecture — raw/cleansed/curated zones in the lake, a shared catalog, the right purpose-built engine per consumption pattern — reduces that debt and, critically, supports real-time processing rather than only nightly batch. It is also where you decide governance shape: a centralised lake versus a federated data mesh of domain-owned data products, a choice that is far cheaper to make now than to retrofit.

How to do it well

• Standardise the lake on S3 with open table formats. S3 as the storage layer plus Apache Iceberg (now natively supported across Athena, Glue, EMR, and Redshift, and underpinning S3 Tables) gives you ACID transactions, schema evolution, and time travel without lock-in.
• Make the catalog the source of truth. A single technical catalog (the AWS Glue Data Catalog / SageMaker Lakehouse catalog) with AWS Lake Formation for fine-grained, tag-based access control prevents every team building its own metadata silo.
• Prefer serverless to simplify ongoing management, as AWS guidance advises — Athena, Glue, EMR Serverless, Redshift Serverless, and Kinesis/MSK Serverless remove cluster-tending toil and scale with demand.
• Pick engines by consumption pattern, not by habit. Interactive SQL on the lake → Athena; large-scale warehousing → Redshift; sub-second key lookups → DynamoDB; search/observability → OpenSearch; streaming analytics → Managed Service for Apache Flink.

Concrete artifacts, decisions, and AWS tools

The artifact is a reference data architecture naming the chosen technology for every layer, the zoning and catalog standard, and a lake house topology diagram showing how the lake and purpose-built stores exchange data.

Platform engineering

What it is

Platform engineering is the capability that builds a compliant multi-account cloud environment with enhanced security, plus packaged, reusable cloud products. This is where platform architecture’s blueprints become running infrastructure: the landing zone that lets teams provision conformant accounts on demand, the federation that lets them log in with existing credentials, the centralised logging and DNS, and the curated catalog of self-service products that codify best practice. The mandate is explicit — leverage infrastructure as code (IaC) to define configurations declaratively, and continuously improve enterprise standards as consumable services.

Why it matters

Without platform engineering, “governance” is a wiki page and a hope: each new account is hand-crafted, drifts from standard, and quietly accumulates risk. With it, an account is born compliant — the OU it lands in attaches the right SCPs, the baseline stack provisions logging and config rules, the network is auto-peered, and the team gets a vetted set of Service Catalog products instead of a blank console. This is the capability that converts central control from a bottleneck (every change is a ticket) into an enabler (guardrails are inherited, paved roads are self-service), which is the entire economic argument for cloud at enterprise scale.

How to do it well

• Stand up the landing zone with AWS Control Tower, which orchestrates Organizations, IAM Identity Center, Config, CloudTrail, and a Log Archive + Audit account into a governed baseline, then extend it with Customizations for Control Tower (CfCT) or AWS Control Tower Account Factory for Terraform (AFT) so account vending is a pipeline, not a console click.
• Federate identity between your existing IdP and AWS via IAM Identity Center, so users authenticate with existing credentials and assume permission sets rather than holding long-lived IAM users.
• Centralise the cross-cutting services architecture chose: organization-wide CloudTrail to a locked S3 log archive, a Config aggregator, inbound/outbound Route 53 Resolver endpoints, and an aggregated view of accounts and controls (Control Tower dashboard, Security Hub, AWS Config conformance packs).
• Package enterprise standards as products. Evaluate and certify which services teams may consume, then publish vetted, parameterised AWS Service Catalog products (built on CloudFormation or Terraform) so a “compliant VPC,” “approved RDS instance,” or “logging-enabled S3 bucket” is one launch away.

Concrete artifacts, decisions, and AWS tools

Artifacts: a deployed, governed landing zone, an account-vending pipeline, a Service Catalog portfolio of certified products, and the IaC repositories that define them all.

Data engineering

What it is

Data engineering is the capability to automate and orchestrate data flows across your organisation. Where data architecture decides the shape of the platform, data engineering builds and runs the pipelines that move data through it — consuming raw data and producing optimised, query-ready data, with the monitoring, logging, alerting, and guardrails that keep those pipelines healthy. AWS guidance is specific about the operating model: form cross-functional teams spanning infrastructure/operations, software engineering, and data management; use metadata to drive pipelines; and build reusable blueprints that abstract pipeline complexity so analysts and scientists can self-serve.

Why it matters

Pipelines are where data platforms succeed or rot. Hand-built, undocumented extracts become the fragile critical path that breaks every quarter-end; nobody owns them, nobody can change them, and every new dataset means another bespoke job. Treating data engineering as a software discipline — version-controlled, tested, parameterised, metadata-driven — converts that liability into a paved road: a new source is onboarded by configuring a blueprint, not by writing a new one-off. This is also where data quality and lineage become enforceable rather than aspirational, and where the difference between “we have data” and “we trust our data” is actually built.

How to do it well

• Make pipelines metadata-driven and reusable. Catalog source contracts and transformation config so one parameterised pipeline serves many datasets; package common integration patterns as AWS Glue blueprints (or reusable CDK/Step Functions templates) that analysts invoke as self-service workflows.
• Choose the right authoring/orchestration tooling for the team. AWS Glue for serverless Spark ETL and the catalog; Amazon MWAA (managed Airflow) or Step Functions for orchestration; EMR Serverless for heavy Spark; Managed Service for Apache Flink for streaming. For low-code, visual lineage-aware flows, Amazon SageMaker (the unified studio that now subsumes the former DataZone experience) provides catalog, governance, and project workflows.
• Build quality and observability in, not on. Define expectations with AWS Glue Data Quality (DQDL rules), emit pipeline metrics/alarms to CloudWatch, and capture lineage so a failed run is diagnosable and a bad dataset is traceable.
• Engineer for failure. Idempotent, restartable tasks; dead-letter handling; checkpointing for streaming; and alerting on pipeline failures — the controls AWS calls out explicitly.

Concrete artifacts, decisions, and AWS tools

Artifacts: a library of reusable pipeline blueprints, orchestrated DAGs/state machines under version control, data-quality rule sets, and a pipeline observability dashboard.

Provisioning and orchestration

What it is

Provisioning and orchestration is the capability to create, manage, and distribute catalogs of approved cloud products to end users. It is the self-service layer that sits on top of platform engineering’s IaC: a centrally-managed portal where teams browse, request, and deploy only approved products — consistently, repeatably, and with governance baked in — rather than constructing resources by hand. AWS calls for making products accessible via APIs and via personalised portals, and for integrating with ITSM tools and automating CMDB updates so the cloud is a first-class citizen of your existing operations.

Why it matters

As an organisation grows, “consistent provisioning” stops being achievable by discipline alone — the surface area is too large and the console too permissive. A curated catalog flips the default: instead of anything is possible unless blocked, only vetted, parameterised products are easy, and each carries its guardrails (least-privilege launch role, tagging, region constraints) intrinsically. This is what reconciles speed with compliance: developers deploy in minutes without raising a ticket, and the platform team knows every deployment conforms because the catalog is the only paved road. It is also the natural integration seam with enterprise ITSM, so cloud provisioning shows up in ServiceNow and the CMDB like everything else.

How to do it well

• Use AWS Service Catalog as the distribution mechanism. Author products from CloudFormation or Terraform, group them into portfolios, share portfolios across the org via Organizations, and assign launch constraints so users provision with a controlled role rather than their own permissions.
• Offer the catalog through the channels teams actually use — the Service Catalog console, the ServiceNow integration (AWS Service Management Connector), the Service Catalog API, and increasingly through an internal developer portal (e.g. Backstage) so provisioning is one click from where engineers already work.
• Automate CMDB and ITSM updates so a launched product opens/updates the right records, and approvals flow through existing change processes.
• Govern the catalog like code. Products are versioned, peer-reviewed, and promoted; TagOptions enforce tagging; and the catalog is itself defined in IaC so the paved roads are reproducible and auditable.

Concrete artifacts, decisions, and AWS tools

Artifacts: a published product catalog (portfolios + versioned products with launch constraints), the ITSM/portal integration, and a tagging/CMDB automation standard.

Modern application development

What it is

Modern application development is the capability to build well-architected, cloud-native applications — and to modernise the ones you already have. Its substance is a set of practices: build with containers and serverless so resources auto-scale from zero to peak; decouple into microservices using event-driven architectures; implement security at every layer and every lifecycle stage; and modernise legacy apps via replatforming (moving your own containers/databases/brokers to managed services) and refactoring (rewriting monoliths to cloud-native designs). AWS also flags an easily-missed reliability concern: design with service quotas and physical resource limits in mind so they never silently throttle a workload.

Why it matters

This is where the agility the whole framework promises is actually realised — or not. Lift-and-shift gets you to the cloud; modern application development gets you the speed, elasticity, and cost-efficiency that justify being there. Containers and serverless turn capacity planning into a runtime concern and let you pay for what you use; microservices and event-driven design let independent teams ship independently; and replatforming managed services (RDS/Aurora instead of self-run databases, MSK instead of self-run Kafka, EKS/ECS instead of hand-built clusters) reclaims the engineering time previously spent tending infrastructure. Done without discipline, though, “microservices” becomes a distributed monolith — so the well-architected qualifier carries real weight.

How to do it well

• Default to serverless; reach for containers when you need to. AWS Lambda + API Gateway + EventBridge + Step Functions for event-driven, scale-to-zero workloads; Amazon ECS or EKS (with Fargate to avoid managing nodes) for containerised services, long-running processes, or portability needs.
• Decouple with events and queues. EventBridge for routing, SQS/SNS for buffering and fan-out, and explicit contracts between services so teams deploy independently — the event-driven posture AWS prescribes.
• Replatform before you refactor where it pays. Move self-managed databases to Aurora/RDS, self-managed Kafka to Amazon MSK, caches to ElastiCache/MemoryDB; reserve full refactoring (decomposing monoliths, often via the strangler-fig pattern) for the components where cloud-native design returns the most.
• Respect the limits. Track and raise service quotas proactively (Service Quotas, plus Trusted Advisor checks) and design for physical constraints so growth never becomes an outage.

Concrete artifacts, decisions, and AWS tools

Artifacts: a reference application architecture (compute model, eventing, API style, per-service data stores), a modernisation backlog classifying each legacy app as replatform/refactor, and a service-quota plan.

Continuous integration and continuous delivery (CI/CD)

What it is

CI/CD is the capability to evolve and improve applications and services faster than organisations using traditional processes — by adopting DevOps with continuous integration, automated testing, and continuous delivery. AWS guidance prescribes a deliberate progression: start with a minimum viable pipeline for CI, then grow into a continuous delivery pipeline with more stages — staging and production steps, manual approvals for production — and choose among deployment strategies: in-place, rolling, immutable, and blue/green. It also nudges a practice: encourage developers to write unit tests early and run them before pushing to the central repository.

Why it matters

CI/CD is the loop that the entire Platform perspective feeds: the landing zone, the catalog, the data pipelines, and the applications are all only as good as your ability to change them safely and often. A team without CI/CD ships in fearful, infrequent, big-bang releases; a team with it ships small, reversible changes many times a day, catches regressions in minutes, and turns deployment from an event into a non-event. Crucially, in the AWS model infrastructure ships through pipelines too — landing-zone changes, Service Catalog products, and Terraform/CDK stacks all flow through the same reviewed, tested, gated machinery, which is what makes “governance as code” trustworthy rather than theatrical.

How to do it well

• Start with a minimum viable pipeline and grow it. Source → build → test as the CI core, then add staging, integration tests, manual approval, and production as you mature — exactly the progression AWS describes.
• Pick a coherent toolchain. Native AWS: CodePipeline (orchestration), CodeBuild (build/test), CodeDeploy (deployment strategies), CodeConnections (Git provider integration), and CodeArtifact (package registry); or GitHub Actions / GitLab CI federated into AWS via OIDC. (Note that AWS CodeCommit is closed to new customers, so new pipelines typically source from GitHub/GitLab/Bitbucket.)
• Choose deployment strategies per workload risk. Rolling for stateless fleets, immutable (replace, never patch) for reproducibility, and blue/green (with CodeDeploy or weighted Route 53 / ALB target-group shifting) for zero-downtime cutover and instant rollback. Lambda and ECS support canary/linear traffic-shifting natively via CodeDeploy.
• Shift security and quality left. Run SAST/secret-scanning (Amazon Inspector, CodeGuru, third-party SAST) and image scanning (ECR) in the pipeline; gate on tests and policy checks so unsafe changes never reach production.

Deployment-strategy comparison

Artifacts: pipeline definitions as code, a branching and testing strategy, a deployment-strategy standard per workload class, and pipeline security gates.

Real-world enterprise scenario

Meridian Logistics is a fictional INR 9,000-crore freight and supply-chain company: ~6,000 employees, a 40-person platform/cloud team being stood up, and a mandate to move 220 applications off two ageing data centres over 30 months. They have completed CAF’s Strategy and Plan work and a Foundational landing-zone build; they now apply the Platform perspective in earnest. Their North-Star metric: cut time-to-first-deploy for a new product team from 11 weeks to under 3 days while keeping every account audit-clean.

Platform architecture. The architecture guild ratifies a target reference architecture grounded in the AWS SRA: an OU tree of Security, Infrastructure, Workloads/Prod, Workloads/NonProd, and Sandbox, with account = workload × stage. They adopt a 10.64.0.0/12 master CIDR carved into per-Region, per-account /20s on a spreadsheet that becomes the IPAM source of truth, a Transit Gateway hub with centralised egress through AWS Network Firewall, and shared Route 53 Resolver endpoints. Identity federates Meridian’s existing Entra ID into IAM Identity Center. Two warehouse-management workloads are flagged to remain on Outposts in regional depots for sub-10 ms scanner latency. Artifact: a 30-page reference architecture + guardrail catalog (28 SCPs/RCPs, 60 Config rules).

Data architecture. Their fragmented reporting estate (an on-prem Oracle warehouse plus 14 nightly extracts) is redesigned as a lake house: S3 + Iceberg via S3 Tables as the lake, raw/cleansed/curated zones, the Glue Data Catalog governed by Lake Formation tag-based access, Athena for ad-hoc SQL, Redshift Serverless for the finance warehouse, OpenSearch for shipment-tracking search, and DynamoDB for the real-time parcel-status store. Streaming telemetry from 40,000 GPS units lands via Kinesis into Managed Service for Apache Flink. Artifact: a layered reference data architecture and lake-house topology diagram.

Platform engineering. They graduate from the Foundational landing zone to AWS Control Tower extended with Account Factory for Terraform (AFT), so a vended account arrives with baseline logging, Config conformance packs, Security Hub, auto-Transit-Gateway attachment, and the right SCPs by OU. Organization CloudTrail writes to a locked Log Archive account. They publish 22 AWS Service Catalog products (compliant VPC, hardened RDS, logging-enabled S3 bucket, EKS-on-Fargate baseline), all defined in Terraform and promoted through a pipeline. Artifact: a governed landing zone, an AFT account-vending pipeline, and a 22-product Service Catalog portfolio.

Data engineering. A new cross-functional data-platform squad (ops + software + data management) builds five Glue blueprints covering their common patterns (CDC from RDS via DMS, flat-file ingest, API pull, streaming aggregate, warehouse load). Pipelines are orchestrated in Amazon MWAA, validated with Glue Data Quality DQDL rules, and monitored in CloudWatch. Onboarding a new source drops from ~3 weeks of bespoke work to ~2 days of configuring a blueprint. Artifact: a blueprint library, MWAA DAGs in Git, and DQ rule sets.

Provisioning and orchestration. The Service Catalog is surfaced three ways — the AWS console, a Backstage internal developer portal, and ServiceNow via the AWS Service Management Connector, which also writes back to the CMDB. TagOptions enforce a mandatory tag schema (cost-centre, owner, data-classification). Launch constraints mean a developer deploys a hardened RDS in minutes using a controlled role, never their own broad permissions. Artifact: a multi-channel catalog with ITSM/CMDB automation.

Modern application development. New services are serverless-first (Lambda + API Gateway + EventBridge + Step Functions) for event-driven freight events; long-running optimisation engines run on EKS with Fargate. The legacy routing monolith is decomposed via strangler-fig, replatforming its Oracle dependency to Aurora PostgreSQL and its messaging to Amazon MSK. A service-quota plan (Service Quotas + Trusted Advisor) pre-raises limits ahead of peak season. Artifact: a reference app architecture and a modernisation backlog tagging each of 220 apps as rehost/replatform/refactor.

CI/CD. Every repo (apps, IaC, Service Catalog products) ships through CodePipeline + CodeBuild + CodeDeploy, sourced from GitHub via CodeConnections (OIDC), with CodeArtifact as the package registry. Stateless services use rolling deploys; the customer-facing tracking portal uses blue/green with CodeDeploy traffic-shifting; security gates run Inspector and ECR image scans. Landing-zone and catalog changes flow through the same gated pipelines.

Measurable outcome (12 months in): time-to-first-deploy for a new team fell from 11 weeks to 2 days; 96 of 220 apps migrated; new data-source onboarding dropped ~90%; 100% of accounts pass Control Tower/Security Hub conformance; and production deploy frequency rose from monthly to 40+ per week with change-failure rate under 8%.

Deliverables & checklist

• Target reference architecture — OU model, IP/network plan, identity-federation model, guardrail catalog (SCPs/RCPs/Config rules), logging design, hybrid/on-prem decisions.
• Reference data architecture — chosen technology per layer (ingestion/storage/catalog/processing/consumption), zoning + catalog standard, lake-house topology.
• Governed landing zone — Control Tower (or equivalent) deployed, Log Archive + Audit accounts, Config conformance, Security Hub aggregation.
• Account-vending pipeline — CfCT or AFT, baseline stack applied at account birth.
• IaC repositories — CloudFormation/CDK/Terraform under version control for all platform infrastructure.
• Identity federation — external IdP integrated with IAM Identity Center; permission-set catalog.
• Data pipeline blueprints — reusable, metadata-driven Glue/Step Functions/MWAA templates + Glue Data Quality rule sets.
• Service Catalog portfolio — versioned, vetted products with launch constraints and TagOptions.
• ITSM/CMDB integration — ServiceNow connector and/or internal developer portal; CMDB auto-updates.
• Reference application architecture — compute model, event-driven patterns, API style, per-service data stores; service-quota plan.
• Modernisation backlog — each legacy app classified rehost/replatform/refactor.
• CI/CD pipelines as code — branching/testing strategy, deployment-strategy standard per workload class, security gates.

Common pitfalls

1. Deferring the account/OU and network design until “after the pilot.” Re-homing live accounts and re-IP-ing VPCs are the most expensive remediations in cloud. Avoid it: ratify the multi-account model and a non-overlapping IPAM plan in platform architecture before vending production accounts, even for a two-team pilot.
2. Treating the landing zone as a one-time setup, not a product. Control Tower deployed once and never iterated drifts and ages. Avoid it: run the landing zone through CfCT/AFT pipelines, version the baseline, and treat account-vending and the Service Catalog as continuously-improved products with owners.
3. Building data pipelines as bespoke one-offs. Hand-crafted extracts become the fragile, un-ownable critical path. Avoid it: invest early in reusable, metadata-driven Glue blueprints and a self-service onboarding path so a new source is configured, not coded — the explicit AWS guidance.
4. A wide-open console instead of a curated catalog. “Governance by discipline” fails at scale; teams build resources inconsistently and accumulate silent risk. Avoid it: make the Service Catalog the paved road with launch constraints so the compliant path is also the easy path, surfaced through the portals teams already use.
5. “Microservices” that are really a distributed monolith. Decoupling in name only — synchronous chains, shared databases, lock-step deploys — adds latency and failure modes without the agility. Avoid it: enforce true decoupling via EventBridge/SQS, independent data stores, and explicit contracts; honour the well-architected qualifier.
6. Pipelines that exclude infrastructure, or skip security gates. If landing-zone and catalog changes bypass CI/CD, “governance as code” is theatre; if pipelines lack SAST/image scanning, speed ships vulnerabilities faster. Avoid it: route all changes (app and IaC) through gated pipelines with Inspector/ECR scanning and approvals for production.

What’s next

Part 6 turns to the Security perspective of the AWS Cloud Adoption Framework — identity and access management, threat detection, vulnerability management, infrastructure and data protection, application security, and incident response — building the controls that the platform you have just engineered must enforce.