Cloud Strategy - Part III: Architecting for the Cloud

Cloud architecture is more than running applications on someone else’s infrastructure. This article explains the architectural principles that make cloud adoption effective: automation, elasticity, managed services, resilience, security, Infrastructure as Code, stateless design, serverless, migration strategy, cost optimization.

This series provides an annotated summary, review and analysis of Gregor Hohpe’s book, Cloud Strategy, available at leanpub.com/cloudstrategy.

Executive summary

Cloud architecture is not simply about running applications on someone else's infrastructure. Cloud-native systems are designed around automation, elasticity, managed services, resilience, security, and continuous evolution. This final post in the series explores the architectural principles that enable organizations to benefit from cloud computing, including Infrastructure as Code, stateless design, Zero Trust security, automation-first operations, serverless computing, and modern migration strategies. It also examines how organizations can measure migration success, optimize cloud costs, and progressively mature their cloud capabilities through the Crawl-Walk-Run adoption model.

Principles of Cloud Architecture

“There are many ways to the cloud. The worst you can do is transport your existing processes to the cloud, which will earn you a new data center, but not a cloud.” — Gregor Hohpe

Hohpe outlines key principles for cloud architecture and migration. While an application’s core functionality remains largely the same whether on-premises or in the cloud, the implementation methods should shift significantly to account for different constraints. Cloud applications must be designed for self-healing, high availability, scalability, and cost-efficiency.

Automation

Cloud platforms redefine infrastructure through the lens of the API. With few exceptions, every manual action performed within the web console can be fully automated using command-line interfaces or Infrastructure as Code tools like Terraform.

Automation is the bedrock of modern cloud architecture, extending from the application layer to the core infrastructure. While the initial investment requires more effort than manual provisioning, the long-term dividend in velocity, stability, and system resilience is significant. An automated environment is not only easier to replicate at scale but also inherently self-healing and faster to restore. Through integrated monitoring, systems also gain the ability to dynamically adjust capacity according to demand or automatically restore servers following a failure. 

Utilizing Infrastructure as Code (IaC), with tools such as Terraform, transforms infrastructure provisioning into a scalable and repeatable operation. In this model, the version-controlled repository serves as the definitive source of truth. Furthermore, the implementation of drift detection facilitates the automated correction of manual configuration errors, while mandatory peer reviews ensure that every modification is approved prior to deployment.

Automation serves several important goals in a cloud operating model:

• Speed: enables faster delivery and supports rapid innovation.
• Repeatability: reduces manual variation, removes many human errors, and improves quality.
• Confidence: makes deployments more frequent, predictable, and less stressful.
• Resilience: reduces recovery time after outages by making rebuild, redeployment, and failover processes faster and more reliable.
• Transparency: creates a clear record of what changed, when it changed, and who approved it, making troubleshooting easier.
• Continuous improvement: makes processes easier to refine, because improving an automated workflow is usually simpler than correcting many manual habits.
• Compliance: embeds security, policy, and quality checks directly into the deployment process instead of relying only on late manual reviews.

Every cloud provider exposes its services through public APIs, which makes automation and Infrastructure as Code possible. The simplest approach is to use CLI commands and shell scripts. Most programming languages also provide SDKs for cloud APIs, for example Boto3 library for Python. This can be useful for small tasks, experiments, or operational shortcuts, but it does not scale well as environments become larger, more regulated, or shared across multiple teams. To fully benefit from cloud automation, organizations usually need more structured tools such as CloudFormation, AWS CDK, Terraform, OpenTofu, Pulumi, or similar frameworks. These tools add complexity, but they also provide version control, repeatability, reviewability, modularity, and a safer way to manage infrastructure over time.

Stateless applications

In distributed environments, managing state remains a complex task; consequently, cloud-native architectures gain significant advantages by prioritizing statelessness.

The benefits of stateless applications include:

• Elastic scaling: adjusting capacity upward or downward as needed.
• System repair: quickly replacing malfunctioning components with fresh instances.
• Version roll-backs: shutting down current instances to redeploy previous versions.
• Balanced load distribution: directing requests to any available backend without the constraints of local state.

