Split the VPC into tiers
- Web: the container visitors reach, with Access open to the internet.
- App: APIs and background workers, with Access set to inside the VPC only. Turn on the Invoker token too if only certain callers should reach it.
- Data: databases with the public endpoint turned off. Apps reach them at
server-name.internal.
Tag services, then write rules by tag
In VPC > Security groups, give each service a tag for its role, such as web, api or db. Then make a group for each tier that opens only the port it needs: web to api on 8080, and api to db on 5432. Rules only allow; whatever no rule names stays closed.
New services join the Default group, where they reach each other on every port. For production, once each service has its own group, take it out of the Default group, so a problem in one service can’t reach everything else.
A fixed outgoing IP only where it’s needed
If a bank or partner allowlists your IP, create a NAT Gateway and send only the app tier’s subnet through it (see NAT Gateway). Other subnets keep the shared outgoing IP at no extra cost.
Working on a production database from your computer
Turn on the public endpoint only while you need it, allow only your own IP, and turn it off again afterwards. Connections always use TLS.
Joining projects
- Peer production with shared tools, not with testing. Give testing its own copy of what it needs.
- Peering opens nothing on its own. After both sides accept, add a security group rule that names the peered VPC or a group it shares (see Security groups and VPC peering).
- Peering joins two VPCs in one region and isn’t transitive: if A peers with B and B with C, A still can’t reach C. For three or more projects, or across regions, use a Network Hub.
Many projects, offices or regions: a Star hub with a firewall
- Create the hub in the shared-tools project and make that project the Center: databases, monitoring and internal APIs every team uses live there.
- Attach each production project as an Edge. Edges reach the center but not each other, so a problem in one project can’t spread to the next.
- Bring offices in with a Site-to-Site VPN gateway and staff with a Client-to-Site one, instead of opening databases to the internet (see VPN Gateway).
- Add a firewall to the hub: Between spokes allows only the connections you expect, and To the internet sends every project out from the same fixed IPs, with one place to control them (see Firewall on a Network Hub).
- Keep testing off the production hub. If testing needs a hub, give it its own.
- Security groups still apply in every VPC: the hub and the firewall let a connection reach the VPC, and the service’s security group must allow it too.