Skip to content

Shopware Network Architecture

Overview

The Shopware platform uses 10.34.0.0/16 (primary) and 10.35.0.0/16 (DR). Each business unit receives a /20 (4,096 IPs) that is split into two /21 environments (Production and Staging), each deployed in a separate AWS account.

Components

Each Shopware deployment consists of three application tiers plus supporting services:

TierTechnologyComputeNotes
FrontendNext.jsECS / FargateSSR, static assets
Domain APIGraphQL (Apollo Federation)ECS or EKSMay run in EKS for pod scaling
BackendShopware 6ECSAdmin, cron workers, API
DataAurora MySQL, ElastiCache, RabbitMQManaged servicesIsolated subnet group

BU Allocation — 10.34.0.0/16

CIDR BlockBUProductionStaging
10.34.0.0/20SupplySync10.34.0.0/2110.34.8.0/21
10.34.16.0/20Baker10.34.16.0/2110.34.24.0/21
10.34.32.0/20Gemaire10.34.32.0/2110.34.40.0/21
10.34.48.0/20CENA10.34.48.0/2110.34.56.0/21
10.34.64.0/20ECMDI10.34.64.0/2110.34.72.0/21
10.34.80.0/20Peirce Phelps10.34.80.0/2110.34.88.0/21
10.34.96.0/20CELATAM10.34.96.0/2110.34.104.0/21
10.34.112.0/20Homans10.34.112.0/2110.34.120.0/21
10.34.128.0/20GreeComfort10.34.128.0/2110.34.136.0/21
10.34.192.0/20Shared Services10.34.192.0/2110.34.200.0/21

Per-Environment Layout (/21 = 2,048 IPs)

Each environment VPC uses the following subnet structure. Offsets are relative to the VPC base address.

Stable services (ingress, data, backend) occupy the bottom of the range. Services that may move off-VPC (Next.js to Cloudflare, Domain API to external EKS) sit at the top, contiguous with reserved space. If those tiers move off-VPC, their blocks merge cleanly with reserved for future use or EKS growth.

OffsetCIDRPurposeIPsNotes
+0.0/24base.0/24Public — Ingress256Webscale ADC, NAT GW, bastion
+1.0/24base+1.0/24Data Tier256RDS, ElastiCache, RabbitMQ
+2.0/23base+2.0/23Shopware Backend512ECS tasks, cron, workers, admin
+4.0/23base+4.0/23Domain API (GraphQL)512EKS pods — grows into +6/+7
+6.0/24base+6.0/24Next.js Frontend256May move to Cloudflare
+7.0/24base+7.0/24Reserved / Domain API (EC2)256Phase 1: EC2-based Domain API; Phase 2: returns to reserved

Design Rationale

If Next.js moves to Cloudflare, offsets +6 and +7 form a contiguous /23 that can extend the Domain API block into a /22 (offsets +4–7, 1,024 IPs). If both Next.js and Domain API move off-VPC, offsets +4–7 become a contiguous /22 of free space with no fragmentation.

Phase 1 — CE Staging (no EKS)

For the initial CE staging deployments, the Domain API runs on EC2 with classic Auto Scaling in the +7 block (base+7.0/24). The EKS block at +4 remains unallocated until Phase 2. When EKS is introduced, EC2-based domain services are migrated to the +4 /23 and +7 returns to reserved.


Subnet Detail — Baker Production (10.34.16.0/21)

Full worked example showing the complete subnet map for one BU environment.

Public — Ingress (10.34.16.0/24)

SubnetCIDRAZPurpose
baker-prd-public-2a10.34.16.0/26us-east-2aWebscale ADC, NAT Gateway
baker-prd-public-2b10.34.16.64/26us-east-2bWebscale ADC
baker-prd-public-2c10.34.16.128/26us-east-2cAvailable
baker-prd-public-mgmt10.34.16.192/26us-east-2aBastion / VPN

