Multi-Cloud Architecture - Technical Validation¶
Project: ABV-SECOPS-AI-2025 | Date: January 2025
Purpose: Technical architecture review and corrections
Validation Results¶
Section 1: GCP Vertex AI Integration¶
VALIDATED: Internet-Based Connectivity¶
Design Decision: Use internet connectivity instead of dedicated Cloud Interconnect.
Technical Rationale:
| Factor | Analysis | Validation |
|---|---|---|
| WxCC to GCP transfer | Cloud-to-cloud on Cisco/Google backbone (not public internet) | ✅ Architecturally correct |
| Data volume | ~6GB/day (CDR + recordings) | ✅ Internet bandwidth sufficient |
| Security | VPC Service Controls + TLS 1.3 | ✅ Meets security requirements |
| Latency requirements | Batch/near-real-time analytics (not <10ms critical) | ✅ Internet latency acceptable |
Traffic Flow:
WxCC Cloud (Cisco) → Google Cloud Platform
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Path: Cisco backbone → Google backbone
Latency: <5ms (cloud-to-cloud within same region)
Security: Service Account authentication + TLS 1.3
Inspection: None required (trusted cloud providers)
CORRECTED: Private Service Connect Applicability¶
Original Design: Included Private Service Connect for private API access.
Technical Issue: Private Service Connect provides RFC 1918 private IPs for GCP APIs, but requires: - GCP VPC with subnet allocation - Either Cloud VPN or Cloud Interconnect to reach those private IPs from on-premise
Current Connectivity Model: Internet-based (no VPN/Interconnect)
Correction:
SCENARIO 1: Admin accessing GCP Console
─────────────────────────────────────────
Admin → SD-WAN → Umbrella SASE → console.cloud.google.com (public IP)
Private Service Connect: NOT APPLICABLE ❌
SCENARIO 2: WxCC → GCP Vertex AI
─────────────────────────────────────────
WxCC Cloud → aiplatform.googleapis.com (public IP, but via Google backbone)
Private Service Connect: NOT APPLICABLE ❌
SCENARIO 3: Future GCP VMs accessing Vertex AI
───────────────────────────────────────────────
GCP VM (10.200.1.10) → aiplatform.p.googleapis.com (private IP 10.200.100.10)
Private Service Connect: APPLICABLE ✅
Recommendation: Remove Private Service Connect from initial implementation. Add only if deploying GCP Compute Engine VMs in future phases.
VALIDATED: VPC Service Controls¶
Design: Security perimeter around GCP resources using VPC Service Controls.
Technical Verification:
| Question | Answer | Status |
|---|---|---|
| Works with internet-based access? | YES - controls WHO accesses, not HOW they connect | ✅ |
| Prevents data exfiltration? | YES - egress rules block unauthorized destinations | ✅ |
| Compatible with CCAI Platform? | YES - CCAI APIs are VPC-SC compatible | ✅ |
Architecture:
┌────────────────────────────────────────────────────────────────────┐
│ VPC SERVICE CONTROLS PERIMETER │
├────────────────────────────────────────────────────────────────────┤
│ │
│ PROTECTED SERVICES (Inside Perimeter): │
│ • Vertex AI (aiplatform.googleapis.com) │
│ • BigQuery (bigquery.googleapis.com) │
│ • Cloud Storage (storage.googleapis.com) │
│ • Cloud DLP (dlp.googleapis.com) │
│ │
│ INGRESS POLICY: │
│ ✅ Allow from: WxCC Cloud IP ranges (52.0.0.0/8) │
│ ✅ Allow from: On-premise NAT IPs (specific /32 addresses) │
│ ❌ Block: All other internet sources │
│ │
│ EGRESS POLICY: │
│ ✅ Allow to: WxCC Webhook (webhook.wxcc-us1.cisco.com) │
│ ✅ Allow to: On-premise Splunk (specific IP via Cloud VPN) │
│ ❌ Block: All other destinations │
│ │
└────────────────────────────────────────────────────────────────────┘
Configuration (Terraform):
resource "google_access_context_manager_service_perimeter" "wxcc_perimeter" {
parent = "accessPolicies/${var.access_policy_id}"
name = "accessPolicies/${var.access_policy_id}/servicePerimeters/wxcc_data"
title = "WxCC Sensitive Data Perimeter"
status {
restricted_services = [
"bigquery.googleapis.com",
"storage.googleapis.com",
"aiplatform.googleapis.com",
"speech.googleapis.com",
"language.googleapis.com",
"dlp.googleapis.com"
]
resources = ["projects/${var.project_number}"]
ingress_policies {
ingress_from {
sources {
access_level = google_access_context_manager_access_level.trusted_sources.id
}
}
ingress_to {
resources = ["*"]
operations {
service_name = "*"
method_selectors {
method = "*"
}
}
}
}
egress_policies {
egress_from {
identities = ["serviceAccount:vertex-ai-sa@project.iam.gserviceaccount.com"]
}
egress_to {
resources = ["projects/${var.splunk_project_number}"]
operations {
service_name = "storage.googleapis.com"
method_selectors {
method = "google.storage.objects.get"
}
}
}
}
}
}
resource "google_access_context_manager_access_level" "trusted_sources" {
parent = "accessPolicies/${var.access_policy_id}"
name = "accessPolicies/${var.access_policy_id}/accessLevels/trusted_sources"
title = "Trusted Source IPs"
basic {
conditions {
ip_subnetworks = [
"52.0.0.0/8", # WxCC Cloud ranges
"203.0.113.50/32", # Mumbai office NAT IP
"203.0.113.100/32", # London office NAT IP
"203.0.113.75/32" # NJ office NAT IP
]
}
}
}
VALIDATED: Cloud Data Loss Prevention (DLP)¶
Design: Automatic PII detection and redaction in call transcripts.
Technical Implementation:
┌────────────────────────────────────────────────────────────────────┐
│ DLP REDACTION PIPELINE │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ① Call Recording → Vertex AI Speech-to-Text │
│ Output: "My credit card is 4111-1111-1111-1111 and SSN is │
│ 123-45-6789" │
│ │
│ ② Cloud DLP API Inspection │
│ Detects: CREDIT_CARD_NUMBER, US_SOCIAL_SECURITY_NUMBER │
│ │
│ ③ De-identification │
│ Output: "My credit card is [CREDIT_CARD_NUMBER] and SSN is │
│ [US_SOCIAL_SECURITY_NUMBER]" │
│ │
│ ④ Store in BigQuery │
│ Table: wxcc_analytics.call_transcripts │
│ Column: transcript_redacted (searchable, no PII) │
│ │
│ ⑤ Original Audio Stored Separately │
│ Bucket: gs://wxcc-recordings-pii-restricted/ │
│ Access: Restricted to specific service accounts only │
│ Encryption: CMEK with 90-day key rotation │
│ │
└────────────────────────────────────────────────────────────────────┘
DLP Configuration:
from google.cloud import dlp_v2
def redact_pii(text):
dlp = dlp_v2.DlpServiceClient()
project_id = "abhavtech-wxcc-prod"
inspect_config = {
"info_types": [
{"name": "PERSON_NAME"},
{"name": "CREDIT_CARD_NUMBER"},
{"name": "US_SOCIAL_SECURITY_NUMBER"},
{"name": "PHONE_NUMBER"},
{"name": "EMAIL_ADDRESS"},
{"name": "STREET_ADDRESS"},
{"name": "DATE_OF_BIRTH"}
],
"min_likelihood": "POSSIBLE",
"limits": {"max_findings_per_request": 0}
}
deidentify_config = {
"info_type_transformations": {
"transformations": [{
"primitive_transformation": {
"replace_with_info_type_config": {}
}
}]
}
}
response = dlp.deidentify_content(
request={
"parent": f"projects/{project_id}",
"deidentify_config": deidentify_config,
"inspect_config": inspect_config,
"item": {"value": text}
}
)
return response.item.value
VALIDATED: Contact Center AI (CCAI) Platform¶
Design: Use purpose-built CCAI instead of generic Vertex AI components.
Architecture Comparison:
| Component | Generic Vertex AI | CCAI Platform | Recommendation |
|---|---|---|---|
| Speech-to-Text | Vertex AI Speech API | CCAI Speech (same engine, optimized for telephony) | CCAI ✅ |
| Sentiment Analysis | Vertex AI NLU API | CCAI Insights (pre-trained for contact center) | CCAI ✅ |
| Agent Assist | Build custom | Native real-time suggestions | CCAI ✅ |
| Analytics Dashboard | Build in Looker | Pre-built CCAI Insights UI | CCAI ✅ |
| WxCC Integration | Custom API integration | Native connectors | CCAI ✅ |
CCAI Architecture:
┌────────────────────────────────────────────────────────────────────┐
│ CCAI PLATFORM COMPONENTS │
├────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ CCAI INSIGHTS │ │
│ │ ──────────────────────────────────────────────────────────── │ │
│ │ • Automatic call transcription (telephony-optimized) │ │
│ │ • Sentiment analysis (positive/negative/neutral) │ │
│ │ • Entity extraction (product names, issue types) │ │
│ │ • Topic clustering (automatic categorization) │ │
│ │ • Pre-built dashboard (call volume, CSAT correlation) │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ AGENT ASSIST │ │
│ │ ──────────────────────────────────────────────────────────── │ │
│ │ • Real-time transcription during live calls │ │
│ │ • Knowledge base search (suggest KB articles to agent) │ │
│ │ • Smart reply (suggest responses based on conversation) │ │
│ │ • Intent detection (understand customer request) │ │
│ │ • Display: Agent desktop pop-up with suggestions │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ DIALOGFLOW CX │ │
│ │ ──────────────────────────────────────────────────────────── │ │
│ │ • IVR natural language understanding │ │
│ │ • Multi-turn conversation flow (context awareness) │ │
│ │ • Intent training (custom for Abhavtech use cases) │ │
│ │ • Entity recognition (account numbers, product codes) │ │
│ │ • Fulfillment webhooks (backend integration) │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────┘
Section 2: Azure Integration¶
VALIDATED: ExpressRoute for Office 365¶
Design: Dedicated ExpressRoute circuits for Microsoft peering (Office 365).
Technical Architecture:
┌────────────────────────────────────────────────────────────────────────┐
│ AZURE EXPRESSROUTE - TECHNICAL ARCHITECTURE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ HUB SITES (3 Locations) │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Mumbai C8500-12X London C8500-12X NJ C8500-12X │ │
│ │ ┌────────────────┐ ┌────────────────┐ ┌──────────┐ │ │
│ │ │ BGP AS: 65000 │ │ BGP AS: 65001 │ │ AS: 65002│ │ │
│ │ │ VLAN: 4001 │ │ VLAN: 4002 │ │ VL: 4003 │ │ │
│ │ └────────┬───────┘ └────────┬───────┘ └────┬─────┘ │ │
│ │ │ │ │ │ │
│ └───────────┼─────────────────────────┼────────────────────┼───────┘ │
│ │ │ │ │
│ │ 10 Gbps │ 10 Gbps │ 10 Gbps │
│ │ Tata Comm │ BT │ AT&T │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ MICROSOFT EXPRESSROUTE CIRCUITS │ │
│ │ ────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ Circuit 1: Mumbai Circuit 2: London Circuit 3: NJ │ │
│ │ • 10 Gbps • 10 Gbps • 10 Gbps │ │
│ │ • Premium SKU • Premium SKU • Premium SKU │ │
│ │ • BGP ASN: 12076 • BGP ASN: 12076 • ASN: 12076 │ │
│ │ • Primary: 169.254.200.0/30 │ │
│ │ • Secondary: 169.254.200.4/30 (redundant) │ │
│ │ │ │
│ │ PEERING TYPES: │ │
│ │ ✅ Microsoft Peering (Office 365, Azure AD, Dynamics 365) │ │
│ │ ✅ Private Peering (Azure VNets - if needed) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ MICROSOFT CLOUD (OFFICE 365) │ │
│ │ ────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ • Exchange Online (Email): 52.96.0.0/14 │ │
│ │ • Teams (Calling/Meetings): 52.112.0.0/14 │ │
│ │ • SharePoint Online: 52.108.0.0/14 │ │
│ │ • OneDrive: 52.104.0.0/14 │ │
│ │ • Azure AD (Authentication): 40.126.0.0/18 │ │
│ │ │ │
│ │ BGP ROUTING: │ │
│ │ • Microsoft advertises: ~600 Office 365 prefixes │ │
│ │ • Abhavtech advertises: 10.252.0.0/16 (on-premise network) │ │
│ │ • Route preference: ExpressRoute > Internet (BGP local pref) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
BGP Configuration (SD-WAN Edge):
! Mumbai C8500-12X ExpressRoute Configuration
! ExpressRoute interface (Microsoft Peering - Primary)
interface TenGigabitEthernet0/0/2.4001
description AZURE-EXPRESSROUTE-MSFT-PEERING-PRIMARY
encapsulation dot1Q 4001
ip address 169.254.200.2 255.255.255.252
no shut
!
! ExpressRoute interface (Microsoft Peering - Secondary for redundancy)
interface TenGigabitEthernet0/0/3.4001
description AZURE-EXPRESSROUTE-MSFT-PEERING-SECONDARY
encapsulation dot1Q 4001
ip address 169.254.200.6 255.255.255.252
no shut
!
! BGP Configuration
router bgp 65000
bgp log-neighbor-changes
bgp router-id 10.252.1.1
!
! Microsoft ExpressRoute peer (Primary)
neighbor 169.254.200.1 remote-as 12076
neighbor 169.254.200.1 description MSFT-EXPRESSROUTE-PRIMARY
neighbor 169.254.200.1 ebgp-multihop 2
neighbor 169.254.200.1 update-source TenGigabitEthernet0/0/2.4001
!
! Microsoft ExpressRoute peer (Secondary)
neighbor 169.254.200.5 remote-as 12076
neighbor 169.254.200.5 description MSFT-EXPRESSROUTE-SECONDARY
neighbor 169.254.200.5 ebgp-multihop 2
neighbor 169.254.200.5 update-source TenGigabitEthernet0/0/3.4001
!
address-family ipv4
! Advertise on-premise network to Microsoft
network 10.252.0.0 mask 255.255.0.0
!
! Activate Microsoft peers
neighbor 169.254.200.1 activate
neighbor 169.254.200.5 activate
!
! Accept only Office 365 prefixes from Microsoft
neighbor 169.254.200.1 route-map MSFT-IN in
neighbor 169.254.200.1 route-map MSFT-OUT out
neighbor 169.254.200.5 route-map MSFT-IN in
neighbor 169.254.200.5 route-map MSFT-OUT out
!
! Prefer primary circuit (higher local-preference)
neighbor 169.254.200.1 route-map SET-LOCAL-PREF-200 in
neighbor 169.254.200.5 route-map SET-LOCAL-PREF-100 in
exit-address-family
!
! Route-map: Accept only Office 365 prefixes
ip prefix-list OFFICE365-PREFIXES seq 10 permit 52.96.0.0/14 le 32
ip prefix-list OFFICE365-PREFIXES seq 20 permit 52.104.0.0/14 le 32
ip prefix-list OFFICE365-PREFIXES seq 30 permit 52.108.0.0/14 le 32
ip prefix-list OFFICE365-PREFIXES seq 40 permit 52.112.0.0/14 le 32
ip prefix-list OFFICE365-PREFIXES seq 50 permit 40.96.0.0/12 le 32
ip prefix-list OFFICE365-PREFIXES seq 60 permit 40.126.0.0/18 le 32
!
route-map MSFT-IN permit 10
match ip address prefix-list OFFICE365-PREFIXES
!
route-map MSFT-IN deny 999
!
! Route-map: Advertise only corporate network
ip prefix-list TO-MICROSOFT seq 10 permit 10.252.0.0/16
!
route-map MSFT-OUT permit 10
match ip address prefix-list TO-MICROSOFT
!
route-map MSFT-OUT deny 999
!
! Route-map: Set local preference for primary path preference
route-map SET-LOCAL-PREF-200 permit 10
set local-preference 200
!
route-map SET-LOCAL-PREF-100 permit 10
set local-preference 100
!
Traffic Flow Validation:
Before ExpressRoute (via Internet):
────────────────────────────────────────
User → SD-WAN → Umbrella DIA → Internet → Office 365
Latency: 80-120ms
Packet Loss: 0.5-2%
Jitter: 15-30ms
Path: Multiple ISP hops, unpredictable
After ExpressRoute (Dedicated):
────────────────────────────────────────
User → SD-WAN → ExpressRoute → Microsoft Backbone → Office 365
Latency: 5-10ms ✅
Packet Loss: <0.1% ✅
Jitter: <5ms ✅
Path: Direct to Microsoft, predictable ✅
VALIDATED: Azure Virtual WAN¶
Design: Cloud-based SD-WAN hub for branch connectivity to Azure VNets.
Architecture:
┌────────────────────────────────────────────────────────────────────────┐
│ AZURE VIRTUAL WAN - TECHNICAL ARCHITECTURE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ BRANCH SITES (IPsec over Internet) │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Branch 1 Branch 2 Branch 3 │ │
│ │ (Bangalore) (Delhi) (Hyderabad) │ │
│ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ ISR 4331 │ │ ISR 4331 │ │ ISR 1100 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ BGP: 65010 │ │ BGP: 65011 │ │ BGP: 65012 │ │ │
│ │ │ LAN: │ │ LAN: │ │ LAN: │ │ │
│ │ │ 192.168.50 │ │ 192.168.51 │ │ 192.168.52 │ │ │
│ │ │ .0/24 │ │ .0/24 │ │ .0/24 │ │ │
│ │ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │ │
│ │ │ │ │ │ │
│ └────────┼───────────────────┼──────────────────┼──────────────────┘ │
│ │ IPsec │ IPsec │ IPsec │
│ │ IKEv2 │ IKEv2 │ IKEv2 │
│ │ AES-256 │ AES-256 │ AES-256 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ AZURE VIRTUAL WAN HUB (Central India - Mumbai) │ │
│ │ ────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ Hub Configuration: │ │
│ │ • Address Space: 10.200.0.0/23 (Azure auto-assigned) │ │
│ │ • VPN Gateway SKU: VpnGw3 │ │
│ │ • Gateway Capacity: 1.25 Gbps per tunnel │ │
│ │ • Max Tunnels: 10 (total aggregate: 12.5 Gbps) │ │
│ │ • BGP ASN: 65515 (Azure auto-assigned) │ │
│ │ • BGP Peer: 10.200.0.254 (gateway IP) │ │
│ │ │ │
│ │ Connected VNets (via VNet peering): │ │
│ │ ┌───────────────────────────────────────────────────────────┐ │ │
│ │ │ abhavtech-azure-prod (10.100.0.0/16) │ │ │
│ │ │ • Subnet: application-servers (10.100.2.0/24) │ │ │
│ │ │ • Subnet: databases (10.100.3.0/24) │ │ │
│ │ │ • Subnet: private-endpoints (10.100.10.0/24) │ │ │
│ │ │ │ │ │
│ │ │ Resources: │ │ │
│ │ │ • Azure SQL: abhavtech-sql.database.windows.net │ │ │
│ │ │ Private IP: 10.100.10.10 │ │ │
│ │ │ • Azure Storage: abhavtechstorage.blob.core.windows.net │ │ │
│ │ │ Private IP: 10.100.10.20 │ │ │
│ │ └───────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ┌───────────────────────────────────────────────────────────┐ │ │
│ │ │ abhavtech-azure-shared (10.101.0.0/16) │ │ │
│ │ │ • Subnet: management (10.101.1.0/24) │ │ │
│ │ │ • Subnet: azure-firewall (10.101.2.0/26) │ │ │
│ │ │ │ │ │
│ │ │ Resources: │ │ │
│ │ │ • Azure Firewall: 10.101.2.4 (central inspection) │ │ │
│ │ │ • Azure Bastion: 10.101.1.10 (jump host) │ │ │
│ │ └───────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ROUTING TABLE: │ │
│ │ ┌───────────────────────────────────────────────────────────┐ │ │
│ │ │ Destination │ Next Hop │ Source │ │ │
│ │ │───────────────────────────────────────────────────────── │ │ │
│ │ │ 192.168.50.0/24 │ Branch 1 VPN │ BGP (learned) │ │ │
│ │ │ 192.168.51.0/24 │ Branch 2 VPN │ BGP (learned) │ │ │
│ │ │ 192.168.52.0/24 │ Branch 3 VPN │ BGP (learned) │ │ │
│ │ │ 10.100.0.0/16 │ VNet Peering │ Auto (VNet) │ │ │
│ │ │ 10.101.0.0/16 │ VNet Peering │ Auto (VNet) │ │ │
│ │ └───────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
Branch VPN Configuration (ISR 4331 - Bangalore):
! Bangalore ISR 4331 - IPsec to Azure Virtual WAN
! IKEv2 Proposal
crypto ikev2 proposal AZURE-IKEV2-PROPOSAL
encryption aes-cbc-256
integrity sha384
group 14
!
! IKEv2 Policy
crypto ikev2 policy AZURE-IKEV2-POLICY
proposal AZURE-IKEV2-PROPOSAL
!
! IKEv2 Keyring
crypto ikev2 keyring AZURE-KEYRING
peer azure-vwan-mumbai
address 52.172.10.50
pre-shared-key <SECRET_PSK_FROM_AZURE_PORTAL>
!
! IKEv2 Profile
crypto ikev2 profile AZURE-IKEV2-PROFILE
match identity remote address 52.172.10.50
identity local address 203.0.113.50
authentication remote pre-share
authentication local pre-share
keyring local AZURE-KEYRING
!
! IPsec Transform Set
crypto ipsec transform-set AZURE-IPSEC-TS esp-aes 256 esp-sha384-hmac
mode tunnel
!
! IPsec Profile
crypto ipsec profile AZURE-IPSEC-PROFILE
set transform-set AZURE-IPSEC-TS
set ikev2-profile AZURE-IKEV2-PROFILE
!
! Tunnel Interface
interface Tunnel100
description IPsec-to-Azure-Virtual-WAN-Mumbai
ip address 10.200.1.10 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel mode ipsec ipv4
tunnel destination 52.172.10.50
tunnel protection ipsec profile AZURE-IPSEC-PROFILE
no shut
!
! BGP Configuration
router bgp 65010
bgp log-neighbor-changes
bgp router-id 192.168.50.1
!
! Azure Virtual WAN BGP peer
neighbor 10.200.0.254 remote-as 65515
neighbor 10.200.0.254 description AZURE-VWAN-HUB-MUMBAI
neighbor 10.200.0.254 ebgp-multihop 2
neighbor 10.200.0.254 update-source Tunnel100
!
address-family ipv4
! Advertise branch LAN to Azure
network 192.168.50.0 mask 255.255.255.0
!
! Activate Azure peer
neighbor 10.200.0.254 activate
exit-address-family
!
! Static route to reach BGP peer over tunnel
ip route 10.200.0.254 255.255.255.255 Tunnel100
VALIDATED: Azure Private Link¶
Design: Private endpoints for Azure PaaS services (no public IP exposure).
Architecture:
┌────────────────────────────────────────────────────────────────────────┐
│ AZURE PRIVATE LINK ARCHITECTURE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ AZURE VNET (abhavtech-azure-prod: 10.100.0.0/16) │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Subnet: private-endpoints (10.100.10.0/24) │ │
│ │ ┌────────────────────────────────────────────────────────────┐ │ │
│ │ │ │ │ │
│ │ │ Private Endpoint 1: pe-abhavtech-sql │ │ │
│ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Private IP: 10.100.10.10 │ │ │ │
│ │ │ │ Target Resource: abhavtech-sql (Azure SQL Database) │ │ │ │
│ │ │ │ FQDN: abhavtech-sql.database.windows.net │ │ │ │
│ │ │ │ Public IP: DISABLED ❌ │ │ │ │
│ │ │ │ Network Policy: Reject all internet access │ │ │ │
│ │ │ └──────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ Private Endpoint 2: pe-abhavtech-storage │ │ │
│ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Private IP: 10.100.10.20 (Blob) │ │ │ │
│ │ │ │ Private IP: 10.100.10.21 (File) │ │ │ │
│ │ │ │ Target: abhavtechstorage (Storage Account) │ │ │ │
│ │ │ │ FQDN: abhavtechstorage.blob.core.windows.net │ │ │ │
│ │ │ │ Public IP: DISABLED ❌ │ │ │ │
│ │ │ └──────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ │ Private Endpoint 3: pe-abhavtech-keyvault │ │ │
│ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │
│ │ │ │ Private IP: 10.100.10.30 │ │ │ │
│ │ │ │ Target: abhavtech-kv (Azure Key Vault) │ │ │ │
│ │ │ │ FQDN: abhavtech-kv.vault.azure.net │ │ │ │
│ │ │ │ Public IP: DISABLED ❌ │ │ │ │
│ │ │ └──────────────────────────────────────────────────────┘ │ │ │
│ │ │ │ │ │
│ │ └────────────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ PRIVATE DNS ZONES (Azure-managed) │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ privatelink.database.windows.net: │ │
│ │ • abhavtech-sql.database.windows.net → 10.100.10.10 │ │
│ │ │ │
│ │ privatelink.blob.core.windows.net: │ │
│ │ • abhavtechstorage.blob.core.windows.net → 10.100.10.20 │ │
│ │ │ │
│ │ privatelink.file.core.windows.net: │ │
│ │ • abhavtechstorage.file.core.windows.net → 10.100.10.21 │ │
│ │ │ │
│ │ privatelink.vaultcore.azure.net: │ │
│ │ • abhavtech-kv.vault.azure.net → 10.100.10.30 │ │
│ │ │ │
│ │ (DNS zones linked to VNet, auto-updated) │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ON-PREMISE DNS RESOLUTION │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Conditional Forwarding (Windows DNS / BIND): │ │
│ │ │ │
│ │ database.windows.net → Forward to 10.100.0.2 (Azure DNS) │ │
│ │ blob.core.windows.net → Forward to 10.100.0.2 │ │
│ │ file.core.windows.net → Forward to 10.100.0.2 │ │
│ │ vault.azure.net → Forward to 10.100.0.2 │ │
│ │ │ │
│ │ Example Query: │ │
│ │ User queries: abhavtech-sql.database.windows.net │ │
│ │ → On-prem DNS forwards to Azure DNS (10.100.0.2) │ │
│ │ → Azure DNS returns: 10.100.10.10 (private endpoint) │ │
│ │ → User connects via Virtual WAN IPsec tunnel │ │
│ │ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
Terraform Configuration:
## Azure SQL Private Endpoint
resource "azurerm_private_endpoint" "sql" {
name = "pe-abhavtech-sql"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
subnet_id = azurerm_subnet.private_endpoints.id
private_service_connection {
name = "psc-sql"
private_connection_resource_id = azurerm_mssql_server.sql.id
is_manual_connection = false
subresource_names = ["sqlServer"]
}
private_dns_zone_group {
name = "dns-group-sql"
private_dns_zone_ids = [azurerm_private_dns_zone.sql.id]
}
}
## Private DNS Zone for Azure SQL
resource "azurerm_private_dns_zone" "sql" {
name = "privatelink.database.windows.net"
resource_group_name = azurerm_resource_group.rg.name
}
## Link Private DNS Zone to VNet
resource "azurerm_private_dns_zone_virtual_network_link" "sql" {
name = "vnet-link-sql"
resource_group_name = azurerm_resource_group.rg.name
private_dns_zone_name = azurerm_private_dns_zone.sql.name
virtual_network_id = azurerm_virtual_network.prod.id
registration_enabled = false
}
## Disable Public Network Access on Azure SQL
resource "azurerm_mssql_server" "sql" {
name = "abhavtech-sql"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
version = "12.0"
administrator_login = "sqladmin"
administrator_login_password = var.sql_admin_password
public_network_access_enabled = false # Critical: Disable public access
}
Section 3: SD-WAN Integration¶
VALIDATED: Application-Aware Routing¶
Design: Intelligent traffic steering based on application type.
Policy Architecture:
┌────────────────────────────────────────────────────────────────────────┐
│ SD-WAN APPLICATION-AWARE ROUTING LOGIC │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ DECISION TREE: │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Incoming Packet from User │ │
│ └────────────────────────┬────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ CLASSIFICATION (Deep Packet Inspection + NBAR2) │ │
│ │ ─────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ • Destination IP/CIDR │ │
│ │ • Application signature (NBAR2 database) │ │
│ │ • DSCP marking (if present) │ │
│ │ • TCP/UDP port (fallback if no signature match) │ │
│ │ │ │
│ └────────────────────────┬────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ POLICY MATCHING (Sequential Evaluation) │ │
│ │ ─────────────────────────────────────────────────────────────── │ │
│ │ │ │
│ │ SEQ 10: Corporate Apps (10.252.0.0/16) │ │
│ │ ├─ Match: YES → Action: Route via MPLS → DONE ✅ │ │
│ │ └─ Match: NO → Continue to SEQ 20 │ │
│ │ │ │
│ │ SEQ 20: Office 365 (52.96.0.0/14, 52.104.0.0/14, etc.) │ │
│ │ ├─ Match: YES → Action: Route via ExpressRoute → DONE ✅ │ │
│ │ └─ Match: NO → Continue to SEQ 30 │ │
│ │ │ │
│ │ SEQ 30: Azure VNet (10.100.0.0/16, 10.101.0.0/16) │ │
│ │ ├─ Match: YES → Action: Route via Virtual WAN IPsec → DONE ✅ │ │
│ │ └─ Match: NO → Continue to SEQ 40 │ │
│ │ │ │
│ │ SEQ 40: GCP APIs (*.googleapis.com, *.google.com) │ │
│ │ ├─ Match: YES → Action: Route via Umbrella DIA → DONE ✅ │ │
│ │ └─ Match: NO → Continue to SEQ 50 │ │
│ │ │ │
│ │ SEQ 50: SaaS Apps (Salesforce, ServiceNow, Zoom, etc.) │ │
│ │ ├─ Match: YES → Action: Route via Umbrella DIA → DONE ✅ │ │
│ │ └─ Match: NO → Continue to SEQ 60 │ │
│ │ │ │
│ │ SEQ 60: Default (0.0.0.0/0 - All Internet) │ │
│ │ └─ Match: YES → Action: Route via Umbrella DIA → DONE ✅ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘
vManage Centralized Policy Configuration:
## vManage Centralized Policy (YAML Representation)
policy_name: "Abhavtech-Multi-Cloud-Routing-Policy"
policy_type: "Centralized-Control-Policy"
sequences:
## SEQUENCE 10: Corporate Applications
- sequence_id: 10
sequence_name: "Corporate-Apps-MPLS"
match:
destination_cidr:
- 10.252.0.0/16
applications:
- erp
- intranet
- file-servers
actions:
transport_type: mpls
sla_class: business-critical
preferred_color: mpls
backup_color: dia
loss_threshold: 1%
latency_threshold: 50ms
jitter_threshold: 10ms
## SEQUENCE 20: Office 365
- sequence_id: 20
sequence_name: "Office365-ExpressRoute"
match:
destination_cidr:
- 52.96.0.0/14
- 52.104.0.0/14
- 52.108.0.0/14
- 52.112.0.0/14
- 40.96.0.0/12
- 40.126.0.0/18
applications:
- office365-exchange
- office365-sharepoint
- office365-teams
- office365-onedrive
actions:
transport_type: expressroute
sla_class: real-time
preferred_color: azure-expressroute
backup_color: dia
qos_marking: EF # Expedited Forwarding for Teams voice
loss_threshold: 0.5%
latency_threshold: 15ms
jitter_threshold: 5ms
## SEQUENCE 30: Azure VNet Workloads
- sequence_id: 30
sequence_name: "Azure-VNet-Virtual-WAN"
match:
destination_cidr:
- 10.100.0.0/16 # abhavtech-azure-prod
- 10.101.0.0/16 # abhavtech-azure-shared
applications:
- azure-sql
- azure-storage
- azure-vm-rdp
actions:
transport_type: azure-virtual-wan
sla_class: business-critical
preferred_color: dia # IPsec over internet to Virtual WAN
backup_color: mpls
loss_threshold: 1%
latency_threshold: 30ms
jitter_threshold: 10ms
## SEQUENCE 40: GCP Vertex AI
- sequence_id: 40
sequence_name: "GCP-Umbrella-DIA"
match:
destination_fqdn_regex:
- ".*\\.googleapis\\.com"
- ".*\\.google\\.com"
applications:
- gcp-console
- vertex-ai-api
- google-workspace
actions:
transport_type: umbrella-dia
sla_class: business-critical
preferred_color: dia
security_inspection: umbrella-full
loss_threshold: 2%
latency_threshold: 100ms
## SEQUENCE 50: SaaS Applications
- sequence_id: 50
sequence_name: "SaaS-Umbrella-DIA"
match:
applications:
- salesforce
- workday
- servicenow
- zoom
- webex
saas_categories:
- collaboration
- crm
- hr
actions:
transport_type: umbrella-dia
sla_class: interactive
preferred_color: dia
security_inspection: umbrella-full
loss_threshold: 2%
latency_threshold: 100ms
## SEQUENCE 60: Default Internet
- sequence_id: 60
sequence_name: "Internet-Default-Umbrella"
match:
destination_cidr:
- 0.0.0.0/0
actions:
transport_type: umbrella-dia
sla_class: best-effort
preferred_color: dia
security_inspection: umbrella-full
Implementation Readiness¶
Prerequisites Checklist¶
NETWORK INFRASTRUCTURE:
□ SD-WAN deployed across all 19 sites
□ Umbrella SASE tunnels operational
□ MPLS circuits active (hub sites)
□ DIA circuits active (all sites)
□ BGP peering functional (SD-WAN to ISP)
SECURITY INFRASTRUCTURE:
□ ISE deployed (14 nodes)
□ 802.1X authentication enabled
□ SGT tagging operational
□ FTD firewalls deployed (18 units)
□ Duo MFA deployed
CLOUD PREREQUISITES:
□ GCP project created (abhavtech-wxcc-prod)
□ Azure subscription active
□ Azure AD tenant configured
□ WxCC deployed (175 agents operational)
□ Office 365 E5 licenses (3,200 users)
TECHNICAL RESOURCES:
□ Public IP addresses documented (NAT IPs)
□ BGP ASN assignments confirmed
□ DNS infrastructure functional
□ NTP synchronization configured
Next Steps: Implementation Guides¶
Ready to create step-by-step technical implementation guides:
Guide 1: GCP Vertex AI Implementation - Terraform infrastructure-as-code - VPC Service Controls configuration - Cloud DLP setup - CCAI Platform deployment - WxCC integration (webhooks, APIs) - BigQuery dataset schema - Python scripts for data pipeline
Guide 2: Azure ExpressRoute Implementation - Circuit provisioning with carriers - BGP peering configuration (SD-WAN) - Office 365 route filtering - Failover testing procedures - Performance validation
Guide 3: Azure Virtual WAN Implementation - Hub provisioning - IPsec tunnel configuration (branches) - BGP configuration - Private Link setup - Private DNS zones - Connectivity testing
Guide 4: SD-WAN Cloud OnRamp Configuration - vManage policy creation - Application-aware routing rules - SLA monitoring configuration - Failover policies - Testing and validation
VALIDATION COMPLETE ✅
Architecture is technically sound and ready for implementation. Shall I proceed with creating detailed implementation guides?
© 2025 Abhavtech - Technical Documentation