Cloud Deployment Models
Where your cloud infrastructure lives determines your control, your compliance posture, and your attack surface.
Public Cloud
Infrastructure is owned and operated by a third-party provider and shared among multiple tenants. AWS, Azure, and GCP are public clouds. Capital expenditure drops to zero; operational expenditure scales with usage. The trade-off: you have no physical access and must trust provider security certifications (SOC 2, ISO 27001, FedRAMP).
Private Cloud
Dedicated infrastructure for a single organisation, either on-premises or hosted. OpenStack and VMware vSphere are common platforms. You control the hardware but absorb the full cost of capacity planning, maintenance, and security. Proxmox VE is used as the private-cloud platform in this course.
Community Cloud
Shared infrastructure among organisations with common concerns: a government cloud, a healthcare cloud. NIC MeghRaj (India) is a community cloud for government departments. Compliance requirements align; cost is shared.
Hybrid Cloud
A composition of two or more cloud models connected by technology that enables data and application portability. A hospital might keep patient records in a private cloud and use public cloud for burst compute. Security policies must span the boundary consistently.
Migration Approaches and Their Security Characteristics
| Strategy | Description | Key Security Risk |
|---|---|---|
| Rehost (Lift-and-shift) | Move workloads to cloud VMs as-is | Legacy vulnerabilities migrate unchanged |
| Replatform | Minimal changes to leverage managed services | Misconfigured managed service settings |
| Refactor | Redesign for cloud-native architecture | Larger change surface during transition |
| Retire | Decommission systems | Incomplete data deletion |
| Retain | Keep on-premises | Hybrid connectivity expands attack surface |
The Shared Responsibility Model
The shared responsibility model defines what the cloud provider secures and what you must secure. It shifts depending on the service model.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider |
| Hypervisor / runtime | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Application code | Customer | Customer | Provider |
| Data | Customer | Customer | Customer |
| Identity & access | Customer | Customer | Customer |
| Network controls | Shared | Provider | Provider |
The most common cloud breach pattern: A customer misunderstands the shared responsibility boundary and leaves a layer they own (usually data or identity) without adequate controls.
A Real Example: S3 Misconfiguration
An S3 bucket's access control is entirely the customer's responsibility. AWS secures the underlying storage hardware and provides the tools (bucket policies, ACLs, Block Public Access). When Capital One was breached in 2019, the attacker exploited an overly permissive IAM role: a customer responsibility, not AWS's. The provider was not liable.
Key Takeaway
Before deploying any workload to the cloud, map every component of your stack against the shared responsibility model. Document what you own. Treat provider-managed layers as trusted but not your problem to patch, and treat customer-managed layers as entirely your problem regardless of how the provider markets the service.