Cloud Infrastructure Mechanisms

• These are the core building blocks from which all cloud architectures are composed. Understanding them at this level explains why cloud platforms behave the way they do — not just how to use the console.
• Each mechanism appears as a supporting actor in the Cloud Architecture Patterns page — this glossary provides the conceptual foundation for those patterns.

Note

These are foundational definitions of cloud primitives. Where relevant, each section maps the concept to its real-world equivalents in AWS, GCP, and Azure to bridge theory and practice.

---

Logical Network Perimeter

A logical network perimeter is the isolation of a network environment from the rest of a communications network. It establishes a virtual network boundary that can encompass a group of related cloud IT resources — even if those resources span different physical hosts or data centers.

What it does:

• Isolates cloud IT resources from unauthorised users, non-users, and other cloud consumers
• Controls bandwidth available to isolated resources
• Enables per-consumer network policy enforcement without requiring dedicated hardware

Core components:

Component	Role
Virtual Firewall	Filters traffic to/from the isolated network; controls internet interaction; can be allocated to a single consumer
Virtual Network (VLAN)	Isolates the network environment within the broader data center fabric

Together, a virtual firewall + isolated virtual network = a consumer’s complete logical network perimeter.

Connectivity between perimeters: When separate perimeters must communicate (e.g., consumer on-premises connecting to provider cloud), they are bridged via a VPN using point-to-point encryption between endpoints.

Layered perimeter example:

Layer	Description
External / Extranet	Outermost boundary; routers → external firewalls; loosely isolated from the internet
DMZ (Demilitarized Zone)	Between external and internal firewalls; hosts proxy servers for DNS, email, web portals; all inbound traffic passes through here
Management Network	Behind management firewalls; provides self-service and on-demand resource provisioning portals
Intra-Data Center	Connects management and virtual networks across data centers via intra-data center firewalls

Real-world platform equivalents:

Concept	AWS	GCP	Azure
Logical network perimeter	VPC (Virtual Private Cloud)	VPC Network	Virtual Network (VNet)
Virtual network isolation	Subnets + NACLs	Subnets + Firewall Rules	Subnets + NSGs
DMZ pattern	Public subnet + ALB	Dedicated ingress subnet + Cloud Load Balancing	DMZ subnet + Azure Firewall
Cross-perimeter VPN	Site-to-Site VPN / Direct Connect	Cloud VPN / Interconnect	VPN Gateway / ExpressRoute

See also: Cloud Access Mechanisms — Firewall & VPN, Cloud Architecture Patterns — Workload Distribution.

---

Virtual Server

A virtual server (synonymously: virtual machine / VM) is virtualisation software that emulates a physical server. It is the most foundational compute primitive of cloud environments — used to host IT resources, cloud services, and other cloud mechanisms.

Why virtual servers are the backbone of cloud: Cloud providers share the capacity of a single physical server among multiple consumers by issuing them individual VM instances. This is what makes the pay-per-use model possible — instead of a dedicated server sitting idle, physical resources are partitioned and billed only for what is consumed.

Creation and lifecycle:

• Instantiated on-demand from VM images — files representing virtual disk images that a hypervisor uses to boot the server
• Managed by a Virtual Infrastructure Manager (VIM) that coordinates hardware and hypervisors to find the optimal physical host for each new instance
• Support live VM migration — a running VM can be suspended, have its state synced via shared cloud storage, and resumed on a different physical host without downtime (critical for auto-scaling)
• Support resource replication — multiple identical instances can be spawned from a single image for HA and load distribution

Performance tiers (typical provider model):

Tier	vCPUs	RAM	Use case
Small	1	4 GB	Dev/test, low-traffic services
Medium	4	16 GB	Web servers, microservices
Large	16	64 GB	Data processing, app servers
Ultra-Large	128	512 GB	HPC, in-memory databases

Deployment flow:

1. Consumer selects a template VM from self-service portal
2. A copy of the VM image is generated in consumer-controlled cloud storage
3. Consumer initiates the server; portal passes performance profile + VM image to VIM
4. VIM creates the active instance on the optimal physical host
5. Consumer logs in to administer and customise

Real-world platform equivalents:

