Cloud’s Death Certificate

In network diagrams, the cloud is an area that is not expanded here. The person drawing the diagram knows they are connecting to an external network, but need not draw every external node; a mass of boundary temporarily stands in for those details on the page. Drawings need this kind of omission. It is not meant to make readers believe there is nothing there, but to keep the diagram from being crushed by completeness. If the cause of death were written as “lightweight fraud,” the first line would already be wrong.

In AWS’s shared responsibility model, the cloud cannot remain so ambiguous. Security of the Cloud and security in the Cloud cut the boundary apart. What was temporarily folded away in the diagram becomes configuration work in the responsibility document, and also becomes the question of which day one can stop and apply patches. That mass of boundary is no longer merely a boundary; it is placed inside an arrangement that can be operated, retrospectively accounted for, and also mistaken.

These two prepositions are small, yet they drag the cloud out of the icon. Of is like an outer shell, pointing to the side the provider must hold secure; in is like the lights, locks, and desks inside a room, pointing to the parts users must still place and inspect themselves. The cloud does not dissipate here. It merely loses the tolerance of being a mass of boundary. It begins to require people to say clearly: which side this matter belongs to, whose negligence a given lapse counts as, and which night must be cleared for an update.

NIST’s definition includes minimal management effort. Engineering needs this abstraction; without abstraction, systems cannot be used. On serverless pages, the wording is more direct: run code without thinking about servers or clusters. The servers are still there; developers have simply been placed in a position where they can temporarily not think about servers. This temporariness is thin, yet enough to change a person’s posture: the eyes remain on the code, while the layer underneath first recedes beyond the document.

The correction by Masanet et al. makes “lightweight fraud” impossible to sign off on: a surge in demand does not mean energy consumption surges at the same speed; centralization can at times truly be more efficient. Lightness need not immediately be judged a lie. What is harder to handle is that some lightness comes from real folding, and some folding must later be restored elsewhere as work.

It is not in the diagram, yet it has been scheduled into another timetable’s patch window.