I believe, although this is a broad architectural topic, that many monolithic applications can be gradually re-architected or refactored so that state is moved out of the application server and into external services. The goal is not to eliminate state entirely, but to avoid storing it inside a specific server, container, or runtime instance. When application state is externalized, any instance, container, or function can handle any request. This makes the application easier to scale, replace, recover, and deploy.

Use managed services

Managed services from providers like AWS offer extensive suites that expedite application prototyping and deployment while reducing the administrative burden of configuration. These offerings allow for cost-effective experimentation with new architectures, often proving cheaper than on-premise licensed or open-source alternatives. 

While vendor lock-in remains a frequent corporate concern, Gregor Hohpe suggests (and I totally agree) that the operational advantages generally eclipse the risks. Effective application design can mitigate these issues by isolating managed service dependencies within wrapper modules, which simplifies the process of swapping components if a migration becomes necessary. Given that most major cloud providers offer comparable features across their service catalogs, the strategic value and time savings provided by these managed solutions often outweigh the potential for restricted flexibility. Furthermore, many managed services are built on open-source technologies that retain varying degrees of compatibility with other cloud providers and on-premises environments.

The author explores the multifaceted nature of lock-in within IT architecture, emphasizing that it is a nuanced business of trade-offs rather than a binary state to be avoided at all costs. Experienced architects recognize that some degree of lock-in is inevitable and that avoiding it through creating options carries costs in money, complexity, and potentially new forms of lock-in. The book identifies several specific types of lock-in:

• Vendor lock-in: The difficulty and expense of switching from one vendor to a competitor, often reinforced by commercial arrangements.
• Product lock-in: Being tied to a specific product's APIs and features, a risk that persists even with open-source software.
• Version lock-in: Costs associated with upgrades that break customizations or the risk of a product line being discontinued.
• Architecture lock-in: The high cost of overhauling application structures, such as moving from services to serverless.
• Platform lock-in: Dependencies on cloud platforms for user accounts, security policies, and data.
• Skills and Mental lock-in: The time required to retrain staff and the subtle danger of absorbing unconscious assumptions that limit alternative options.

Ultimately, the architect's role is to find a "Return On Lock-In" (ROL) by balancing the benefits of a specific product or vendor against the cost of reducing that lock-in.

AWS, for example, is not only virtual servers. It is a broad platform of services for compute, storage, networking, databases, security, analytics, AI, automation, governance, and application integration. The strategic value comes from combining these services into architectures that reduce operational burden and accelerate business delivery.

Defense in depth

Traditional on-premises security typically relies on a network perimeter where internal entities are inherently trusted. In contrast, cloud environments are internet-facing and feature hardened perimeters with service-to-service communication, creating a much more ambiguous distinction between internal and external boundaries. Applications and their individual components should adopt the same mindset by prioritizing authenticated communications and maintaining resilience during failures. 

AWS describes Zero Trust as a model where access is not based only on network location, but on strong identity, fine-grained authorization, and contextual signals. Do not trust a request just because it comes from “inside the network.” Authenticate, authorize, encrypt, observe, and design for failure at every service boundary.

Evolving architecture

The dynamic nature of cloud environments and managed services necessitates the continuous evaluation and refinement of cloud-native applications. As cloud providers frequently introduce new service features, adjust pricing structures, or phase out older offerings, organizations that fail to adapt their architectures risk incurring unnecessary costs, missing strategic opportunities, and accumulating technical debt through obsolete workarounds. 

AWS continuously introduces new instance families, processors, and managed services that often improve price-performance.

Looking only at nominal prices we see a reduction of 42%: from $0.133 to $0.077. Considering inflation it is an adjusted reduction of about 60%. 

Even more interesting is performance per dollar. Over the last decade, AWS has not only reduced the real cost of compute by roughly 60%, but has also continuously increased the performance available from each instance generation. The combined effect is that a dollar spent on EC2 today can deliver several times more useful computing capacity than the same inflation-adjusted dollar spent ten years ago. Unlike traditional data centers, customers can often benefit from these improvements simply by migrating workloads to newer instance families rather than purchasing new hardware.

