Part 2: Multi-Cloud Transition Strategy¶
Why Multi-Cloud?¶
Current State: GCP-only for Vertex AI / WxCC analytics
Future State: AWS + Azure + GCP with unified network fabric
Business Drivers:
| Cloud Provider | Primary Workloads | Abhavtech Use Case |
|---|---|---|
| AWS | Enterprise applications, data lakes | S3 data lake, EC2 app servers, RDS databases |
| Azure | Microsoft ecosystem, AD integration | Azure AD, Office 365 ExpressRoute, Azure DevOps |
| GCP | AI/ML, contact center analytics | Vertex AI, WxCC analytics, BigQuery |
Typical Multi-Cloud Triggers: - M&A: Acquire company using different cloud provider - Best-of-breed: Use AWS for infrastructure, GCP for AI, Azure for productivity - Vendor diversification: Reduce lock-in, negotiate better pricing - Data residency: Different clouds have different regional presence
Multi-Cloud Network Architecture¶
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ ABHAVTECH MULTI-CLOUD INTERCONNECT ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ON-PREMISE HUB SITES │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ SD-WAN FABRIC (Cisco vManage 20.15.x) │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ Mumbai Hub │ │ London Hub │ │ NJ Hub │ │ │
│ │ │ C8500-12X │ │ C8500-12X │ │ C8500-12X │ │ │
│ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │
│ │ │ │ │ │ │
│ └─────────┼──────────────────┼──────────────────┼────────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ ┌─────────▼──────────┐ ┌───▼──────────┐ ┌───▼──────────┐ │
│ │ GCP CLOUD │ │ AWS CLOUD │ │ AZURE CLOUD │ │
│ │ (Vertex AI/WxCC) │ │ (Apps/Data) │ │ (M365/AD) │ │
│ ├────────────────────┤ ├──────────────┤ ├──────────────┤ │
│ │ │ │ │ │ │ │
│ │ asia-south1 │ │ ap-south-1 │ │ Central IN │ │
│ │ • Dedicated 10G │ │ • Direct │ │ • ExpressRt │ │
│ │ Interconnect │ │ Connect │ │ 10G │ │
│ │ • VLAN 3001 │ │ 10G │ │ • VLAN 3003 │ │
│ │ │ │ • VLAN 3002 │ │ │ │
│ │ VPC: │ │ │ │ VNet: │ │
│ │ 10.200.0.0/16 │ │ VPC: │ │ 10.202.0.0/16│ │
│ │ │ │ 10.201.0.0/16│ │ │ │
│ └────────────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ └─────────────────────┼─────────────────┘ │
│ │ │
│ ┌─────────────▼──────────────┐ │
│ │ INTER-CLOUD PEERING │ │
│ │ (Optional for cloud-to- │ │
│ │ cloud data transfer) │ │
│ │ │ │
│ │ • GCP ↔ AWS: VPC Peering │ │
│ │ • GCP ↔ Azure: VNet Peer │ │
│ │ • AWS ↔ Azure: TGW Peer │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────┘
Multi-Cloud Connectivity Options¶
Option 1: Hub-and-Spoke (Recommended for Phase 1)¶
Architecture: - On-premise is the hub - All clouds connect to on-premise - Cloud-to-cloud traffic routes through on-premise
Pros: - Centralized control (SD-WAN policies) - Lower cost (no inter-cloud peering charges) - Unified security (FTD inspection at on-prem)
Cons: - Higher latency for cloud-to-cloud (extra hop) - On-prem becomes single point of failure
Use When: - Cloud-to-cloud traffic is <20% of total - Security requirement: all traffic must be inspected on-prem - Cost-sensitive (inter-cloud bandwidth is expensive)
SD-WAN Configuration:
# vManage Cloud OnRamp Policy
cloud_onramp_config:
gcp:
type: colocation
region: asia-south1
bgp_asn: 16550
preferred_transport: cloud-interconnect
backup_transport: dia
aws:
type: colocation
region: ap-south-1
bgp_asn: 64512
preferred_transport: direct-connect
backup_transport: dia
azure:
type: colocation
region: central-india
bgp_asn: 12076
preferred_transport: expressroute
backup_transport: dia
## Route all cloud-to-cloud through on-prem
inter_cloud_routing:
gcp_to_aws: via_on_prem
gcp_to_azure: via_on_prem
aws_to_azure: via_on_prem
Option 2: Mesh (Direct Cloud-to-Cloud)¶
Architecture: - Each cloud connects to on-premise AND to each other cloud - Cloud-to-cloud traffic routes directly
Pros: - Low latency for cloud-to-cloud (direct path) - No on-prem bottleneck
Cons: - Higher cost (inter-cloud bandwidth expensive) - Complex routing (9 connections for 3 clouds + on-prem) - Harder to inspect traffic (need cloud-native firewalls)
Use When: - Cloud-to-cloud traffic is >50% of total - Latency-sensitive workloads (e.g., GCP Vertex AI → AWS S3 data lake) - Multiple regions per cloud (need direct mesh)
Inter-Cloud Peering:
| Source | Destination | Method |
|---|---|---|
| GCP → AWS | Data transfer | VPC Peering (via Internet) |
| GCP → Azure | Data transfer | VNet Peering |
| AWS → Azure | Data transfer | TGW Peering |
Option 3: Hybrid (Recommended for Phase 2)¶
Architecture: - On-premise is primary hub - Direct cloud-to-cloud for latency-sensitive workloads only
Example: - GCP Vertex AI needs AWS S3 data lake → Direct GCP-AWS peering - Azure AD needs GCP resources → Route through on-prem (not latency-sensitive)
Pros: - Balance of cost and performance - Flexible routing policies
Cons: - More complex configuration - Need to classify workloads (latency-sensitive vs cost-sensitive)
Multi-Cloud SD-WAN Integration¶
Cisco SD-WAN Cloud OnRamp Configuration:
! Mumbai Hub C8500-12X Configuration
! VRF for GCP traffic
vrf definition VRF-GCP
rd 65000:1
address-family ipv4
route-target export 65000:1
route-target import 65000:1
exit-address-family
!
! VRF for AWS traffic
vrf definition VRF-AWS
rd 65000:2
address-family ipv4
route-target export 65000:2
route-target import 65000:2
exit-address-family
!
! VRF for Azure traffic
vrf definition VRF-AZURE
rd 65000:3
address-family ipv4
route-target export 65000:3
route-target import 65000:3
exit-address-family
!
! GCP Cloud Interconnect interface
interface TenGigabitEthernet0/0/1.3001
description GCP-Cloud-Interconnect-VLAN3001
encapsulation dot1Q 3001
vrf forwarding VRF-GCP
ip address 169.254.100.2 255.255.255.252
no shut
!
! AWS Direct Connect interface
interface TenGigabitEthernet0/0/1.3002
description AWS-Direct-Connect-VLAN3002
encapsulation dot1Q 3002
vrf forwarding VRF-AWS
ip address 169.254.101.2 255.255.255.252
no shut
!
! Azure ExpressRoute interface
interface TenGigabitEthernet0/0/1.3003
description Azure-ExpressRoute-VLAN3003
encapsulation dot1Q 3003
vrf forwarding VRF-AZURE
ip address 169.254.102.2 255.255.255.252
no shut
!
! BGP for multi-cloud routing
router bgp 65000
!
address-family ipv4 vrf VRF-GCP
neighbor 169.254.100.1 remote-as 16550
neighbor 169.254.100.1 activate
network 10.0.0.0 mask 255.0.0.0 ! Advertise on-prem networks
exit-address-family
!
address-family ipv4 vrf VRF-AWS
neighbor 169.254.101.1 remote-as 64512
neighbor 169.254.101.1 activate
network 10.0.0.0 mask 255.0.0.0
exit-address-family
!
address-family ipv4 vrf VRF-AZURE
neighbor 169.254.102.1 remote-as 12076
neighbor 169.254.102.1 activate
network 10.0.0.0 mask 255.0.0.0
exit-address-family
!
! SD-WAN Application-Aware Routing for multi-cloud
! Route GCP Vertex AI traffic to GCP VRF
ip access-list extended ACL-GCP-VERTEX-AI
permit ip any 10.200.0.0 0.0.255.255
!
! Route AWS S3 traffic to AWS VRF
ip access-list extended ACL-AWS-S3
permit ip any 10.201.0.0 0.0.255.255
!
! Route Azure AD traffic to Azure VRF
ip access-list extended ACL-AZURE-AD
permit ip any 10.202.0.0 0.0.255.255
!
! Policy-based routing
route-map RM-MULTI-CLOUD permit 10
match ip address ACL-GCP-VERTEX-AI
set vrf VRF-GCP
!
route-map RM-MULTI-CLOUD permit 20
match ip address ACL-AWS-S3
set vrf VRF-AWS
!
route-map RM-MULTI-CLOUD permit 30
match ip address ACL-AZURE-AD
set vrf VRF-AZURE
!
Multi-Cloud Observability¶
Extend Existing Platforms:
| Platform | Current (GCP-Only) | Multi-Cloud Extension |
|---|---|---|
| Splunk | GCP logs via Cloud Logging | + AWS CloudWatch Logs (Kinesis Firehose) + Azure Monitor Logs (Event Hub) |
| ThousandEyes | GCP asia-south1 tests | + AWS ap-south-1 tests + Azure Central India tests + Inter-cloud latency tests |
| AppDynamics | GCP Vertex AI monitoring | + AWS EC2 app monitoring + Azure App Services monitoring |
Unified Dashboard:
┌─────────────────────────────────────────────────────────────────┐
│ MULTI-CLOUD UNIFIED OPERATIONS DASHBOARD │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ GCP HEALTH │ │ AWS HEALTH │ │ AZURE HEALTH │ │
│ │ │ │ │ │ │ │
│ │ Vertex AI: │ │ EC2: │ │ AD Sync: │ │
│ │ ✅ Healthy │ │ ✅ Healthy │ │ ✅ Healthy │ │
│ │ │ │ │ │ │ │
│ │ BigQuery: │ │ S3: │ │ ExpressRt: │ │
│ │ ✅ Healthy │ │ ✅ Healthy │ │ ✅ Healthy │ │
│ │ │ │ │ │ │ │
│ │ Latency: │ │ Latency: │ │ Latency: │ │
│ │ 12ms │ │ 18ms │ │ 10ms │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ INTER-CLOUD CONNECTIVITY │ │
│ │ │ │
│ │ GCP ↔ AWS: 15ms latency ✅ Healthy │ │
│ │ GCP ↔ Azure: 12ms latency ✅ Healthy │ │
│ │ AWS ↔ Azure: 20ms latency ✅ Healthy │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ COST SUMMARY (MTD) │ │
│ │ │ │
│ │ GCP: $18,500 ▲ 5% vs last month │ │
│ │ AWS: $12,300 ▼ 3% vs last month │ │
│ │ Azure: $8,900 ➡ Flat │ │
│ │ TOTAL: $39,700 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Multi-Cloud Security¶
Unified Security Policies:
| Control | GCP | AWS | Azure | Enforcement |
|---|---|---|---|---|
| Encryption at Rest | CMEK | AWS KMS | Customer-Managed Keys | Required |
| Encryption in Transit | TLS 1.3 | TLS 1.3 | TLS 1.3 | Required |
| IAM Least Privilege | Service Accounts | IAM Roles | Managed Identities | Required |
| Network Segmentation | VPC | VPC | VNet | Separate VRFs per cloud |
| DLP | Cloud DLP | Macie | Purview | PII redaction |
| SIEM Integration | Splunk HEC | Splunk HEC | Splunk HEC | All logs to Splunk |