AWS account setup
  • AWS account setup
  • How to
    • How to log in to the AWS console
    • How to get credentials for working locally, e.g. the AWS CLI
    • How to select a role in the AWS CLI
    • How to get credentials for staff who aren't developers
  • Users, IAM roles, accounts, and so on
    • Introduction
    • What are our AWS accounts?
    • What is an initial role?
    • What are our standard roles?
  • Networking
    • Our VPC setup
Powered by GitBook
On this page
  • Public-facing services
  • Private services
  1. Networking

Our VPC setup

PreviousWhat are our standard roles?

Last updated 1 year ago

The design of our VPC and networking is based on .

A is an isolated network inside AWS. Within the VPC, everything can talk to everything else – the question is what can talk to the outside world.

We split our services into public-facing and private, and we create matching subnets.

Public-facing services

Public-facing services that we want to be reachable externally go into public subnets (for example, EC2 instances that we need to be able to SSH into). These connect to the Internet through an Internet Gateway, and each resource will have its own external IP address.

The services can connect out to the Internet, and the Internet can connect back in.

Private services

Private services that we don't want to be reachable externally go into private subnets (for example, data pipelines).

These can connect out to the public Internet through a NAT Gateway, but the Internet can't connect back in.

The NAT Gateway is associated with a fixed Elastic IP address, which means that all requests coming from our private services will come from a single IP address.

Practical VPC Design
VPC (virtual private cloud)