E2C continuum and cloud computing

Picture an autonomous car with three very different jobs. First, it must detect an obstacle and brake, and that answer has to arrive within milliseconds. Second, it wants a good route, which means combining traffic reports from many cars in the same region. Third, its driving model must improve over time, and that means training on months of history from the whole fleet. No single computer suits all three. The obstacle check belongs right next to the sensors. Route optimization belongs somewhere that sees the whole region. Training belongs where there is enormous storage and compute. The three places sit at small, medium and large distance from the car.

The lecture turns that intuition into a definition. The Edge-to-cloud (E2C) continuum is a continuum of latencies between a client and a server. The Edge layer, the Fog layer and the Cloud layer are not separate worlds. They are regions of one range, ordered by how long a request takes to reach them and come back. Moving away from the client adds latency, and in exchange it adds capacity: more processors, more storage, a wider view of the data.

The floor that distance sets

Glass has a refractive index of about 1.4 to 1.6 (typically around 1.5), so light in fiber moves at roughly 200,000 km/s. Applied to the continuum, that floor reads:

To try your own distances and media, use the latency calculator in Lecture 01 part 07, which also explains why real round trips cost several times this bound.

A multiplayer game hosted in a distant cloud region lags: every shot travels thousands of kilometres and back. The obvious fix is to move the cloud next to the players. The lecture's answer is a flat no, and the reason is worth understanding, because it shapes everything that follows.

A cloud data center is a very complex system, it is very expensive, and it is centralized on purpose. Building one is, in the words of the Berkeley "Above the Clouds" report, a hundred-million-dollar undertaking. The payoff of that size is Economies of scale: a very large data center buys network bandwidth, storage and administration at a fraction of the unit cost a medium one pays. Satyanarayanan puts it the same way: centralization exploits economies of scale to lower the marginal cost of system administration and operations. Split one giant site into a thousand neighborhood sites and you throw that advantage away.

So the cloud stays where it is, and something smaller goes out instead. The lecture calls it a mini cloud, or Mini data center, and the key move is that you can place several of them at different points on the latency continuum. Each one is close enough to cut latency for nearby clients, while the big data center keeps its economics.

The pattern in production: Netflix Open Connect

A Content delivery network (CDN) is the clearest working example. Netflix started its Open Connect program in 2011. It places its own caching appliances (Open Connect Appliances, OCAs) at internet exchange points and, free of charge, inside the networks of qualifying ISPs; it now works with more than a thousand ISP partners. The ISP provides power, space and connectivity. Because Netflix can predict what its members will watch, it pre-fills each appliance during off-peak "fill windows", so at peak time the popular titles are already a few hops from the viewer.

In a smart city, small computers sit in cabinets at road junctions. Each one reads the cameras and sensors at its junction, notices a queue building or a pedestrian waiting, and changes the signal timing in real time, with no round trip to a distant cloud. Bonomi and colleagues at Cisco used almost the same example when they introduced the idea in 2012: a smart traffic light node that reads local sensors detecting pedestrians and bikers.

The layer of such mini data centers gets a name: the fog. A Mini data center is a scaled-down version of a big data center that bridges the gap between the edge and the cloud, and it offers all three classic services: compute, storage and networking. Bonomi defined fog computing as "a highly virtualized platform that provides compute, storage, and networking services between end devices and traditional Cloud Computing Data Centers." The name is a joke with a point: the fog is a cloud close to the ground.

Bonomi listed what makes the fog distinct from the cloud above it:

• Low latency and location awareness: a node knows where it is and serves who is near.
• Wide-spread geographic distribution and a very large number of nodes.
• Support for mobility, wireless access and real-time streaming.
• Heterogeneity: nodes come in many shapes and from many vendors.

The fog is also hierarchical. Nodes form tiers, and in Bonomi's words, "the higher the tier, the wider the geographical coverage, and the longer the time scale." The lowest tier runs control loops in milliseconds to sub-seconds; higher tiers work over seconds to minutes and even days, and the cloud keeps data for months and years. NIST SP 500-325 later made the building blocks concrete: fog nodes can be physical (gateways, switches, routers, servers) or virtual (virtualized switches, virtual machines, cloudlets). It also names mist computing, a lightweight and optional form of fog at the very edge. In 2018 IEEE adopted the OpenFog Reference Architecture as standard IEEE 1934-2018, a sign that the idea had moved from paper to practice.

Consider a fleet of autonomous delivery drones. When one drone's battery runs low it must return to base. That decision uses nothing but the drone's own state, and it must work even if every radio link is down, so it runs on the drone's own compute with no networking at all. When several drones fly in the same area, they must agree on flight paths to avoid collisions. Now the data spans several parties in one region, so the drones talk to a fog ground station, and networking is essential. Finally, the cloud combines data from every drone in the fleet to improve routes over time. That function's scope is global.

The lecture asks a sharp question: do we really need the networking service at every point on the latency continuum? The drone example answers it. Whether a function needs networking depends on its scope, meaning how many parties and how much area its data spans, not on whether the layer is called edge, fog or cloud. Walking from the cloud toward the device (the numbered points 1, 2 and 3 on the slides), more functions can run locally and depend less on remote communication, because the functions that live there have narrower scope.

Here the device itself plays the edge role, the NIST usage flagged in concept 1.

Research supports the same rule. Satyanarayanan shows that analyzing raw video on a nearby cloudlet means only the "(much smaller) extracted information and metadata must be transmitted to the cloud", and the cloudlet can enforce privacy policies before anything leaves. Bonomi's lowest fog tier runs machine-to-machine control loops in milliseconds and filters data before passing it up. In both cases, local functions stay local, and only results with wider scope travel.

Take the drone tasks one last time and map them onto networks. Local work runs on the edge, on the device or inside its local area network. Collision coordination runs in the fog, across a wide area network run by an operator. Fleet-wide learning runs in the cloud, reached over the public Internet. That mapping is the lecture's summary picture, and it is the one to memorize.

The edge lives on the LAN and offers compute and storage. The fog lives on the WAN and offers compute, storage and networking. The cloud lives on the Internet and is the full data center, offering every service at global scale. Each has a priority: edge prioritizes autonomy, fog prioritizes coordination, and cloud prioritizes global connectivity. Read together with the scope rule, this is the whole Edge-to-cloud (E2C) continuum in one table.