Concept	AWS	GCP	Azure
Virtual server	EC2 Instance	Compute Engine (GCE) VM	Azure Virtual Machine
VM image	AMI (Amazon Machine Image)	Custom Image / Public Image	VM Image / Managed Image
Live migration	Stop → snapshot → restore (manual)	Transparent live migration	VM maintenance (live migrate)
VIM equivalent	EC2 control plane + Auto Scaling	GCE control plane + Managed Instance Groups	Azure Fabric Controller

Tip

GCP Compute Engine performs transparent live migration of VMs during host maintenance with no consumer action required — a significant operational advantage over traditional VM migration which typically requires downtime.

See also: Cloud Architecture Patterns — Dynamic Scalability, Elastic Capacity.

---

Hypervisor

The hypervisor is the virtualisation layer installed directly on physical (bare-metal) hardware that generates and manages virtual server instances. It is what makes one physical machine appear as many independent virtual machines to consumers.

What a hypervisor does:

• Creates VM instances from stored VM images
• Schedules and shares underlying hardware resources (CPU, memory, I/O) across multiple VMs, presenting them to each VM’s OS as if they were dedicated
• Manages live VM migration at the individual host level (coordinated by the VIM across hosts)
• Acts as the resource replication engine — spawning multiple identical VMs from a single image

Scope and limitations:

Capability	Hypervisor alone	With VIM
Creates VMs	✅ On its physical host only	✅ Across all managed hosts
Scales VMs (vertical)	✅ Increase/decrease CPU+RAM of hosted VMs	✅
Migrates VMs across hosts	❌ Needs VIM coordination	✅
Global resource optimisation	❌ Single-host view	✅ Fleet-wide view

Hypervisor types:

Type	Description	Examples
Type 1 (bare-metal)	Installed directly on hardware; no host OS required; lower overhead, higher performance	Xen (AWS), KVM (GCP/OpenStack), VMware ESXi, Hyper-V
Type 2 (hosted)	Runs on top of a host OS; higher overhead; used for development/testing	VirtualBox, VMware Workstation

Public cloud providers universally use Type 1 hypervisors. AWS uses a customised Xen/KVM hybrid (Nitro), GCP and most OpenStack deployments use KVM, Azure uses Hyper-V.

Live migration flow:

1. VIM detects overloaded physical host
2. VIM commands source hypervisor to suspend the VM
3. VM state is synced via shared cloud storage
4. VIM commands target hypervisor (idle host) to resume the VM
5. VM becomes active on new host — transparent to the consumer

See also: Cloud Architecture Patterns — Elastic Capacity, Redundant Storage.

---

Cloud Storage Device

A cloud storage device provides remote, virtualised storage provisioned for cloud consumers — exposed via cloud storage services and billed on a pay-per-use basis via fixed-increment capacity allocation.

Primary concerns with cloud storage:

Concern	Detail
Security & privacy	Data integrity and confidentiality are more susceptible when stored externally; mitigated by encryption at rest and in transit
Compliance	Moving data across geographic/national boundaries triggers legal and regulatory obligations (GDPR, data sovereignty laws)
Performance	Large databases accessed over WANs suffer higher latency than LAN-local storage — a key architectural trade-off

Storage levels and interfaces:

Network Storage (File and Block)

Type	Structure	Interface	Best for
File storage	Data in files and folders	SMB, CIFS, NFS	Shared file systems, home directories, content management
Block storage	Fixed-format data blocks; lowest level, closest to hardware	SCSI, LUNs	Databases, boot volumes — better raw I/O performance than file

Block storage with LUNs (Logical Unit Numbers) generally outperforms file-level storage because the OS manages the file system rather than a remote NAS — eliminating a translation layer.

Object Storage

• Stores and references data as web resources, each with associated metadata
• Accessed via REST or HTTP-based APIs
• Standard: SNIA’s Cloud Data Management Interface (CDMI)
• Infinitely horizontally scalable — no hierarchy limit; ideal for unstructured data at massive scale

Database Storage

Type	Structure	Query	Strengths	Trade-offs
Relational (SQL)	Tables, rows, columns; enforced relationships; normalised	SQL	Data integrity, complex joins, transactions	Expensive vertical scaling; remote access latency
Non-relational (NoSQL)	Loose structure; schema-flexible	Varies (key-value, document, graph)	Horizontal scaling, high throughput, schema flexibility	No native transactions/joins; data grows (denormalised); often proprietary

Real-world platform equivalents:

