> ## Documentation Index
> Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Networking, Dependencies and Configuration Contract

> How SG-Infra uses the shared VPC, its dependency on the legacy repo, and the configuration it publishes for consumers.

This page describes how SG-Infra connects to the network, its dependency on the legacy repo, and the configuration it publishes for the systems that use it.

## The Network Dependency

SG-Infra does not create its own VPC. Instead, its security stack reads the SSM parameter that TalentIdPipeline-Infra-CDK publishes (`/TalentId/Infra/ConfigurationInfra`), takes the VPC id from it, and looks up that shared VPC. The MongoDB instance is then placed inside it.

The consequence is that SG-Infra has a hard, if indirect, dependency on the legacy repo. Any system using SG-Infra still depends on [TalentIdPipeline-Infra-CDK](/software/developer/estate/infra/talentidpipeline-infra-cdk) for its network. Removing that dependency, by giving SG-Infra its own VPC, is the main outstanding step before it is fully self-contained.

## Security Groups

SG-Infra creates two security groups in the shared VPC:

* A Lambda security group (`smedley-group-infra-lambda-security-group`), intended for the compute of systems that use SG-Infra.
* A MongoDB security group (`smedley-group-infra-mongodb-security-group`), which allows inbound on `27017` only from the Lambda security group.

As in the legacy repo, access to the database is granted by membership of the Lambda security group rather than by IP ranges. These security groups are separate from the legacy repo's own security groups, even though they live in the same VPC.

## The Configuration Contract

SG-Infra publishes its own configuration to SSM Parameter Store so that consuming systems (currently Fleet Management Platform) can discover what they need at deploy time:

| Parameter | Contents |
| - | - |
| `/Sg/Infra/Configuration` | The VPC id and the Lambda security group id |
| `/Sg/Infra/Configuration/MongoDb` | The name of the Secrets Manager secret holding the MongoDB connection details |
| `/Sg/Infra/Configuration/MongoDb/Backup` | The backup bucket name and ARN |
| `/Sg/Infra/Configuration/Volume` | The data volume id |

A consuming system reads these parameters, then reads the named secret to get the connection string and CA certificate. This is the same decoupling pattern the legacy repo uses, and the same caution applies: the parameter names and shapes are an interface, so renaming or removing them can break consumers.

## Why It Is Built This Way

* Reusing the existing shared VPC avoided duplicating network infrastructure and let SG-Infra focus on the database. The cost is the ongoing dependency on the legacy repo, which is explicitly called out as something to remove in future.
* Publishing configuration to SSM keeps consumers decoupled from the exact resource ids. As with the legacy repo, the contract is implicit and unversioned, so changes need care.

## Key Files

| File | Role |
| - | - |
| `CdkBuild/lib/sg_infra_security_stack.ts` | Reads the legacy VPC configuration, looks up the VPC, creates the security groups, and publishes the SG-Infra configuration |
| `CdkBuild/lib/sg_infra_volume_stack.ts`, `sg_infra_backup_stack.ts` | Publish the volume and backup parameters |
| `CdkBuild/lib/sg_infra_utils.ts` | The helper that reads SSM configuration |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.