Where does an edge layer meet the fog? Through an Edge gateway, a device that does local processing for the edge devices behind it and connects them upward to fog nodes. The edge box omits networking because the functions placed there have device-local scope, as slides 7 and 8 argued; the gateway's uplink gives the edge connectivity, but the edge offers no networking service to others.

A city installs 200 traffic cameras, and each one streams video at 4 Mbps. If every stream goes straight to the cloud, 800 Mbps of raw video crosses the wide-area network every second, around the clock, mostly showing empty roads.

Now put one small server room in the district, between the cameras and the cloud. It runs vehicle detection on all 200 streams and forwards only the events: one 2 kB record per camera per second saying what passed and how fast.

The numbers are not a toy. Satyanarayanan estimates that only 12,000 users streaming 1080p video would already need a 100 Gbps link into the cloud, and a million users would need 8.5 Tbps. His cloudlets exist largely to “reduce ingress bandwidth into the cloud”.

The rule: a shared layer between edges and cloud

The server room is what this course calls the Fog layer: a layer that provides compute, storage and networking at critical points closer to the client on the Edge-to-cloud (E2C) continuum. Physically it is usually a Mini data center, the "cloud close to the ground" that part 01 introduced with Bonomi's definition. Part 01 asked what the fog is; this concept asks what it is for.

The defining fact is that one Fog node serves many edges. Everything useful about the fog follows from that sharing:

• Less edge-to-cloud transfer. The fog filters, aggregates and answers locally, so less data crosses the long, expensive path. That lowers Latency for the requests it answers and frees bandwidth for everything else, as the camera example showed.
• Data geo-restriction. Because the fog sits inside a region, personal data can be processed there and never leave. This is Data geo-restriction, and it exists for legal and privacy compliance.
• Shorter edge-to-edge paths. Two edges under the same fog can talk through it. Their traffic turns around in the district instead of travelling to a distant data center and back.

Why geo-restriction is a legal requirement, not a preference

Data protection laws restrict where personal data may go. The EU GDPR, Chapter V, Article 44, allows a transfer to a third country only under the conditions that chapter lays down. Saudi Arabia's Personal Data Protection Law, Article 29, governs transfer outside the Kingdom, and SDAIA publishes standard contractual clauses for such transfers. A Riyadh hospital can therefore keep raw scans on a fog node inside the Kingdom and send only anonymised aggregates onward to a cloud region elsewhere.

Satyanarayanan adds two related benefits. A cloudlet can enforce its owner's privacy policy before any data is released to the cloud, and it can mask a transient cloud outage by keeping local services running until the link returns.

A robot arm on a factory floor must recognise the part in front of it. Its own processor is too weak for the detection model, so it sends each frame to a gateway box on the factory LAN and gets back a label. The robot knows one address. It never learns whether the gateway answered by itself or passed the hard frames to a fog server two buildings away.

The rule: four roles at the boundary

That gateway box is the Edge layer. In this course the edge has four roles:

1. WAN boundary. It sits on the physical boundary of the wide-area network that extends the cloud, the last stop before the client's own network.
2. Offload target. The client can hand it compute jobs it cannot or should not run itself, such as the robot's detection model.
3. Fast small-data processing. It handles small amounts of data at reasonable speed, close enough that the round trip stays short.
4. Gateway that hides the fog. It is the client's single door into the rest of the continuum, and the fog behind it stays invisible.

The last role has a precise parallel in HTTP. RFC 9110, §3.7, defines a gateway, also called a reverse proxy, as an intermediary that “acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers”. The client believes it is talking to the server. The edge plays exactly that part for the fog.

Hiding matters because the fog changes. Operators add nodes, fail over to a spare, or move a service to a less loaded server. If clients addressed fog nodes directly, every such change would have to be pushed to every robot, sensor and phone. With the edge in front, only the edge's forwarding changes and the clients never notice.

Real products follow this shape. AWS IoT Greengrass runs on a local gateway and lets devices “act locally on the data that they generate”, “filter and aggregate device data” and “react autonomously to local events”, while staying connected to AWS for the rest.

A city wants to predict tomorrow's traffic from two years of data from every intersection. Training that model needs thousands of GPUs for days and petabytes of history in one place. No district fog room or edge gateway has either, and no single district has all the data.

The rule: scale in three forms

That job belongs to the Cloud layer, which provides compute, storage and networking at a much bigger scale:

• Big compute means high-performance computing. AWS advertises that you can “scale HPC applications to thousands of CPUs and GPUs with Elastic Fabric Adapter”.
• Big storage means big data that lives for a long time. Bonomi describes the cloud as the “repository for data that has a permanence of months and years”, and Amazon S3 is a real service built for that kind of long-lived data at petabyte scale.
• Big networking means connectivity between clouds. Google Cross-Cloud Interconnect gives dedicated links from Google Cloud to AWS, Azure, OCI and Alibaba Cloud at 10 Gbps, 100 Gbps or 400 Gbps (the 400 Gbps option only to AWS and OCI).

Putting the three layers side by side

With all three roles in hand, the layers line up along two axes at once. Going up from edge to fog to cloud, the area served grows, and so does how long the data is kept and acted on. Bonomi summarises the interplay as “Fog localization, and Cloud globalization”.

The price of the cloud's reach is distance, and distance is Latency. Use the simulator to feel it: switch from the “all edge” preset to the “all cloud” preset, then set single tasks to fog, and watch how much of the response time becomes network rather than computation.

Follow one temperature reading through a cold-storage company. The rule for frozen goods is that the room must stay at or below 8 °C, and one thermometer has just read 9 °C.

The rule: sense, process, coordinate, analyse

Slide 13 compresses this into one sentence: edge devices sense, edge gateways provide local processing, fog nodes coordinate regionally, and the cloud analyses globally. In this course's model the devices and gateways belong to the Edge layer, the coordinators to the fog layer, and the analytics to the Cloud layer.

The shape is a tree. Many devices hang off each gateway, several gateways off each fog node, and a few fog nodes off the cloud. NIST describes the same structure when it says fog nodes can be clustered “vertically (to support isolation), horizontally (to support federation)”. Data flows up the tree and shrinks at every level, while decisions are taken at the lowest level that has enough information.

