Setting Up Hybrid Cloud Deployment for Web Application
Hybrid Cloud is architecture where part of infrastructure runs in public cloud, part in own data center or private cloud. Not "cloud for looks," but conscious workload division by security, latency, cost, or regulatory constraints.
Typical Hybrid Cloud Motivations
Regulatory requirements. Personal data, financial transactions, medical records must stay on own servers. Web tier, CDN, analytics in cloud.
Latency-sensitive components. Trading systems, real-time signal processing, production systems require minimal latency to local devices. Edge computing + cloud control plane.
CapEx vs OpEx. Base load (predictable) on owned hardware (cheaper long-term). Peak load (burst) in cloud (don't pay for idle resources).
Gradual migration. Can't migrate everything at once — migrate by service. In transition — hybrid.
Network Connection: Hybrid Cloud Foundation
Without reliable fast channel between on-premise and cloud — not hybrid cloud, but two separate environments.
AWS Direct Connect: dedicated physical channel from 1 Gbps to 100 Gbps. Latency 1-5ms (depends on distance to PoP). Suitable for production traffic and data replication.
GCP Dedicated Interconnect / Azure ExpressRoute: equivalents for respective clouds.
AWS Site-to-Site VPN: IPSec over internet, up to 1.25 Gbps. Cheaper, faster to setup, less reliable. Suitable for dev/staging or backup to Direct Connect.
# Terraform: AWS Direct Connect Gateway
resource "aws_dx_gateway" "main" {
name = "hybrid-dx-gateway"
amazon_side_asn = "64512"
}
resource "aws_dx_gateway_association" "main" {
dx_gateway_id = aws_dx_gateway.main.id
associated_gateway_id = aws_vpn_gateway.main.id
}
Workload Division
Typical scheme for web app with data requirements:
On-premise:
- Database with personal data
- File storage of sensitive documents
- Internal microservices (HR, ERP)
Public Cloud (AWS/GCP/Azure):
- Web tier and API gateway
- CDN (CloudFront, Cloud CDN)
- Analytics and ML
- CI/CD and development tools
- Staging and development environments
Service Mesh for on-premise ↔ cloud Connection
Istio or Linkerd create unified service network over Kubernetes clusters in both environments. mTLS between services, service discovery, traffic routing.
Consul Connect: alternative, works on VMs, not just Kubernetes. Consul datacenter on-premise, federation with AWS via mesh gateway.
# Consul mesh gateway for on-premise
service {
name = "mesh-gateway"
kind = "mesh-gateway"
address = "10.0.1.50"
port = 443
proxy {
config {
envoy_gateway_bind_addresses {
default {
address = "0.0.0.0"
port = 443
}
}
}
}
}
Kubernetes in Hybrid Cloud
AWS EKS Anywhere / Azure Arc: run managed Kubernetes on own hardware with management from cloud control plane.
OpenShift: Red Hat OpenShift works same on any hardware and any cloud.
Rancher: open source management of multiple clusters (on-premise + cloud) from single UI.
Monitoring and Observability
Metrics, logs, and traces must aggregate in one place regardless where component runs.
Scheme:
- On-premise: Prometheus + Loki + Jaeger agent
- Cloud: Prometheus + Loki + Jaeger agent
- Central aggregation: Grafana Cloud or self-hosted Grafana in cloud, federated Prometheus
Hybrid Cloud Security
Zero Trust Network: each request authenticated regardless of network. BeyondCorp / Cloudflare Access.
Identity Federation: AWS IAM Roles Anywhere lets on-premise workloads get temporary AWS credentials via PKI, without long-lived keys.
Data encryption in transit: all data between on-premise and cloud via TLS 1.3 or IPSec.
Implementation Timeline
- Direct Connect / VPN setup — 1-4 weeks (Direct Connect requires physical connection)
- Network segmentation and firewall rules — 3-5 days
- Kubernetes federation (Rancher/Arc) — 3-7 days
- Service mesh + mTLS — 3-7 days
- Observability centralization — 2-4 days
- Testing + documentation — 3-5 days