Networking Approach
What we’re trying to fix
Networking is hard. Setting up a landing zone, VPCs, subnets, endpoints, peering, NACLS, gateways, etc, is both complex and time consuming. We want to take care of this so that users can focus on what is important to them - their application.
What we investigated
We looked into having a VPC per account. While this provides good network isolation, because we have one account per application environment, it would mean a lot of VPC peering would be required to connect applications together if needed.
What we decided
VPCs
Instead of creating a VPC in each account, we have organised the VPCs into central ‘environment’ accounts (one account per SDLC stage). Within the environment accounts there is one VPC per business unit, per environment.
So we have the following environment accounts:
- production
- preproduction
- test
- development
Within these environment accounts there is one VPC per business unit. For example within the production account there is one VPC for LAA, and one for HMPPS.
These VPCs are then shared via Resource Access Manager (RAM) to the application accounts.
For example the production LAA VPC may be shared to multiple LAA application accounts. This enables LAA applications to communicate with each other without the need for VPC peering as they are using the same VPC.
Connection to other VPCs - i.e. if an LAA application needs to communicate with a HMPPS application - is done through the Transit Gateway. NACLs can be opened to allow access, and security groups from other accounts can be referenced.
Subnets
General
Each VPC will have a general subnet set - subnets that can be used for most of the application accounts. These are shared to the application accounts using RAM.
For most business areas, the general subset set will be enough, but we can always create more subnet sets if needed.
The subnet sets contain three types of subnet:
- Public (for public resources such as load balancers)
- Private (for private resources such as application servers)
- Data (for data resources such as databases)
Each of the different subnet types are spread across all three London region availability zones (eu-west-2a, eu-west-2b, and eu-west-2c), making a total of nine subnets.
For more information on the subnet ranges, see the subnet allocation page.
Protected
Protected subnets are created per account and used for VPC endpoints. We provide the following VPC endpoints as standard, and can add additional ones as required:
- SSM Messages
- S3
- EC2
- EC2 Messages
Transit Gateway
The transit gateway subnets are created per-account to allow access to other accounts and services via the transit gateway.
NACLs
Access to the subnet sets is controlled with Network Access Control Lists (NACLs).
NACLs allow traffic in and out of the Modernisation Platform (North/South), but prevent traffic from traversing business unit VPCs (East/West).
Traffic within a VPC is not restricted.
Network Firewall
AWS Network Firewalls provide additional controls to traffic entering and exiting the Modernisation Platform.
Other VPCs
There are other VPCs in the Modernisation Platform core infrastructure accounts, these are connected to the transit gateway as well.
Some examples that you will connect to:
- network-services (where the transit gateway lives)
- shared-services
- logging
- security
Transit Gateway
The transit gateway allows us to interconnect the different VPCs to enable communication between business units. The Transit Gateway also enables connection to third parties external to the MoJ via a VPN. Routing is split into production and non production data for data protection.
Diagram
For more information on how the VPC sharing fits into the bigger networking picture, see the main networking diagram