Project 7 – Multi-Cloud Strategy | Cloud Computing Course

1. The Cloud Provider Landscape

Three providers dominate the cloud market: Amazon Web Services (AWS) with ~32% market share, Microsoft Azure with ~22%, and Google Cloud Platform (GCP) with ~11%. Each has strengths in specific areas. A smart cloud strategy uses the right provider for the right workload — this is the essence of multi-cloud architecture. This project is research and documentation-intensive — your deliverable is a professional strategy document, not code.

2. Cloud Provider Service Comparison Matrix

Understanding how services map across providers is essential for architects who must choose the right service for each workload and for engineers who switch employers and must learn a new cloud platform quickly. The underlying concepts are identical — only the service names and details differ.

Service Category	AWS	Azure	GCP	Local Lab Equivalent
Virtual Machines	EC2 (Elastic Compute Cloud)	Virtual Machines (VMs)	Compute Engine (GCE)	VirtualBox Ubuntu VM
Container Service	ECS / Fargate	Azure Container Instances	Cloud Run	Docker Engine (Project 3)
Kubernetes	EKS (Elastic K8s Service)	AKS (Azure K8s Service)	GKE (Google K8s Engine)	MicroK8s / Kind (Project 9)
Object Storage	S3 (Simple Storage Service)	Azure Blob Storage	Cloud Storage (GCS)	MinIO (Project 5)
Managed SQL DB	RDS (Relational DB Service)	Azure SQL Database	Cloud SQL	MariaDB (Project 4 & 5)
NoSQL Database	DynamoDB	Cosmos DB	Firestore / Bigtable	MongoDB / Redis
CDN	CloudFront	Azure CDN / Front Door	Cloud CDN	Nginx caching headers
Load Balancer	ALB / NLB (ELB)	Azure Load Balancer / App Gateway	Cloud Load Balancing	HAProxy (Project 4)
VPC / Network	VPC (Virtual Private Cloud)	Virtual Network (VNet)	VPC (same term)	Linux bridge network
IAM	IAM (Users, Groups, Policies)	Azure Active Directory + RBAC	Cloud IAM	Linux users + sudo (Project 6)
Secrets Manager	AWS Secrets Manager / SSM	Azure Key Vault	Secret Manager	HashiCorp Vault (Project 6)
IaC (Infrastructure)	CloudFormation / Terraform	ARM Templates / Terraform	Deployment Manager / Terraform	Terraform (Project 8)
CI/CD Pipelines	CodePipeline / GitHub Actions	Azure DevOps	Cloud Build / Cloud Deploy	GitHub Actions (Project 10)
Monitoring	CloudWatch	Azure Monitor	Cloud Monitoring (Stackdriver)	Prometheus + Grafana (P10)
Serverless Functions	Lambda	Azure Functions	Cloud Functions	(covered conceptually)
Data Warehouse	Redshift	Synapse Analytics	BigQuery	SQLite analytics DB
Free Tier	12 months for most + always free	12 months + $200 credit	90 days + $300 credit	Unlimited (local lab)

3. Step-by-Step Action Items

PHASE 1 · RESEARCH Research Cloud Provider Pricing, SLAs, and Compliance

Professional cloud architects use official documentation and pricing calculators to build accurate cost models. This step requires you to visit each provider's website and extract specific information. This research is a core professional skill — cloud cost management is a major responsibility in cloud engineering roles.

Open AWS Pricing Calculator: Go to https://calculator.aws/pricing/2/home. Add these services and note the monthly estimate for a small deployment:
• 1x t3.medium EC2 instance (2 vCPU, 4 GB RAM) — 24/7
• 100 GB S3 Standard storage
• 1x RDS MySQL db.t3.micro (20 GB storage)
• 100 GB data transfer out per month
• Record the total monthly estimate

AWS pricing uses "on-demand" pricing by default (pay per hour, no commitment). The same resources on "Reserved" pricing (1-year or 3-year commitment) can be 40–72% cheaper. Spot Instances (unused capacity) can be 90% cheaper but can be interrupted with 2 minutes warning. Understanding these pricing models and when to use each one is a critical cost optimization skill that saves companies millions of dollars annually. Record your specific estimates — they are part of your deliverable.

Open Azure Pricing Calculator: Go to https://azure.microsoft.com/en-us/pricing/calculator/. Add equivalent services:
• 1x B2s Virtual Machine (2 vCPU, 4 GB RAM)
• 100 GB Azure Blob Storage (LRS)
• 1x Azure SQL Database (Basic tier, 2 GB)
• 100 GB outbound transfer
• Record the total monthly estimate