Bonomi's fog tiers from part 01 give the time scales, here in his Smart Grid example. The first fog tier runs control loops “from milliseconds to sub seconds”, and it “filters the data to be consumed locally, and sends the rest to the higher tiers”. Higher fog tiers work on “seconds to minutes”, and even days. The cloud keeps data for months to years.

A platoon of trucks drives at 108 km/h, which is 30 m/s, with gaps of about 10 m. The front truck brakes hard. How far does the next truck travel before it even starts to react? That depends on where the brake decision is computed.

The rule: map each element to a layer by how fast it must act

• Cars are edge nodes. Each vehicle processes its own sensor data in real time, in the Edge layer. Cars also talk directly to each other over the vehicle-to-vehicle (V2V) network, which skips every piece of infrastructure.
• Roadside units are fog nodes. An Roadside unit (RSU) along the road sees the vehicles near it and can, for example, warn them about a traffic jam ahead. In the paper behind slide 14's figure, “RSUs are managed by the RSUC which has more resources for computing, storage, and communication through Internet to the cloud.” The RSU controller (RSUC) is therefore the fog aggregator that links the roadside units to the cloud.
• The cloud coordinates globally. The Cloud layer offers global coordination, long-term storage and HPC, but at a higher Latency.

The figure comes from Wang, Guo, Gao, Fang, Li and Sun, “Fog-Based Distributed Networked Control for Connected Autonomous Vehicles” (2020). In their connected cruise control case study the RSU calculates control coefficients and sends them to each vehicle, and the car's on-board controller computes the real-time control signals from them. The split mirrors the time scales: the fog tunes the controller, the car closes the loop.

This is not an exotic case. NIST uses it to illustrate the fog's geographical distribution: “streaming services to moving vehicles, through proxies and access points geographically positioned along highways”. Bonomi lists cars talking to roadside units and smart traffic lights as a core fog use case.

Look at your electricity bill. You never bought a power station, you never hired the engineers who run it, and you can plug in a kettle or a server without asking anyone. You pay for the kilowatt-hours you actually used, and the grid is reached through a socket in the wall. Computing can be sold the same way.

The claim is older than most people expect. Speaking at MIT's centennial in 1961, John McCarthy predicted that computing may someday be organized as a public utility, just as the telephone system is. He imagined computer service companies with subscribers connected to them, where each subscriber pays only for the capacity actually used, yet has access to everything a very large system offers. That is Utility computing, and the slide's verdict is right: it is remarkably close to what we now call cloud computing.

Three parts of one sentence

Read McCarthy's sentence slowly and it splits into three ideas. First, there is shared central capacity: one very large system that many subscribers draw on. Second, usage is metered and billed, so you pay for what you consume rather than for what you own. Third, subscribers reach the system over a network, from wherever they are. Fifty years later, NIST SP 800-145 wrote the formal definition of cloud computing, and three of its five essential characteristics line up with these ideas almost word for word.

Part 06 teaches all five NIST characteristics and the deployment models. For now, keep the pattern: cloud computing is first an economic arrangement, and the technology exists to make that arrangement safe and cheap.

Picture a company that runs its ERP system on premise. It leases a building and fits it with power and cooling, buys racks, switches, a storage array and servers, installs an operating system, runs a database, patches security holes and finally deploys the application its staff actually use. Every one of those steps needs its own people and its own budget line, and nobody else is responsible if any of them fails.

That is Legacy IT. The defining rule is simple: the customer manages every layer. The slide draws nine of them, and they are worth learning bottom to top, because every cloud service model in part 07 is defined by how many of these same layers move to a provider. Infrastructure as a service takes the bottom ones, platform as a service takes more, and software as a service takes them all.

The slide's four bullets name the expensive physical base of this stack: data center technology to operate applications and store data, servers to run the business applications, networking to connect the servers, and storage for large amounts of data. Those are exactly the layers that part 05 will price as capital expenditure, and they are the first layers a cloud provider takes over. NIST SP 800-145 phrases each service model the same way, by listing which layers the consumer still controls.

Take a server with 64 cores and 256 GB of RAM that runs one web application at about 10% load. Most of that machine is idle most of the time, yet it still uses power, rack space and an administrator's attention. Now carve it into six virtual machines: a Linux web server, a Linux database, a Windows directory server and three more. Each one gets its own virtual CPUs, its own slice of RAM, its own virtual disk and its own network card, and each boots its own operating system.

That carving is Virtualization: the resources of one computer are split so that several independent operating system instances can run on it at the same time. Each piece is a Virtual machine (VM), and it has two defining traits. It behaves like any other computer, with its own components, and it runs inside an isolated environment on the physical machine. NIST SP 800-125 puts it formally: virtualization is the simulation of the software and hardware on which other software runs, and that simulated environment is called a virtual machine. The guest appears to have its own processor, memory, storage controllers, Ethernet controllers, display, keyboard and mouse.

Two payoffs: consolidation and isolation

The first payoff is consolidation. NIST calls it operational efficiency: you place more load on each physical computer, so you buy, power and cool fewer of them. The hardware stops being a set of fixed boxes and becomes a pool, which is exactly the Resource pooling that McCarthy's utility needed.

The second payoff is isolation. Smith and Nair state it plainly: if security on one guest system is compromised, or one guest operating system fails, the software on the other guests is not affected. NIST adds that the hypervisor partitions the system's resources so that each guest can reach only its own. Isolation is what lets a provider rent neighbouring VMs to strangers, and it is the "safely" in the slide's summary that virtualization turns hardware into a pool that can safely run many independent computers.

