A management team wanted to reduce infrastructure cost by moving a large, inefficient application from an on-premises or colocation data center to AWS. The question sounded binary: should the monolith stay on bare metal or move to the cloud? The more important question was what kind of system would be moved.
Lift-and-Shift Does Not Create Efficiency
A company can inventory its physical server, rent a roughly comparable EC2 instance, attach database and storage services, and run the same application there. That is a valid migration technique, but it preserves the application's old behavior. Oversized servers remain oversized. Wasteful database calls remain wasteful. Constantly running capacity continues to run constantly.
The economics can become worse, but it is important to identify the correct meter. If the application and database both run inside one EC2 instance, AWS does not separately bill the bytes moving between those two processes as network data transfer. A poorly constructed SQL call can still be expensive: repeatedly scanning large tables or returning unnecessary rows consumes CPU, memory, and storage I/O. The application may then require a larger EC2 instance, more EBS throughput or provisioned IOPS, and more costly storage performance merely to overcome inefficiency that was inexpensive or hidden on owned hardware.
If the architecture separates the application and database, the consequences depend on placement. EC2-to-RDS transfer within the same Availability Zone is free, while traffic across Availability Zones can incur regional data-transfer charges. NAT gateways, load balancers, cross-Region paths, and other services can add their own data-processing or transfer charges. The same bad SQL can therefore create two different costs: excessive resource consumption wherever the database runs, and metered data movement when the query crosses a billable boundary.
Cloud infrastructure is not inherently cheaper than owned or leased bare metal. It is more granular. The customer pays separately for compute, storage, database capacity, requests, backups, data movement, resilience, and other services. A literal copy of an inefficient architecture can reproduce the same waste with a more detailed bill.
Where the Cloud Creates Value
The savings and operating advantages come from using the cloud differently:
- Capacity can be provisioned in minutes rather than after a hardware purchase and a 36-month lease commitment.
- Servers can be scaled up, scaled down, or shut off as demand changes instead of being sized permanently for a peak.
- Managed services can provide backups, patching, monitoring, failover, and service-level commitments without recreating every capability with an internal on-call team.
- Multiple geographic regions are available without building facilities and staffing operations in each location.
- Automation and usage measurement make it possible to match resources more closely to actual demand.
- Architectures can place tightly coupled services together, cache repeated requests, reduce unnecessary data movement, and use storage or compute classes appropriate to each workload.
None of those benefits appears automatically when a virtual machine is copied into EC2. They require rightsizing, application and query profiling, sensible service placement, and often some modernization of the monolith's most expensive behaviors.
Separating Migration from Modernization
My work was to distinguish migration from modernization. We mapped the application's compute, database, storage, and network behavior; identified wasteful SQL and high-volume traffic paths; and compared the cost of a literal lift-and-shift with a staged architecture that could exploit elasticity and managed services.
The application did not have to be split immediately into dozens of microservices. A monolith can run in the cloud. But it must be operated with an understanding that the meter is always running and that resource boundaries affect both performance and cost.
What the Cloud Actually Changes
Management received a more useful answer than “cloud is cheaper.” The cloud could reduce commitment, improve geographic reach, and transfer some reliability work to managed services. It could also cost more if the company rented a permanent copy of its old data center and left inefficient data flows untouched.
The economic case depended on paying for what the application needed, when it needed it, and fixing the behaviors that had been cheap enough to ignore on premises.
See other Cloud Economics: Cloud-Cost Spike
See other Legacy Modernization: Out-Maneuvered Incumbent · Sustaining Workload