Storage type	AWS	GCP	Azure
Object	S3	Cloud Storage	Azure Blob Storage
Block	EBS (Elastic Block Store)	Persistent Disk	Azure Managed Disks
File	EFS (NFS) / FSx (SMB)	Filestore	Azure Files
Relational DB	RDS / Aurora	Cloud SQL / AlloyDB	Azure SQL / PostgreSQL
NoSQL	DynamoDB / DocumentDB	Firestore / Bigtable	Cosmos DB

Caution

Data sovereignty matters. Before migrating databases to cloud storage, audit whether your data residency requirements allow storage in the provider’s available regions. GDPR, HIPAA, and sector-specific regulations may restrict where data can physically reside.

See also: Cloud Architecture Patterns — Resource Pooling, Resilient Disaster Recovery.

---

Cloud Usage Monitor

A cloud usage monitor is a lightweight, autonomous software program that collects and processes IT resource usage data — forming the instrumentation layer that makes pay-per-use billing, auto-scaling decisions, and capacity planning possible.

Monitors are typically configured to forward collected data to a centralised log database for post-processing and reporting.

Three agent-based implementation formats:

Agent type	How it works	Typical metrics collected
Monitoring Agent	Intermediary service agent sitting along communication paths; intercepts messages transparently, logs metrics, forwards the message	Network traffic volume, message counts, request rates
Resource Agent	Event-driven module; hooks into resource software and fires on predefined state-change events	VM start/stop/scale events; resource allocation changes
Polling Agent	Periodically polls IT resources at a defined interval	Uptime/downtime, periodic CPU/memory utilisation

Example billing pipeline: A cloud provider transitioning from flat annual leases to hourly pay-per-use billing can use a Resource Agent that hooks into the VIM:

1. VIM emits events: VM_Starting, VM_Started, VM_Stopping, VM_Stopped, VM_Scaled
2. Each event payload includes: event type, VM performance tier, VM ID, consumer ID, timestamp
3. Agent calculates usage cycles — time intervals between state-change events (e.g., VM_Started → VM_Scaled_Up)
4. Total minutes-active per billing period are stored in a log database
5. Administration portal queries the database to generate consumer invoices

Real-world platform equivalents:

Concept	AWS	GCP	Azure
Monitoring agent	CloudWatch Agent	Ops Agent	Azure Monitor Agent
Resource event monitoring	CloudTrail / EventBridge	Cloud Audit Logs / Eventarc	Azure Activity Log / Event Grid
Usage/billing data	Cost Explorer + CUR	Cloud Billing Export	Cost Management + Billing
Polling / metrics	CloudWatch Metrics	Cloud Monitoring	Azure Monitor Metrics

See also: Cloud Architecture Patterns — Workload Distribution, Dynamic Scalability, Cloud Cost Optimization.

---

Resource Replication

Resource replication is the creation of multiple identical instances of an IT resource — the primary mechanism for achieving high availability, fault tolerance, and horizontal scalability in cloud environments.

Scope: Acts as a “parent mechanism” — it describes the capability that multiple concrete technologies implement:

Replication type	Implemented by	What gets replicated
VM replication	Hypervisor	Virtual server instances from a stored VM image
Service replication	Load balancer + orchestrator	Cloud service implementations
Data replication	Storage replication agents	Data sets, cloud storage devices
Environment replication	PaaS runtime	Ready-made environments, full application stacks

Synchronous vs. asynchronous replication:

Mode	Behaviour	Use case
Synchronous	Write confirmed only after all replicas updated	Financial systems, databases requiring zero data loss
Asynchronous	Write confirmed immediately; replicas updated eventually	Geographic distribution across high-latency links; acceptable RPO > 0

Cross-data center HA flow:

1. VM on physical host in Data Center A fails
2. VIM in Data Center B detects failure condition
3. VIMs in both data centers coordinate
4. Data Center B VIM creates a new instance from the pre-replicated VM image
5. Service resumes — consumer experiences minimal downtime

Real-world platform equivalents:

Concept	AWS	GCP	Azure
VM replication / HA	Auto Scaling Groups + Multi-AZ	Managed Instance Groups (MIGs)	VM Scale Sets
Storage replication	S3 Cross-Region Replication / EBS snapshots	Cloud Storage multi-region / PD snapshots	GRS / ZRS storage
Service replication	ECS / EKS replica sets	GKE replica sets	AKS replica sets

See also: Cloud Architecture Patterns — Dynamic Scalability, Redundant Storage Architecture.

---

Ready-Made Environment