Install Ubuntu in VirtualBox on an x86 laptop. Ubuntu's own code runs directly on the real CPU at full speed. Only when Ubuntu tries something sensitive, such as changing page tables or touching a device, does the virtualization software step in, perform the operation on Ubuntu's behalf against the real hardware, and hand back the result. Ubuntu never notices. Now run an old console game in a Nintendo emulator: every guest instruction has to be translated, because the guest speaks a different instruction set. (BlueStacks, the slide's other example, does the same for the ARM code inside Android apps.) Finally, sit in a flight simulator. It does not run the aircraft's software at all; it models how the aircraft behaves.

These three scenes are virtualization, emulation and Simulation. The first property to name is transparency. Inside a VM you install an operating system and applications exactly as on a physical computer, and the applications do not notice they are in a VM. Requests from the guest are transparently intercepted by the Virtual machine monitor (VMM) and converted for the real hardware, and the VM never becomes aware of the layer between it and the machine. Smith and Nair describe the mechanism: when a guest performs a privileged instruction, the VMM intercepts it, checks it and performs it on behalf of the guest, and guest software is unaware of this behind-the-scenes work.

Popek and Goldberg: what counts as a VM

In 1974, Popek and Goldberg gave the precise version. A virtual machine is "an efficient, isolated duplicate of the real machine", and a VMM must have three properties.

1. Equivalence. Programs see an environment essentially identical to the original machine. Apart from timing and resource availability, they behave as they would on bare hardware.
2. Efficiency. A statistically dominant subset of the guest's instructions runs directly on the real processor, with no software intervention.
3. Resource control. The VMM stays in complete control of the real resources. A guest cannot reach resources it was not allocated.

The efficiency property is the one that draws the line. Popek and Goldberg say explicitly that it rules out traditional emulators and complete software interpreters (simulators) from the virtual machine umbrella. Their Theorem 1 gives a sufficient condition for building a VMM this way: every sensitive instruction is also privileged, so it traps to the VMM instead of running silently.

Emulation still matters. Smith and Nair note that a whole-system VM whose ISA differs from the host, such as Virtual PC running Windows on a PowerPC Mac, must emulate both application and OS code. It works, and it is how you run old consoles or foreign architectures, but you pay for every instruction.

In 1972 an IBM mainframe could be shared by hundreds of users at once. The trick was the Control Program (CP), which gave each user a complete virtual machine, a virtual System/370 duplicating the physical hardware. Inside that VM each user ran CMS, a simple single-user operating system. Many single-user machines, each in its own VM, added up to a multi-user time-sharing system. That product was VM/370, and Creasy's 1981 paper cited on the slide tells its story.

The lineage starts earlier. CP/CMS was conceived in 1964, CP-40 and CMS were running in 1966, and CP-67 on the System/360 Model 67 was in production use from 1967. IBM announced VM/370 on August 2, 1972. Its descendant, z/VM, still runs on IBM mainframes, so virtualization is one of the longest-lived ideas in computing.

A family, classified by what is virtualized

Today "virtualization" names a family of techniques. They differ in which layer is virtualized and how much of the guest is changed.

• Partitioning splits one machine's hardware into fixed, separate partitions.
• Hardware emulation presents hardware different from the real platform, at a translation cost.
• Application virtualization wraps one application so it runs isolated from the host OS.
• Full virtualization presents virtual hardware close enough to the real thing that unmodified guest OSs run.
• Paravirtualization modifies the guest kernel to call the hypervisor directly instead of touching emulated hardware.
• Hardware virtualization gives each complete guest OS its own virtual hardware, which the VMM maps onto shared physical CPU, memory, storage and network (slide 21). CPU extensions such as Intel VT-x andAMD-V (hardware-assisted virtualization) make this efficient.
• OS-level virtualization shares one kernel and isolates user spaces, which gives containers.
• Storage virtualization pools disks behind a SAN or software-defined storage.
• Network virtualization carves logical networks out of shared links with VLAN or VXLAN.

Hardware assistance exists because x86 does not meet Theorem 1's condition. Barham and colleagues note that some x86 supervisor instructions fail silently instead of trapping, so a VMM cannot catch them. VMware ESX Server solved this for full virtualization by dynamically rewriting guest code, Xen sidestepped it with paravirtualization, and later CPUs added extensions that make the instructions trap.

Two independent axes

The most important correction in this part is that two different questions get mixed up. The first axis is guest modification: does the guest OS run unmodified (full virtualization), or is its kernel changed to cooperate with the hypervisor (paravirtualization)? Barham and colleagues define paravirtualization exactly this way: a virtual machine abstraction similar but not identical to the hardware, which requires modifications to the guest OS but none to guest applications.

The second axis is hypervisor placement: does the VMM run directly on the hardware (Type 1 hypervisor) or on top of a host operating system (Type 2 hypervisor)? Goldberg's 1973 thesis defines it so: a Type I VMM runs on a hardware host, a Type II VMM runs on an extended host, meaning an operating system. Part 04 teaches the two types in depth. NIST SP 800-125 confirms the axes are independent by naming bare metal and hosted as the two forms of full virtualization.

Three VMs share one host. Follow a single disk write from one of them. The application calls a library function to save a file. The library asks the guest OS. The guest OS drives what it believes is its disk controller, but that controller is virtual hardware. When the guest touches it, the access reaches the hardware/software interface, where the Virtual machine monitor (VMM) catches it and maps it onto the real SSD that all three VMs share.

The rule behind the picture is a single horizontal cut. Everything above the hardware/software interface, the application, library, operating system and virtual hardware, is replicated for each VM and isolated from the others. Everything below it, the CPU, memory, storage and network, is physical, shared and multiplexed by the VMM. Smith and Nair say the VMM has access to, and manages, all the hardware resources, and NIST says the hypervisor controls the flow of instructions between the guests and the physical CPU, disk, memory and network cards. So the OS instances are isolated from each other, and each runs on virtualized resources that are mapped to physical ones.

Where you cut decides the kind of virtualization

The interface on the slide is essentially the instruction set architecture. Smith and Nair write that the ISA marks the division between hardware and software, and they identify three key interfaces: the ISA, the ABI (system calls plus user instructions) and the API (library calls). Cut the stack at the ISA and you get a system VM with a full guest OS, as on this slide. Cut higher, at the ABI or API, and you get process VMs or OS-level containers, where the kernel is shared and only the user space is isolated. That is the bridge to part 04.

Start with a laptop running VirtualBox with Ubuntu inside it. When you press the power button, macOS boots first. VirtualBox is then just another application, next to Safari, and the whole Ubuntu guest lives inside that application's process. Now compare a server in an AWS data center that hosts EC2 instances. Nothing general purpose boots before the hypervisor. It is the first thing on the machine, and it hands out CPU and memory to the guests directly.

Both machines do Virtualization, and both run a Virtual machine monitor (VMM) that makes each Virtual machine (VM) believe it has a real computer. The difference is where the VMM sits, and that comes down to one question: who owns the hardware?

Two placements

• A Type 1 hypervisor (bare metal, or native) is the lowest software layer on the machine. It runs directly on the hardware and acts as a specialized OS whose only job is to run guests. Red Hat describes it as a hypervisor that "runs directly on the host's hardware to manage guest operating systems".
• A Type 2 hypervisor (hosted) runs on a conventional OS "as a software layer or application". The host OS owns the hardware, and the VMM is one of its processes, with less privilege than the OS itself. VirtualBox's own manual calls it "a so-called hosted hypervisor, sometimes referred to as a type 2 hypervisor".

Real examples, and where the labels get blurry

VMware's Type 1 hypervisor is ESXi, described as "the hypervisor [that] runs virtual machines"; vCenter Server is the central management service for many ESXi hosts, and vSphere is the name of the whole suite. On the hosted side sit VirtualBox, VMware Workstation and Parallels Desktop.

Picture a lab PC running VirtualBox for a coursework VM, next to an EC2 c7i instance. When the coursework VM compiles code, its virtual CPU is just a thread that competes with Chrome and the antivirus for time on the host scheduler. The EC2 instance gets CPUs and memory partitioned for it by a minimal hypervisor, with no desktop OS in the way.

That picture gives the whole comparison. Because a Type 1 hypervisor owns the hardware, it adds less overhead (the slide says about 5%), manages resources directly and isolates guests more strongly, but it needs more skill to install and operate. A Type 2 hypervisor reaches the hardware only through the host OS, so it costs more (about 10%), controls resources indirectly and isolates less, but anyone can install it.

Why cloud providers pick Type 1

A Cloud service provider (CSP) sells slices of the same physical server to strangers. Every percent of overhead is capacity it cannot sell, and every extra layer between tenants is attack surface. AWS shows where this leads. Its Nitro Hypervisor is "a custom-developed, minimized hypervisor based on KVM", cut down on purpose: it has "no networking stack, no general-purpose file system implementations, and no peripheral device driver support". Networking and storage are offloaded to dedicated Nitro Cards and exposed to guests through SR-IOV. The hypervisor does little more than partition CPU and memory, which is the Type 1 idea taken to its limit, and the design is lean enough that AWS can also sell bare metal instances.

On one Ubuntu server, run docker run nginx and then docker run mongo. Each starts in well under a second, because neither boots an operating system. Both are ordinary Linux processes making system calls into the same host kernel. Run uname -r inside either one and it prints the host's kernel version, because there is no other kernel to ask.

That is OS-level virtualization. There is no hypervisor and no guest kernel. The line that matters is the System call interface, the entry point through which user-space code asks the kernel for anything. Above it, each environment has its own isolated user space: the application and its libraries. Below it, everything is shared: the kernel, and the hardware (or the virtual hardware, if the host is itself a VM). These isolated environments are called a Container.

The design has three consequences. Containers are light and fast, because starting one is starting a process. They are tied to one OS family, because the shared kernel must understand their system calls. NIST is blunt: "a Linux host can only run containers built for Linux". And their boundary is weaker than a VM's, because a shared kernel "invariably results in a larger inter-object attack surface than seen with hypervisors". One kernel bug can be a door between every container on the host.

Take the slide's own example: one server runs a database and a web server as plain processes. Two things can go wrong. First, the web server can list the database's processes, send them signals, read its files and bind its ports, so whoever compromises one has a view of the other. Second, a heavy query makes the database use every CPU core, and the website stalls.

These are different problems, and Linux fixes each with a different kernel feature. The first is about visibility. A Namespace gives a group of processes its own view of a kernel resource, so the web server cannot even see the database's processes, network stack or mount points. The second is about consumption. Control groups (cgroups) put quotas, weights and accounting on how much CPU, memory and I/O a group can use. Docker's security guide gives the same split: namespaces "provide the first and most straightforward form of isolation", while cgroups "implement resource accounting and limiting".

Neither feature is new. The first namespace (mount) arrived in Linux 2.4.19 in 2002, most of the rest landed between 2.6.15 and 2.6.26 (July 2008), and user namespaces were only completed in 3.8 (2013), which made unprivileged containers practical. Cgroups were started in 2006 and merged in 2.6.24. A Container is simply these two combined, plus a root filesystem image. NIST describes the second half with a concrete case: a host with 10 GB of memory can give 1 GB to each of nine containers, so no single one can starve the rest.

You can make a Namespace by hand on any Linux machine. The command below starts a shell in a new PID namespace and mounts a fresh /proc for it. Inside, ps a shows only two processes, and the shell believes it is PID 1.

sudo unshare --fork --pid --mount-proc bash
ps a

PID TTY      STAT   TIME COMMAND
      1 pts/0    S      0:00 bash
      8 pts/0    R+     0:00 ps a

From a second terminal on the host, the same bash appears in ps -A under a large global PID such as 24517. Nothing was copied and no second kernel was started. The kernel simply shows that process a different numbering. NIST gives the container version: ps -A inside an Apache Container lists only httpd.

The rule

The Linux manual defines a namespace as something that "wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance". There is one kernel and many views. Every process belongs to exactly one namespace of each type, and a container runtime such as Docker creates a fresh set (all but user and time, by default) for every container. You can see a process's memberships as symbolic links in /proc/<pid>/ns/ (since Linux 3.8), and a tool can join an existing namespace with setns(2), which is how docker exec gets a shell into a running container.

The network namespace is what gives each container "its own networking stack, including unique interfaces and IP addresses", in NIST's words, so two containers can both listen on port 80. The user namespace, when enabled, lets a process be root inside its container while mapping to an unprivileged user on the host.

On a host with 2 CPUs, start MongoDB with docker run --cpus=1.5 --memory=512m mongo. Docker writes two numbers into the container's cgroup: a CPU quota of 150000 µs per 100000 µs period, and a memory ceiling of 512 MiB. If MongoDB grows past that ceiling and the kernel cannot reclaim memory, the OOM killer kills a process inside that cgroup only. The web server next to it never notices.

docker run -d --name db --cpus=1.5 --memory=512m mongo
cat /sys/fs/cgroup/system.slice/docker-$(docker inspect -f '{{.Id}}' db).scope/cpu.max
cat /sys/fs/cgroup/system.slice/docker-$(docker inspect -f '{{.Id}}' db).scope/memory.max

150000 100000
536870912

How cgroups work

The manual says cgroups "allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored". Each kind of resource is enforced by a controller, which Red Hat defines as "a kernel subsystem that represents a single resource, such as CPU time, memory, network bandwidth or disk I/O". The main controllers are cpu, memory, io, pids and cpuset; freezing, a separate freezer controller in cgroup v1, is the core file cgroup.freeze in v2. Cgroup v2, official since Linux 4.5, puts everything in one tree mounted at /sys/fs/cgroup, where every setting is a small file you can read and write.

The slide lists four functions, and each maps to concrete files:

A 50-person company buys five servers. The invoice arrives and gets paid, and it feels like the job is done. It is only the start. The servers need a rack and a room to stand in. They burn electricity every hour of every day, and an air conditioner has to remove the heat they make. Someone has to install them, configure them and patch them. In year three a disk dies, the RAM is too small, and the cycle of buying begins again.

That is the life of Legacy IT. In part 03 you saw that in this model the customer manages every layer, from the building up to the application. The flip side is simple: the customer also pays for every layer. The honest way to price it is the Total cost of ownership (TCO), which adds up everything it costs to own and run the system over its life, not just what it costs to buy.

Five buckets of cost

1. Hardware purchase. Servers, storage and network gear.
2. Housing. The enclosure (rack, power strips, console switch) and the room it lives in.
3. Operations. Power, cooling and maintenance.
4. Personnel. The people who install, configure and maintain the machines.
5. Upgrades and refresh. Extending or replacing hardware as it ages.

The buckets behave differently over time. Hardware, housing kit and refreshes are lumpy: big amounts at a few moments. Accountants call this kind of spending Capital expenditure (CapEx). Operations and personnel recur month after month, and that is Operational expenditure (OpEx). The next concepts make this split precise. For now, notice which buckets the case study will actually price, because the gap matters at the end.

The company in the case study is a small news streaming firm with 50 employees. It needs three things from its IT: networking, web hosting and backups. The question is what it costs to run that on its own hardware for three years, so it can later be set against a cloud bill for the same job.

Fix the assumptions before you add anything up

A Total cost of ownership (TCO) comparison is only fair when both scenarios use the same scope and the same assumptions. Otherwise the cheaper option may simply be covering less. The case study fixes three assumptions up front.

• The software is open source, so licence fees are zero on both sides.
• Maintenance costs the same on-premise and in the cloud, so it cancels out of the comparison and is left out of both totals.
• The horizon is 3 years. That matches how long servers are typically used before replacement. Barroso et al. note that servers have a shorter lifetime than buildings and are usually depreciated over 3 to 4 years, while data center buildings are depreciated over 15to 20 years.

The hardware

The firm buys five identical 1U rack servers. Each has two Intel Xeon E5-2640 v2 processors, a 2013 server part that Intel lists with 8 cores, 16 threads, a 2.0 GHz base clock, a 20 MB cache and a 95 W thermal design power, for two-socket boards only.

Two quick derivations make this concrete. Compute first: 5 × 2 × 8 = 80 physical cores, or 160 hardware threads, across the fleet. Power second: the two CPUs alone can dissipate 2 × 95 = 190 W, the power supply is rated for 460 W, and the measured draw used later is 308 W, about 67% of the rating.

The five servers cost 17,500 EUR. They are bought once and used for years. The electricity bill arrives every month. A technician who comes to replace a failed fan is paid for that visit, even though the fan sits inside a long-lived asset. Those three payments fall into two different accounting categories, and the difference is the heart of the cloud's financial argument.

The accounting definitions

Capital expenditure (CapEx) is spending on fixed assets that will be used for more than one period. The international standard IAS 16 defines such property, plant and equipment as tangible items “expected to be used during more than one period”. Their cost is not charged all at once. Instead it is spread over the useful life by depreciation, “the systematic allocation of the depreciable amount of an asset over its useful life”. Barroso et al. put it in data center terms: CapEx is the investment made upfront and then depreciated over a certain timeframe.

Operational expenditure (OpEx) is the recurring cost of actually running things, excluding depreciation: electricity, repairs and maintenance, salaries of on-site staff, rent, and service subscriptions such as Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). IAS 16 paragraph 12 is explicit that the costs of the day-to-day servicing of an asset are not added to its carrying amount. They are expensed as they occur.