Azure pricing is structured similarly to AWS but with different tier names. B-series VMs are "burstable" — they accumulate CPU credits when idle and use them for periods of high activity. This is similar to AWS T3/T4g instances. The pricing calculator allows region selection — pricing varies by region due to different infrastructure costs. Regions in India (Central India, South India) typically have similar pricing to US East regions.

Open GCP Pricing Calculator: Go to https://cloud.google.com/products/calculator. Add equivalent services:
• 1x e2-medium Compute Engine instance
• 100 GB Cloud Storage Standard
• 1x Cloud SQL MySQL db-f1-micro
• 100 GB egress traffic
• Record the total monthly estimate

GCP has some unique pricing advantages: automatic sustained-use discounts (the longer you run a VM, the bigger the discount — automatically, no reservation required), committed use discounts, and per-second billing (AWS and Azure charge per-minute minimum for most services). GCP also offers free operations on most Cloud Storage operations — whereas AWS charges per 1,000 API requests on S3. These differences matter at scale.

Create a Price Comparison Table with your findings:

CLOUD PROVIDER PRICING COMPARISON — ABC RETAIL BASELINE (Replace X.XX with your actual researched figures) Service | AWS ($/month) | Azure ($/month) | GCP ($/month) ------------------------|---------------|-----------------|--------------- Small VM (2vCPU/4GB) | $XX.XX | $XX.XX | $XX.XX 100 GB Object Storage | $XX.XX | $XX.XX | $XX.XX Managed SQL DB (small) | $XX.XX | $XX.XX | $XX.XX 100 GB Data Transfer | $XX.XX | $XX.XX | $XX.XX TOTAL MONTHLY | $XX.XX | $XX.XX | $XX.XX TOTAL ANNUAL | $XXX.XX | $XXX.XX | $XXX.XX Notes: - All figures for equivalent resources (same CPU, RAM, storage) - AWS: on-demand pricing, us-east-1 region - Azure: pay-as-you-go, East US region - GCP: on-demand, us-central1 region - Does not include Reserved/Committed use discounts

PHASE 1 · STEP 2 Research and Compare Cloud SLAs (Service Level Agreements)

An SLA (Service Level Agreement) is a legal contract between a cloud provider and customer that guarantees a specific uptime percentage. If the provider fails to meet the SLA, they offer service credits (partial refunds). Understanding SLAs is critical — a 99.9% uptime SLA means up to 8.76 hours of downtime per year is "acceptable" and earns no credit.

Research SLAs for each provider. Open these pages and document the uptime guarantees:

AWS SLAs: https://aws.amazon.com/compute/sla/ Azure SLAs: https://azure.microsoft.com/en-us/support/legal/sla/ GCP SLAs: https://cloud.google.com/terms/sla

Uptime %	Max Downtime / Year	Max Downtime / Month	Meaning
99.9% ("Three Nines")	8.76 hours	43.8 minutes	Standard SLA — most basic cloud services
99.95% ("Three and a half")	4.38 hours	21.9 minutes	Premium SLA — multi-AZ deployments
99.99% ("Four Nines")	52.6 minutes	4.38 minutes	High availability — multi-region deployments
99.999% ("Five Nines")	5.26 minutes	26 seconds	Carrier-grade — banking & telecommunications

These numbers have enormous business implications. For an e-commerce site that does ₹100 crore/year in revenue, one hour of downtime costs approximately ₹11,415 in lost revenue (₹100 crore ÷ 8760 hours). Achieving Five Nines typically requires: multiple availability zones in multiple regions, active-active database replication with automatic failover, global load balancing, and a runbook for every possible failure scenario. The cost of achieving Five Nines is usually much higher than the cost of the occasional outage — cloud engineers must help management make this cost-benefit decision.

Document the SLA comparison in your strategy document:

SLA COMPARISON — CORE COMPUTE SERVICES Service | AWS EC2 (Multi-AZ) | Azure VM (Zone) | GCP Compute -----------------|--------------------|-----------------|------------------ Compute SLA | 99.99% | 99.99% | 99.99% Object Storage | 99.99% | 99.99% (RA-GRS) | 99.999999999% SQL Database | 99.95% (Multi-AZ) | 99.99% | 99.95% DNS | 100% (Route 53) | N/A | 100% (Cloud DNS) Credit at breach | 10-30% credit | 10-25% credit | 10-50% credit Note: SLAs only apply to production deployments meeting minimum requirements (e.g., Multi-AZ deployment for 99.99% EC2 SLA)

