Skip to main content

Networking Approach

What we’re trying to fix

Networking is hard, setting up a landing zone, a VPC, 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. Although 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 one application to another if needed.

What we decided


Instead of creating a VPC in each account, we have created separate environment accounts, and have one VPC per business unit, per environment.

So we have the following environment accounts:

  • production
  • preproduction
  • test
  • development

Within these environment accounts there is a VPC per business unit. For example one VPC for the LAA, and one for HMPPS.

These VPCs are then shared via 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, for example 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.



Each VPC will have a general subnet set - a set of 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-west2c), making a total of nine subnets.

For more information on the subnet ranges, see the subnet allocation page.


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.


Access to the subnet sets is controlled with Network ACLs (NACLs).

NACLs allow traffic in and out of the Modernisation Platform (North/South), but prevent traffic from traversion 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.

Examples of some of these that you will connect to are:

  • 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.

Transit Gatway


Shared VPC Diagram

For more information on how the VPC sharing fits into the bigger networking picture, see the main networking diagram

This page was last reviewed on 1 June 2023. It needs to be reviewed again on 1 December 2023 by the page owner #modernisation-platform .
This page was set to be reviewed before 1 December 2023 by the page owner #modernisation-platform. This might mean the content is out of date.