Why the cloud talks about this split

The Berkeley “Above the Clouds” report notes that the cloud's appeal is often described as converting capital expenses into operating expenses, but argues that “pay as you go” captures the real benefit better. Without an upfront purchase, money stays free for the core business, and capacity can follow demand instead of being bought for a guessed peak. AWS's Well-Architected cost guidance says the same in practical terms: adopt a consumption model, and stop spending money on the undifferentiated heavy lifting of racking, stacking and powering servers. That argument is exactly what part 06 tests against this case study.

Now the firm goes shopping. Everything on this list is a durable asset paid for on day one, so all of it is Capital expenditure (CapEx). The rule is a plain sum: quantity times unit price, over every item bought.

Storage, not compute, dominates

The surprise in the bill is where the money goes. The servers, the part everyone pictures, are only about a quarter of it. The SAN alone is 35,000 / 68,824 ≈ 50.9% of the CapEx, and once running costs are added it is still 39.0% of the whole three-year Total cost of ownership (TCO). A SAN is a dedicated network that gives servers shared, redundant, block-level access to pooled disks, and that redundancy and shared access are expensive. This is one reason managed storage and Object storage are such strong selling points for the cloud: the provider amortises that cost over thousands of customers.

Decoding the small items

• PDU, a power distribution unit: the rack's managed power strip that feeds every device in it.
• KVM here means a keyboard-video-mouse switch, which lets one console control many servers.
• SAN, a storage area network: the shared storage pool described above.