Of course, part of this improvement reflects the broader trend in CPU and hardware technology. Server CPU performance per dollar has also improved significantly over the last decade, probably in the same broad order of magnitude as raw EC2 compute improvements.

However, CPU price-performance is only one part of the real cost of compute. In an on-premises data center, the total cost also includes facilities, power, cooling, networking, storage, software licenses, support contracts, operations staff, spare capacity, and hardware refresh cycles. These additional costs mean that the full cost per useful unit of compute may not fall as quickly as the CPU benchmark-per-dollar alone.

AWS also benefits from massive economies of scale, high utilization across a global customer base, custom hardware such as Nitro and Graviton, and continuous optimization of its infrastructure platform. A single enterprise data center usually cannot match that scale or refresh cycle. Therefore, while hardware improvements benefit both cloud providers and on-premises environments, cloud platforms can often convert those improvements into lower cost, higher performance, and more usable capacity faster.

Application-centric approach

While an infrastructure-oriented strategy is rooted in a traditional data-center perspective—focused on replicating on-premises components like servers, storage, and firewalls within AWS—an application-centric approach prioritizes business results. This outcome-driven perspective asks: “What is required for this application to provide value, scale effectively, maintain resilience, and evolve over time?”

Shifting to an application-centric model significantly alters the cloud computing landscape by focusing on accelerating software delivery and minimizing operational friction. This transformation is powered by automation—including Infrastructure as Code (IaC) and fully automated toolchains—alongside horizontally scalable, cloud-ready applications. When integrated with Lean development and CI/CD practices, these tools fundamentally redefine how an enterprise approaches software delivery.

Shift-left approach

Traditional on-premises application design typically relies on limited, pre-existing components, followed by sequential security and operations reviews that can cause bottlenecks. In contrast, cloud environments offer a vast array of architectural options, enabling the use of pre-approved templates and modules to accelerate delivery. By integrating automated security checks directly into the deployment toolchain, organizations can validate quality and security—often before infrastructure is even provisioned—effectively 'shifting left' and embedding these practices at the start of the development process.

A good AWS example is a Landing Zone + Infrastructure as Code + CI/CD pipeline with embedded security controls. In a traditional approach, a development team wants a new application environment and the approval process can take weeks, if not more: network changes, firewall, security review, compliance review, operations, infrastructure provisioning.

With the shift-left approach, available in the cloud, the organization creates a library of approved building blocks (network, computing, database, logging, monitoring, etc.), already implementing best practices and compliance (encryption, tagging, backup, security, etc.) and developers assemble these components rather than designing everything from scratch.

Robustness

“Everything fails all the time.” — Werner Vogel, Chief Technology Officer at Amazon

A critical part of operating the cloud is expecting and preparing for failure. In the cloud context, robustness means the ability of an application or system to continue working correctly, or degrade gracefully, when things go wrong. Reliability is often measured using metrics such as Mean Time Between Failures (MTBF), although modern cloud systems typically use multiple reliability and availability indicators.. 

In cloud architecture, robustness is the ability of an application to tolerate failures, traffic changes, latency, and dependency problems without collapsing, using design patterns such as redundancy, retries, queues, autoscaling, health checks, and graceful degradation.

Resiliency

Resilience is the ability of a cloud system to recover from failure and return to a healthy state, while robustness is the ability to keep behaving well under stress or imperfect conditions. Resilient applications add a self-correcting loop that returns the system to the desired state, and require complex coordination between components and external applications.

Resilience is about recovery and continuity:

• automatic failover;
• backup and restore;
• multi-AZ or multi-region design;
• disaster recovery;
• self-healing infrastructure;
• tested RTO and RPO;
• incident response and recovery procedures.

Resilience can be measured with metrics that show how often failures happen, how much impact they create, and how quickly the system recovers.

Serverless

Serverless computing means you build and run applications without managing the underlying servers yourself. You focus on code, configuration, events, data, and business logic; AWS handles provisioning, scaling, patching, capacity, availability, and much of the operational plumbing. 