PHASE 2 · STEP 1 Design the Multi-Cloud Architecture for ABC Retail

A multi-cloud strategy deliberately spreads workloads across providers to prevent vendor lock-in, optimize costs for each workload type, and achieve higher availability. However, multi-cloud adds complexity — you must manage two or more cloud environments, billing systems, IAM systems, and networking setups. This trade-off must be carefully considered.

Create a "Cloud Workload Distribution" decision table. For each ABC Retail workload, document which cloud is best suited and why:

ABC RETAIL — CLOUD WORKLOAD ASSIGNMENT Workload | Provider | Service | Reason ------------------------|----------|-----------------|------------------------- Web Application Servers | AWS | EC2 Auto-Scaling| Best auto-scaling features Product Image CDN | AWS | CloudFront+S3 | 400+ edge locations globally User Auth / SSO | Azure | Azure AD B2C | Best enterprise identity mgmt Database Backups | Azure | Blob Storage (RA-GRS) | Geo-redundant, cheaper DR Sales Analytics | GCP | BigQuery | Best price/performance for SQL ML Recommendations | GCP | Vertex AI | Best ML infrastructure CI/CD Pipelines | Azure | Azure DevOps | Best developer tooling Kubernetes Cluster | GCP | GKE | Best managed K8s experience DNS Management | AWS | Route 53 | 100% SLA, best health checks Monitoring (primary) | GCP | Cloud Monitor | Best dashboard visualization

This distribution is not random — each assignment reflects genuine provider strengths. AWS has the largest global CDN (CloudFront with 400+ points of presence). Azure Active Directory is the most widely adopted enterprise identity solution — if ABC Retail's corporate employees already use Azure AD, integration is seamless. GCP's BigQuery can process petabytes of data at a fraction of the cost of alternatives — and Vertex AI is Google's ML platform with pre-trained retail-specific models. Making decisions based on service strength, not just brand loyalty, is the mark of a skilled cloud architect.

Address vendor lock-in risks — identify which services are "portable" and which are "locked":

