​

Networking Module

​

Overview

​

Key Features

• Private Architecture: All workloads run in private subnets with no direct internet access
• Network Isolation: Separate subnets for applications, databases, and network tiers
• Security Groups: Fine-grained traffic control between components
• VPC Endpoints: Private connectivity to AWS services (S3, ECR, Secrets Manager, etc.)
• Flow Logging: Network traffic monitoring and audit trails
• Flexible Deployment: Support for new VPC creation or existing VPC integration

​

Network Architecture

​

VPC Configuration

• DNS Hostnames: Enabled (required for EKS and VPC endpoints)
• DNS Support: Enabled (enables DNS resolution within VPC)

• Creates only the required subnets (if not provided)
• Integrates with existing networking infrastructure

​

Subnet Design

​

1. Private Subnets

• 10.0.10.0/24 (254 IPs per subnet)
• 10.0.20.0/24

• No public IP assignment
• No direct internet access
• Traffic routed within VPC or through VPC endpoints
• Used for EKS control plane and worker nodes

• EKS worker nodes
• Application pods (backend API, Celery workers)
• Internal load balancers
• Bastion hosts

​

2. Database Subnets

• 10.0.100.0/24
• 10.0.200.0/24

• Fully isolated from internet
• Only accessible from EKS nodes via security groups
• Separate route table with no routes (isolated)
• Used exclusively for database instances

• RDS PostgreSQL instances
• Database replicas
• Read replicas (if configured)

​

Route Tables

​

Private Route Table

• Local VPC traffic only (automatic)
• No internet gateway route (no internet access)
• Enterprise connectivity via VPC peering or VPN (configured separately)

​

Database Route Table

• Local VPC traffic only (automatic)
• No other routes (maximum isolation)

​

Security Groups

​

1. EKS Cluster Security Group

• All traffic: 0.0.0.0/0 (required for cluster operations and AWS API calls)

​

2. EKS Nodes Security Group

• All traffic to VPC CIDR (allows communication within VPC)

​

3. RDS Security Group

• All traffic to VPC CIDR

​

4. ALB Security Group (Internal)

• All traffic: 0.0.0.0/0 (ALB needs to reach target pods)

​

5. Frontend ALB Security Group

• All traffic: 0.0.0.0/0 (ALB needs to reach target pods)

​

6. VPC Endpoints Security Group

• All traffic: 0.0.0.0/0

​

VPC Endpoints

​

Gateway Endpoints

​

S3 Endpoint

• Application file storage and retrieval
• ECR image layer storage (ECR uses S3 backend)
• Log archival and backups
• Static asset delivery

​

Interface Endpoints

​

ECR Endpoints

• com.amazonaws.{region}.ecr.dkr - Docker Registry API
• com.amazonaws.{region}.ecr.api - ECR control plane API

• EKS nodes pulling container images
• CI/CD pipelines accessing ECR
• Image scanning and vulnerability checks

• ecr.dkr: Docker daemon communicates with ECR registry
• ecr.api: ECR control plane operations (list images, get authorization tokens)

​

EC2 Endpoint

• EKS node bootstrap scripts calling EC2 APIs
• Auto Scaling Group operations
• ENI attachment and management
• Instance metadata access

​

STS Endpoint

• IRSA (IAM Roles for Service Accounts) in EKS
• Pod service accounts assuming IAM roles
• Temporary credential generation
• Cross-account access

​

EKS Endpoint

• kubectl commands from bastion host
• EKS cluster management operations
• eksctl operations
• Cluster configuration updates

​

Elastic Load Balancing Endpoint

• AWS Load Balancer Controller creating ALBs
• Target group registration
• Health check configuration
• Listener rule management

​

Secrets Manager Endpoint

• Application pods fetching database credentials
• API key retrieval
• Configuration secret access
• Certificate management

​

SSM Endpoints

• com.amazonaws.{region}.ssm - Systems Manager
• com.amazonaws.{region}.ssmmessages - Session Manager messaging
• com.amazonaws.{region}.ec2messages - SSM Agent communication

• SSH-less bastion host access
• Node troubleshooting via Session Manager
• Secure remote command execution
• Session logging and auditing

​

Private DNS

