/hybrid-cloud-architect

name: hybrid-cloud-architect
type: reference
description: "Designs hybrid cloud architectures connecting on-premises infrastructure with public cloud services. Use when designing systems spanning on-prem and cloud, or when the user mentions hybrid cloud or multi-environment architecture."
effort: 4
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
user-invocable: true
when_to_use: "When designing complex multi-cloud or hybrid cloud solutions across AWS, Azure, GCP, and private clouds"

Hybrid Cloud Architect

Designs hybrid and multi-cloud architectures that bridge on-premises infrastructure (OpenStack, VMware, bare metal) with public cloud services (AWS, Azure, GCP).

When to Use

• Designing systems that span on-premises and cloud environments
• Planning workload placement across private and public clouds
• Migrating from on-prem to hybrid architecture
• User mentions hybrid cloud, multi-cloud, or cross-environment

When NOT to Use

• Single-cloud deployment (use cloud-architect instead)
• Pure infrastructure provisioning without architecture decisions (use devops-deploy)
• Application-level architecture without infrastructure concerns (use backend-architect)

Workflow

1. Assess Requirements

Gather constraints before designing:

| Dimension | Questions | |-----------|----------| | Compliance | Data sovereignty? Regulatory frameworks (HIPAA, PCI-DSS, GDPR)? | | Performance | Latency requirements? Data gravity? Real-time vs batch? | | Budget | TCO targets? Existing licenses? CapEx vs OpEx preference? | | Skills | Team expertise in cloud platforms? OpenStack experience? | | Timeline | Migration urgency? Phased approach acceptable? |

2. Classify Workloads

For each workload, determine placement:

| Criteria | On-Prem | Public Cloud | Edge | |----------|---------|-------------|------| | Data sovereignty | Yes | No unless region-locked | Yes | | Low latency (less than 10ms) | Yes | No unless co-located | Yes | | Elastic scaling | No | Yes | No | | Cost-sensitive steady-state | Yes | No | - | | Managed services needed | No | Yes | No |

3. Design Connectivity

Choose connectivity based on requirements:

Options:

• VPN: Low cost, lower bandwidth, good for non-critical traffic
• Dedicated (Direct Connect / ExpressRoute / Interconnect): High bandwidth, low latency, SLA-backed
• SD-WAN: Multi-site, dynamic path selection, cost optimization
• Service mesh: For cross-cloud microservices communication (Istio, Linkerd)

4. Design Security Architecture

Apply zero-trust across environments:

• Identity federation: AD/LDAP to cloud IAM (SAML/OIDC)
• Network segmentation: Micro-segmentation, security groups across clouds
• Encryption: In-transit (TLS) + at-rest, key management per environment
• Secret management: Centralized (Vault) or cloud-native (KMS/KeyVault)
• Compliance: Per-environment compliance controls, audit logging

5. Design Data Strategy

| Pattern | Use When | Tools | |---------|----------|-------| | Active-active replication | RPO=0, RTO less than 1min | Database-native replication, Kafka | | Active-passive | RPO less than 15min, RTO less than 1hr | Cross-cloud backup, DNS failover | | Data mesh | Domain ownership, distributed teams | Data catalogs, federated queries | | Edge preprocessing | IoT, real-time analytics | Edge compute to cloud aggregation |

6. Define Infrastructure as Code

Multi-cloud IaC strategy:

• Terraform/OpenTofu: Cross-cloud resource provisioning
• Ansible: Configuration management
• Pulumi/CDK: Complex orchestration logic
• OPA/Conftest: Policy as Code
• GitOps (ArgoCD/Flux): Multi-environment deployment

State management:

• Remote state with locking (S3+DynamoDB, Azure Storage, GCS)
• Separate state per environment, shared modules
• State migration plan for cross-cloud moves

7. Design Observability

Unified monitoring across environments:

• Metrics: Prometheus + Thanos / Grafana Mimir (cross-cloud)
• Logs: Centralized logging (ELK/Loki) with per-environment collectors
• Traces: Distributed tracing (Jaeger/Tempo) across service boundaries
• Alerting: Unified alerting with environment-aware routing
• Cost monitoring: Per-cloud cost dashboards, anomaly detection

8. Plan Disaster Recovery

| Tier | Strategy | RPO | RTO | Cost | |------|----------|-----|-----|------| | Tier 1 | Active-active multi-cloud | 0 | less than 1min | High | | Tier 2 | Active-passive cross-cloud | less than 15min | less than 1hr | Medium-High | | Tier 3 | Backup + manual failover | less than 24hr | less than 4hr | Medium | | Tier 4 | Backup only | less than 24hr | less than 24hr | Low |

DR automation:

• Automated failover triggers (health checks, circuit breakers)
• Runbook automation for failover procedures
• Regular DR testing schedule (quarterly minimum)

Output

Deliver:

• Architecture diagram: showing all environments, connectivity, data flow
• Workload placement matrix: workload to environment with justification
• Connectivity plan: network topology, bandwidth, latency requirements
• Security model: identity, network, data security per environment
• Cost estimate: TCO comparison, per-environment breakdown
• Migration plan: phased approach with rollback procedures (if applicable)

Platform-Specific Notes

OpenStack Integration

• Services: Nova (compute), Neutron (network), Cinder (block storage), Swift (object), Keystone (identity)
• Hybrid identity: Keystone federation with cloud IAM
• Networking: Provider networks, VLAN/VXLAN for multi-tenant isolation

AWS Hybrid

• Outposts: AWS hardware in on-prem data center
• EKS Anywhere: Kubernetes on-prem with EKS compatibility
• Direct Connect: Dedicated network connection

Azure Hybrid

• Azure Arc: Manage resources across environments from Azure
• Azure Stack: On-prem Azure services
• ExpressRoute: Dedicated private connection

GCP Hybrid

• Anthos: Multi-cloud Kubernetes management
• Distributed Cloud: GCP services on-prem
• Cloud Interconnect: Dedicated network conne