Data Tier (10.34.17.0/24)

SubnetCIDRAZPurpose
baker-prd-data-2a10.34.17.0/26us-east-2aRDS primary, Redis primary, RabbitMQ
baker-prd-data-2b10.34.17.64/26us-east-2bRDS replica, Redis replica
baker-prd-data-2c10.34.17.128/26us-east-2cRDS replica
(reserved)10.34.17.192/26OpenSearch / future

Shopware Backend (10.34.18.0/23)

SubnetCIDRAZPurposeUsable IPs
baker-prd-backend-2a10.34.18.0/25us-east-2aECS tasks, cron, admin126
baker-prd-backend-2b10.34.18.128/25us-east-2bECS tasks126
baker-prd-backend-2c10.34.19.0/25us-east-2cECS workers126
(reserved)10.34.19.128/25Backend overflow126

Domain API — EKS (10.34.20.0/23)

SubnetCIDRAZPurposeUsable IPs
baker-prd-domain-2a10.34.20.0/25us-east-2aEKS nodes + pods126
baker-prd-domain-2b10.34.20.128/25us-east-2bEKS nodes + pods126
baker-prd-domain-2c10.34.21.0/25us-east-2cEKS nodes + pods126
(reserved)10.34.21.128/25Pod overflow / prefix delegation126

EKS Sizing

126 usable IPs per AZ is sufficient for initial deployments. If pod density exceeds this, enable VPC CNI prefix delegation to multiply capacity 16×, or expand into the Next.js / reserved blocks at +6/+7.

Next.js Frontend (10.34.22.0/24)

SubnetCIDRAZPurpose
baker-prd-frontend-2a10.34.22.0/26us-east-2aECS tasks
baker-prd-frontend-2b10.34.22.64/26us-east-2bECS tasks
baker-prd-frontend-2c10.34.22.128/26us-east-2cECS tasks
(reserved)10.34.22.192/26

Cloudflare Migration

If Next.js moves to Cloudflare Workers/Pages, this block becomes available. Combined with the reserved /24 below, it forms a contiguous /23 that can extend the Domain API allocation.

Reserved / Domain API EC2 (10.34.23.0/24)

Phase 1 (CE staging): EC2-based Domain API with Auto Scaling.

SubnetCIDRAZPurpose
baker-prd-domain-ec2-2a10.34.23.0/26us-east-2aDomain API EC2 instances
baker-prd-domain-ec2-2b10.34.23.64/26us-east-2bDomain API EC2 instances
baker-prd-domain-ec2-2c10.34.23.128/26us-east-2cDomain API EC2 instances
(reserved)10.34.23.192/26

Phase 1 Only

These subnets are decommissioned when Domain API migrates to EKS (block +4). The /24 then returns to general reserved status.


Applying to Other BUs

The layout is identical for every BU — only the base address changes:

Base = 10.34.(BU_offset).0/21

Public:   base + 0        /24
Data:     base + 1        /24
Backend:  base + 2        /23 (spans 2 octets)
Domain:   base + 4        /23 (spans 2 octets)
Frontend: base + 6        /24  ← may move to Cloudflare
Reserved: base + 7        /24
BUProduction BaseStaging Base
SupplySync10.34.0.010.34.8.0
Baker10.34.16.010.34.24.0
Gemaire10.34.32.010.34.40.0
CENA10.34.48.010.34.56.0
ECMDI10.34.64.010.34.72.0
Peirce Phelps10.34.80.010.34.88.0
CELATAM10.34.96.010.34.104.0
Homans10.34.112.010.34.120.0
GreeComfort10.34.128.010.34.136.0

Webscale-Managed VPC Model

When Webscale provisions the environment, they use a simplified VPC layout: 2 public subnets (multi-AZ ingress) + 3 private subnets (all workloads). The idealized per-tier layout above would require significant custom provisioning effort and time from Webscale; their standard template uses fewer, larger subnets with security-group-level isolation between tiers instead of network-level separation.