• AWS service calls automatically resolve to the VPC endpoint IP
• No application code changes required
• Services use standard AWS SDK endpoints
• Traffic stays within VPC

# This code automatically uses VPC endpoint
import boto3
s3_client = boto3.client('s3')  # Resolves to VPC endpoint, not public internet

​

VPC Flow Logs

• Source and destination IP addresses
• Source and destination ports
• Protocol
• Number of packets
• Number of bytes
• Action (ACCEPT or REJECT)
• Timestamp

• Security incident investigation
• Network troubleshooting
• Compliance auditing
• Traffic pattern analysis
• Unusual traffic detection

2 123456789012 eni-abc123 10.0.10.50 10.0.100.20 45234 5432 6 10 1024 1609459200 1609459260 ACCEPT OK

• Source: 10.0.10.50:45234 (EKS node)
• Destination: 10.0.100.20:5432 (RDS database)
• Protocol: 6 (TCP)
• Action: ACCEPT (security groups allowed)

​

Module Configuration

​

Basic Configuration (New VPC)

module "networking" {
  source = "./modules/networking"

  name_prefix = "artos-production"
  
  # VPC configuration
  vpc_cidr = "10.0.0.0/16"
  
  # Subnet configuration
  private_subnet_cidrs  = ["10.0.10.0/24", "10.0.20.0/24"]
  database_subnet_cidrs = ["10.0.100.0/24", "10.0.200.0/24"]
  
  # Enable VPC endpoints
  enable_vpc_endpoints = true
  
  tags = {
    Environment = "production"
  }
}

​

Configuration with Existing VPC

module "networking" {
  source = "./modules/networking"

  name_prefix = "artos-production"
  
  # Use existing VPC
  vpc_id   = "vpc-existing123"
  vpc_cidr = "10.0.0.0/16"  # Must match existing VPC CIDR
  
  # Use existing subnets or create new ones
  private_subnet_ids  = ["subnet-abc123", "subnet-def456"]
  database_subnet_ids = ["subnet-ghi789", "subnet-jkl012"]
  
  # Enable VPC endpoints in existing VPC
  enable_vpc_endpoints = true
  
  tags = {
    Environment = "production"
  }
}

​

Production Configuration

module "networking_production" {
  source = "./modules/networking"

  name_prefix = "artos-production"
  
  # VPC with larger CIDR for growth
  vpc_cidr = "10.0.0.0/16"
  
  # Multiple AZs for high availability
  private_subnet_cidrs  = [
    "10.0.10.0/24",   # AZ1 - 254 IPs
    "10.0.20.0/24",   # AZ2 - 254 IPs
    "10.0.30.0/24"    # AZ3 - 254 IPs
  ]
  
  database_subnet_cidrs = [
    "10.0.100.0/24",  # AZ1
    "10.0.200.0/24",  # AZ2
    "10.0.210.0/24"   # AZ3
  ]
  
  # Enable all VPC endpoints for private connectivity
  enable_vpc_endpoints = true
  
  # Additional security groups that can access EKS (e.g., bastion)
  additional_security_group_ids = [
    module.bastion.bastion_security_group_id
  ]
  
  # Bastion access to ALBs
  bastion_security_group_id = module.bastion.bastion_security_group_id
  
  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
    CostCenter  = "engineering"
  }
}

​

Development Configuration

module "networking_dev" {
  source = "./modules/networking"

  name_prefix = "artos-dev"
  
  # Smaller VPC for development
  vpc_cidr = "10.1.0.0/16"
  
  # Single AZ for development
  private_subnet_cidrs  = ["10.1.10.0/24"]
  database_subnet_cidrs = ["10.1.100.0/24"]
  
  # VPC endpoints optional for dev (can reduce costs)
  enable_vpc_endpoints = true
  
  tags = {
    Environment = "development"
    AutoShutdown = "true"
  }
}

​

Security Best Practices

​

1. Network Segmentation

• Application workloads in private subnets
• Databases in isolated database subnets
• No direct communication between tiers without security group rules

• Database subnets have no routes (local traffic only)
• Private subnets have no internet gateway route
• Each tier has dedicated route table

​

2. Security Group Rules

