Infrastructure as a Service

Physical facilities and infrastructure hardware form the foundation of IaaS. With cloud computing we abstract and pool these resources, but at the most basic level we always need physical hardware, networks, and storage to build on. These resources are pooled using abstraction and orchestration. Abstraction, often via virtualization, frees the resources from their physical constraints to enable pooling. Then a set of core connectivity and delivery tools (orchestration) ties these abstracted resources together, creates the pools, and provides the automation to deliver them to customers.

All this is facilitated using Application Programming Interfaces (APIs). APIs are typically the underlying communications method for components within a cloud, some of which (or an entirely different set) are exposed to the cloud consumer to manage their resources and configurations. Most cloud APIs these days use REST (Representational State Transfer), which runs over the HTTP protocol, making it extremely well suited for Internet services.

In most cases, those APIs are both remotely accessible and wrapped into a web-based user interface. This combination is the cloud management plane, since consumers use it to manage and configure the cloud resources, such as launching virtual machines (instances) or configuring virtual networks. From a security perspective, it is the both the biggest difference from protecting physical infrastructure (since you can't rely on physical access as a control) as well as the top priority when designing a cloud security program. If an attacker gets into your management plane, they potentially have full remote access to your entire cloud deployment.

Thus IaaS consists of a facility, hardware, an abstraction layer, an orchestration (core connectivity and delivery) layer to tie together the abstracted resources, and APIs to remotely manage the resources and deliver them to consumers.

Here is a simplified architectural example of a compute IaaS platform:

This is a very simple diagram showing the compute and storage controllers for orchestration, hypervisors for abstraction, and the relationship between the compute and storage pools. It omits many components, such as the network manager.

A series of physical servers each run two components: a hypervisor (for virtualization) and the management/orchestration software to tie in the servers and connect them to the compute controller. A customer asks for an instance (virtual server) of a particular size and the cloud controller determines which server has the capacity and allocates an instance of the requested size.

The controller then creates a virtual hard drive by requesting storage from the storage controller, which allocates storage from the storage pool, and connects it to the appropriate host server and instance over the network (a dedicated network for storage traffic). Networking, including virtual network interfaces and addresses, is also allocated and connected to the necessary virtual network.

The controller then sends a copy of the server image into the virtual machine, boots it, and configures it; this creates an instance running in a virtual machine, with virtual networking and storage all properly configured. Once this entire process is complete, the metadata and connectivity information is brokered by the cloud controller and available to the consumer, who can now connect to the instance and log in.