Cloud+: Cloud Architecture

1. Cloud Service Models (IaaS / PaaS / SaaS)

Infrastructure as a Service (IaaS)

Raw infrastructure — VMs, storage, networking. You manage: OS, runtime, middleware, applications, data. Provider manages: physical hardware, hypervisor, data center.

Examples: AWS EC2, Azure Virtual Machines, GCP Compute Engine

Platform as a Service (PaaS)

Managed platform — runtime and middleware handled by provider. You manage: application code and data only. Provider manages: OS, patching, scaling infrastructure.

Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine

Software as a Service (SaaS)

Complete application delivered over the web. Provider manages everything — infrastructure, platform, and application. You manage: user accounts and data within the app.

Examples: Salesforce, Microsoft 365, Google Workspace

Function as a Service (FaaS) — Serverless

Event-driven compute — code executes in response to triggers with zero server management. You pay per execution, not per hour. Scales automatically to zero when idle.

Examples: AWS Lambda, Azure Functions, Google Cloud Functions

2. Cloud Deployment Models

Public Cloud

Resources owned and operated by a third-party provider, shared across many customers on shared infrastructure. Pros: elastic scalability, no capex, global reach, pay-as-you-go. Cons: less control, shared tenancy compliance concerns.

Private Cloud

Dedicated infrastructure for one organization — either on-premises or hosted by a third party for exclusive use. Pros: full control, regulatory compliance, customization. Cons: high capex, ongoing maintenance burden.

Hybrid Cloud

Combination of public + private cloud with orchestrated connectivity between them. Classic use case: keep sensitive/regulated data on-premises private cloud, burst overflow workloads to public cloud during peak demand.

Multi-Cloud

Using services from multiple public cloud providers simultaneously (e.g., AWS + Azure + GCP). Benefits: avoid vendor lock-in, use best-of-breed services from each provider, geographic redundancy. Challenges: operational complexity, cost management, multi-cloud skills gap.

Community Cloud

Shared infrastructure for organizations with common requirements — e.g., government agencies sharing a FedRAMP-compliant cloud, or healthcare orgs sharing HIPAA-compliant infrastructure.

3. Virtualization Concepts

Hypervisors

Software layer that creates and manages virtual machines (VMs) by abstracting physical hardware.

• Type 1 (Bare-metal): Runs directly on physical hardware — no host OS required. Better performance and security. Data center standard. Examples: VMware ESXi, Microsoft Hyper-V, KVM (Linux Kernel-based VM)
• Type 2 (Hosted): Runs on top of a host operating system. Easier setup, lower performance. Used for dev/test. Examples: Oracle VirtualBox, VMware Workstation

Virtual Machines

Isolated virtual compute instances each running a full guest OS. Heavyweight — full OS overhead. Strong isolation between VMs. Boot time: minutes. Size: GBs.

Key VM Features

• Snapshots: Point-in-time copy of full VM state (disk + memory + config) — used for backup and rollback before risky changes
• Templates: Pre-configured VM images for rapid, consistent deployment of new VMs
• Overprovisioning: Assigning more virtual resources (vCPU, vRAM) than physical hardware has — works because average VM utilization is low, but can cause resource contention under load

4. Cloud Networking Concepts

VPC (Virtual Private Cloud)

Isolated, logically defined virtual network within a public cloud — you control IP address ranges (CIDR), subnets, route tables, and gateways. Foundation of cloud network architecture.

Subnets

• Public subnet: Has route to Internet Gateway — resources can receive internet traffic (web servers, load balancers)
• Private subnet: No direct internet route — internal resources only (databases, application servers)

Firewall Controls

• Security Groups: Stateful virtual firewall at the instance level. Tracks connection state — if you allow outbound, return traffic is automatically allowed. Allow rules only (no deny).
• NACLs (Network Access Control Lists): Stateless firewall at the subnet level. Must explicitly allow both request AND response traffic. Supports allow AND deny rules. Rules evaluated in order.

Connectivity Options

• VPN: Encrypted tunnel over the public internet connecting on-premises to cloud VPC. Variable latency, lower cost, quick setup.
• Direct Connect / ExpressRoute: Dedicated private physical connection to cloud (bypasses public internet). Consistent low latency, high bandwidth. Higher cost. For production workloads requiring predictable performance.

Load Balancers

• Application LB (Layer 7): HTTP/HTTPS traffic, path-based and host-based routing, SSL termination
• Network LB (Layer 4): TCP/UDP traffic, ultra-low latency, preserves source IP
• Global LB: Routes traffic across multiple regions for geo-distribution and HA

CDN (Content Delivery Network)

Distributes cached static content (images, scripts, video) to edge locations globally — reduces latency by serving content from the closest point to the user. Examples: CloudFront, Azure CDN, Cloudflare.

5. Containerization Concepts

Container Fundamentals

• Container: Lightweight, isolated runtime process sharing host OS kernel. Fast startup (seconds), small footprint (MBs).
• Container vs VM: VMs — full OS, strong isolation, slow startup, GBs. Containers — shared kernel, process isolation, fast startup, MBs.

Docker Components