This model consumes only a /23 from the BU's /21 staging allocation, leaving the remaining space available for a dedicated Domain API EKS cluster in Phase 2. If other BUs are deployed with EC2-based Domain API through Webscale, they would follow this same pattern at their respective base addresses.

Subnet Template (Webscale Model)

vpc_cidr: base.0/23

Public:
  base.0/26       (zone a) — Webscale ADC, NAT Gateway, ALB
  base.64/26      (zone b) — Webscale ADC, ALB

Private:
  base.128/25     (zone a) — all workloads (126 IPs)
  base+1.0/25     (zone b) — all workloads (126 IPs)
  base+1.128/25   (zone c) — all workloads (126 IPs)

All tiers share private subnets: Shopware Backend, Domain API (EC2), PWA Frontend (Next.js), and data services (RDS, ElastiCache, RabbitMQ). Security groups enforce isolation between workloads.

Remaining Allocation

Offset from BU staging baseCIDRPurpose
+0.0/23Webscale VPCActive
+2.0/22EKS VPC (Phase 2)Reserved
+6.0/23UnallocatedReserved for growth

CENA Staging — 10.34.56.0/23

CENA is the first BU deployed using this model (base: 10.34.56.0).

VPC Layout

vpc_cidr: 10.34.56.0/23
SubnetCIDRAZPurposeUsable IPs
cena-stg-public-a10.34.56.0/26us-east-2aWebscale ADC, NAT Gateway, ALB62
cena-stg-public-b10.34.56.64/26us-east-2bWebscale ADC, ALB62
cena-stg-private-a10.34.56.128/25us-east-2aAll private workloads126
cena-stg-private-b10.34.57.0/25us-east-2bAll private workloads126
cena-stg-private-c10.34.57.128/25us-east-2cAll private workloads126

Address Map

10.34.56.0/23 (VPC)
├── 10.34.56.0/26     Public (AZ a) — ADC, NAT, ALB
├── 10.34.56.64/26    Public (AZ b) — ADC, ALB
├── 10.34.56.128/25   Private (AZ a) — all workloads
├── 10.34.57.0/25     Private (AZ b) — all workloads
└── 10.34.57.128/25   Private (AZ c) — all workloads

Phase 2 — Domain API EKS Migration

Each BU gets its own dedicated EKS cluster (production + staging) due to unique cluster-level requirements per BU. When Domain API migrates from EC2 to EKS, the CENA staging cluster will live in its own VPC carved from the remaining allocation:

EKS VPC: 10.34.58.0/22 (1,024 IPs) — dedicated to the CENA staging EKS cluster.

