Guide Cloud Architect

A senior multi-cloud architect with expertise in designing scalable, secure, and cost-effective cloud solutions across AWS, Azure, and Google Cloud Platform, helping you make informed decisions on cloud strategy, migration, and architecture.

When to Use This Agent

Choose Guide Cloud Architect when:

• Designing cloud architectures that may span multiple providers
• Making cloud provider selection decisions (AWS vs. Azure vs. GCP)
• Planning cloud migration strategies (on-premises to cloud)
• Designing hybrid or multi-cloud architectures
• Evaluating cloud-native vs. cloud-agnostic architectural approaches

Consider alternatives when:

• Working exclusively with one cloud provider (use the provider-specific agent)
• Implementing specific cloud services (use a service-specific agent)
• Managing cloud costs exclusively (use a FinOps agent)

Quick Start

Copy
# .claude/agents/guide-cloud-architect.yml
name: Guide Cloud Architect
description: Multi-cloud architecture design and strategy
model: claude-sonnet
tools:
  - Read
  - Write
  - Glob
  - Grep
  - WebSearch

Example invocation:

claude "Design a cloud architecture for a global video streaming platform that serves 10 million users across 5 regions, with CDN, transcoding, and real-time analytics"

Core Concepts

Cloud Provider Service Comparison

Category	AWS	Azure	GCP
Compute	EC2, Lambda, ECS	VMs, Functions, Container Apps	Compute Engine, Cloud Run
Kubernetes	EKS	AKS	GKE
SQL Database	RDS, Aurora	Azure SQL, CosmosDB (SQL)	Cloud SQL, AlloyDB
NoSQL	DynamoDB	CosmosDB	Firestore, Bigtable
Object Storage	S3	Blob Storage	Cloud Storage
CDN	CloudFront	Front Door	Cloud CDN
Messaging	SQS, SNS	Service Bus	Pub/Sub
AI/ML	SageMaker, Bedrock	Azure AI, OpenAI Service	Vertex AI
Data Warehouse	Redshift	Synapse	BigQuery

Architecture Decision Matrix

Copy
## Cloud Selection: Video Streaming Platform

### Decision Criteria
| Factor | Weight | AWS | Azure | GCP |
|--------|--------|-----|-------|-----|
| CDN Coverage | 25% | 9/10 (CloudFront) | 8/10 (Front Door) | 7/10 (Cloud CDN) |
| Media Services | 20% | 8/10 (MediaConvert) | 9/10 (Media Services) | 6/10 (Transcoder) |
| Analytics | 20% | 7/10 (Redshift) | 7/10 (Synapse) | 9/10 (BigQuery) |
| Cost | 20% | 7/10 | 7/10 | 8/10 |
| Team Experience | 15% | 9/10 | 5/10 | 6/10 |
| **Weighted Score** | | **8.0** | **7.3** | **7.2** |

### Recommendation: AWS
Primary driver: strongest CDN, team expertise, broadest service selection.
Consider GCP for analytics layer (BigQuery) if cross-cloud complexity is acceptable.

Migration Strategy Patterns

Pattern	Description	Risk	Effort	Best For
Rehost (Lift & Shift)	Move as-is to cloud VMs	Low	Low	Quick migration
Replatform	Minor optimization for cloud	Low	Medium	Database migrations
Refactor	Redesign for cloud-native	Medium	High	Long-term optimization
Rebuild	Rewrite on cloud-native services	High	Very High	Legacy modernization
Replace	Adopt SaaS alternative	Low	Low	Commodity workloads

Configuration

Parameter	Description	Default
primary_cloud	Primary cloud provider (aws, azure, gcp, multi)	Based on analysis
multi_cloud_strategy	Multi-cloud approach (avoid, selective, full)	selective
migration_approach	Default migration pattern	replatform
cost_optimization	Cost priority (lowest, balanced, performance)	balanced
compliance	Regulatory requirements	None
team_skills	Team's existing cloud skills	Survey-based

Best Practices

1. Choose one primary cloud provider and use others selectively. Multi-cloud for the sake of avoiding vendor lock-in creates more complexity than it prevents. Pick the provider that best matches your primary workload, team skills, and business relationships. Use a second provider only for specific strengths (BigQuery for analytics, CloudFront for CDN) that justify the added operational complexity.

2. Design for cloud-native patterns, not just cloud-hosted. Moving VMs from a data center to EC2 instances gains little. Design for managed services (serverless, PaaS, managed databases) that eliminate infrastructure management. A "cloud-native" architecture uses auto-scaling, event-driven processing, managed databases, and infrastructure-as-code. These patterns deliver the cost and agility benefits that motivated the cloud move.

3. Implement infrastructure as code from the first deployment. Never create cloud resources manually through the console. Every resource should be defined in Terraform, Bicep, CDK, or Pulumi. IaC provides repeatability (identical environments), auditability (changes tracked in git), and disaster recovery (rebuild from code). Manual console changes are undocumented, unrepeatable, and impossible to review.

4. Design security as a cross-cutting concern, not an afterthought. Every architecture decision has security implications. Network design determines blast radius. Identity design determines access control. Data design determines encryption requirements. Evaluate security at each architectural decision point, not as a review after the architecture is complete. Security retrofitting is expensive and often incomplete.

5. Plan for cost visibility from the architecture phase. Tag every resource with cost-allocation tags (team, environment, project). Design resource boundaries that align with cost centers. Choose pricing models (reserved, spot, on-demand) based on workload patterns. Set budget alerts before deploying, not after the first surprising bill. Cloud cost management is an architectural concern, not an operations afterthought.

Common Issues

Cloud costs escalate unexpectedly after initial deployment. The biggest cost surprises come from data transfer charges (cross-region, cross-AZ, internet egress), oversized instances left running in non-production environments, and storage accumulation without lifecycle policies. Implement cost monitoring dashboards visible to engineering teams (not just finance), set alerts at 80% of budget, and review costs weekly during the first quarter of any new deployment.

Multi-cloud strategy creates operational complexity that exceeds the lock-in risk it mitigates. Maintaining expertise, tooling, and processes across two or three cloud providers doubles or triples operational overhead. The team needs to know AWS IAM and Azure AD and GCP IAM. Each provider's networking, monitoring, and deployment tooling is different. Only adopt multi-cloud when there is a concrete business requirement (data residency, specific service capability) — not as an abstract risk mitigation strategy.

Cloud migration timeline extends far beyond initial estimates. Migrations that were estimated at 6 months often take 18 months because teams underestimate: data migration complexity, application dependencies discovered during migration, performance tuning needed after migration, and organizational change management. Plan migrations in phases, deliver value incrementally, and build in buffer time. A phased migration that delivers benefits at each phase is better than a big-bang migration that delivers nothing until completion.