• Dockerfile: Text file with build instructions defining how to create an image layer by layer
• Image: Immutable, layered artifact built from Dockerfile. Base OS layer + application layers stacked on top.
• Container: Running instance of an image — ephemeral by default (data lost on stop)
• Registry: Storage and distribution for images. Public: Docker Hub. Private: AWS ECR, Azure ACR, GCP Artifact Registry.

Container Networking Modes

• Bridge: Default mode — isolated network per host, containers communicate via virtual bridge
• Host: Container shares the host's network stack directly — no isolation
• Overlay: Multi-host networking for orchestrated clusters — spans across nodes

Container Storage

Container filesystem is ephemeral — data is lost when the container stops. Use volumes (managed by Docker/orchestrator) or bind mounts (host directory) for persistent data that survives container restarts.

6. Container Orchestration (Kubernetes)

What Orchestration Provides

Automated lifecycle management of containers: scheduling (where to run), scaling (how many replicas), self-healing (replace failed containers), networking (service discovery), and storage management.

Core Kubernetes Objects

• Pod: Smallest deployable unit in K8s — wraps one or more containers sharing network namespace and storage volumes. Ephemeral by nature.
• Deployment: Declarative controller that manages a set of identical pod replicas. Handles rolling updates, rollbacks, and self-healing (restarts failed pods to maintain desired replica count).
• Service: Stable virtual IP and DNS name abstracting a group of pods. Types: ClusterIP (internal), NodePort (node-level external), LoadBalancer (cloud LB provisioned).
• Namespace: Virtual cluster for logical isolation of resources — separate teams/environments within one physical K8s cluster.
• Ingress: HTTP/HTTPS routing rules mapping external hostnames/paths to backend Services. Requires an Ingress Controller (e.g., NGINX, Traefik).
• ConfigMap / Secret: Externalize configuration from container images — ConfigMap for non-sensitive config, Secret for credentials (base64-encoded, optionally encrypted at rest).

Managed Kubernetes Services

Cloud providers manage the K8s control plane (API server, etcd, scheduler) — you manage worker nodes and workloads.

• EKS — Amazon Elastic Kubernetes Service (AWS)
• AKS — Azure Kubernetes Service (Microsoft)
• GKE — Google Kubernetes Engine (GCP)

7. Database Fundamentals in Cloud

Relational Databases (SQL / RDBMS)

Structured data with fixed schema, tables, and relationships. ACID-compliant for transactional data. Use for: e-commerce orders, financial records, user accounts.

Cloud examples: AWS RDS (MySQL, PostgreSQL, Oracle), Azure SQL Database, Google Cloud SQL

NoSQL Database Categories

• Key-Value: Fast lookups by unique key — DynamoDB, Redis, Memcached. Use: session data, caching, shopping carts
• Document: JSON/BSON document storage with flexible schema — MongoDB, Cosmos DB. Use: product catalogs, content management, user profiles
• Column-family: Wide-column storage optimized for analytics and time-series — Apache Cassandra, HBase. Use: IoT data, event logs, analytics
• Graph: Optimized for relationships and traversal queries — Neo4j, AWS Neptune. Use: social networks, recommendation engines, fraud detection

High Availability vs Read Scaling

• Multi-AZ: Synchronous replication to a standby in a different Availability Zone. Purpose: HA and automatic failover. Zero data loss. Standby CANNOT serve read traffic.
• Read Replica: Asynchronous copy for distributing read traffic. Purpose: read scaling only. NOT for failover (replica lag possible). Can be in same AZ, different AZ, or different region.

CAP Theorem

Distributed systems can guarantee at most 2 of 3 properties: Consistency (all nodes see same data), Availability (every request gets a response), Partition Tolerance (works despite network failures). Most cloud DBs choose AP (available + partition tolerant) or CP.

Caching

Place Redis or Memcached in front of the database to serve frequently-read data from memory — dramatically reduces database load and read latency. Common patterns: cache-aside, write-through.

8. Resource Optimization and Billing

Right-Sizing

Match instance type and size to actual workload resource consumption. Analyze CPU, memory, network, and disk utilization metrics — then downsize over-provisioned resources or upsize under-powered ones. First step before any pricing optimization.

Pricing Models

• On-Demand: Pay per hour/second with no commitment. Highest unit cost. Maximum flexibility. Use for: unpredictable workloads, short-term projects.
• Reserved Instances / Committed Use: 1 or 3-year commitment in exchange for up to 72% discount vs on-demand. Use for: stable, predictable baseline workloads (databases, core application servers).
• Spot / Preemptible Instances: Unused cloud capacity at up to 90% discount — can be interrupted with short notice (2 min on AWS). Use for: batch jobs, rendering, ML training, any fault-tolerant workload that checkpoints progress.

Auto Scaling

Automatically adjust compute capacity based on real-time demand. Scale out = add instances. Scale in = remove instances. Policies: target tracking (maintain metric like 70% CPU), step scaling (tiered thresholds), scheduled scaling (known traffic patterns).

Cost Governance

• Tagging: Mandatory for cost allocation — tag every resource with project, team, environment, and cost center. Without tags, you cannot attribute cloud spend.
• Cost anomaly detection: Automated alerts when spending deviates from expected baseline — catch runaway resources early.
• FinOps: Cultural and operational framework for shared financial accountability — engineering, finance, and business teams collaboratively optimize cloud spend. Not just a finance function.