With the hardware bought, the meter starts running. Every watt the servers draw is paid for, every watt of heat they make has to be pumped out by the cooling, and the room has a monthly rent. These recurring costs are the Operational expenditure (OpEx), and adding them to the Capital expenditure (CapEx) gives the Total cost of ownership (TCO).

Cooling costs more than computing

Look again at the two energy lines. Cooling, at 3,702 EUR/yr, costs more than the servers' own power at 2,962 EUR/yr. For every 308 W of IT load, the room spends another 385 W getting rid of the heat. The standard way to express this is power usage effectiveness, defined by The Green Grid as total facility energy divided by IT equipment energy. Here that ratio is at least (308 + 385) / 308 = 2.25, and that is before counting the UPS, lighting or any other overhead.

The Uptime Institute's surveys put the industry average PUE at about 2.50 in 2007 and about 1.56 in 2024, and large hyperscale sites run well below that average. A small server room cooled by a generic air conditioner is simply much less efficient than a purpose-built data center. That gap is one of the structural reasons the cloud can undercut on-premise running costs.

What the TCO leaves out

The 89,715 EUR is a clean, recomputable number, and that is its value. It is also a lower bound, because several real costs sit outside it. Read the list below against the cost buckets from the first concept.

The energy lines are also sensitive to price. At 0.30 EUR/kWh instead of 0.22, three years of power plus cooling rise from about 20,033 EUR to about 27,318 EUR, about 36% more, exactly the price ratio 0.30 / 0.22, because energy cost is linear in price. When you build such a model for research, vary the inputs you are least sure about and report the range, not only the point estimate.