• Specific port ranges instead of “all ports”
• Reference security groups instead of CIDR blocks when possible
• Document each rule’s purpose in descriptions
• Regular audit of unused rules

# Good - specific and documented
ingress {
  from_port       = 5432
  to_port         = 5432
  protocol        = "tcp"
  security_groups = [aws_security_group.eks_nodes.id]
  description     = "PostgreSQL access from EKS pods only"
}

# Avoid - too permissive
ingress {
  from_port   = 0
  to_port     = 65535
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

​

3. VPC Endpoint Security

• Dedicated security group for endpoints
• Restrict access to VPC CIDR only
• Enable Private DNS for transparent access
• Monitor endpoint usage via VPC Flow Logs

​

4. Flow Log Analysis

• Rejected traffic patterns (potential attacks)
• Unusual source IPs
• Port scanning attempts
• Data exfiltration indicators

fields @timestamp, srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| stats count() by srcAddr, dstPort
| sort count desc
| limit 20

​

5. CIDR Planning

• Use RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
• Leave room for growth (don’t use /24 for entire VPC)
• Avoid overlapping CIDRs with corporate networks
• Reserve ranges for future subnets

VPC: 10.0.0.0/16 (65,536 IPs)
├── Private Subnets: 10.0.0.0/20 (4,096 IPs)
├── Database Subnets: 10.0.100.0/22 (1,024 IPs)
├── Reserved for Future: 10.0.104.0/22 (1,024 IPs)
└── Management: 10.0.255.0/24 (256 IPs)

​

Troubleshooting

​

Cannot Access AWS Services from Pods

1. Verify VPC Endpoints are Created:

aws ec2 describe-vpc-endpoints \
  --filters "Name=vpc-id,Values=<vpc-id>" \
  --query 'VpcEndpoints[*].[ServiceName,State]' \
  --output table

2. Check Endpoint Security Group:

aws ec2 describe-security-groups \
  --group-ids <endpoint-sg-id> \
  --query 'SecurityGroups[0].IpPermissions'

3. Verify Private DNS is Enabled:

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids <endpoint-id> \
  --query 'VpcEndpoints[0].PrivateDnsEnabled'
# Should return: true

4. Test from Pod:

kubectl run test-pod --image=amazon/aws-cli --rm -it -- /bin/bash
# Inside pod:
nslookup s3.amazonaws.com  # Should resolve to VPC endpoint private IP
aws s3 ls  # Should work without internet access

​

RDS Connection Failures

1. Verify Security Group Rules:

aws ec2 describe-security-groups \
  --group-ids <rds-sg-id> \
  --query 'SecurityGroups[0].IpPermissions[?ToPort==`5432`]'

2. Check if Source is EKS Nodes Security Group:

# Should show EKS nodes security group as source

3. Test Connectivity from Pod:

kubectl run -it --rm debug --image=postgres:14 --restart=Never -- \
  psql -h <rds-endpoint> -U <username> -d postgres

4. Check VPC Flow Logs:

# Look for REJECT actions on port 5432
aws logs filter-log-events \
  --log-group-name /vpc/<vpc-id>/flow-logs \
  --filter-pattern "[version, account, eni, source, destination, srcport, destport=\"5432\", protocol, packets, bytes, windowstart, windowend, action=\"REJECT\", flowlogstatus]"

​

Bastion Cannot Access EKS API

1. Verify Bastion in Additional Security Groups:

additional_security_group_ids = [
  module.bastion.bastion_security_group_id
]

2. Check EKS Security Group Ingress:

aws ec2 describe-security-groups \
  --group-ids <eks-cluster-sg> \
  --query 'SecurityGroups[0].IpPermissions[?ToPort==`443`]'

3. Verify EKS VPC Endpoint:

aws ec2 describe-vpc-endpoints \
  --filters "Name=service-name,Values=com.amazonaws.<region>.eks" \
  --query 'VpcEndpoints[0].[State,PrivateDnsEnabled]'

​

Related Modules

• EKS Module - Uses VPC and subnets for cluster deployment
• RDS Module - Uses database subnets and security groups
• Bastion Module - Deployed in private subnets with VPC endpoint access
• IAM Module - IRSA requires STS VPC endpoint