Why serverless is useful:

• No server management: less OS patching, capacity planning, and infrastructure maintenance.
• Automatic scaling: good for variable or unpredictable traffic.
• Pay-per-use: often cost-effective for intermittent workloads.
• Faster development: teams can assemble applications from managed services.
• Event-driven architecture: useful for APIs, automation, data processing, integrations, and background jobs.

But serverless is not magic. You still need to design carefully for:

• cold starts;
• time limits;
• observability;
• security and IAM permissions;
• distributed debugging;
• vendor lock-in;
• cost surprises at high volume;
• state management, because functions are usually stateless.

Containers

Docker serves as a foundational technology for transitioning to the cloud. By encapsulating application artifacts within Docker images, organizations can streamline deployment and integrate seamlessly with various managed cloud services, including serverless offerings.

Within the AWS ecosystem, there are several ways to execute containerized workloads:

• Standard Instances: Running directly on EC2 server instances.
• Managed Services: ECS manages container scheduling while EC2 instances remain customer-managed.
• Serverless: Running containers on AWS Fargate without managing the underlying servers.
• Orchestration: Employing EKS for managed Kubernetes clusters in complex microservices architectures.

Advantages of docker containers:

• Image inheritance: A clever feature allowing the use of base images. Instead of manually identifying every file, developers can reference a base image to include necessary runtimes and libraries via a single line in a Dockerfile.
• Lightweight virtualization: Utilizing Linux kernel mechanisms to limit resource usage (CPU, memory) and namespaces to provide isolated views of resources like network ports or file paths.
• Enclosed and predictable: Like a physical shipping container, Docker containers enclose code, libraries, and dependencies, ensuring that deployments are predictable, repeatable, and free from missing configuration files.
• Uniform and standardized: Containers are highly standardized in their dimensions and exterior features. This allows platforms to remain efficient and flexible, as the same "crane" or platform can handle any container regardless of its internal contents.

Migration strategies

Before migration

Application inventory

Before planning your migration, you should have a detailed application inventory:

• Application name and business owner
• Technical owner / support team
• Business criticality: critical, important, low priority
• Business function supported
• Users and usage patterns
• Current hosting location: data center, vendor, SaaS, branch office
• Architecture overview: servers, databases, middleware, storage
• Application dependencies: upstream/downstream systems, APIs, batch jobs, file transfers
• Data classification: personal data, financial data, confidential data, regulated data
• Compliance requirements: GDPR, PCI DSS, ISO, sector-specific rules
• Availability requirements
• RTO and RPO
• Performance and latency requirements
• Current resource usage: CPU, memory, storage, network, database size
• Peak usage periods
• Licensing constraints
• Operating system and software versions
• Security controls: authentication, encryption, firewall rules, secrets
• Backup and disaster recovery setup
• Monitoring and logging setup
• Known issues and technical debt
• Cost of current operation
• Change frequency / release frequency

This provides a mapping of application relationships, which can be used in conjunction with the following criteria to determine migration priority.

Migration metrics

You should define in advance a set of metrics to track the migration progress. 

For instance, you might track the number of workloads migrated or the percentage of applications moved by a set date. While simple to monitor, such metrics can be misleading. The objective is not just to migrate workloads but to deliver genuine business value—something end users may not perceive. These are known as 'proxy metrics,' and the strategy should be to prioritize metrics that meaningfully impact the business.

Relying exclusively on IT-focused metrics can create a disconnect between technical teams and business leadership, as these figures often fail to reflect tangible business value. Without clear visibility into these outcomes, leadership support may diminish, potentially stalling or delaying the migration.

The seven R of application migration

Now, a general migration strategy for each application should be decided. As someone deeply immersed in the AWS ecosystem, I will reference the AWS "7 Rs" framework for cloud migration, although most major providers utilize nearly identical methodologies. 

Migration criteria

For many organizations, a major component of cloud strategy is deciding which applications should be migrated, modernized, retained, or retired, but simply moving IT assets often results in creating just another, more expensive, data center. Organizations should leave behind assumptions such as the necessity of operating servers and utilizing packaged applications. 

