Centralised VPC Endpoints
The Modernisation Platform runs a centralised VPC endpoints hub in the core network services account. This is a dedicated VPC containing interface endpoints for a wide range of AWS services, shared to consumer accounts rather than duplicated in each VPC.
The hub currently serves isolated network accounts only. If your account uses the standard shared VPC model, see using endpoints in a standard account below.
Why we do this
Interface endpoints are charged per endpoint, per availability zone, per hour. Creating an endpoint for every service in every VPC duplicates that cost, and repeats the same DNS and routing configuration in each place.
Isolated network accounts build their own VPC and do not have the shared protected subnets that standard accounts get, so without a central hub each one would need its own full set of endpoints. Running one curated set centrally and reaching it over the Transit Gateway means many more services can be offered than would otherwise be practical.
This approach is described in ADR 0045. That ADR is currently marked Proposed, and migration of existing endpoint-per-VPC deployments is a separate, phased activity.
Who it serves
Consumer accounts are listed explicitly in vpc-endpoints.tf. At the time of writing these are Cloud Platform and Container Platform accounts - the MoJ hosting platforms that run on top of the Modernisation Platform using the isolated network option.
Please check the Terraform for the current list rather than relying on this page.
How to use it
Access is not automatic. A consumer account needs to:
- Accept the AWS Resource Access Manager (RAM) share for the
centralised-endpointsRoute53 Profile. - Associate that shared Route53 Profile with the VPCs that need to resolve the endpoint service names.
Once associated, DNS for the supported services resolves to the central endpoints, and traffic routes over the Transit Gateway.
The hub VPC uses the range 10.20.240.0/20, as recorded in the CIDR allocation register. Return routes are propagated into the hub’s Transit Gateway route table so responses can find their way back.
Available services
The current list is maintained in centralised-vpc-endpoints.json. At the time of writing it covers:
apigateway, athena, backup, cloudtrail, config, detective, dms, ec2, ec2messages, ecr.api, ecr.dkr, eks, eks-auth, elasticache, email, email-smtp, events, guardduty-data, inspector2, kinesis-firehose, kms, lambda, logs, rds, rds-data, secretsmanager, securityhub, sns, sqs, ssm, ssmmessages, sts, transcribe, wafv2
Again, please check the JSON file for the current list rather than relying on this page.
Using endpoints in a standard account
If your account uses the standard shared VPC model, you are not onboarded to the hub.
Your VPC already has interface endpoints for EC2, EC2 Messages, SSM and SSM Messages in its protected subnets, plus a gateway endpoint for S3.
If you need an endpoint for another AWS service, we can add it to your VPC using the additional_endpoints option in the environments-networks JSON. See environments-networks json explained.
If you think the centralised hub would be a better fit for your use case, please raise it in #ask-modernisation-platform.