What the cloud actually changed · Chapter 1 of 1
How renting virtual hardware changes software design
Moving to the cloud changes software from a procurement problem to an architecture decision, forcing engineers to design for dynamic capacity.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
Renting someone else’s computer
What are you actually paying for when you boot a server in the cloud?
Under normal load of 500 rps, the fixed fleet of 4 instances operates at 10% CPU, wasting 90% of capacity.
- 01
Renting physical space and time
When you provision a cloud server, you are not buying physical metal. You are renting a slice of a physical machine running in an AWS data centre. AWS handles the power, physical security, cooling, and hardware maintenance, leaving you with virtual access to CPU, memory, and disk space.
- 02
Sharing physical hardware securely
To make renting efficient, AWS uses virtualisation. A host machine runs hypervisor software, which carves one physical box into dozens of virtual machines. This allows multiple companies to run workloads on the same silicon without seeing each other’s memory or accessing each other’s data.
- 03
The things the cloud does not solve
Renting a server does not fix poorly written code, database locks, or database connection timeouts. If your web application crashes when ten users log in, moving it to AWS will not make it stable. The cloud removes physical constraints but introduces new network dependencies that you must manage yourself.
Check yourself
If a physical host machine in an AWS data centre suffers a hardware failure, what happens to your virtual machine running on it?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
The economics of virtual capacity
Why does renting capacity by the second change how you size your systems?
Under normal load of 500 rps, the fixed fleet of 4 instances operates at 10% CPU, wasting 90% of capacity.
- 01
Buying for the busiest hour
Before cloud computing, company data centres were designed for the peak hour of the entire year. An e-commerce system needed enough physical servers to handle Black Friday traffic. For the remaining 364 days of the year, up to 90% of that physical hardware sat idle, consuming power and space.
- 02
Shifting risk to the provider
Elasticity means you can boot a virtual machine in 60 seconds and destroy it 10 minutes later. AWS bears the cost of maintaining massive pools of idle servers so that you do not have to. This shifts the risk of capacity planning from your balance sheet to their infrastructure.
- 03
Designing for clean shutdown
To benefit from elasticity, your software must tolerate short lifecycles. A server might launch at 09:00 and terminate at 09:15 when demand drops. Your application must store session data externally, start up within seconds, and shut down cleanly when receiving a termination signal.
- Paid for, unused
- $556 / week
- Requests dropped
- 48,800
- Hours over capacity
- 32
The numbers
- Virtual machine boot time
- 30 to 90 secondsThis delay means you cannot react instantly to traffic spikes; you must scale ahead of demand.
- Minimum billing duration
- 60 secondsInstances are billed per second after the first minute, making short-lived tasks cost-effective.
- Average on-premises server capacity used
- 10% to 15%Traditional on-premises hardware is heavily underutilised to ensure peak traffic can be served.
Check yourself
Why does elasticity require applications to be stateless and store data externally?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →