GCP network design for a E-Commerce Application
Alright, let’s build this like a real production e-commerce network, not a toy diagram. I’ll go step-by-step, explain why each piece exists, and call out common e-commerce gotchas along the way. I’ll assume Google Cloud Platform (GCP), multi-tier app (web → API → data), and growth in mind.

1️⃣ Start with the high-level architecture (what we’re aiming for)
Before touching GCP consoles, you need a mental model:
Public edge: Users → Load Balancer → Web/App
Private core: APIs, databases, caches
Controlled egress: Outbound traffic locked down
Strong isolation: Prod ≠ staging ≠ dev
2️⃣ Project & environment strategy (don’t skip this)
Best practice for e-commerce:
├── ecommerce-prod
├── ecommerce-staging
└── ecommerce-dev
Why
Billing isolation
IAM blast-radius control
Easy teardown of non-prod
⚠️ Mistake to avoid: Multiple environments in one project → painful IAM & firewall rules later.
3️⃣ Design the VPC (your network backbone)
Create one custom VPC per environment.
Example VPC
Region: us-central1 (primary)
Subnet layout (regional, not zonal)
| Subnet | CIDR | Purpose |
|---|---|---|
| public-web | 10.10.0.0/24 | Web tier (behind LB) |
| private-app | 10.10.1.0/24 | APIs, backend services |
| private-data | 10.10.2.0/24 | Databases, caches |
| management | 10.10.3.0/28 | Bastion, ops |
Why this matters for e-commerce
Limits PCI scope
Easier firewall rules
Clear traffic flows for audits
4️⃣ Internet access: ingress & egress done right
Ingress (users → app)
Global HTTP(S) Load Balancer
Cloud Armor (WAF + DDoS)
Managed SSL certs
Flow:
Egress (app → internet)
Cloud NAT for private subnets
No public IPs on backend services
⚠️ E-commerce rule of thumb:
If it doesn’t need inbound traffic, it should NOT have a public IP.
5️⃣ Web & application tier
Web tier options
Cloud Run (best for modern e-commerce)
GKE (if you need heavy customization)
Compute Engine (legacy / special cases)
Typical setup
Cloud Run services in private-app subnet
Serverless NEG attached to Load Balancer
Auto-scaling for sales spikes
Why Cloud Run shines
Handles Black Friday spikes automatically
Pay-per-use
No node management
6️⃣ API & internal service communication
Use private, internal networking only.
Internal HTTPS load balancer
Service-to-service auth (IAM / IAP)
No east-west traffic over public internet
This keeps:
Checkout APIs
Inventory services
Payment orchestration
fully private.
7️⃣ Data layer (most sensitive part)
Typical e-commerce stack
Cloud SQL (orders, users)
Firestore / Bigtable (catalog, sessions)
Memorystore (Redis) (cart, cache)
Networking rules
Private IP only
Located in
private-datasubnetFirewall: only app subnet allowed
🔐 Bonus: Enables easier PCI & SOC2 compliance.
8️⃣ Firewall rules (zero trust mindset)
Sample rules
| Rule | Source | Target | Allow |
|---|---|---|---|
| web-ingress | LB ranges | web subnet | 443 |
| app-to-data | private-app | private-data | DB ports |
| deny-all | 0.0.0.0/0 | all | ❌ |
Tips
Use tags or service accounts, not IPs
Start restrictive, open only when needed
9️⃣ Hybrid & external integrations
For payment gateways, ERP, or on-prem systems:
Cloud VPN (fast start)
Cloud Interconnect (high volume)
Private Service Connect for SaaS
🔟 Observability & security (production-grade)
Must-haves:
VPC Flow Logs
Cloud Logging & Monitoring
Cloud Armor WAF rules
Security Command Center
E-commerce insight
Most attacks hit:
/checkout/login/cart
Tune WAF rules specifically for these paths.
🧠 Final traffic flow (end-to-end)
→ Global HTTPS LB + WAF
→ Web (Cloud Run)
→ Internal LB
→ API services
→ Cache / DB (Private IP)
→ Cloud NAT (if outbound needed)
Comments (0)
No comments yet.
