beaus-tolling

AWS Cloud Architecture

Executive Summary

The AWS design for Beaus should optimize for the lowest practical operating cost at low and medium scale, while preserving a clean scale-up path for very high event throughput and strict service-level expectations.

That means two things are true at once:

• the platform should not overspend early
• the architecture must not paint itself into a corner

Reality Check on Scale

A sustained target of 1 million trips per second is a hyperscale ingestion problem. It is not realistic to describe that as the absolute lowest-cost operating posture.

The practical design goal is:

• keep baseline cost low when traffic is modest
• separate the ingestion hot path from operator-facing transactional systems
• scale the ingestion and stream-processing plane independently when throughput spikes

This is the only credible way to align cost discipline, maintainability, and extreme-scale readiness.

Recommended Architecture

flowchart TB
  USERS["Agents, supervisors, admins, customers"] --> CF["CloudFront"]
  CF --> WAF["AWS WAF + Shield Standard"]
  WAF --> S3UI["S3 static front-end hosting"]
  WAF --> ALB["Application Load Balancer"]

  ALB --> EKS["Amazon EKS on Graviton nodes"]
  EKS --> REDIS["ElastiCache for Redis"]
  EKS --> RDS["Amazon RDS for PostgreSQL"]
  EKS --> S3DATA["Amazon S3 for evidence, exports, archives"]
  EKS --> MSK["Amazon MSK"]

  ROAD["Roadside event producers"] --> NLB["Network Load Balancer / ingest gateway"]
  NLB --> INGEST["Dedicated ingest services"]
  INGEST --> MSK

  MSK --> STREAM["Kafka consumers / stream processors"]
  STREAM --> RDS
  STREAM --> S3DATA
  STREAM --> REPORT["Report projections"]

  GH["GitHub Actions"] --> OIDC["AWS OIDC federation"]
  OIDC --> ECR["Amazon ECR"]
  OIDC --> EKS

Core AWS Services

Edge and delivery

• CloudFront for all front-end delivery
• S3 for static web assets
• AWS WAF for managed rule sets and custom protections
• Shield Standard for baseline DDoS protection

Application runtime

• EKS for the Java microservices and supporting workloads
• Graviton-based worker nodes for better price/performance
• Karpenter for elastic node provisioning and simpler scale management

Data

• RDS for PostgreSQL for transactional service databases
• ElastiCache for Redis for caching, session, rate limiting, and idempotency support
• S3 for evidence, report exports, raw trip archives, and immutable operational artifacts

Event backbone

• MSK for Kafka-based event streaming
• separate topic families and consumer groups for ingestion, business workflows, and downstream analytics

Security and operations

• KMS for encryption keys
• CloudTrail for audit
• GuardDuty and Security Hub for security monitoring
• AWS Config for control-plane visibility
• CloudWatch for logs, metrics, alarms, and dashboards

Cost-Optimized Design Principles

1. Keep front ends serverless

Angular applications should be delivered from S3 and CloudFront, not from long-running web servers.

2. Separate hot ingest from transactional services

Do not push peak trip ingest directly into PostgreSQL-backed microservices. Kafka absorbs the spike; downstream services consume and materialize only what they own.

3. Use managed services where they reduce operational drag

Managed services cost more than pure DIY in some scenarios, but they are often cheaper overall once availability, patching, staffing, and incident cost are counted.

4. Use Graviton and elastic node provisioning

Graviton instances and Karpenter-based scaling are the preferred baseline for reducing compute cost without giving up performance.

5. Minimize NAT spend

Use VPC endpoints where possible and avoid unnecessary always-on NAT footprint in non-production environments.

Performance Strategy

Agent and customer UX

Design target:

• common user actions should feel sub-second at the screen level once the session is warm
• critical APIs should generally target p95 under 300 ms inside the region

Trip ingestion

Design target:

• event ingestion is decoupled from back-office read latency
• hot-path ingestion uses horizontally scalable gateways and Kafka partitions
• downstream persistence and enrichment happen asynchronously

Availability and Release

• multi-AZ production footprint
• immutable image-based deployments
• rolling updates with readiness gates
• versioned front-end asset publishing
• environment-based approvals for production changes

Security and PII

• encrypt data at rest with KMS-backed services
• enforce TLS in transit
• classify and minimize PII
• isolate secrets in AWS-native secret stores
• avoid long-lived cloud credentials in CI by using GitHub OIDC federation

Recommended Starting Shape

Non-production

• single small EKS cluster or even ECS migration placeholder if budget is extremely constrained
• shared MSK only if event testing is needed; otherwise local Compose for engineering and minimal AWS footprint in staging
• single Redis and right-sized PostgreSQL instances

Production initial launch

• one EKS cluster, multi-AZ
• RDS PostgreSQL per service boundary or grouped by trust zone early on
• Redis primary with replica if required
• one MSK cluster sized for actual observed throughput, not hypothetical peak alone

Scale-up path

• split ingest and business processing node groups
• add dedicated MSK capacity and partition growth
• move heavy analytics and archival workloads deeper into S3-based pipelines
• scale read models separately from transactional services