To determine migration priorities, Hohpe provides a structured criteria framework for evaluating which on-premises assets to move first.

Tier

Directing internet traffic from the internet to your front-end in the cloud reduces latency and congestion on the on-prem network. Front-end components can scale much easier in the cloud, assuming the backend can support the load. A possible issue is the increase in latency between front-end and back-end.

Generation

Modern applications are more likely to fit the new cloud architecture: microservices, container orchestration, continuous integration, etc. Older components will likely require a more complex refactoring. 

Criticality

Migrating less critical applications first serves as a strategic training ground, enabling teams to cultivate the specialized skills necessary for managing more complex workloads. This phased approach simultaneously leverages cloud-native benefits—such as enhanced security and elastic scalability—thereby reducing the overall operational burden on IT teams.

Life Cycle

Testing development environments in the cloud offers significant advantages, including reduced privacy concerns—since real production data should not be used—and cost savings from leveraging Infrastructure as Code to provision and de-provision temporary resources. However, the primary drawback is the risk of testing in an environment that may diverge significantly from production configurations.

Data Classification

Migrating non-sensitive data and applications to the cloud helps meet data residency requirements and minimizes potential exposure from cloud breaches. However, since on-premises environments are not inherently more secure than the cloud, retaining sensitive data on-premises does not eliminate overall security risks.

Data Freshness

Cloud platforms are ideal for backups, leveraging cost-effective storage tiers, managed backup services, robust encryption, and built-in automation. For example, using services like AWS Glacier to store rarely accessed historical records can generate substantial savings. Furthermore, critical data can be shielded from ransomware attacks using immutable backup solutions, such as Amazon S3 Object Lock or AWS Backup Vault Lock.

Operational State

Disaster recovery in the cloud is highly effective, as it leverages automated scalability to minimize costs during normal operations while allowing for the (relatively) rapid restoration of workloads during an on-premises outage. The total cost of this approach is determined by the chosen disaster recovery model:

Backup and Restore — keep backups of data and infrastructure definitions; restore systems after a disaster. Lowest cost, highest RTO/RPO.

Pilot Light — keep the critical core components running in AWS, such as databases or minimal infrastructure, and scale the rest during recovery.

Warm Standby — keep a smaller but fully functional version of the production environment running, then scale it up during a disaster.

Multi-site Active/Active — run production workloads in multiple locations at the same time, serving traffic from more than one site. Highest cost, lowest RTO/RPO.

Workload Demand

Cloud elasticity is perfectly suited for handling short-duration burst workloads, avoiding the inefficiency of maintaining over-provisioned on-premises infrastructure. Furthermore, AWS offers "Spot Instances," a specialized pricing model that can yield savings of up to 90% compared to on-demand pricing.

Cloud platforms are also ideal for applications with uneven or periodic traffic patterns—such as day-night cycles, press releases, or seasonal events like Black Friday. Elasticity dynamically scales capacity to match demand, significantly lowering costs associated with underutilized infrastructure. Scaling policies can be configured based on predefined schedules or real-time monitoring metrics, such as request volume or CPU utilization.

Even more migration criteria

I will add some extra criteria myself.

User location

Applications serving a global user base with strict low-latency requirements significantly benefit from the cloud's distributed regions and availability zones. Deploying resources geographically closer to users minimizes latency while simultaneously enhancing overall system availability.

Security posture

Applications that have historically been targeted by hackers and were difficult to recover on-premises (for example, DDoS attacks or server-side script injections) will greatly benefit from the cloud's global reach and scalability, further enhanced by services like AWS Shield and Web Application Firewalls. Subscription-based support on AWS also helps mitigate the additional costs associated with DDoS attacks.

Cloud environments generally offer a more robust security posture than traditional on-premises setups, if correctly configured and managed. Modern attack vectors—such as hardware-level vulnerabilities and compromised supply chain—place conventional data center perimeter defenses at a disadvantage. Conversely, cloud providers embed security directly into their infrastructure, often utilizing custom hardware—such as the AWS Nitro System—specifically designed to enhance the security of computing resources.

