Networking Prerequisites
This page documents the network infrastructure required for an AosCloud deployment on AWS. It covers VPC design, subnet planning across availability zones, VPC endpoint requirements for private EKS communication, and security group rules governing traffic between services.
Prerequisites
Before configuring networking, review:
- Required AWS Services — identifies which services need network connectivity
- Infrastructure Overview — introduces the overall deployment model
Single-VPC Architecture
AosCloud deploys all resources into a single VPC. This VPC hosts the EKS cluster, all managed services (Aurora PostgreSQL, DocumentDB, ElastiCache, EFS), VPC endpoints, and load balancers.
CIDR Planning
The base VPC CIDR defaults to 10.231.0.0/16 and is configurable per environment:
| Parameter | Default | Netmask |
|---|---|---|
| Base VPC CIDR | 10.231.0.0/16 | 255.255.0.0 (65,536 addresses) |
A /16 block provides sufficient address space for all subnets. Choose a CIDR that does not overlap with your corporate network or other VPCs that may need peering/transit gateway connectivity in the future.
VPC Configuration
The VPC is created with:
- DNS hostnames enabled (
enable_dns_hostnames = true) - Default tenancy
- An Internet Gateway attached for public subnets and NAT
Subnet Layout
The VPC address space is divided into purpose-specific subnets spread across availability zones.
Subnet Allocation Table
Given the default base CIDR 10.231.0.0/16:
| Subnet | Approximate Range | Purpose | AZs |
|---|---|---|---|
| EKS Private (pods) | 10.231.0.0/18 split into 3 | EKS node groups, pods, internal LB | 3 |
| EKS Public | within 10.231.0.0/18 | Public load balancers, NAT Gateway | 3 |
| Endpoints | 10.231.100.0/24 | VPC Interface Endpoints | 1 |
| Aurora PostgreSQL | ~10.231.253.192/26 → 3× /28 | Aurora DB subnet group | 3 |
| DocumentDB | ~10.231.255.128/26 → 3× /28 | DocumentDB subnet group | 3 |
| ElastiCache | ~10.231.255.64/26 → 3× /28 | ElastiCache Redis subnet group | 3 |
EKS Subnets (Detail)
The EKS cluster creates its own subnets within the Kubernetes services CIDR block (10.231.0.0/18):
- 3 private subnets — one per AZ, tagged
kubernetes.io/role/internal-elb = 1. Used for node groups, pods, and internal load balancers. Each node joins the private route table with a default route via NAT Gateway. - 3 public subnets — one per AZ, tagged
kubernetes.io/role/elb = 1. Used for internet-facing load balancers. Each has a default route to the Internet Gateway. - 1 NAT Gateway — placed in the first public subnet, providing outbound internet for private subnets.
Managed Service Subnet Groups
Aurora PostgreSQL, DocumentDB, and ElastiCache Redis each require a subnet group spanning multiple AZs for high availability:
| Service | Subnets | AZ Count | Placement |
|---|---|---|---|
| Aurora PostgreSQL | 3 subnets | 3 | Base VPC, private |
| DocumentDB | 3 subnets | 3 | Base VPC, private |
| ElastiCache Redis | 3 subnets | 3 | Base VPC, private |
| EFS | Mount targets in EKS pod subnets | 3 | EKS private subnets |
EFS mount targets are placed directly in the EKS pod subnets rather than in dedicated subnets, because EFS clients (pods) must be in the same subnet or a routable subnet to access mount targets.
Network Topology Diagram
VPC Endpoints
EKS private clusters require VPC Interface Endpoints to communicate with AWS services without traversing the public internet. All endpoints are placed in the dedicated endpoints subnet and associated with both the base VPC default security group and the EKS cluster security group.
Required Endpoints
Twelve VPC endpoints provide private connectivity:
| Service Endpoint | Purpose |
|---|---|
com.amazonaws.<region>.ec2 | EKS node registration, ENI management |
com.amazonaws.<region>.ecr.api | ECR API calls for image manifest retrieval |
com.amazonaws.<region>.ecr.dkr | Docker image layer pulls from ECR |
com.amazonaws.<region>.logs | CloudWatch Logs for Fluent Bit log shipping |
com.amazonaws.<region>.sts | STS for IRSA token exchange (pod IAM roles) |
com.amazonaws.<region>.elasticloadbalancing | ALB/NLB provisioning by AWS Load Balancer Controller |
com.amazonaws.<region>.autoscaling | Cluster Autoscaler integration |
com.amazonaws.<region>.secretsmanager | CSI Secrets Store driver access to secrets |
com.amazonaws.<region>.rds | Aurora PostgreSQL API operations |
com.amazonaws.<region>.s3 | S3 access (artifacts, backups) |
com.amazonaws.<region>.elasticache | ElastiCache management API |
com.amazonaws.<region>.email-smtp | SES SMTP endpoint for outbound email |
All endpoints use Interface type. The S3 endpoint has private_dns_enabled = false (AWS limitation for S3 Interface endpoints), while all other endpoints have private_dns_enabled = true.
Endpoint Security
Each VPC endpoint is associated with:
- The base VPC default security group — allows traffic from all resources in the VPC
- The EKS cluster security group — allows traffic from EKS nodes and pods
This dual-attachment ensures both managed services and EKS workloads can reach AWS APIs through the endpoints.
Security Groups
AosCloud uses a combination of VPC default security groups and custom security groups to control network traffic.
Security Group Architecture
| Security Group | VPC | Purpose |
|---|---|---|
| Base VPC Default SG | Base VPC | Applied to managed services (Aurora, DocumentDB, Redis, EFS, endpoints) |
| EKS Cluster SG | Base VPC | Applied to EKS nodes; managed by EKS |
| EKS Public LB SG | Base VPC | Custom SG for internet-facing load balancers (optional) |
Inter-Group Rules
EKS ↔ Base VPC (Bidirectional)
Full connectivity between the EKS cluster security group and the base VPC default security group. This permits EKS pods to reach managed services and VPC endpoints.
| Rule | Direction | Protocol | Ports | Source/Destination |
|---|---|---|---|---|
eks_to_base | Ingress on Base SG | All (-1) | 0–65535 | EKS Cluster SG |
base_to_eks | Ingress on EKS SG | All (-1) | 0–65535 | Base VPC Default SG |
Effect: Any pod running in EKS can communicate on any port with any resource in the Base VPC default security group (Aurora on 5432, DocumentDB on 27017, Redis on 6379, EFS on 2049, etc.), and vice versa.
Public Load Balancer (Optional)
When ingress security group rules are configured, a dedicated security group is created for the EKS public load balancer:
| Rule | Direction | Protocol | Ports | Source |
|---|---|---|---|---|
| Configurable ingress | Ingress | Per rule | Per rule | Per rule CIDR |
| All egress | Egress | All (-1) | 0–65535 | 0.0.0.0/0, ::/0 |
Configure ingress rules to restrict inbound traffic to specific ports and source CIDRs. For example, you might allow HTTPS (443) from all sources and a management port (10000) from internal networks only.
Port Requirements Summary
The following ports must be reachable between EKS pods and managed services (all within the VPC, governed by the EKS ↔ Base bidirectional rule):
| Service | Port | Protocol | Direction |
|---|---|---|---|
| Aurora PostgreSQL | 5432 | TCP | EKS → Aurora |
| DocumentDB | 27017 | TCP | EKS → DocumentDB |
| ElastiCache Redis | 6379 | TCP | EKS → ElastiCache |
| EFS (NFS) | 2049 | TCP | EKS → EFS mount targets |
| AMQP (RabbitMQ in-cluster) | 5672 | TCP | Pod → Pod (Istio mesh) |
| AMQPS (RabbitMQ management) | 15672 | TCP | Pod → Pod (Istio mesh) |
| HTTPS (AWS endpoints) | 443 | TCP | EKS → VPC endpoints |
Outbound Internet Access
EKS private subnets access the internet through the NAT Gateway placed in the first public subnet. This is required for:
- Pulling container images from external registries (when not cached in ECR)
- Sending outbound email via SES (if VPC endpoint is insufficient)
- Connecting to external APIs
The NAT Gateway has an Elastic IP. All egress from private subnets routes through 0.0.0.0/0 → NAT Gateway → Internet Gateway.
Route Tables
| Route Table | Subnets | Default Route | Additional Routes |
|---|---|---|---|
| EKS Private | EKS private subnets, Endpoints subnet | 0.0.0.0/0 → NAT Gateway | — |
| EKS Public | EKS public subnets | 0.0.0.0/0 → Internet Gateway | — |
| Base VPC Default | (implicit for non-EKS subnets) | local only | — |
The endpoints subnet is explicitly associated with the EKS private route table, ensuring that VPC endpoint traffic from EKS uses the correct routing path.
CIDR Planning Guidance
When choosing your VPC CIDR:
- Use a
/16block — the subnet calculations assume a full/16and will produce incorrect results with smaller blocks - Avoid RFC 1918 conflicts — ensure your chosen CIDR does not overlap with corporate VPN ranges or other AWS VPCs you may peer with
- Reserve space for growth — the default
10.231.0.0/16leaves the rest of10.0.0.0/8available for other environments or services - Staging offset — a
+1modifier is applied to the second octet for staging environments (e.g.,10.232.0.0/16if base is10.231.0.0/16), ensuring non-overlapping CIDRs across environments
Related Documentation
- Required AWS Services — services that depend on this network configuration
- Infrastructure Overview — overall deployment model and reading order
- AWS Resource Architecture — full topology diagram showing how network components connect