2006: Rent the machine by the request

Amazon's2006 S3 and EC 2 announcements presented storage and compute as services reached through programmable interfaces. These products did not invent every form of rented computing. Their importance lies in the combination of self-service provisioning, standardized resources, metering, and an operating organization supporting the interface. The announcement documents are primary evidence of the original offering; their historical prices and limits should not be mistaken for current product terms.

An API request can replace part of a procurement workflow. Instead of ordering a server, waiting for delivery, installing it, and arranging power and networking, a customer requests a resource from a shared pool. The work does not disappear. The provider performs capacity planning, hardware replacement, fleet management, and much of the underlying operations. The customer still chooses access policies, application architecture, data handling, and acceptable failure behavior.

Use a fictional workload requiring 100 servers for two hours and ten servers for the other 22 hours each day. Its demand is 100×2+10×22=420 server-hours. Owning enough capacity for the peak supplies 2400 server-hours daily, so average utilization is 17.5% under this simplified model. Metered resources can align expense more closely with 420 hours, but only if provisioning, shutdown, licensing, and performance permit that usage pattern. Idle resources left running destroy the assumed saving.

Now distinguish the data plane from the control plane. Existing application instances might continue processing while a provisioning API is unavailable, or the application might fail because it calls that API on every request. A design's dependence on control operations must be explicit. Identity services, region selection, quota limits, storage access, and deployment procedures introduce other boundaries that can fail independently of the physical server.

An object store is also not a mounted disk merely because both hold bytes. Operations, naming, consistency guarantees, access control, and failure responses belong to its documented contract. Applications need retry-safe behavior when a request succeeds but its response is lost. Redundancy within a provider's design does not automatically produce a tested customer backup or recovery procedure.

Cost comparison needs more than hourly compute. Include storage, requests, transfer, staff, support, idle commitments, migration work, and the value of faster experiments. A stable highly utilized workload can favor a different arrangement from a bursty one. Exit costs depend on portable data formats, reproducible deployment, identity assumptions, and services whose behavior is difficult to replace.

The cloud changes the location of responsibility. Draw a failure case and assign each recovery action to provider or customer according to the actual service contract. Then test the customer-owned steps. Renting resources can shorten access to computing, but dependable applications still require explicit state, observability, budgets, and recovery plans. The useful conclusion is conditional on workload and ownership, not that cloud is universally cheaper or universally more reliable.

Reconstruction exercise

Calculate the fictional workload’s daily server-hours and peak-owned utilization. At a made-up rate of two cost units per used server-hour, compute the metered compute bill. An owned installation has a daily fixed cost of 700 units excluding staff. Which looks cheaper under this narrow model, and what three omitted factors could reverse the answer? Describe a recovery dependency that remains with the application team.

Worked solution

Demand is 420 server-hours, and 100 owned servers supply 2400 hours, giving 17.5% utilization. Metered compute costs 420×2=840 units, exceeding the hypothetical owned fixed cost 700 despite lower idle capacity. Staffing, hardware lifecycle costs, storage and transfer, reserved commitments, provisioning delays, or different performance per server could reverse this narrow comparison. Low utilization alone does not prove lower total cloud cost. The application team may still need to restore a logically corrupted dataset from a suitable backup, rebuild deployment configuration, and verify that restored records satisfy business invariants. Provider hardware replacement does not identify the correct application state or choose a recovery point for the customer.

Test the limits and transfer the idea

1. Capacity trace · allow 30 minutes

Delayed scaling creates a queue that later capacity must drain

A fictional service receives 200 requests/second for ten minutes. Each server handles 20 requests/second; five servers are initially running. Five more become ready after two minutes. Requests wait in an unlimited FIFO queue and processing cost is uniform. Compute backlog after two minutes and at the end of the burst. Demand then falls to 50/second while ten servers stay running. How long to drain the queue? State two assumptions that make this model optimistic.

Get a starting hint

Matching arrival rate stops backlog growth; it does not erase work that already accumulated.

Compare your reasoning with the worked solution

Initial capacity is 100/second, so the backlog grows at 100/second for 120 seconds, reaching 12,000 requests. Ten servers then provide 200/second, exactly matching incoming demand; backlog stays 12,000 through the remaining eight minutes. After demand drops, spare capacity is 200−50=150/second, so draining takes 12000/150=80 seconds. The model ignores request timeouts, retry amplification, variation in service time, storage bottlenecks and allocation failures. Unlimited buffering is also unrealistic. The 2006 AWS announcements are primary records of historical service offerings, not guarantees about these invented provisioning times. Capacity planning must include recovery from accumulated work, not merely the point at which the current request rate is matched.

Check your reasoning

• Computes backlog growth and its persistence at matched capacity.
• Finds the eighty-second drain time using spare capacity.
• States concrete model limits without attributing them to AWS.

2. Dependency and restore test · allow 25 minutes

Backups cannot recover an inaccessible identity

A fictional application has nightly encrypted backups in a second region. Its only decryption-key service and administrator login depend on the failed primary region. A team claims the second-region copy proves recovery. Trace the attempted restore and propose a drill that demonstrates independent recovery while controlling access to sensitive keys. Explain what evidence is required beyond an object-count check.

Get a starting hint

Possessing ciphertext, having permission to retrieve it and having usable decryption keys are separate conditions.

Compare your reasoning with the worked solution

The operator may reach the backup storage but fail to authenticate, or retrieve encrypted objects but fail to obtain the decryption key. In either case the copy exists without a usable recovery path. A drill should disable primary-region identity and key dependencies, invoke a preauthorized independent emergency-access process, restore a representative backup into isolated infrastructure and verify application-level records and invariants. Protect emergency credentials with restricted access, logged use and tested revocation or rotation; the exercise need not publish secrets or bypass authorization. Record restore duration and the newest recovered committed transaction. Object counts establish only some storage-level properties. They do not prove decryptability, schema compatibility, complete transactions or the team's ability to operate without the failed control plane.

Check your reasoning

• Identifies both identity and decryption dependencies.
• Tests a restore with the primary dependency actually unavailable.
• Checks application consistency and recovery time beyond stored-object counts.

Check your understanding

A workload uses 420 server-hours daily. Metered cost is 2 per hour; owned daily fixed cost is 700 before staff. What does this narrow comparison show?

• Staffing cannot change the result.
• Metered compute must be cheaper because utilization is low.
• The owned system costs2400 because that is capacity.
• Metered compute is840, exceeding700 under these assumptions.

Explanation

Usage alignment and total cost are distinct; omitted operating and lifecycle costs may reverse the comparison.

A provider replaces a failed disk, but a customer’s application deleted valid records. Which responsibility remains?

• Application-level recovery from an appropriate backup or history and verification of the restored state.
• The customer can ignore recovery because storage is rented.
• Hardware replacement automatically restores the intended business state.
• A second region always identifies which deletion was wrong.

Explanation

Physical durability does not determine application intent or undo logically valid but unwanted operations.

Sources and further reading

• Announcing Amazon S3, March 13,2006: Amazon Web Services original announcement
• Amazon EC 2 Beta,2006: Amazon Web Services original announcement