Network Considerations

Network Considerations for VPC CIDR Selection

Overview

When deploying the Trusst platform into your AWS environment, one of the key infrastructure decisions is selecting the appropriate VPC (Virtual Private Cloud) CIDR block. This document provides guidance to help you choose between using our default VPC CIDR configuration or specifying a custom CIDR block that aligns with your existing network architecture.

Default VPC CIDR Configuration

Default Settings

  • Primary CIDR Block: 10.60.0.0/20 (4,096 IP addresses)

  • Availability Zones: 2 (configurable)

  • NAT Gateways: 1 (configurable, max 1 per AZ)

  • Subnet Configuration (per AZ):

    • Public Subnets: /24 (256 IPs per subnet)

    • Private Subnets with Egress: /24 (256 IPs per subnet)

    • Isolated Subnets (Database): /27 (32 IPs per subnet)

Subnet Allocation Example (Default)

With the default 10.60.0.0/20 CIDR:

  • Public Subnets: 10.60.0.0/24, 10.60.1.0/24

  • Private Subnets: 10.60.2.0/24, 10.60.3.0/24

  • Isolated Subnets: 10.60.4.0/27, 10.60.4.32/27

When to Use Default Configuration

The default configuration is suitable when:

  • ✅ Greenfield Deployment: You're deploying Trusst in a new AWS account with no existing infrastructure

  • ✅ No IP Conflicts: The 10.60.0.0/20 range doesn't conflict with your existing networks

  • ✅ Isolated Environment: The Trusst platform will operate independently without complex connectivity requirements

  • ✅ Proof of Concept: You're evaluating the platform and don't need integration with existing systems

  • ✅ Standard Workloads: Your expected usage aligns with typical Trusst deployments

Advantages of Default Configuration

  • Quick deployment with no additional network planning required

  • Pre-optimized subnet sizing for typical Trusst workloads

  • Avoids common CIDR ranges (10.0.0.0/16, 172.31.0.0/16) to reduce conflict probability

  • Tested configuration ensuring all components communicate properly

  • Efficient IP allocation with room for growth

Custom VPC CIDR Configuration

When to Use Custom Configuration

You should specify a custom CIDR block when:

  • ⚠️ IP Range Conflicts: The default 10.60.0.0/20 overlaps with existing infrastructure

  • ⚠️ VPC Peering Required: You plan to establish VPC peering connections with other VPCs

  • ⚠️ Transit Gateway Integration: You're using AWS Transit Gateway for inter-VPC routing

  • ⚠️ VPN Connectivity: You need Site-to-Site VPN or Client VPN connections

  • ⚠️ Direct Connect: You're using AWS Direct Connect to your on-premises network

  • ⚠️ Compliance Requirements: Your organization mandates specific IP ranges for different environments

  • ⚠️ Large Scale Deployment: You need more than 4,096 IP addresses

CIDR Block Requirements

Minimum Requirements

  • Minimum Size: /20 (4,096 IP addresses)

  • Maximum Size: /16 (65,536 IP addresses) for future growth

  • Required Subnets: 6 subnets across 2 AZs (3 subnet types per AZ)

CIDR Block Conflicts to Avoid

  1. Common AWS Default Ranges

    • 172.31.0.0/16 - AWS default VPC

    • 10.0.0.0/16 - Commonly used in tutorials

    • 10.60.0.0/20 - Trusst default (if using custom)

  2. On-Premises Networks

    • Typical corporate ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

    • Check with your network team for reserved ranges

  3. Partner/Vendor Networks

    • If connecting to external services via VPN or Direct Connect

    • Common SaaS provider ranges that may conflict

Network Architecture Details

Subnet Types and Usage

  1. Public Subnets (/24 per AZ)

    • Application Load Balancers (ALB)

    • NAT Gateways

    • Bastion hosts (if required)

    • Internet-facing services

  2. Private Subnets with Egress (/24 per AZ)

    • ECS Fargate tasks

    • Lambda functions (if VPC-attached)

    • EC2 instances (GPU servers)

    • VPC Endpoints (ECR, CloudWatch, Secrets Manager)

  3. Isolated Subnets (/27 per AZ)

    • Aurora RDS clusters

    • No direct internet access

    • Database security isolation

VPC Endpoints (Cost Optimization)

The infrastructure automatically creates VPC endpoints for:

  • S3 (Gateway endpoint) - No data transfer charges

  • ECR (Interface endpoint) - Container image pulls

  • CloudWatch Logs (Interface endpoint) - Log streaming

  • Secrets Manager (Interface endpoint) - Secure credential access

These endpoints reduce NAT gateway costs and improve security by keeping traffic within AWS's network.

Security Groups

Three security groups are automatically created:

  1. ECS Security Group - For containerized services

  2. Aurora Security Group - For database access (port 5432)

  3. GPU Security Group - For GPU-accelerated transcription services

IP Address Consumption

Typical IP Usage for Standard Deployment

Component
IP Count
Notes

ECS Tasks

20-50

Scales with load, each task gets an IP

RDS Aurora

2-4

Primary + read replicas

ALB

2-4

2 per AZ minimum

NAT Gateways

1-2

1 per AZ (configurable)

VPC Endpoints

6-12

2-4 per interface endpoint

Reserved AWS IPs

10

First 4 and last 1 IP per subnet

Total Active

~50-100

Normal operations

Growth Buffer

30-50%

Recommended reserve

Scaling Considerations

  • High Volume: 100+ concurrent calls may require 100+ ECS task IPs

  • Multi-Region: Each region needs its own VPC and CIDR

  • Disaster Recovery: Consider DR site CIDR requirements

