Regions, Availability Zones, and Why They Matter
A cloud region is a geographic area containing multiple, isolated data centres called availability zones (AZs). AZs within a region are connected by low-latency private fibre but are separated by flood plains, power grids, and fire zones. Deploying across multiple AZs gives you fault tolerance; deploying across multiple regions gives you disaster recovery.
From a security perspective, regions matter for data residency. When you store data in ap-south-1 (Mumbai), AWS guarantees the data does not leave that region unless you explicitly replicate it. Indian regulatory frameworks, such as DPDP Act 2023 and RBI guidelines, often mandate in-country data storage.
Control Plane vs. Data Plane
| Plane | Purpose | Examples | Security Risk |
|---|---|---|---|
| Control plane | Manage resources: create, configure, delete | AWS Console, CLI, API, CloudFormation | Compromised admin credentials; IAM privilege escalation |
| Data plane | Carry actual workload traffic | EC2 network, S3 object retrieval, RDS queries | Data exfiltration, injection attacks |
Attackers who compromise the control plane own everything; that is why MFA on root accounts and least-privilege IAM policies are non-negotiable.
Defence in Depth in the Cloud
Defence in depth layers controls so that a failure in one does not expose everything behind it.
| Layer | Cloud Implementation |
|---|---|
| Perimeter | WAF, DDoS protection (AWS Shield, Azure DDoS), CDN edge rules |
| Network | VPC, security groups, NACLs, private subnets |
| Host | OS hardening, patch management, endpoint detection |
| Application | Input validation, secure coding, dependency scanning |
| Data | Encryption at rest and in transit, tokenisation, key management |
| Identity | MFA, least privilege, IAM policies, JIT access |
| Monitoring | CloudTrail, GuardDuty, SIEM, alerting |
Zero Trust Architecture
Zero Trust operates on the principle: never trust, always verify. In a cloud context, this means verifying explicitly by authenticating and authorising every request, even internal ones; using least privilege by granting minimum access for minimum time; and assuming breach by designing for containment, not just prevention.
Zero Trust in the cloud means east-west traffic (VM to VM inside a VPC) is subject to the same policy checks as north-south traffic (internet-facing). Micro-segmentation and service mesh architectures (Istio, AWS App Mesh) enforce this.
Virtualisation: Type-1 vs Type-2 Hypervisors
| Type | Runs On | Examples | Performance | Use Case |
|---|---|---|---|---|
| Type-1 (bare-metal) | Directly on hardware | VMware ESXi, Microsoft Hyper-V, KVM | High | Cloud data centres, production |
| Type-2 (hosted) | On top of an OS | VMware Workstation, VirtualBox | Lower | Developer labs, testing |
AWS uses a customised KVM hypervisor (Nitro) for EC2. Understanding the hypervisor layer matters because hypervisor escapes, though rare, represent the most severe cloud vulnerability class.
Hardware-Assisted Virtualisation
Modern CPUs include virtualisation extensions that let the hypervisor trap privileged instructions without full software emulation. Intel VT-x introduces VMX root mode for the hypervisor and VMX non-root mode for guests, using the VMCS (VM Control Structure) to save and restore guest state, while AMD-V is the equivalent AMD implementation using VMCB (VM Control Block).
These extensions reduce virtualisation overhead from 20-40% to under 5% in modern workloads.
Containers vs. Virtual Machines
| Dimension | Virtual Machine | Container |
|---|---|---|
| Isolation boundary | Full hardware emulation | Kernel namespaces + cgroups |
| Boot time | Minutes | Milliseconds |
| OS overhead | Full guest OS per VM | Shared host kernel |
| Attack surface | Hypervisor escape | Kernel exploit, container escape |
| Forensic artefacts | VM snapshot, memory dump | Container image layers, runtime logs |
Containers share the host kernel. A kernel vulnerability exploitable from inside a container affects all containers on that host. The 4Cs of cloud-native security (Cloud, Cluster, Container, Code) represent the layered approach to securing containerised workloads.
Key Takeaway
Architecture decisions made at design time, such as single AZ vs. multi-AZ, Type-1 vs. Type-2 hypervisor, or containers vs. VMs, all determine which threat vectors are relevant and what controls must be layered above them. Security cannot be bolted on after architecture is finalised.