Data analytics

Applications that rely heavily on data analytics, machine learning, or AI benefit significantly from the cloud's cost-effective storage options and managed services (Athena, Bedrock, Sagemaker). These large-scale machine learning and AI models are complex systems that are challenging to replicate in on-premises environments.

Cloud architecture components

Creating a strategy for an application-centric cloud involves more than just the construction and execution of software. For example, these components should all be part of a production-ready architecture: 

• Application
• Communication
• Delivery Pipeline
• Monitoring/Operations
• Run-time platform

Delivery pipeline

The objective is to establish a pipeline that facilitates Continuous Integration and Continuous Delivery (CI/CD). This involves a unified process to build, test, package, and deploy code, while embedding quality assurance and security protocols throughout the lifecycle.

Run-time platform

Running software requires an environment to manage workload distribution, failure recovery, and traffic routing. This domain encompasses virtualization, virtual machines, containers, and serverless runtimes.

Monitoring/operations

Running complex applications requires visibility into their performance and health. Monitoring helps detect issues like load spikes, memory depletion, or increased CPU usage before they lead to downtime. This involves log processing, time series databases, and dashboards.

Communication

Applications and services require secure, dynamic, and transparent communication with other systems and the public via APIs. This interaction—ensuring message protection, version testing, and dependency visibility—is managed through API gateways, proxies, and service meshes.

Application

Applications (or services) are the focal point. Their structure and behavior must be optimized for cloud environments to be effective. 

Cloud-ready applications should be designed with FROSST characteristics: frugal in their resource usage, relocatable across environments, observable in production, seamlessly updatable, internally secured, and tolerant of failure.

Budgeting the Cloud

Cloud savings must be earned; they do not appear automatically. Costs need to be reviewed regularly to identify mistakes, waste, and opportunities to resize, optimize, or re-architect existing applications. Cost control is a shared responsibility across engineering, operations, finance, and business teams, but it is often useful to establish a dedicated group of cloud and financial management experts: the FinOps team.

When a monolithic application is first migrated to the cloud, unexpected costs may appear. This does not necessarily mean that the cloud is more expensive by nature. Managed cloud infrastructure has a significant cost, despite the provider’s economies of scale. High and unexpected initial costs are often a signal that the application architecture and resource sizing need to be reconsidered. On-premises environments are commonly designed for peak capacity because hardware must be purchased in advance. In the cloud, where capacity can scale up and down with demand, the same assumptions can lead to overprovisioning and waste. The opportunity is to use cloud elasticity, managed services, and better sizing to align cost more closely with actual business usage.

Cloud computing provides transparent, detailed billing, making it possible to understand where money is being spent and where optimization opportunities exist. Instead of seeing infrastructure as a fixed cost, teams can analyze usage patterns and identify improvements at the software, architectural, and operational level.

The first and often easiest variable to optimize is resource size. Teams can look for overprovisioned compute, memory, storage, or database capacity, then resize resources to better match the real needs of the application. In many cases, this means choosing a better CPU and RAM combination, reducing unused capacity, or using autoscaling to adapt capacity to demand.

Another powerful lever is runtime: how long an environment actually needs to be active. Development and test environments usually do not need to run outside office hours. They can often be stopped, scaled down, or recreated when needed. For example, an environment that runs only during business hours instead of 24/7 can significantly reduce its monthly cost, sometimes to roughly one quarter of the original spend, depending on the schedule and services used.

Architecture is one of the most important factors in cloud cost optimization. The biggest savings usually do not come from small infrastructure adjustments, but from choosing a model that better fits how the workload actually behaves.

Data analytics is a good example. Analytics workloads may require significant computing power, but often only for short periods of time. In an on-premises environment, this can leave expensive hardware idle for much of the day, because capacity must be purchased for peak demand. In the cloud, a managed, pay-as-you-go service such as Amazon Athena can reduce this waste by running queries only when needed and charging based on usage. This kind of architectural change can create much larger savings than simply resizing servers.