Decision Matrix

Consideration

Default CIDR (10.60.0.0/20)

Custom CIDR

Deployment Speed

✅ Immediate

⏱️ Requires planning

IP Capacity

✅ 4,096 IPs

🔧 Configurable

Conflict Risk

✅ Low (uncommon range)

✅ Eliminated with planning

Network Integration

⚠️ Check for conflicts

✅ Full flexibility

Configuration Complexity

✅ Simple

⚠️ Requires expertise

Future Connectivity

⚠️ May conflict

✅ Future-proof

Recommended Custom CIDR Ranges

If the default 10.60.0.0/20 conflicts with your infrastructure, consider:

For Production Environments

  • 10.64.0.0/20 - Next logical range if 10.60 conflicts

  • 10.100.0.0/20 - Good isolation from common ranges

  • 172.20.0.0/20 - Alternative if 10.x.x.x is heavily used

  • 100.64.0.0/20 - RFC 6598 space (verify ISP compatibility)

For Development/Testing

  • 10.200.0.0/20 - Clear separation from production

  • 172.25.0.0/20 - Isolated development range

  • 192.168.64.0/20 - Small environments (if within private range)

For Large Scale Deployments

  • 10.60.0.0/16 - Full /16 for maximum growth (65,536 IPs)

  • 10.128.0.0/16 - Alternative large range

  • 172.24.0.0/16 - If 10.x.x.x unavailable

Configuration Parameters

When deploying with CDK, you can customize:

{
  maxAzs: 2,              // Number of Availability Zones (2-3 recommended)
  cidr: '10.60.0.0/20',   // Your chosen CIDR block
  natGateways: true,      // Enable NAT gateways
  natGatewayCount: 1      // Number of NAT gateways (1-2 typical)
}

Integration Scenarios

Scenario 1: Standalone Deployment

  • Recommendation: Use default 10.60.0.0/20

  • Rationale: Uncommon range, unlikely to conflict

Scenario 2: Integration with Corporate Network

  • Recommendation: Custom CIDR coordinated with network team

  • Example Process:

    1. Document existing CIDR blocks

    2. Identify available /20 or larger range

    3. Plan VPN/Direct Connect routing

    4. Update CDK configuration

Scenario 3: Multi-Region Deployment

  • Recommendation: Regional CIDR strategy

  • Example:

    • US-East-1: 10.60.0.0/20

    • US-West-2: 10.61.0.0/20

    • EU-West-1: 10.62.0.0/20

Scenario 4: High Availability Requirements

  • Recommendation: Increase NAT gateway count

  • Configuration:

    • Set natGatewayCount: 2 for redundancy

    • Consider 3 AZs for maximum availability

Pre-Deployment Checklist

Before finalizing your CIDR decision:

Migration Considerations

Changing CIDR Post-Deployment

⚠️ Critical Warning: Changing the VPC CIDR after deployment requires:

  • Complete infrastructure teardown and rebuild

  • Database backup and restoration

  • DNS and certificate updates

  • Application reconfiguration

  • Service downtime (hours to days)

  • Data migration complexity

Strong Recommendation: Invest time upfront to select the correct CIDR. The cost of migration far exceeds the planning effort.

Troubleshooting Guide

Common Issues and Solutions

Issue
Symptom
Solution

CIDR Overlap

VPC peering fails

Use custom non-overlapping CIDR

IP Exhaustion

ECS tasks fail to start

Use larger CIDR (/16 or /18)

Route Conflicts

VPN connectivity issues

Adjust CIDR or routing tables

NAT Gateway Costs

High AWS bills

Verify VPC endpoints are working

Support and Assistance

Information to Provide Trusst Support

When requesting CIDR guidance, please provide:

  1. Current Network Map:

    Production VPC: 10.0.0.0/16
Development VPC: 10.1.0.0/16
On-Premises: 192.168.0.0/16

  2. Connectivity Requirements:

    • VPC peering needs

    • VPN/Direct Connect status

    • Internet egress requirements

  3. Scale Projections:

    • Expected concurrent users

    • Call volume estimates

    • Growth timeline

Frequently Asked Questions

Q: Why doesn't Trusst use the default AWS VPC? A: We require a custom VPC for security isolation, specific subnet configuration, and VPC endpoint optimization.

Q: Can I change the subnet sizes? A: Subnet masks are optimized for the platform. Modifications require custom CDK changes and may impact scalability.

Q: Is 10.60.0.0/20 always safe to use? A: While uncommon, always verify against your network documentation. Some organizations reserve entire 10.x ranges.

Q: Can I use a smaller than /20 CIDR? A: Not recommended. The platform requires minimum 4,096 IPs for proper operation and growth.

Q: Do I need public subnets if not internet-facing? A: Yes, ALBs and NAT gateways require public subnets even for internal-only deployments.

Conclusion

The VPC CIDR selection impacts:

  • ✅ Network connectivity and integration options

  • ✅ Platform scalability and growth potential

  • ✅ Operational complexity and maintenance

  • ✅ Future architectural flexibility

Default Choice (10.60.0.0/20): Suitable for most deployments with its uncommon range reducing conflict probability while providing adequate capacity.

Custom CIDR: Required when the default conflicts with existing infrastructure or when specific network architecture demands it.

Key Takeaway: Time invested in CIDR planning prevents costly migrations. When in doubt, document your existing network thoroughly and choose a custom CIDR that guarantees no conflicts.

For additional assistance with network planning or custom CIDR configuration, please visit Trusst's Customer Portal with your network documentation ready.

PreviousTrusst AI ArchitectureNextAdvocating for Responsible AI

Last updated