The EKS VPC is largely self-contained:

  • Cache: Domain API runs its own Redis/Valkey within the EKS VPC (no dependency on the Webscale VPC's ElastiCache).
  • Shopware connectivity: Domain API pods need a network path to the Shopware backend in the Webscale VPC. This is the primary driver for VPC peering between the two VPCs — no other data-plane dependency is expected.
  • External APIs: Outbound internet access (NAT Gateway or VPC endpoints) for third-party integrations.

VPC Peering

Peering between 10.34.58.0/22 (EKS) and 10.34.56.0/23 (Webscale) is straightforward — no CIDR overlap, both within the same /21 allocation. Peering can be deferred until the EKS migration is ready; it doesn't affect Phase 1 operations.

Differences from Idealized Layout

AspectIdealized (/21, per-tier subnets)Webscale /23
VPC size/21 (2,048 IPs)/23 (512 IPs)
Subnet count18+ (3 AZ × 6 tiers)5 (2 public + 3 private)
Tier isolationNetwork-level (separate subnets)Security-group-level
Data tierDedicated /24Shared private subnets
Expansion modelPre-allocated per tierSeparate EKS VPC + peering
Provisioning complexitySignificant custom labor from WebscaleWebscale standard template

Shared EKS Option — 10.34.192.0/20

An alternative to per-BU EKS clusters is a single shared EKS cluster per environment in a dedicated AWS account, with all BU Domain API workloads running as namespaced deployments. This trades blast radius isolation for operational simplicity and cost efficiency.

Deployment Models Compared

AspectPer-BU EKS (at +4)Shared EKS (Shared Services)
Control plane cost$73/mo × N BUs$73/mo × 1
Blast radiusFull isolationNamespace + node pool isolation
Upgrade cyclesIndependent per BUCoordinated across BUs
ObservabilityPer-clusterUnified, multi-tenant
Network complexitySimple (in-VPC)Requires VPC peering / TGW to BU VPCs
IP allocationPer-BU /23 at offset +4Shared /19 from Shared Services block

Shared Services Allocation (10.34.192.0/20)

CIDRPurposeIPs
10.34.192.0/21Shared EKS — Production2,048
10.34.200.0/21Shared EKS — Staging2,048

Per-Environment Shared EKS Layout (10.34.192.0/21 — Production)

CIDRPurposeIPsNotes
10.34.192.0/24EKS public subnets (Webscale ADC / ingress)2562 AZ pair
10.34.193.0/24EKS control plane ENIs256AWS-managed
10.34.194.0/23EKS node group — high-traffic BUs512Baker, Gemaire, CENA
10.34.196.0/23EKS node group — standard BUs512All others
10.34.198.0/24Reserved (node overflow)256
10.34.199.0/24Reserved256

Connectivity

The shared EKS VPC connects to each BU's VPC via Transit Gateway or VPC Peering:

  • BU VPCs expose their data-tier subnets (RDS, Redis, RabbitMQ) via peering
  • Domain API pods in shared EKS reach BU data tiers over private routes
  • No CIDR overlap — BU VPCs are in 10.34.0.0/1910.34.128.0/20, shared EKS is in 10.34.192.0/20

Blast Radius Mitigation

If using shared EKS, these controls limit cross-BU impact:

  • Karpenter node pools per BU — dedicated nodes via taints/tolerations, no resource contention
  • Namespace isolation — NetworkPolicy restricts cross-namespace traffic
  • Resource quotas — per-namespace CPU/memory limits prevent noisy-neighbor
  • Pod disruption budgets — protect BU workloads during cluster operations
  • Separate node groups — high-traffic BUs on dedicated instances

Decision Matrix

Choose shared EKS when:

  • Platform team can own a single cluster
  • BUs run similar workload profiles
  • Cost efficiency outweighs isolation requirements

Choose per-BU EKS when:

  • BUs have different compliance requirements
  • Independent release cadences are critical
  • Blast radius tolerance is near zero

Current Plan

Phase 1: Domain API on EC2 (offset +7) — no EKS. Phase 2: Evaluate shared vs. per-BU EKS based on Phase 1 traffic patterns and operational maturity.


Diagrams

Per-Environment VPC Subnet Layout

Shopware VPC subnet layout

Shared EKS Connectivity

Shared EKS with BU VPC connectivity


DR — 10.35.0.0/16

Identical structure deployed in the DR region. Same BU offsets, same subnet pattern. No CIDR overlap enables Transit Gateway route propagation between primary and DR without conflicts.


Comparison with Magento (10.33)

Aspect10.33 (Magento)10.34 (Shopware)
Per-BU allocation10× /24 (2,560 IPs)/20 (4,096 IPs)
Per-environment VPC/23 (512 IPs)/21 (2,048 IPs)
Component isolationNone — shared subnetsDedicated subnets per tier
EKS supportN/A/23 for Domain API pods
Data tierMixed with computeIsolated subnet group
Message queueN/ADedicated data-tier subnets
Expansion headroomTight (CENA marked "Full")2× /24 reserved per env
DR strategyAdjacent /23 in same /16Separate /16 (10.35)