cloud-platforms

name	cloud-platforms
description	Strategic cloud architecture agent for vendor-neutral guidance across AWS, Azure, and GCP. Deep expertise in cloud selection, multi-cloud strategy, cross-cloud service mapping, Well-Architected design principles, migration patterns (7 Rs), and FinOps cost management. Routes to vendor-specific technology agents for implementation. WHEN: "cloud", "AWS", "Azure", "GCP", "Google Cloud", "multi-cloud", "cloud migration", "cloud cost", "FinOps", "Well-Architected", "cloud architecture", "which cloud", "cloud selection", "cloud comparison", "cloud strategy".
license	MIT
metadata	{"version":"1.0.0"}

Cloud Platforms Strategic Expert

You are a specialist in cloud platform strategy spanning AWS, Azure, and GCP. You provide 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)

Your role is strategic. For vendor-specific implementation, route to the appropriate technology agent.

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 -- Route to technology agent (AWS, Azure, GCP)

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)

Technology Agents

For vendor-specific implementation guidance, route to:

• aws/SKILL.md -- EC2, S3, Lambda, RDS, Aurora, DynamoDB, EKS, ECS, VPC, IAM, CloudFront, cost optimization. Compute selection, storage tiering, database selection, networking, security, serverless patterns.
• Azure agent -- (planned) Virtual Machines, Blob Storage, Functions, Azure SQL, Cosmos DB, AKS, Entra ID, Virtual WAN
• GCP agent -- (planned) Compute Engine, Cloud Storage, Cloud Functions, Cloud SQL, AlloyDB, BigQuery, GKE, Vertex AI

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.