aws-ui-ssm-access-lambda
TypeScript AWS Lambda that lets CloudFront-hosted SPAs securely read AWS SSM Parameter Store values (including SecureStrings) over a Lambda Function URL via the Parameters-and-Secrets Lambda extension.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | typescript |
| Frameworks | AWS Lambda, webpack 5, Jest 29 |
| Runtimes | nodejs |
| Tests / CI | some / CI in place |
| Last commit | 2025-11-18 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest |
| Source | Open in Azure DevOps |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
aws-ui-ssm-access-lambda
Purpose
A single-handler Lambda that acts as a secure bridge between CloudFront-hosted single-page applications and AWS SSM Parameter Store. The SPA calls a Lambda Function URL with a parameterpath query string; the handler proxies the lookup through the AWS Parameters-and-Secrets Lambda extension (localhost:2773), re-fetching with decryption when the parameter is a SecureString, and maps SSM errors to 401/404/500 responses so no credentials reach the frontend.
Tech stack
TypeScript 5 on Node.js (pipeline builds on Node 20.x; the sample Terraform pins nodejs18.x), bundled with webpack 5 plus zip-webpack-plugin into a deployable zip. Handles both API Gateway v1 and v2 event shapes plus raw Function URL events. Structured logging via the internal @tc/tc-logging npm package; ESLint 9, Prettier and Jest/ts-jest tooling.
Deployment
No classic release pipelines (release_count 0); in scope via the build-YAML/AWS trace (build->yaml-deploy, build pipeline aws-ui-ssm-access-lambda). The in-repo azure-pipelines.yaml uses the shared InternalOSS/azure-pipelines-templates ci.yml (release/v1.0): a Node 20.x build stage, then a lambdas stage that packages the zip into the tc-devops-artifacts S3 bucket, with useTFVarsDeployment: true, awsFunctionalArea: devops and ecsTerraformRepo: aws-devops-tc-apps — the actual Terraform lives in that separate DevOps repo, with only an example definition (temp-tf-definition.md) checked in here.
Dependencies
One runtime dependency: the internal @tc/tc-logging npm package (no corresponding repo in the included estate list). Everything else is dev tooling. External services: AWS Lambda, the Parameters-and-Secrets extension, SSM Parameter Store, and CloudFront/Lambda Function URLs as the invocation path.
Data stores
None owned. Reads AWS SSM Parameter Store (per-app parameter paths, IAM-scoped) but stores nothing itself.
Integration points
Inbound HTTP GET via a Lambda Function URL fronted by CloudFront; outbound HTTP to the local Lambda extension for SSM reads. No estate APIs, buses or databases.
Code health
Small, focused codebase (one ~370-line handler) with a Jest unit-test file and mocked logging, lint/format tooling and a genuinely good README (Mermaid architecture and sequence diagrams, IAM examples, troubleshooting). Some leftover debug logging and duplicated v1/v2 event-parsing branches in the handler. Last commit 2025-11-18.
Modernisation risks
Low — modern TypeScript on a current Node runtime with tests and YAML CI. Watchpoints: the example Terraform grants a Function URL with authorization_type = "NONE" (access control depends entirely on CloudFront and IAM parameter scoping, which the real Terraform in aws-devops-tc-apps must get right), the Node runtime version is pinned outside this repo, and exposing SecureString values to browser clients means any IAM-policy widening leaks secrets to the frontend.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. Only AWS SSM access tooling; no data store packages or configuration found.