Another important factor is that cloud platforms are continuously optimized by the provider behind the scenes. Over time, new instance families, processors, storage options, managed services, and pricing models are introduced, often offering better performance, lower cost, or both. For this reason, cloud cost optimization should not be treated as a one-time activity completed at migration. Teams should periodically review whether newer services or instance types can improve the cost-performance ratio of their workloads. The goal is not to migrate for its own sake, but to keep taking advantage of the new opportunities the cloud platform makes available.

Cost optimization should consider the full picture, not only the infrastructure bill. A meaningful comparison must include both cloud resource costs and engineering or administration costs.

For example, a platform such as Kubernetes may appear more expensive at the infrastructure level because it requires multiple specialized nodes, operational tooling, monitoring, security configuration, and ongoing maintenance. However, in some organizations it can still be economically justified if it standardizes deployments, improves automation, reduces manual work, increases reliability, and lowers the time teams spend releasing and operating applications.

The real question is not simply “Which option has the lowest monthly infrastructure cost?” but:

Which option delivers the required reliability, speed, security, and maintainability at the lowest total cost of ownership?

The transition to a cloud-based model presents several challenges to traditional enterprise financial planning routines due to its consumption-based nature:

• The usage-based model eliminates the cost predictability associated with capitalized infrastructure, where expenses vary with actual usage rather than following fixed depreciation schedules.
• Cloud services utilized for software delivery can result in an apparent increase in total operational costs compared to capitalizable project costs.
• The visibility provided by shared and cloud services exposes previously hidden costs, which may be challenging for some organizations to confront.

In the traditional on-premises model, infrastructure is usually acquired through long-term investments and fixed commitments. As a result, a 10% reduction in usage does not automatically produce a 10% reduction in cost. Servers, storage, licenses, facilities, and support contracts often remain in place even when demand decreases.

This rigidity can make difficult periods harder to manage financially. When a company needs to shrink, reduce activity, or respond to lower demand, much of the infrastructure cost may remain fixed. Cloud computing does not eliminate cost management challenges, but its consumption-based model can make it easier to align spending with actual usage over time.

Migration phases

The “crawl, walk, run” model is a common maturity/adoption metaphor rather than a single formal IT standard. In cloud strategy, it is used to describe a phased approach: first establish basic capability, then standardize, validate and scale, and finally optimize and industrialize cloud usage.

Crawl

For a company with no existing cloud presence or experience, the Crawl phase is primarily about learning, experimentation, and building the foundations required for future adoption. The goal is not large-scale migration, but reducing uncertainty, developing skills, validating assumptions, and establishing the minimum governance needed to operate safely in the cloud.

Key activities include:

• Define the initial cloud strategy and business objectives.
• Create initial governance processes covering security, cost management, and operational ownership.
• Set up cloud sandboxes where teams can experiment safely without impacting production systems.
• Build foundational cloud skills through training, certifications, workshops, and hands-on exercises.
• Form an initial Cloud Center of Excellence (CCoE) or cloud working group to guide adoption.
• Deploy demonstration applications, proofs of concept, or internal workloads to gain practical experience.
• Establish basic cost visibility, tagging standards, budgets, and reporting mechanisms.
• Implement fundamental security controls such as identity management, logging, encryption, and least-privilege access.
• Evaluate how cloud capabilities could enable new products, services, business models, or operating models.
• Begin creating reusable templates, automation patterns, and Infrastructure as Code practices.

Typical outcomes of the Crawl phase include:

• A documented cloud strategy and roadmap.
• A functional sandbox landing zone and governance baseline.
• Initial cloud-skilled teams and internal champions.
• Development and test environments running in the cloud.
• Early operational experience with cloud services.
• A clearer understanding of migration opportunities, risks, costs, and business value.

AWS Cloud Adoption Framework (CAF) maturity: Not Started — Start. The organization is building awareness, skills, governance, and foundational capabilities before moving to broader cloud adoption.

Walk

In the Walk phase, the organization moves beyond experimentation and begins adopting cloud in a structured and repeatable way. The objective is to establish common standards, validate the operating model with real workloads, and prepare for larger-scale migration.

