Overview

---
name: overview
description: "Strategic, vendor-neutral guidance across AWS, Azure, and GCP: cloud selection, multi-cloud strategy, cross-cloud service equivalence mapping, Well-Architected design principles, migration patterns (7 Rs), and FinOps cost management. Use when deciding which cloud to use, evaluating multi-cloud, mapping a service from one cloud to another, planning a cloud migration, or setting up cost governance -- \"cloud\", \"multi-cloud\", \"cloud migration\", \"FinOps\", \"Well-Architected\", \"which cloud\", \"cloud comparison\", \"cloud strategy\". Do NOT use for single-provider service selection -- use the `aws`, `azure`, or `gcp` skill. Do NOT use for CLI syntax (`cli-scripting`), Terraform/CloudFormation/Bicep authoring (`devops`), EKS/AKS/GKE ops (`containers`), database engine internals (`database`), VPC/VNet depth (`networking`), object storage depth (`storage`), or cloud IAM/CSPM depth (`security`)."
license: MIT
---

# Cloud Platforms Strategic Overview

This skill covers cloud platform strategy spanning AWS, Azure, and GCP: vendor-neutral guidance on:

- Cloud selection (which cloud for which workload)
- Multi-cloud strategy (when it makes sense, when it doesn't)
- Cross-cloud service equivalence mapping
- Well-Architected design principles (cross-cloud)
- Migration strategy (7 Rs framework, sequencing, tooling)
- FinOps practice (cost visibility, optimization, governance)

This is strategic guidance. For vendor-specific implementation, use the `aws`, `azure`, or `gcp` skill.

## How to Approach Tasks

When you receive a request:

1. **Classify** the request type:
   - **Cloud selection** -- Use the decision framework below
   - **Service mapping** -- Load `references/service-mapping.md`
   - **Architecture review** -- Load `references/well-architected.md`
   - **Migration planning** -- Load `references/migration.md`
   - **Cost management** -- Load `references/finops.md`
   - **Vendor-specific** -- Use the `aws`, `azure`, or `gcp` skill

2. **Understand context** -- Ask about existing investments, team skills, compliance requirements, and workload characteristics before recommending a cloud.

3. **Be honest about trade-offs** -- Every cloud can run every workload. The question is which makes a given workload easier, cheaper, or better supported.

4. **Include cost context** -- Never recommend architecture without addressing cost implications. Cloud decisions are business decisions.

## Cloud Selection Framework

### When to Choose Which Cloud

The right cloud is determined by workload requirements, organizational context, and strategic goals -- not marketing.

#### Amazon Web Services (AWS)

**Best for:** General-purpose workloads, broadest service catalog (200+ services), largest talent pool, most third-party integrations (ISVs support AWS first), serverless-first architectures (Lambda ecosystem most mature), IoT workloads, broadest geographic coverage (33+ regions).

**Strengths:** Service breadth, marketplace, documentation depth, community size, partner network, compliance frameworks (GovCloud, FedRAMP High).

**Watch out for:** Complex pricing, data egress costs, IAM policy language complexity, service naming inconsistency.

#### Microsoft Azure

**Best for:** Organizations with existing Microsoft investments (O365, Active Directory, SQL Server, .NET), hybrid cloud (Azure Arc, Azure Stack HCI -- strongest hybrid story), Windows Server workloads, Entra ID identity, SAP on cloud, government/regulated industries (sovereign clouds).

**Strengths:** Enterprise identity (Entra ID), hybrid cloud (Arc), Microsoft ecosystem integration, enterprise sales relationships, single vendor for productivity + cloud.

**Watch out for:** Service naming churn (frequent rebrands), portal UX complexity, networking model differences from AWS/GCP.

#### Google Cloud Platform (GCP)

**Best for:** Data-intensive/analytics workloads (BigQuery is best-in-class), Kubernetes-native architectures (GKE -- Google invented K8s), AI/ML workloads (Vertex AI, TPU access), cost-sensitive workloads (automatic Sustained Use Discounts, custom machine types), real-time data processing (Pub/Sub + Dataflow).

**Strengths:** Data analytics, Kubernetes, AI/ML, network performance (private global backbone), pricing simplicity, custom machine types.

**Watch out for:** Smaller service catalog, smaller partner ecosystem, history of product deprecation, smaller talent pool, fewer regions.

### Decision Factor Matrix

| Factor | Favors AWS | Favors Azure | Favors GCP |
|--------|-----------|-------------|-----------|
| Existing skills | AWS-certified staff | .NET/Windows/AD staff | K8s/data eng staff |
| Vendor relationships | AWS partner agreements | Microsoft EA/CSP | Google enterprise deal |
| Service-specific strength | Broadest catalog | Identity/hybrid | Data/AI/K8s |
| Talent availability | Largest pool | Large (.NET + cloud) | Smaller, specialized |
| Cost optimization | RIs + Savings Plans | RIs + Hybrid Benefit | SUDs + Custom VMs |
| Enterprise integration | Broad ISV support | O365/AD/SAP integration | Workspace/BigQuery |
| Compliance | Most certifications | Sovereign clouds, Gov | Strong EU data residency |

### Decision Process

1. **Inventory constraints** -- Regulatory, data residency, existing contracts, team skills
2. **Identify workload characteristics** -- Compute type, data volume, latency needs, burst patterns
3. **Map to platform strengths** -- Which cloud's native services best match the workload?
4. **Evaluate total cost** -- Not just compute, but egress, support, training, hiring
5. **Assess vendor lock-in risk** -- How portable does the architecture need to be?
6. **Proof of concept** -- Always validate assumptions with a real PoC before committing

### Quick Decision Tree

```
Heavy Microsoft ecosystem (AD, O365, .NET, SQL Server)?
  YES --> Azure
  NO --> Primary workload is data/analytics or AI/ML?
    YES --> GCP (BigQuery, Vertex AI)
    NO --> Kubernetes-native architecture?
      YES --> GCP (GKE) or AWS (EKS) -- both strong
      NO --> Need broadest service catalog + largest talent pool?
        YES --> AWS
        NO --> All are viable. PoC on 2, choose based on
              team preference, pricing, and support experience.
```

## Multi-Cloud Strategy

### Types of Multi-Cloud

| Type | Description | Complexity | Best For |
|------|-------------|-----------|----------|
| **Best-of-Breed** | Different workloads on the cloud that best serves them | Moderate | Most practical approach |
| **DR Multi-Cloud** | Primary on one cloud, DR on another | Moderate | Cloud-level DR |
| **Active Multi-Cloud** | Workloads running simultaneously on multiple clouds | Highest | Maximum resilience |
| **Lock-in Avoidance** | Abstraction layers for portability | High | Often counterproductive |

### Should You Go Multi-Cloud?

```
Regulatory/compliance requires multiple clouds?
  YES --> Multi-cloud (compliance-driven)
  NO --> Need cloud-level DR (not just region-level)?
    YES --> DR multi-cloud (passive second cloud)
    NO --> Specific workloads clearly better on different clouds?
      YES --> Best-of-breed multi-cloud
      NO --> M&A brought in a different cloud?
        YES --> Multi-cloud (consolidate over time)
        NO --> Single cloud. Invest in depth, not breadth.
```

**Valid reasons:** Compliance/data sovereignty requirements, cloud-level DR, genuinely different strengths for different workloads (BigQuery for analytics + AWS for everything else), M&A bringing in a different cloud, negotiation leverage.

**Invalid reasons:** "Just in case" (maintaining two platforms is rarely justified), "cloud-agnostic is always better" (abstraction layers sacrifice 40-60% of cloud-native capabilities), FOMO (using every cloud's best feature requires staffing three platform teams).

**Recommendation:** Use cloud-native services as default. Use abstraction layers only where portability is a validated requirement, not a theoretical one.

### Abstraction Layer Trade-offs

| Abstraction | Portable? | Trade-off |
|------------|-----------|-----------|
| Terraform/OpenTofu | IaC is portable | Cloud resources underneath are not -- you still write provider-specific code |
| Kubernetes | Compute is portable | Storage, networking, IAM, managed services are cloud-specific |
| Pulumi | Same as Terraform | Same trade-offs, different language |
| Cloud-native services | Not portable | Higher performance, lower cost, more features, less operational burden |

### Key Cross-Cloud Challenges

**Networking:** Site-to-site VPN between cloud VPCs (cheapest), dedicated interconnect partners (Megaport, Equinix Fabric), non-overlapping CIDR planning from day one. Transit architectures: hub VPC/VNet in each cloud connected via VPN or interconnect; spoke VPCs peer to hub. DNS: split-horizon or centralized with conditional forwarding.

**Identity:** Centralized IdP (Entra ID, Okta) federated to all clouds via SAML/OIDC. Use workload identity federation for service-to-service. Avoid long-lived keys stored across clouds. Cross-cloud calls: short-lived tokens via OIDC federation.

**Governance:** Centralized guardrails, distributed execution. Single CI/CD platform (GitHub Actions, GitLab CI) deploying to all clouds. Single observability platform (Datadog, Grafana Cloud) aggregating across clouds. Landing zone per cloud following cloud-native best practices. Consistent IaC tooling with shared modules per cloud.

### Multi-Cloud Governance Patterns

**Landing zone per cloud:**
- AWS: Control Tower + Organizations + SCPs
- Azure: Azure Landing Zones + Management Groups + Azure Policy
- GCP: Cloud Foundation Toolkit + Organization Policies + Shared VPC

**Shared services layer:**
- CI/CD: single platform deploying to all clouds
- Secret management: HashiCorp Vault for cross-cloud, or each cloud's native + sync
- Monitoring: single observability platform with skills/exporters in each cloud
- Service mesh: Istio or Consul for cross-cloud service discovery and mTLS

## Cross-Cloud Service Mapping (Condensed)

For complete tables, load `references/service-mapping.md`. Key equivalences:

| Category | AWS | Azure | GCP |
|----------|-----|-------|-----|
| VMs | EC2 | Virtual Machines | Compute Engine |
| Kubernetes | EKS | AKS | GKE |
| Serverless containers | Fargate | Container Apps | Cloud Run |
| Functions | Lambda | Functions | Cloud Functions |
| Object storage | S3 | Blob Storage | Cloud Storage |
| Managed RDBMS | RDS / Aurora | Azure SQL / Azure DB | Cloud SQL / AlloyDB |
| NoSQL key-value | DynamoDB | Cosmos DB | Bigtable |
| Data warehouse | Redshift | Synapse Analytics | BigQuery |
| CDN | CloudFront | Front Door | Cloud CDN |
| Identity | IAM | Entra ID + RBAC | IAM |
| Secrets | Secrets Manager | Key Vault | Secret Manager |
| IaC (native) | CloudFormation | Bicep | Config Connector |
| Monitoring | CloudWatch | Monitor + Log Analytics | Cloud Monitoring |
| ML Platform | SageMaker | Azure ML | Vertex AI |
| LLM Hosting | Bedrock | Azure OpenAI | Vertex AI Model Garden |

### Pricing Model Differences

| Mechanism | AWS | Azure | GCP |
|-----------|-----|-------|-----|
| Auto-discount | -- | -- | SUDs: up to 30% for VMs running 25%+ of month |
| Reserved (1yr / 3yr) | Up to 42% / 60% | Up to 40% / 60% | CUDs: up to 37% / 55% |
| Flexible commitment | Savings Plans | Savings Plans | CUDs |
| BYOL savings | -- | Hybrid Benefit (up to 85%) | -- |
| Custom machine types | -- | -- | Yes (pay for exact vCPU/RAM) |
| Spot/preemptible | Up to 90% (2-min warning) | Up to 90% (30-sec) | Up to 91% (30-sec) |
| Cross-AZ egress | $0.01/GB each direction | **Free** | **Free** |
| Internet egress (10 TB) | $0.09/GB | $0.087/GB | $0.085-0.12/GB |

**Key insight:** Azure and GCP do not charge for cross-AZ traffic within a region. AWS charges $0.01/GB each direction, which compounds for distributed architectures. GCP's automatic Sustained Use Discounts require no commitment -- they apply automatically.

## Well-Architected Principles (Cross-Cloud)

These principles apply regardless of which cloud you use. For per-cloud framework details, load `references/well-architected.md`.

| Pillar | Core Principle |
|--------|---------------|
| **Operational Excellence** | IaC everywhere, CI/CD pipelines, observability (metrics + logs + traces), deployment strategies (blue/green, canary) |
| **Security** | Zero trust, least privilege, encryption at rest and in transit, managed identities (no long-lived credentials), audit logging |
| **Reliability** | Multi-AZ minimum for production, health checks + auto-healing, chaos engineering, DR tiers (backup/restore to active-active) |
| **Performance** | Right-sizing, caching layers, async processing, auto-scaling, database read replicas, CDN for global audiences |
| **Cost Optimization** | Right-sizing (#1 impact), reserved capacity for steady-state, Spot for fault-tolerant, storage tiering, eliminate waste, tag everything |
| **Sustainability** | Fewer resources = less energy, serverless when appropriate, ARM instances (better perf/watt), data lifecycle management |

### Anti-Patterns to Avoid

- **Treating cloud like a data center** -- Lifting VMs without adopting elasticity or managed services
- **Over-engineering for scale** -- Building for 10M users when you have 10K
- **Ignoring data gravity** -- Data is expensive to move; place compute near data
- **Single AZ in production** -- One AZ failure takes down the application
- **No resource tagging** -- Makes cost allocation and automation impossible
- **Overly permissive IAM** -- `*:*` policies and shared credentials
- **Monolithic IaC** -- One Terraform state file for everything

## Migration Strategy Overview

Every application in a migration portfolio should be assigned one of the 7 Rs. For detailed framework, sequencing, and tooling, load `references/migration.md`.

| Strategy | Description | Effort | When |
|----------|-------------|--------|------|
| **Retire** | Decommission. No longer needed. | Low | 10-20% of portfolio |
| **Retain** | Keep in current environment for now. | None | Too complex/risky to move now |
| **Rehost** | Lift and shift to cloud VMs. | Low-Medium | Speed is priority |
| **Relocate** | VMware-to-VMware cloud migration. | Low | Large VMware estate |
| **Replatform** | Targeted optimizations (e.g., self-hosted DB to managed). | Medium | Quick wins available |
| **Refactor** | Redesign as cloud-native (microservices, serverless). | High | Strategic applications |
| **Repurchase** | Replace with SaaS (Exchange to O365, CRM to Salesforce). | Medium | SaaS meets requirements |

### Migration Sequencing

1. **Assess** -- Application inventory, classify by 7 Rs, map dependencies
2. **Mobilize** -- Landing zone, networking (VPN/Direct Connect), security baseline
3. **Migrate in waves** -- Start low-risk, build confidence, increase complexity
4. **Optimize post-migration** -- Right-size, auto-scale, adopt managed services

## FinOps Overview

FinOps brings financial accountability to cloud spend by bridging engineering, finance, and business teams.

**Three phases:** Inform (visibility + allocation via tagging), Optimize (right-sizing + reserved capacity + waste elimination), Operate (budgets + anomaly detection + continuous reviews).

**Key unit economics to track:** cost per transaction, cost per active user, cost per API call, cloud cost as % of revenue. Cloud cost as % of revenue should decrease over time.

For detailed FinOps guidance including tagging strategy, chargeback/showback models, unit economics, and commitment management, load `references/finops.md`.

### Cost Estimation Checklist

When estimating cloud costs for a new workload, account for:

- Compute (VMs, containers, functions -- including dev/staging)
- Storage (object, block, file -- including backups and snapshots)
- Database (instances, replicas, storage, IOPS, backups)
- Networking (load balancers, NAT gateways, VPN/interconnect, static IPs)
- Data transfer (egress to internet, cross-region, cross-AZ)
- Monitoring (metrics, logs, custom metrics, APM, traces)
- Security (WAF, DDoS, vulnerability scanning, KMS)
- Support plan (required tier for production SLA)
- Reserved capacity (subtract from on-demand estimates)
- Growth buffer (add 20-30% for unexpected growth)

## Sibling Skills

For vendor-specific implementation guidance, use:

- `aws` skill -- EC2, S3, Lambda, RDS, Aurora, DynamoDB, EKS, ECS, VPC, IAM, CloudFront, cost optimization. Compute selection, storage tiering, database selection, networking, security, serverless patterns.
- `azure` skill -- Virtual Machines, App Service, Functions, Blob Storage, Azure SQL, Cosmos DB, AKS, Entra ID, networking, cost optimization.
- `gcp` skill -- Compute Engine, Cloud Run, GKE, Cloud Storage, BigQuery, Cloud SQL, AlloyDB, Spanner, Vertex AI, networking, cost optimization.

## Reference Files

Load these when you need deep knowledge for a specific area:

- `references/service-mapping.md` -- Complete cross-cloud service equivalence tables across compute, storage, database, networking, security, serverless, AI/ML, data analytics, and DevOps. Read when comparing services across clouds.
- `references/well-architected.md` -- Cross-cloud design principles by pillar, per-cloud framework summaries (AWS 6 pillars, Azure 5 pillars, GCP 5 focus areas), tools, and recommended organizational structures. Read for architecture reviews.
- `references/migration.md` -- 7 Rs framework, migration sequencing, tools by cloud, data migration patterns (online vs offline), database migration, cross-cloud migration. Read for migration planning.
- `references/finops.md` -- FinOps phases, tagging strategy, chargeback vs showback, anomaly detection, commitment management, unit economics, cost optimization wins by category. Read for cost management questions.