# 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:

```typescript
{
  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:

* [ ] **Check default compatibility**: Verify `10.60.0.0/20` doesn't conflict
* [ ] **Inventory existing networks** (on-premises and cloud)
* [ ] **Document all VPCs** in your AWS accounts
* [ ] **Review VPN routes** if applicable
* [ ] **Check Direct Connect** virtual interfaces (VIFs)
* [ ] **Plan for growth** (4,096 IPs usually sufficient)
* [ ] **Consider DR requirements** for business continuity
* [ ] **Document decision** for future reference

### 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*](https://customer.support.trusst.ai) *with your network documentation ready.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.trusst.ai/product-guides/network-considerations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.