A ready-made environment is the defining primitive of the Platform-as-a-Service (PaaS) delivery model — a predefined, cloud-based platform with pre-installed IT resources that consumers use to develop and deploy applications without managing the underlying infrastructure.

What comes pre-installed:

• Databases, middleware, development tools, and governance tools
• A complete Software Development Kit (SDK) for the consumer’s preferred language/runtime stack
• Middleware for multitenant platform support (web app frameworks, message brokers, etc.)

Why this matters — the IaaS vs PaaS distinction:

Dimension	IaaS (VM-based)	PaaS (Ready-Made Environment)
What consumer manages	OS, runtime, middleware, app, data	App logic and data only
Time to first deployment	Hours to days (provision + configure)	Minutes (push code, done)
Scaling model	Manual or scripted VM replication	Platform handles scaling automatically
Operational burden	High — patching, hardening, etc.	Low — provider manages runtime
Customisation	Complete control	Constrained to platform’s runtime

Logic partitioning for performance and cost: PaaS environments can be split across multiple instances billed at different rates — allowing workloads to be optimised independently:

Instance type	Handles	Billing implication
Front-end instance	Time-sensitive requests, simple queries	Lower resource tier = lower rate
Back-end instance	Long-running processing, heavy computation	Higher resource tier = higher rate

Example: An organisation builds a Java-based catalog web app on a PaaS environment. The front-end handles user queries; the back-end handles full catalog rendering and legacy part number correlation. Both instances share a cloud storage device for persistent data.

Real-world platform equivalents:

Concept	AWS	GCP	Azure
Ready-made environment	Elastic Beanstalk / App Runner	App Engine / Cloud Run	Azure App Service
Managed runtime	Lambda (serverless) / Lightsail	Cloud Functions / Cloud Run	Azure Functions / Container Apps
Database PaaS	RDS / Aurora Serverless	Cloud SQL / Spanner	Azure SQL Managed Instance

Tip

Modern PaaS has evolved significantly beyond these traditional definitions. Today’s platforms (App Engine, Cloud Run, Azure Container Apps) support containerised workloads and event-driven scaling to zero — blurring the line between PaaS and serverless. See Serverless Architecture for the contemporary model.

---

Container

A container is an OS-level virtualisation unit that packages an application and its dependencies into a portable, isolated runtime — offering a deployment and delivery primitive that is lighter than a VM but more self-contained than a bare process.

How containers differ from VMs:

Dimension	Virtual Machine	Container
Isolation unit	Full OS + application	Process namespace + application
Boot time	Minutes	Milliseconds to seconds
Size	GBs (full OS image)	MBs (only app + dependencies)
Overhead	Hypervisor + guest OS	Shared host OS kernel only
Portability	Limited — tied to hypervisor type	High — runs on any OCI-compatible runtime
Density	Dozens per physical host	Hundreds per physical host

Why containers dominate modern cloud delivery: The combination of speed (millisecond startup), density, and image portability makes containers the natural unit of deployment for microservices, CI/CD pipelines, and cloud-native applications. The OCI (Open Container Initiative) standard ensures images built with any compliant tool run on any compliant runtime.

Container orchestration: A single container is rarely the full story. At scale, containers are managed by orchestration platforms that handle scheduling, networking, storage, scaling, and self-healing:

Platform	Model	Managed cloud offering
Kubernetes	Declarative cluster management	EKS (AWS), GKE (GCP), AKS (Azure)
Docker Swarm	Simpler, built-in Docker orchestration	Self-managed
Nomad	Lightweight multi-workload scheduler	Self-managed

Security implication: Containers on the same host share the host OS kernel — a compromised host impacts all containers running on it. Mitigation: deploy containers inside virtual servers (VMs) to contain blast radius to a single VM. See Cloud Threat Taxonomy — Containerization Attack.

Real-world platform equivalents:

Concept	AWS	GCP	Azure
Container runtime service	ECS / EKS / Fargate	GKE / Cloud Run	AKS / Container Apps
Container image registry	ECR	Artifact Registry	Azure Container Registry
Serverless containers	Fargate	Cloud Run	Azure Container Apps

Note

Traditional cloud computing textbooks provide minimal coverage of containers. The expanded content above reflects the current industry state of containerisation, which has evolved significantly since the pre-Kubernetes era.

See also: Cloud Data Security — Containerization Attack, Cloud Architecture Patterns.