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 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 on27017only from the Lambda security group.
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:
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.