Appearance
Shopware CIDR Allocations — Reference
Explicit, precomputed CIDR blocks for every BU × environment × system on the Shopware platform (10.34.0.0/16 primary). Use this page directly when provisioning; no subnet math required.
Deployment Model
Shopware environments are deployed on Webscale, following their VPC model:
- Webscale VPC (offset
+0, a/23) hosts the Shopware Backend (Webscale-managed EC2), data services (RDS, ElastiCache, OpenSearch, RabbitMQ), and all external ingress (Webscale ADCs in the public subnets). All workloads share private subnets with security-group-level isolation. - Dedicated EKS VPC (offset
+4, a/22) hosts the Domain API (GraphQL) and PWA / Next.js Frontend as pods. One dedicated cluster per BU/environment, peered to the Webscale VPC. The EKS VPC has no internet-facing ingress and no AWS ALBs — all inbound traffic arrives from the Webscale ADCs (in the Webscale VPC public subnets) over the VPC peering link. The EKS public subnets exist only for NAT egress.
There is no shared EKS cluster. Each BU/environment gets its own EKS VPC.
The two VPCs are carved from the BU's /21 environment allocation as follows: Webscale at +0 /23, the +2 /23 held as reserved/overflow, and the EKS VPC occupying the +4 /22. This consumes the entire /21 with no fragmentation.
EKS VPC Sized at /22 (revised)
The EKS VPC was originally specced as a /23 at offset +2. Live diagnosis of the CENA staging cluster (watsco-cena-sw-stg-front, VPC 10.34.58.0/23) during a blue/green rollout showed hard IP exhaustion: with two full stack copies live simultaneously, the VPC CNI failed to assign pod IPs (failed to assign an IP address to container), leaving pods stuck in ContainerCreating. A /23 split into /25 (or eksctl's default /26) private subnets does not provide enough per-AZ address space for blue/green plus production replica counts.
The EKS VPC is now a /22 at offset +4 with /24 private subnets (~251 usable per AZ). The Webscale VPC (+0 /23) is unchanged. Existing /23 EKS VPCs cannot be resized in place — moving to the /22 requires standing up a new VPC at the +4 block and migrating the cluster (which aligns naturally with the blue/green cutover workflow).
Each BU receives a /20, split into a Production /21 and a Staging /21, each deployed in a separate AWS account in us-east-2.
Master Allocation Table
| BU | Environment | /21 Allocation | Webscale VPC (+0 /23) | EKS VPC (+4 /22) | Reserved (+2 /23) |
|---|---|---|---|---|---|
| SupplySync | Production | 10.34.0.0/21 | 10.34.0.0/23 | 10.34.4.0/22 | 10.34.2.0/23 |
| SupplySync | Staging | 10.34.8.0/21 | 10.34.8.0/23 | 10.34.12.0/22 | 10.34.10.0/23 |
| Baker | Production | 10.34.16.0/21 | 10.34.16.0/23 | 10.34.20.0/22 | 10.34.18.0/23 |
| Baker | Staging | 10.34.24.0/21 | 10.34.24.0/23 | 10.34.28.0/22 | 10.34.26.0/23 |
| Gemaire | Production | 10.34.32.0/21 | 10.34.32.0/23 | 10.34.36.0/22 | 10.34.34.0/23 |
| Gemaire | Staging | 10.34.40.0/21 | 10.34.40.0/23 | 10.34.44.0/22 | 10.34.42.0/23 |
| CENA | Production | 10.34.48.0/21 | 10.34.48.0/23 | 10.34.52.0/22 | 10.34.50.0/23 |
| CENA | Staging | 10.34.56.0/21 | 10.34.56.0/23 | 10.34.60.0/22 | 10.34.58.0/23 |
| ECMDI | Production | 10.34.64.0/21 | 10.34.64.0/23 | 10.34.68.0/22 | 10.34.66.0/23 |
| ECMDI | Staging | 10.34.72.0/21 | 10.34.72.0/23 | 10.34.76.0/22 | 10.34.74.0/23 |
| Peirce Phelps | Production | 10.34.80.0/21 | 10.34.80.0/23 | 10.34.84.0/22 | 10.34.82.0/23 |
| Peirce Phelps | Staging | 10.34.88.0/21 | 10.34.88.0/23 | 10.34.92.0/22 | 10.34.90.0/23 |
| CELATAM | Production | 10.34.96.0/21 | 10.34.96.0/23 | 10.34.100.0/22 | 10.34.98.0/23 |
| CELATAM | Staging | 10.34.104.0/21 | 10.34.104.0/23 | 10.34.108.0/22 | 10.34.106.0/23 |
| Homans | Production | 10.34.112.0/21 | 10.34.112.0/23 | 10.34.116.0/22 | 10.34.114.0/23 |
| Homans | Staging | 10.34.120.0/21 | 10.34.120.0/23 | 10.34.124.0/22 | 10.34.122.0/23 |
| GreeComfort | Production | 10.34.128.0/21 | 10.34.128.0/23 | 10.34.132.0/22 | 10.34.130.0/23 |
| GreeComfort | Staging | 10.34.136.0/21 | 10.34.136.0/23 | 10.34.140.0/22 | 10.34.138.0/23 |
10.34.144.0/20–10.34.176.0/20are unassigned BU slots.10.34.192.0/20is reserved for Shared Services.Offset map within each
/21:+0/23 = Webscale VPC ·+2/23 = reserved/overflow ·+4/22 = EKS VPC. The EKS/22occupies the top half of the/21(offsets+4through+7), the only/22-aligned block clear of the Webscale VPC.
System-Level CIDRs
Each row in the master table expands into two VPCs. The subnet layout is identical for every BU/environment; only the base address changes.
Webscale VPC (+0 /23) — Backend, Data, Ingress
| Subnet | Offset | AZ | Purpose | Usable IPs |
|---|---|---|---|---|
webscale-public-a | base.0/26 | 2a | Webscale ADC (all ingress), NAT Gateway | 62 |
webscale-public-b | base.64/26 | 2b | Webscale ADC (all ingress) | 62 |
webscale-private-a | base.128/25 | 2a | All workloads (Backend, data) | 126 |
webscale-private-b | base+1.0/25 | 2b | All workloads | 126 |
webscale-private-c | base+1.128/25 | 2c | All workloads | 126 |
EKS VPC (+4 /22) — Domain API + PWA/Frontend
The /22 splits into one public /24 (carved into /26s for NAT egress across 3 AZs) and three private /24s (one per AZ). Offsets are relative to the /22 base at +4.
| Subnet | Offset | AZ | Purpose | Usable IPs |
|---|---|---|---|---|
eks-public-a | base+4.0/26 | 2a | NAT Gateway (egress only) | 62 |
eks-public-b | base+4.64/26 | 2b | NAT Gateway (egress only) | 62 |
eks-public-c | base+4.128/26 | 2c | NAT Gateway (egress only) | 62 |
| (spare public) | base+4.192/26 | — | Reserved | 62 |
eks-nodes-a | base+5.0/24 | 2a | EKS nodes + pods (Domain API, PWA) | 251 |
eks-nodes-b | base+6.0/24 | 2b | EKS nodes + pods | 251 |
eks-nodes-c | base+7.0/24 | 2c | EKS nodes + pods | 251 |
There are no AWS ALBs in the EKS VPC. All external ingress arrives from the Webscale ADCs (in the Webscale VPC public subnets) over the VPC peering link, so the EKS public subnets carry only NAT Gateways for outbound traffic and do not need AWS Load Balancer Controller ELB-discovery tags.
EKS Capacity
/24 private subnets provide 251 usable IPs per AZ (~753 across three AZs). This is sized for the blue/green failure mode: two full stack copies live at once, plus rolling surge and CNI warm-pool overhead. For production (≥2 replicas per deployment, ~50+ app pods per copy), worst-case single-AZ demand during a rollout is ~100 IPs, leaving roughly 2.4× headroom. If pod density ever exceeds this, enable VPC CNI prefix delegation — a /24 has ample room for contiguous /28 prefixes, unlike the previous /25. Cache for the Domain API can run in-cluster (an in-cluster Valkey deployment is a convenience measure), though production ideally uses a shared ElastiCache instance so cache state persists across rolling deployments and blue/green stacks. Peering to the Webscale VPC provides the path to the Shopware backend and carries inbound traffic from the Webscale ADCs (there are no ALBs in the EKS VPC consuming IPs).
Do Not Use eksctl Default Subnets
eksctl's default layout carves the VPC into six /26 subnets (3 public + 3 private), which strands address space and caps each AZ at ~59 IPs — this is what caused the CENA staging exhaustion. Provision the EKS VPC with the explicit /24 private subnets above (via CDK / CloudFormation / Terraform), not eksctl defaults.
Worked Example — SupplySync Staging
Staging base: 10.34.8.0 (account: separate ecom Shopware staging account, us-east-2).
Webscale VPC — 10.34.8.0/23
| Subnet | CIDR | AZ | Purpose |
|---|---|---|---|
| ssync-stg-public-a | 10.34.8.0/26 | 2a | Webscale ADC (all ingress), NAT Gateway |
| ssync-stg-public-b | 10.34.8.64/26 | 2b | Webscale ADC (all ingress) |
| ssync-stg-private-a | 10.34.8.128/25 | 2a | Backend, data services |
| ssync-stg-private-b | 10.34.9.0/25 | 2b | Backend, data services |
| ssync-stg-private-c | 10.34.9.128/25 | 2c | Backend, data services |
EKS VPC — 10.34.12.0/22 ← Domain API + PWA cluster
| Subnet | CIDR | AZ | Purpose |
|---|---|---|---|
| ssync-stg-eks-public-a | 10.34.12.0/26 | 2a | NAT Gateway (egress only) |
| ssync-stg-eks-public-b | 10.34.12.64/26 | 2b | NAT Gateway (egress only) |
| ssync-stg-eks-public-c | 10.34.12.128/26 | 2c | NAT Gateway (egress only) |
| ssync-stg-eks-nodes-a | 10.34.13.0/24 | 2a | EKS nodes + pods |
| ssync-stg-eks-nodes-b | 10.34.14.0/24 | 2b | EKS nodes + pods |
| ssync-stg-eks-nodes-c | 10.34.15.0/24 | 2c | EKS nodes + pods |
The +2 /23 (10.34.10.0/23) is held as reserved/overflow.
Peering: 10.34.12.0/22 (EKS) ↔ 10.34.8.0/23 (Webscale) — no CIDR overlap, both within the 10.34.8.0/21 staging allocation.
Existing SupplySync Deployment
The currently deployed SupplySync environments live on the legacy Magento range (supplysync-staging-vpc = 10.33.2.0/23), provisioned before this plan. The 10.34.x allocations here are forward-looking for the Shopware platform. New Shopware infrastructure uses 10.34.x; the legacy 10.33.x VPCs are documented under SupplySync.
DR — 10.35.0.0/16
The DR region mirrors this structure exactly: same BU offsets, same +0 (Webscale /23) / +4 (EKS /22) system layout, in 10.35.x instead of 10.34.x. No CIDR overlap with primary enables Transit Gateway route propagation between regions. To derive any DR CIDR, replace 10.34 with 10.35 in the tables above.