Skip to main content
This page covers how SG-Infra is structured as code, and how a change gets from a commit to live infrastructure. SG-Infra deployed infrastructure. Box colour shows the deploying stack; dashed grey is owned by TalentIdPipeline-Infra-CDK.
The diagram source is the draw.io file at images/software/developer/estate/infra/sg-infra/architecture.drawio. To change the diagram, edit that source in draw.io, re-export it as PNG to architecture.png in the same folder, and commit both.

​
Overview

SG-Infra is a single TypeScript AWS CDK application. Like the legacy repo it does not deploy resources directly: it defines a self-mutating CodePipeline that deploys everything. Unlike the legacy repo it is written in TypeScript (the team standard), is sourced from GitHub, and splits the infrastructure into four separate stacks so that concerns, and especially the data volume, are isolated from each other.

​
High-Level Structure

  • The CDK app (bin/cdk_build.ts) contains the pipeline stack (SgInfraPipelineStack).
  • The pipeline stack defines the self-mutating CodePipeline (SgInfraPipeline) and points it at the GitHub repository.
  • The pipeline runs one stage, named prod, which deploys four stacks: SgInfraSecurityStack, SgInfraBackupStack, SgInfraVolumeStack and SgInfraMongoInstanceStack.
  • Every stack is tagged with Project FMP.

​
The CI/CD Pipeline

  • Source: the prod branch of the GitHub repository, connected through an AWS CodeConnections connection. This is the modern, GitHub based approach, and a key difference from the legacy repo, which is sourced from CodeCommit.
  • Synth step: changes into the CdkBuild directory, runs npm install, then npx cdk synth.
  • Self-mutation is enabled, so the pipeline updates itself before deploying the stacks.
  • Assets are published one at a time rather than in parallel.
  • A dedicated S3 artifact bucket (sg-infra-pipeline-artifacts) holds pipeline artifacts.

​
The Four Stacks and Why They Are Separated

The single prod stage deploys four stacks. Splitting them is deliberate, and is one of the main improvements over the legacy single grouping:
  • SgInfraSecurityStack looks up the shared VPC, and creates the security groups, the EC2 key pair, the MongoDB connection secret, and the SSM configuration that consumers read.
  • SgInfraBackupStack creates the versioned S3 backup bucket.
  • SgInfraVolumeStack creates the persistent EBS data volume. Keeping the volume in its own stack means the database storage has an independent lifecycle and is not torn down when the instance is replaced.
  • SgInfraMongoInstanceStack creates the EC2 instance, attaches the data volume, and provisions MongoDB. It receives the VPC, security group, key pair, secret, data volume and backup bucket from the other stacks.
CDK wires the dependencies automatically from these cross-stack references, so the stacks deploy in the correct order (security, volume and backup before the instance).

​
How a Change Reaches Production

1

Merge to prod

A change is merged to the prod branch on GitHub.
2

Pipeline triggers

The CodeConnections connection triggers the SgInfraPipeline pipeline.
3

Synth

The Synth step installs dependencies and runs cdk synth.
4

Self-mutate

The pipeline self-mutates, applying any change to the pipeline itself.
5

Deploy

The prod stage deploys the four stacks in dependency order.
As with the legacy repo, there is no manual approval gate. A merge to prod flows straight through to production infrastructure. Because this currently underpins Fleet Management Platform, changes should still be made with care.

​
Why It Is Built This Way

  • TypeScript CDK and GitHub source bring SG-Infra onto the team standard tooling, which is the main reason it exists as the go-forward pattern.
  • Separate stacks isolate the blast radius within the system. The volume in particular is isolated so that rebuilding or replacing the instance does not put the data at risk.
  • The pattern is still a single account, single region, single environment deployment. As with the legacy repo, dev and production are separate databases on the one instance rather than separate environments. For now those are just FMP_DEV and FMP_PROD, since only Fleet Management Platform uses SG-Infra so far; as more systems adopt it the instance will host many databases.

​
Key Files

Last modified on June 30, 2026