VENDOR LOCK-IN RISK ASSESSMENT HIGH RISK (Proprietary services — hard to migrate): - AWS Lambda (logic written as Lambda functions doesn't run on Azure) - Azure Cosmos DB (proprietary API, though compatible layers exist) - GCP Spanner (unique architecture, no equivalent on other clouds) - DynamoDB (proprietary data model) MEDIUM RISK (Standards-based but effort to migrate): - RDS MySQL → Azure SQL MySQL → Cloud SQL MySQL (data migration needed) - EC2 instances → Azure VMs (OS config, scripts work; tooling changes) - CloudFront → Azure CDN (config format differs, same HTTP standards) LOW RISK (Portable — run anywhere): - Docker containers (same image runs on any cloud) - Kubernetes workloads (same YAML on EKS, AKS, GKE, on-premise) - Terraform IaC (same language, different provider plugins) - MariaDB/MySQL data (standard SQL dump/restore) LOCK-IN MITIGATION STRATEGIES: 1. Use open standards: Docker, Kubernetes, Terraform, standard SQL 2. Avoid proprietary managed services where portable alternatives exist 3. Abstract provider-specific code behind interface layers 4. Regularly test migration procedures ("could we move this in 30 days?")

Design the inter-cloud connectivity — how do the three clouds communicate securely:

INTER-CLOUD CONNECTIVITY DESIGN Option 1: VPN Tunnels (Used in this design) - AWS VPC ←→ Azure VNet: Site-to-Site VPN (~$50/month) - Azure VNet ←→ GCP VPC: Site-to-Site VPN (~$50/month) - All inter-cloud traffic encrypted (IPSec) - Latency: ~10-20ms between major regions - Use case: Low-volume control plane traffic (auth tokens, config sync) Option 2: Direct Connect / ExpressRoute / Cloud Interconnect - Dedicated private fiber connection (not over public internet) - Cost: $200-500/month depending on bandwidth - Latency: 1-5ms - Use case: High-volume data transfer between clouds (DB replication) - Only justified at 1TB+/month inter-cloud traffic volume Decision: Use VPN tunnels initially (cost-effective for our traffic volume) Upgrade to dedicated interconnect when traffic exceeds 500GB/month

PHASE 2 · STEP 2 Build the Cloud Governance Framework Document

Cloud Governance ensures that cloud resources are provisioned, managed, and retired according to company policies and regulatory requirements. Without governance, cloud sprawl occurs — unused resources accumulate, costs spiral, and security risks multiply. This document is the foundation of responsible cloud operations.

Create the Cloud Governance Framework document. Use a word processor (Microsoft Word, Google Docs, or LibreOffice Writer) and include all these sections:

CLOUD GOVERNANCE FRAMEWORK — ABC RETAIL PVT. LTD. Document Version: 1.0 Effective Date: [Current Date] Owner: Cloud Center of Excellence (CCoE) ═══════════════════════════════════════════════ SECTION 1: CLOUD STRATEGY STATEMENT "ABC Retail adopts a multi-cloud strategy prioritizing AWS for core application hosting, Azure for enterprise identity and DevOps tooling, and GCP for analytics and machine learning workloads. All cloud deployments must be automated via IaC, subject to cost optimization reviews, and compliant with applicable data protection regulations." SECTION 2: APPROVED CLOUD PROVIDERS Tier 1 (Production workloads): AWS, Azure, GCP Tier 2 (Approved tools/SaaS): GitHub, HashiCorp Vault, Datadog Prohibited: Personal cloud accounts, unauthorized shadow IT SECTION 3: TAGGING AND NAMING STANDARDS All cloud resources MUST have these tags: - Project: "abc-retail" (always) - Environment: dev | staging | prod - Owner: team-name@abc-retail.com - Cost-Center: CC-[department-code] - Created-By: [IAM username] - Auto-Shutdown: true|false (for dev resources) Naming convention: {project}-{service}-{environment}-{region} Example: abc-retail-webserver-prod-ap-south-1 SECTION 4: COST MANAGEMENT POLICIES - Monthly cloud budget: ₹X lakhs (set actual budget) - Require approval for resources costing >₹50,000/month - All dev/test resources must have auto-shutdown schedules - Reserved Instances required for resources running >6 months - Monthly cost review meeting with CCoE and Finance team - Alert at 80% of monthly budget threshold SECTION 5: SECURITY BASELINE - MFA required for ALL cloud console access (no exceptions) - No credentials in code repositories (enforced by git pre-commit hooks) - All production databases must be encrypted at rest - All inter-service communication must use TLS 1.2+ - Security Group changes require peer review approval - Penetration testing quarterly SECTION 6: COMPLIANCE REQUIREMENTS - DPDPA (Digital Personal Data Protection Act - India) → Customer PII must be stored in India region (ap-south-1 or Central India) → Data retention: 3 years maximum for customer data - PCI-DSS Level 3 (payment card data) → No credit card numbers stored — use payment gateway tokenization - GDPR (if EU customers are served) → Right to erasure must be technically implementable SECTION 7: RESOURCE LIFECYCLE MANAGEMENT - Dev environments: Auto-delete after 72 hours of no activity - Staging: Tear down on Fridays, recreate on Mondays (cost saving) - Production: Protected from deletion, requires change management ticket - Deprecated resources: 30-day notice → migration → decommission SECTION 8: INCIDENT RESPONSE IN CLOUD - P1 (complete outage): Response within 15 minutes, all-hands - P2 (degraded service): Response within 1 hour - P3 (non-critical): Response within 4 hours - All incidents → post-mortem document within 5 business days

A Cloud Governance Framework is a living document maintained by a Cloud Center of Excellence (CCoE) — a cross-functional team of cloud architects, security engineers, finance, and compliance. Without governance: engineers spin up expensive GPU instances and forget them, developers store credentials in public GitHub repos, teams use 10 different cloud accounts with no visibility into total spend, and regulatory violations go undetected. Large companies have been fined millions for GDPR violations that could have been prevented by proper cloud governance. The tagging standards section is particularly important — without proper tags, it's impossible to generate cost reports by department, project, or environment.

PHASE 3 · STEP 1 Cloud Cost Optimization Analysis

Cloud cost optimization is one of the highest-value activities a cloud engineer can perform. Companies routinely overpay for cloud by 20–40% due to idle resources, wrong instance types, and missing commitments. Your cost optimization analysis document demonstrates commercial awareness — a skill that distinguishes senior engineers from junior ones.

Create a Cost Optimization Opportunities table for ABC Retail:

COST OPTIMIZATION OPPORTUNITIES Strategy | Savings | How to Implement | Priority ----------------------|---------|----------------------------------|---------- Reserved Instances | 40-72% | Commit 1-3 years for stable VMs | HIGH Spot/Preemptible VMs | 70-90% | Use for batch jobs, non-critical | HIGH Right-sizing | 15-30% | Analyze CPU/RAM utilization | HIGH Auto-scaling | 20-40% | Scale down during low-traffic hrs | HIGH S3 Lifecycle Policies | 20-50% | Move old data to cheaper tiers | MEDIUM Scheduling (dev env) | 60-70% | Auto-stop dev servers overnight | MEDIUM CDN caching | 30-50% | Reduce origin requests via cache | MEDIUM Data Transfer costs | 20-40% | Keep data in same AZ as compute | MEDIUM Nat Gateway → PrivLink| 15-25% | Reduce outbound data cost | LOW Budget Alerts | N/A | Prevent surprise bills | HIGH PROJECTED ANNUAL SAVINGS FOR ABC RETAIL: Baseline monthly estimate (on-demand, no optimization): ₹X lakhs After 1-year Reserved Instances: -40% = ₹X lakhs saved After right-sizing (right instances for workload): -20% = ₹X lakhs saved After dev environment scheduling: -5% = ₹X lakhs saved TOTAL PROJECTED SAVINGS: ₹XX lakhs/year

The most impactful optimization is Reserved Instances or Committed Use contracts — committing to use a specific resource for 1-3 years in exchange for up to 72% discount. This is analogous to signing a long-term office lease vs. month-to-month — the commitment gets you a better rate. Right-sizing is the second most impactful: analyzing actual CPU and memory utilization reports often reveals that developers provisioned 4× more compute than the application actually uses. FinOps (Cloud Financial Operations) is a growing discipline dedicated to exactly these optimizations — large companies employ dedicated FinOps teams.

3. Cloud Provider Selection Decision Framework

4. Deliverables Summary

📄 Files to Submit

Cloud Provider Comparison Matrix (completed table)
Pricing Comparison Table (your actual researched figures)
SLA Comparison Document
Multi-Cloud Architecture Design Document (with the diagram)
Vendor Lock-In Risk Assessment table
Cloud Governance Framework (complete document)
Cost Optimization Analysis and Savings Estimate
Screenshots from AWS, Azure, and GCP pricing calculators

✅ Verification Checklist

All 16 service categories mapped across 3 providers
Pricing calculator visited for all 3 providers
Actual monthly cost figures documented (not estimated)
SLA percentages researched from official SLA pages
Workload distribution table completed with rationale
Lock-in risk assessment completed (High/Medium/Low)
Governance Framework has all 8 required sections
Cost optimization table has at least 8 strategies
Documents are professionally formatted and complete
Indian data residency requirements (DPDPA) addressed

5. Why We Did This & What It Accomplishes

Strategic Intent & Operational Impact

Why We Did This

Cloud architecture is not just about technical configuration — it's about making informed business decisions about where to run workloads, how much to pay, and what risks to accept. The pricing comparison and SLA research skills you practiced here are used by cloud architects every day.
Vendor lock-in is one of the most debated topics in cloud strategy. Companies like Netflix deliberately built their own cross-cloud abstraction layers (Chaos Monkey, Hystrix) to avoid being held hostage by any single provider. Your lock-in analysis demonstrates this strategic thinking.
Cloud Governance is a growing discipline — companies like Gartner estimate that 70% of enterprise cloud failures are due to governance problems (costs spiraling, security misconfigurations, compliance violations) rather than technical failures. This framework addresses the governance gap.

What This Accomplishes

ABC Retail now has a documented multi-cloud strategy that can be presented to management, used to train new engineers, and referenced during procurement decisions. This is the kind of strategic document that cloud architects create at the beginning of cloud journeys.
Your governance framework becomes the policy layer for Projects 8–11 — every IaC deployment (Project 8) must comply with the naming and tagging standards you defined here. Every Kubernetes deployment (Project 9) must meet the security baseline defined here.
The skills demonstrated in this project — provider comparison, pricing analysis, SLA interpretation, and governance framework design — are specifically tested in cloud architect certifications: AWS Solutions Architect Professional, Azure Solutions Architect Expert, and Google Cloud Professional Cloud Architect.