At this point, you should prepare a fully-featured landing zone, scaled from the previous sandbox environment or built from scratch. 

Key activities include:

• Refine and expand the landing zone based on lessons learned during the Crawl phase.
• Establish reusable patterns, templates, Infrastructure as Code modules, and reference architectures.
• Standardize automation for provisioning, deployment, security controls, and operational tasks.
• Implement centralized monitoring, logging, alerting, backup, and cost management practices.
• Define tagging standards and resource ownership models to improve visibility and accountability.
• Formalize the cloud operating model, including processes for governance, security, support, and change management.
• Create cloud platform teams, application teams, and governance functions with clearly defined roles and responsibilities.
• Execute pilot migrations of real applications, typically starting with development, test, or lower-risk production workloads.
• Assess each application and define an appropriate migration strategy, such as rehost, replatform, refactor, replace, retain, or retire.
• Define target architectures for migrated applications and identify modernization opportunities.
• Continue developing cloud skills through hands-on experience, mentoring, and advanced training.

Typical outcomes of the Walk phase include:

• A mature landing zone supporting multiple teams and workloads.
• Standardized deployment and operational practices.
• Reusable automation and Infrastructure as Code libraries.
• Clearly defined ownership and responsibility models.
• Successful pilot migrations demonstrating business value.
• Migration roadmaps and target architectures for the broader application portfolio.
• Increased confidence in operating cloud environments at scale.

AWS Cloud Adoption Framework (CAF) maturity: Start — Advance. The organization begins to operationalize cloud adoption, moving from isolated experiments toward repeatable processes, standardized architectures, and coordinated migration efforts.

Run

In the Run phase, cloud adoption becomes a core business capability rather than a migration program. The focus shifts from testing to moving production workloads and continuously improving how the organization delivers, operates, secures, and governs cloud services at scale.

The foundational platform, operating model, and governance practices established during the earlier phases are now mature enough to support broad organizational adoption with a high degree of automation and self-service.

Key activities include:

• Complete the migration and modernization of production applications according to the defined roadmap.
• Expand self-service capabilities so teams can provision and manage approved resources with minimal manual intervention.
• Implement policy as code and automated guardrails to enforce security, compliance, and governance requirements consistently.
• Mature FinOps practices, including cost allocation, forecasting, optimization, chargeback or showback models, and business value tracking.
• Continuously improve platform capabilities, reusable patterns, automation frameworks, and developer experience.
• Perform regular resilience testing, disaster recovery exercises, failover validation, and game day simulations.
• Measure and improve operational metrics such as deployment frequency, recovery time, service availability, security posture, and platform adoption.
• Review cloud architectures regularly to take advantage of new services, capabilities, and cost optimization opportunities.
• Establish continuous learning programs to maintain cloud, security, platform, and FinOps expertise.
• Evaluate cloud adoption against business objectives and customer outcomes, not just technical metrics.

Typical outcomes of the Run phase include:

• A mature cloud platform supporting multiple teams through self-service and automation.
• Organization-wide adoption of cloud engineering, security, and operational best practices.
• Strong governance enforced primarily through automated controls rather than manual approvals.
• Mature FinOps and cost optimization capabilities.
• Proven resilience through regular testing and operational readiness exercises.
• Continuous modernization and architectural improvement.
• Measurable business outcomes such as faster delivery, improved customer experience, greater operational efficiency, and increased organizational agility.

AWS Cloud Adoption Framework (CAF) maturity: Advance — Excel. Cloud becomes an integrated business capability characterized by automation, platform thinking, continuous optimization, and data-driven decision making.

Conclusion

Successful cloud adoption requires much more than moving servers into a different data center. Organizations must rethink architecture, operations, governance, security, cost management, and even the way teams collaborate. The greatest benefits of the cloud are rarely achieved through migration alone; they emerge when organizations embrace automation, managed services, resilience engineering, continuous improvement, and product-centric thinking. Cloud strategy is therefore not a destination but an ongoing capability. The organizations that derive the most value from the cloud are those that continuously adapt, learn, and evolve alongside the platforms they consume.