AI Cloud Networking and VPC Design

Most cloud networks were not designed; they were grown. A team needed a service, somebody clicked through the VPC wizard, the wizard produced a default VPC with three subnets, and the service launched. The next service joined the same VPC because that was the path of least resistance, even though its security profile was different. The third service got its own VPC because somebody felt strongly about isolation, but the VPC peering was set up haphazardly. The fourth service got load balancers configured by hand. By the time the team is operating five services, the network is a tangle of historical decisions that nobody has the context to redesign, and every new service joins by analogy to whichever existing service looks closest.

Network architecture deserves the same design discipline as any other architecture decision. The CIDR ranges should not collide with future expansions. Public and private subnets should be separated deliberately, not because the wizard split them. DNS, load balancing, and firewall rules should follow patterns the team has agreed to rather than be improvised per service. The discipline is what prevents the tangle, and the discipline is what /forge-network is built to apply: CIDR planning, subnet strategy, DNS configuration, load balancer setup, and firewall rules with least privilege, with documentation per decision.

Why generalist AI ships permissive networks

Ask Cursor or ChatGPT for a VPC. You get a default VPC, three public subnets, a security group that allows 0.0.0.0/0 on port 80 and 443. The result works. It also has no private subnet for the database, no NAT gateway for outbound traffic from private instances, no thought to CIDR ranges, and a security group that exposes ports the application does not need to expose. The network is technically functional and operationally bad, and a generalist tool cannot tell the difference because it cannot see the topology context.

The other failure mode is the missing CIDR plan. CIDR ranges that overlap with existing networks (the company VPN, another VPC the team will peer with later) are a known long-tail incident waiting to happen. A generic 10.0.0.0/16 looks fine until two VPCs need to peer and they both use the same range. The fix is a CIDR plan that anticipates the topology: company-wide ranges allocated, environments separated, regions separated. Most teams do not have this and discover it the day they need to peer two VPCs. /forge-network is built to produce the plan, not just the per-VPC config.

What network design actually requires

A useful network design has five parts. First, the CIDR plan: ranges allocated to regions, environments, and services, with explicit non-overlap so future peering and expansion work without renumbering. Second, the subnet strategy: public subnets for resources that need internet access (load balancers, NAT gateways), private subnets for application instances and databases, with availability-zone diversity for redundancy. Third, the DNS layout: private hosted zones for service-to-service discovery, public hosted zones for customer-facing endpoints, with sensible TTLs and health checks. Fourth, the load balancer setup: SSL termination at the edge, health checks calibrated to the application's startup time and the service's actual readiness signal, target groups scoped per service. Fifth, the firewall rules: least-privilege ingress (only ports the service needs), least-privilege egress (only destinations the service legitimately calls), with rules grouped by service rather than dumped into a single security group.

Each part has trade-offs. A CIDR plan that is too generous wastes address space; one that is too tight leaves no room for growth. Public subnets that are too permissive expose more than necessary; subnets that are too restrictive force NAT routing that adds latency and cost. Health checks that are too aggressive flap on routine deploys; checks that are too lenient leave broken instances in service. The discipline is to make these trade-offs deliberately rather than inherit them from a wizard.

How /forge-network works

Step one: CIDR planning

When invoked, /forge-network asks for the topology context: how many regions are in scope, how many environments (dev, staging, prod, disaster recovery), what existing networks the design needs to coexist with (company VPN, partner VPCs). The output is a CIDR plan with non-overlapping ranges allocated per region per environment, with documentation showing which ranges are reserved for what.

Step two: subnets and routing

Each VPC is broken into public, private, and isolated subnets across multiple availability zones. Route tables are configured deliberately: public subnets route to the Internet Gateway, private subnets route through NAT gateways for outbound, isolated subnets have no internet route (databases, internal services). NACLs add a second layer of protection at the subnet level. The setup is documented per subnet so the next person to join the network knows where new resources should land.

Step three: DNS and load balancing

Private hosted zones in Route53 (or equivalent) handle service-to-service DNS so services call each other by name rather than by IP. Public hosted zones handle customer-facing endpoints with sensible TTLs (long enough to absorb traffic, short enough to support failover). Load balancers are configured per service with SSL termination at the edge, target groups scoped per service, and health checks that match the service's actual readiness endpoint with the right timeout calibrated to the application's startup time.

