Skip to main content
This page describes how other systems plug into this infrastructure: the shared entry points (buckets, users, event topics) and the configuration values that downstream systems read to discover the infrastructure.

​
The Integration Surface

Beyond the VPC and the database, this repo provisions or references the shared touch points that connect the estate together:
  • S3 buckets. A timing data ingestion bucket (where timing data lands), an end of session reports bucket, and the MongoDB backups bucket. These buckets already existed and are referenced by the stack rather than created fresh, so the stack is tied to those specific bucket names.
  • IAM upload users. Two IAM users, AlphaTimingUser and RaceFacerUser, give the external timing providers permission to upload into the ingestion bucket. This is how third party timing data physically enters the estate.
  • SNS topics. A timing data topic (TalentIDTimingDataTopic) and a classification topic (TalentIDClassifyTopic). The ingestion bucket is wired so that creating an object raises an event onto the timing data topic. These topics are the event backbone that downstream TalentID processing subscribes to.
  • TalentID-API repository. The stack also references the TalentID-API CodeCommit repository.
In short: timing data flows in through the ingestion bucket, an event is published to SNS, and downstream systems react and read or write the shared database.

​
The Configuration Contract

Each stack publishes its key outputs to AWS Systems Manager Parameter Store. This is the contract that lets downstream systems find the infrastructure at deploy time without hard-coding ids. Downstream systems read these parameters when they deploy. That makes the parameter names and contents an interface: renaming or removing a key, or changing a value’s shape, can break dependent deployments. Treat them as a published contract.
SG-Infra is one of the consumers of this contract: it reads /TalentId/Infra/ConfigurationInfra to discover the shared VPC. See SG-Infra Networking, Dependencies and Configuration Contract.

​
Why It Is Built This Way

  • Publishing infrastructure ids to Parameter Store decouples downstream stacks from this one. They look up what they need at deploy time instead of carrying hard-coded values.
  • The trade-off is that the contract is implicit. There is no versioning of the parameter shapes and no automatic check that consumers still match.
  • Several referenced resources (the buckets, the users, the API repo) are pre-existing and referenced by fixed names, so the stack assumes those exact resources exist.

​
Key Files

Last modified on June 30, 2026