Take one virtual machine on AWS: an EC2 m2.xlarge instance with a 1 TB SSD block volume, running 24/7. The m2.xlarge is a previous-generation instance with 2 vCPU and 17.1 GiB of memory. Its bill has five lines, and none of them is paid before day one.

Compare that with slide 33. There, 68,824 EUR left the company before a single request was served. Here there is no start column at all. Every euro is Operational expenditure (OpEx), and every line is a resource the provider meters. That gives the general rule for any cloud bill:

This is the NIST characteristic called Measured service, seen from the side of the person paying. Because each line is metered separately, each can be scaled or switched off on its own. You can shrink the instance, move cold files to cheaper object storage, or put a cache in front of the requests, and only that line moves.

How AWS sets these prices

AWS's pricing page names three principles: pay as you go, save when you commit, and pay less by using more. The slide uses plain on-demand prices. AWS's pricing whitepaper (now marked as historical reference) says reservations save up to 75% and Spot capacity up to 90% against on-demand. So the slide's bill is the most expensive way to buy this workload, which matters when you compare it with owning servers. To price a design of your own, use the official AWS Pricing Calculator.

Put the two options side by side. On-premise is a lump of 68,824 EUR at the start, then 6,964 EUR a year. AWS is nothing at the start and 19,364 EUR a year. After three years the slide reports 89,715 EUR against 58,093 EUR.

Where does 19,364 come from? Slide 35 priced one VM at about 3,878 EUR a year, and slide 33 sized the on-premise setup at five servers. 19,364 / 5 ≈ 3,873, so the AWS column is five VMs, one per server. Over three years, 5 × 11,619 = 58,095, within rounding of the printed total.

A verdict is a curve, not a number

The 35% depends entirely on stopping the clock at year three. The fair comparison writes both Total cost of ownership (TCO) figures as functions of time. On-premise starts high because of Capital expenditure (CapEx) and grows slowly. The cloud starts at zero and grows fast. Two lines like that must cross.

So the cloud wins when the horizon is short, when demand is uncertain or bursty, and when hardware would be refreshed before t*. Owning wins for steady load run for many years on hardware you keep.

Benefits the table does not price

Slide 37 lists what the money buys beyond the line items. The provider operates the hardware, keeps the infrastructure's Availability and upgrades it. Extra demand is met through Rapid elasticity. Armbrust and colleagues at Berkeley explain why that last point is worth so much. They call it cost associativity: “using 1000 EC2 machines for 1 hour costs the same as using 1 machine for 1000 hours”. They also note that “real world estimates of server utilization in datacenters range from 5% to 20%”, so owned capacity sits mostly idle. Most of all, the cloud removes the up-front commitment: you do not have to guess your peak before you know your users.

Why nobody deletes their own IT

• Some IT is always local. Laptops, office networks, printers and identity still need someone in the building.
• Some workloads must stay on premises. Tight latency, data residency rules or regulation can forbid sending data to a remote data center. This is the edge side of the E2C continuum from parts 01 and 02: edge resources sit close to the data source, often on the user's own premises.
• Lock-in is a real cost. Vendor lock-in grows with every proprietary service you adopt, and leaving later means paying outbound transfer and rewriting code.

At 2 a.m. you open the AWS console on your phone, launch a VM, and it is running a minute later. An hour later you delete it and stop paying. Nobody at Amazon was woken up. Every part of that experience appears in one sentence that the whole field uses as its reference.

The NIST cloud definition, published by Mell and Grance as SP 800-145 in September 2011, reads:

Map the 2 a.m. VM onto it. A phone on any network is ubiquitous access. Launching without asking is on-demand. The VM came from a shared pool of hardware. It appeared in a minute and disappeared an hour later: rapidly provisioned and released. No one at the provider was involved: minimal interaction.

The 5-3-4 frame

The definition continues: the cloud model “is composed of five essential characteristics, three service models, and four deployment models”. Slide 38 draws them as three layers.

Service models are part 07. This part covers the five characteristics and the four deployment models. NIST later built its cloud reference architecture (SP 500-292) on the same definition, so the vocabulary carries through standards, procurement documents and papers.

Your department has a file server. To get space on it you email IT, wait two days, and receive a fixed quota that never shrinks. It runs on a VM, so it is “virtualized”. Is it a cloud? Test it against the five characteristics and it fails two at once: there is no self-service, and capacity does not grow or shrink with demand. It is virtualized hosting. Now test Google Drive or EC2. They pass all five.

The five characteristics are the test. Slide 39 gives one-line versions. The NIST text is more precise, and the precise words are where the exam marks are.

1. On-demand self-service. A consumer can provision computing capabilities “unilaterally … as needed automatically without requiring human interaction with each service provider”.
2. Broad network access. Capabilities are available over the network through “standard mechanisms” usable from “heterogeneous thin or thick client platforms”: phones, tablets, laptops, workstations.
3. Resource pooling. The provider's resources serve many consumers in a “multi-tenant model”, “dynamically assigned and reassigned according to consumer demand”. The customer does not control the exact location but may specify it “at a higher level of abstraction (e.g., country, state, or datacenter)”. That is why you pick a region but never a rack.
4. Rapid elasticity. Capabilities scale rapidly “outward and inward commensurate with demand”, and to the consumer they “often appear to be unlimited”.
5. Measured service. Cloud systems “automatically control and optimize resource use by leveraging a metering capability” suited to the type of service (storage, processing, bandwidth, active user accounts). Usage “can be monitored, controlled, and reported, providing transparency for both the provider and consumer”. NIST adds in a footnote that metering is typically pay-per-use or charge-per-use. The bill in concept one is this characteristic made visible.

