service

Platform Infrastructure

Owns the shared foundation every RIO service depends on - the EventBridge bus, RDS PostgreSQL, Valkey cache, the ECS cluster and per-service credentials.

Service

Service Overview

rio-infra is not an application — it is the CloudFormation stack that creates the things every other service assumes already exist. It is listed as a service here because it owns the event bus, and that ownership is otherwise invisible in the catalog.

It creates the one and only event bus

The RIO Events Bus is declared here, once:

RioEventBus: # infrastructure/template.yaml:328-331
Name: !Sub "${Environment}-rio-events"

and exported as the stack output RioEventBusName (template.yaml:508).

Every other service stack takes the bus name as an EventBusName parameter. No repository in the platform declares a second AWS::Events::EventBus — so if you are wondering whether some service has its own private bus, it does not.

One template default looks like an exception but is not: rio-commit-service defaults its EventBusName parameter to rio-commit-events. That default is dead config — samconfig.tmpl overrides it to {env}-rio-events in dev, qa and prod alike. Every service really does use this one bus. See Commit Service.

Its own rules listen to AWS, not to RIO

There are no rules on RioEventBus in this repository, and no rio.* source or Title Case detail-type appears anywhere in it. The bus is created here and used elsewhere. Its own three rules target the AWS default bus or a schedule:

RuleBusPatternTarget
RioEcsEventCaptureRule (template.yaml:361-372)defaultsource: aws.ecs (all detail-types)CloudWatch Logs, 7-day retention
RDSEventRule (template.yaml:401-419)defaultsource: aws.rds, detail-type: RDS DB Instance Event, filtered to this instance and the availability / configuration change / failover / recovery / maintenance categories${DeployPrefix}-update-tg-ip Lambda
ScheduledHealthCheck (template.yaml:442-448)rate(5 minutes)${DeployPrefix}-ch-health-monitor Lambda

The RDS rule exists to solve a specific problem: RDS endpoints resolve to IPs that change on failover, so a Lambda re-registers the current IP into a load-balancer target group whenever RDS reports an event.

What else it provisions

  • RDS — PostgreSQL 18.3 with a custom parameter group, plus an RDS Proxy and target group.
  • ElastiCache — Valkey 8.2, encrypted at rest and in transit.
  • ECS — the cluster, named ${Environment}-rio.
  • Secrets Manager — nine secrets: proxy read-only and read-write, plus dedicated DB credentials for rio_identity_service, rio_commit_service, rio_audit_service, rio_platform_notification_service, rio_ingestion_service, rio_opportunity_service and rio_activity_service. Note that last one — the credentials are named for the activity service, which is another sign the rio-deal-desk repo is really the activity service.
  • SSM Parameter Store — SecureStrings for the Valkey auth token, DB passwords, the ClickHouse users, a security salt, the Actian master password, the activity OAuth state secret and the Google Chat webhook.
  • S3${DeployPrefix}-config-bucket, all public access blocked.
  • CloudWatch Logs — the ECS event log group plus a resource policy letting EventBridge write to it.

Outside CloudFormation, a Helmfile deploys ClickHouse (Bitnami chart, 1 shard / 1 replica, 100 Gi) and an HAProxy tcp-forwarder exposing Postgres 5432 and Valkey 6379 into the EKS rio namespace.

What it does not have

Worth stating explicitly, because these are things people expect to find in an infra repo:

  • No SQS queues and no DLQs. The only DLQs in the platform belong to rio-platform-notification-service.
  • No EventBridge Schema Registry, no archives, no replay configuration.
  • No event naming-convention doc. Those rules live in this catalog repo, at .claude/rules/eventbridge.md.
Event-driven architecture documentation: RIO