Requirements for BYON (Bring Your Own Network) Custom VPC setup in AWS

The below instructions apply to customers that are entitled to having the pipeline deployed on a Custom, pre-existing VPC. We call this BYON (Bring your own network). Once we receive VPC ID, we will work with our backend team to validate the VPC set up the pipeline. If we hit any constraint, we will reach out to inform further requirements or clearances.

This only applies to Private Managed Cloud (PMC) pipelines in which the customer supplied an AWS account. We also support VPC Peering in both PMC or Cloud pipelines.

Difference between VPC Peering and BYON (custom VPC)

VPC Peering is not the same as BYON (Bring Your Own Network). VPC Peering allows a Snowplow-created VPC to connect securely to a customer VPC, allowing us to send data to remote networks securely, while BYON allows for setting up the entire pipeline on an existing custom VPC created in the shared AWS account on your end.

CIDR Ranges

If you require Snowplow to be deployed into a specific VPC CIDR range, this should be provided at the same time. We need a /18 provided for the VPC so that we can create /20 and /23 subnets (note: VPC peering and using a custom VPC are an additional bolt-on).

The /18 CIDR is not a hard requirement, but it is our strong preference as it provides headroom for future scaling and simplifies our standard deployment patterns.

If you have existing network constraints, we strongly recommend considering at least a /20 (4,096 IPs) to provide adequate headroom. This would still be significantly smaller than our standard /18 but would reduce the risk of future constraints.

As a last resort, we can work with /22 allocation, but there are important considerations to take into account:

Current Deployment Constraints

• We currently only support 2 Availability Zones in our deployment automation
• The subnet breakdown (/28s and /25s) won't work for Snowplow deployments as they're too small and don't align with our requirements

Option 1: Four /24 Subnets (Minimum viable)

If using a /22, we'd need it subdivided as:

• 2 public subnets (1 per AZ)
• 2 private subnets (1 per AZ)

Option 2: Mixed Subnet Sizes (Preferred)

Better utilization with dedicated EKS node subnets:

• 2 public subnets (/25 each)
• 2 private subnets (/25 each)
• 2 EKS node subnets (/24 each)

Critical: EKS Pod Networking Requirements

Regardless of the primary VPC CIDR chosen, we require a secondary CIDR for EKS pod networking to prevent IP exhaustion:

1. Secondary CIDR: We add a CG-NAT range (100.64.0.0/16 default) to the VPC
   • This range is rarely used in corporate networks, avoiding conflicts
2. Pod subnets: Two /18 subnets for pod IPs
   • 100.64.0.0/18 (AZ1)
   • 100.64.64.0/18 (AZ2)
3. Benefits:
   • Pods get IPs from CG-NAT range, not from limited primary CIDR
   • Prevents IP exhaustion in primary subnets
   • Enables scaling to thousands of pods without impacting other resources

Risks of Using /22

• Limited scalability: 1,024 total IPs may constrain future scaling
• No room for additional services: If deploying other services in the same VPC is required in the future
• Potential IP exhaustion: Especially during high-load periods or scaling events, as more pods/nodes are added to the infrastructure

Tagging the subnets

To enable traefik to be able to deploy successfully within BYON, we need you to add the following tags.

* Snowplow Support will confirm the specific value to use on the public subnet to replace placeholder values in kubernetes.io/cluster/sp-{customer-name}-{env}-eks-cluster.