Three scenarios. Anyone with a credit card rents EC2 capacity in AWS's Bahrain region. A bank runs OpenStackfor its own business units only, either in its own data hall or in a hall it rents. And a student asks: if Saudi Aramco's internal cloud sits in a colocation facility, does it stop being private?

It does not, and the reason is the whole idea of a deployment model. Slide 40 summarizes it as “where the cloud infrastructure is deployed and who is allowed to use it”. Of those two, who may use it is what decides. NIST deliberately leaves ownership and, for most models, location open.

Public cloud

A Public cloud is provisioned “for open use by the general public”. It “may be owned, managed, and operated by a business, academic, or government organization, or some combination of them”, and it “exists on the premises of the cloud provider”, which means off premises for every user. This is the Hyperscaler world of AWS, Azure and Google Cloud. Armbrust et al. describe it as a cloud “made available in a pay-as-you-go manner to the general public”, and the provider is a Cloud service provider (CSP).

Private cloud

A Private cloud is provisioned “for exclusive use by a single organization comprising multiple consumers (e.g., business units)”. It may be owned, managed and operated by the organization, a third party, or both, and it “may exist on or off premises”. The bank's OpenStack deployment is private whether it runs in the bank's basement or in a rented hall, because only the bank's units can use it. The same goes for the colocated Aramco cloud.

During Hajj season or Black Friday, an e-commerce site's traffic multiplies for a few days. The company runs its shop on its own private cloud, sized for a normal week. When that capacity hits its peak, the overflow is sent to EC2, and when the rush ends the rented capacity is released. That move has a name: Cloud bursting, and it is the textbook example of a hybrid cloud.

Hybrid cloud

NIST defines a Hybrid cloud as “a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds)”. Two phrases carry the definition. The parts “remain unique entities”: the private cloud does not dissolve into the public one. And they are bound by technology that enables “portability”: the same application and data can run on either side.

AWS describes cloud bursting as “a configuration method that uses cloud computing resources whenever on-premises infrastructure reaches peak capacity”. It also sells the opposite direction: AWS Outposts brings “AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience”, aimed at low latency, local data processing and data residency. Those are exactly the reasons the previous concept gave for keeping IT on premises, which is why hybrid designs show up all along the E2C continuum.

Community cloud

A Community cloud is provisioned “for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations)”. Like a private cloud, it may be owned and operated by community members, a third party, or both, and it may exist on or off premises.

AWS GovCloud (US) is a working example. It is offered to “verified U.S. government agencies and entities”, in “physically and logically isolated U.S. sovereign regions … operated by U.S. citizens on U.S. soil”. The agencies share it because they share the same compliance regime (FedRAMP High, ITAR), which is precisely NIST's “shared concerns”. NIST SP 800-146 discusses the trade-offs of each deployment model in more depth.

Suppose Majid's lab wants a small web app to track the papers everyone is reading. There are four ways to get it running. Option A: buy servers, rack them in a room on campus and run everything, the classic Legacy IT setup. Option B: rent virtual machines on Amazon EC2 and install the app on them. Option C: push the code to Google App Engine and let Google run it. Option D: subscribe to a ready-made paper tracker and just log in. The app the lab members see is the same in all four cases. What changes is how many layers of the stack the lab runs itself, and how many it hands to a Cloud service provider (CSP).

That observation is the whole idea of a service model. The lecture draws the stack as nine layers, from the bottom up: Data Center, Networking, Storage, Server, Virtualization, Operating Systems, Databases, Security and Applications. A service model is a statement about where one horizontal line sits on that stack. Everything below the line is the provider's job, and everything above it is yours. Reading the slide diagrams, the number of customer-managed layers takes four values, one per model:

The three model names come from the NIST cloud definition, NIST SP 800-145 (Mell and Grance, 2011), which defines exactly three service models: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Each definition starts with the same phrase, "the capability provided to the consumer is", which tells you what NIST is really describing: what the customer is handed, and therefore what the customer is left to manage. The Berkeley "Above the Clouds" report makes the same point as a spectrum: utility computing offerings "will be distinguished based on the level of abstraction presented to the programmer and the level of management of the resources", with Amazon EC2 at one end and Google AppEngine at the other.

Moving the line up has a price and a payoff. The payoff is less operational work: fewer things to patch, back up, monitor and replace. The price is control. You can no longer pick the kernel, tune the database or install an unusual library, because those layers are no longer yours. Microsoft puts it in one sentence: "In an on-premises datacenter, you own the whole stack. As you move to the cloud, some responsibilities transfer to Microsoft."

Start with what launching an Amazon EC2 instance actually looks like. You pick an instance type, which AWS describes as one of "various configurations of CPU, memory, storage, networking capacity, and graphics hardware". You pick an Amazon Machine Image (AMI), a template that includes the operating system, say Ubuntu. You attach an EBS volume for persistent disk, and you set a security group, which AWS calls "a virtual firewall". A minute later you have what AWS calls "a virtual server", billed On-Demand per second with a minimum of 60 s. From that moment on, patching Ubuntu, installing PostgreSQL and hardening SSH are your jobs.

That is Infrastructure as a Service (IaaS) in practice. The provider runs the five bottom layers, Data Center, Networking, Storage, Server and Virtualization, and hands you a Virtual machine (VM). You run the four top layers: Operating Systems, Databases, Security and Applications. NIST phrases it as the capability to "provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications". The consumer "has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls)." You get those resources through On-demand self-service and pay for them as a Measured service.

The resources an IaaS provider rents come in three families:

• Compute: CPU, GPU and RAM, enough to execute arbitrary tasks, from a web server to a model training job.
• Storage: block, file and object storage, three different shapes for data described below.
• Networking: virtual routers, switches and load balancers that connect your machines to each other and to the internet.

Three shapes of storage

Students often treat the three storage types as three speeds of the same disk. They are three different ways of addressing data. Block storage splits data into "fixed-sized blocks", each with its own address, and the server mounts the whole thing as a volume, exactly like a raw disk; AWS calls this EBS. File storage keeps data as files in hierarchical "directory trees" on network-attached storage that many clients can share at once; AWS calls this EFS. Object storage keeps data as "discrete units called objects", each with its own metadata, in "a flat namespace" where "the object's unique identifier provides the address". You reach objects through an HTTP API, not a mount; AWS calls this S3.