Step four: firewall rules with least privilege

Security groups are designed per service with explicit ingress and egress rules. Ingress lists the specific ports the service needs to receive traffic on and the specific source security groups (the load balancer security group, the bastion security group, peers from the same VPC). Egress lists the specific destinations the service needs to call (database security group, external API endpoints, the NAT gateway for general outbound). Wildcards are flagged and require explicit override with a documented reason.

Tonone's /forge-network skill designs cloud networking deliberately: CIDR planning, public/private/isolated subnet strategy, DNS, load balancers, and least-privilege firewall rules with per-decision documentation.

When to use /forge-network, and when not to

/forge-network is the right call when setting up network architecture for a new environment, when redesigning an existing VPC that has outgrown its original setup, when configuring multi-region deployment, or when an existing network config is functional but undocumented and the team wants to understand and improve it.

Skip the skill for incremental network changes inside an existing well-designed VPC (a regular IaC edit). For broader infrastructure provisioning that consumes the network, /forge-infra is the right call. For cost optimization on networking specifically (NAT gateway consolidation, region transfer), /forge-cost is calibrated to that work.

A worked example: VPC for a SaaS in two regions

Suppose the brief is: design VPCs for a SaaS in us-east-1 (primary) and eu-west-1 (DR + EU customers). Run /forge-network.

# CIDR plan
# Reserved company-wide: 10.0.0.0/8
#   us-east-1 prod:  10.10.0.0/16
#   us-east-1 stg:   10.11.0.0/16
#   eu-west-1 prod:  10.20.0.0/16
#   eu-west-1 stg:   10.21.0.0/16
#   Future regions:  10.30.0.0/16+
#   Reserved for VPN: 10.99.0.0/16

# us-east-1 prod VPC subnets (10.10.0.0/16)
resource "aws_subnet" "public" {
  for_each = { a = 0, b = 1, c = 2 }
  vpc_id   = aws_vpc.main.id
  cidr_block = "10.10.${each.value + 1}.0/24"
  availability_zone = "us-east-1${each.key}"
  map_public_ip_on_launch = true
}

resource "aws_subnet" "private_app" {
  for_each = { a = 0, b = 1, c = 2 }
  vpc_id   = aws_vpc.main.id
  cidr_block = "10.10.${each.value + 11}.0/24"
  availability_zone = "us-east-1${each.key}"
}

resource "aws_subnet" "isolated_db" {
  for_each = { a = 0, b = 1, c = 2 }
  vpc_id   = aws_vpc.main.id
  cidr_block = "10.10.${each.value + 21}.0/24"
  availability_zone = "us-east-1${each.key}"
  # No route to internet; only intra-VPC and to peered networks.
}

# Per-service security group (api)
resource "aws_security_group" "api" {
  vpc_id = aws_vpc.main.id
  ingress {
    from_port = 8080
    to_port = 8080
    protocol = "tcp"
    security_groups = [aws_security_group.alb.id]
    description = "From ALB only"
  }
  egress {
    from_port = 5432
    to_port = 5432
    protocol = "tcp"
    security_groups = [aws_security_group.db.id]
    description = "To Postgres in isolated subnet"
  }
  egress {
    from_port = 443
    to_port = 443
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
    description = "HTTPS to external services (Stripe, etc.)"
  }
  # No other egress allowed.
}

Two regions, deliberate CIDR allocation, three-tier subnet split, scoped security groups. Future regions slot in without renumbering. Future services join the same VPC with their own security groups rather than reusing a permissive one. Documentation lives next to the resources so the next person to join the network does not have to reconstruct the design from scratch.

Related skills

/forge-network covers networking. For broader infrastructure provisioning, /forge-infra is the entry point. For cost optimization on networking specifically, /forge-cost includes data transfer and NAT analysis. For diagnosing network-related runtime issues, /forge-diagnose is the right call.

Install

/forge-network ships with the Forge agent in the Tonone for Claude Code package. Install Tonone, invoke /forge-network from any Claude Code session, and the skill produces network architecture calibrated to the project's region and environment topology.

Networks designed deliberately are the ones that survive the second region, the third VPC, and the customer demand for VPN access. The skill is built so the discipline applies on day one.