Skip to main content

v1.9.0 — Event Pre-Scaling + Aurora Data Layer Foundation (ADR-030)

· 5 min read
AWSops Team

v1.9.0 adds event-driven pre-scaling so you can warm resources ahead of predictable spikes (sales, livestreams, quarter-close), and lays the ADR-030 Aurora data-layer foundation (CDK stack, schema, db.ts) that begins untangling build, runtime, and local JSON state from a single EC2 host. Aurora ships off by default / opt-in — existing single-host deployments are untouched.

Highlights

Event Pre-Scaling (ADR-010 Phase 1+2) · Aurora Serverless v2 Foundation (ADR-030 Phase 1) · ADR-029 Mutating Action Gate · AI Code Review Workflow · Hardened Zombie Connection Cleanup

Event Pre-Scaling (ADR-010 Phase 1+2)​

A new admin-only page at /event-scaling lets you warm resources before a large traffic event begins. The flow is four steps from registration to script download:

  1. Register the event — name, start/end window, affected resource tags
  2. Pull historical metrics — if the same event happened before, GetMetricData batches collect CloudWatch metrics for ASG, RDS, MSK, EBS, and ALB across the prior window
  3. Generate an AI warmup plan — Bedrock Sonnet 4.6 produces a multi-phase per-resource scaling plan returned as structured JSON via the PLAN_JSON marker
  4. Download bash scripts — safe, resource-typed generators emit KEDA/HPA, Aurora reader, MSK partition expansion, ASG warm pool, and EBS IOPS scripts

Review-Then-Run (mutation-by-review)​

The dashboard never executes mutating actions itself. Scripts are download-only — an operator reviews them and applies them through kubectl / aws cli from a controlled environment. This aligns with ADR-029 (Proposed): every AI-generated mutating action runs only after explicit human approval.

Files​

FileRole
src/app/event-scaling/page.tsxEvent registration · metric charts · plan display · script download (admin-only)
src/app/api/event-scaling/route.tsCRUD + metrics + Bedrock plan + scripts (GET/POST/PUT/DELETE)
src/lib/event-scaling.tsData model + JSON persistence (data/event-scaling/)
src/lib/event-scaling-prompts.tsBedrock Sonnet 4.6 prompts + PLAN_JSON parsing
src/lib/event-scaling-scripts.tsPer-resource bash script generators
src/lib/queries/event-scaling.tsCloudWatch GetMetricData + ASG/RDS/MSK/EBS/ALB state queries

Aurora Data Layer Foundation (ADR-030 Phase 1)​

The single EC2 host today runs Next.js, embedded Steampipe, the AgentCore Docker build pipeline, and the data/*.json state writer. When Docker builds run, Next.js latency spikes and Steampipe FDW queries time out. ADR-030 splits all four onto ECS Fargate workloads + Aurora app state + dual-tier ECR (Dev=Private, Prod=Public, cosign-signed). v1.9.0 lands only the Phase 1 foundation.

What ships​

ComponentDescription
infra-cdk/lib/awsops-data-stack.tsAurora Serverless v2 PostgreSQL 15.5 (0.5–4 ACU, writer + reader, KMS-encrypted, IAM auth, private subnets, rds.logical_replication=1)
infra-cdk/data/schema.sqlIdempotent 7-table schema (inventory_snapshots, cost_snapshots, agentcore_memory, agentcore_stats, alert_diagnosis, event_scaling_plans, report_schedules) + schema_migrations version tracking + touch_updated_at trigger
src/lib/db.tsApp-side pg Pool (distinct from Steampipe pool). Resolves credentials from AURORA_DATABASE_URL DSN or discrete AURORA_HOST/USER/PASSWORD/DB env vars; isAuroraEnabled() / checkDbHealth() helpers
scripts/13-deploy-aurora.shCDK deploy + Secrets Manager fetch + psql schema apply. Subcommands: deploy / schema / status / dsn

Opt-in deploy​

Default off. Activate via context flag:

cd infra-cdk
npx cdk deploy AwsopsDataStack -c enableAurora=true
# or
../scripts/13-deploy-aurora.sh deploy

The gate exists because (1) Aurora Serverless v2's 0.5-ACU floor (~$43/mo) isn't right for every environment, and (2) Phase 1 dual-write hasn't shipped yet, so actual data still lands in data/*.json.

Steampipe stays​

A subtle but important ADR-030 point: Steampipe is largely stateless. Its FDWs query AWS APIs live and hold results only in-memory — there's no on-disk "data" to lose when a container restarts. Aurora doesn't replace Steampipe; it replaces the JSON files (inventory, cost snapshots, conversation memory, alert records, event-scaling plans, report schedules) that the dashboard itself writes to local disk.

Coming next (Phase 1 dual-write)​

Seven source files will gain an Aurora write path alongside their existing JSON write. Reads continue from JSON until the 7-day parity gate clears:

  • resource-inventory.ts, cost-snapshot.ts, agentcore-memory.ts, agentcore-stats.ts, alert-knowledge.ts, event-scaling.ts, report-scheduler.ts

ADR-029: Mutating Action Framework (Proposed)​

Event pre-scaling ships as review-then-run because the gate model for ADR-010 Phase 3 (automatic execution) hasn't been settled. ADR-029 records that gate in Proposed status — under what conditions and authorization model an AI-generated mutating action becomes executable — as a prerequisite for any future Phase 3 work.

AI Code Review Workflow​

A new GitHub Actions workflow (.github/workflows/claude-review.yml) invokes Claude to automatically review pull requests when they are opened or updated. The review prompt is tuned for AWSops conventions (Steampipe pg Pool, basePath, SCP-blocked columns, etc.).

Hardened Zombie Connection Cleanup​

src/lib/steampipe.ts's zombie cleanup no longer borrows a connection from the pool. It opens a dedicated short-lived Client instead, so cleanup keeps running even when Cost Explorer / IAM-summary FDW paths exhaust the pool. The age threshold has been lowered to 90 seconds.

Stats comparison​

Itemv1.8.1v1.9.0Δ
Pages4143+2 (/event-scaling, /login recount)
API routes1819+1 (/api/event-scaling)
SQL query files2526+1 (event-scaling.ts)
ADRs28 (001-028)30 (001-030)+2 (029 Proposed, 030 Accepted)
CDK stacks3 (Awsops·Cognito·AgentCore)4+1 (AwsopsDataStack, opt-in)
Deploy steps1213+1 (13-deploy-aurora.sh)
Lib files2731+4 (event-scaling* ×3, db.ts)

References​