Platform automation engineer

AWS Artificial Server Quotas Observability Platform

AWS limits as executable checks

  • security groups per VPC
  • access keys per user

Project brief

Shipped

Problem

Important AWS limits can become operational problems before native monitoring exposes them.

Outcome

Custom checks for the AWS limits that native tooling doesn’t monitor (security groups per VPC, access keys per user) surfaced as metrics that warn before growth becomes an operational problem.

Evidence

  • Thresholds live in configuration; results flow out as metrics and alerts.
  • Around the runtime sits tooling that scaffolds new checks (discovery, analysis, generation, validation) turning “we want to govern X” into a reviewed implementation candidate.
  • Thresholds live in configuration. Results surface as CloudWatch metrics and alerts.

Key decisions

  • Handler zone: One central AWS handler owns pagination, retries, and logging, so every quota check stays a small counting function.
  • Quota zone: Account-level and resource-level checks share the same normalized return shape.
  • Output zone: Thresholds live in configuration. Results surface as CloudWatch metrics and alerts.
  • Builder zone: A separate scaffolding layer turns a new limit into a reviewed implementation candidate.

The first figure follows one scheduled check from event to alert. The second shows how a new governed limit gets scaffolded, reviewed, and added to the runtime.

How a check runs

Runtime quota execution
1Quota eventscheduler or queuetriggers a check
2Pollerresolves quota nameone entry point
3Quota classaccount or resource levelshared return shape
4AWS handlergatecentral boundarypagination, retry, logging
5Outputsmetrics · alertsCloudWatch + DynamoDB
A scheduled event becomes a quota measurement through the same five stages, whatever the limit being checked.

I built each check as a small counting function, account-level or resource-level, run through a central AWS handler that owns pagination, retries, response cleanup, and logging. Adding a new governed limit stays a small, consistent unit of work.

Handler zoneOne central AWS handler owns pagination, retries, and logging, so every quota check stays a small counting function.
Quota zoneAccount-level and resource-level checks share the same normalized return shape.

Governing a new limit

Scaffolding a new governed check
1Discoverfind the AWS limit
2Analyzeclassify the check type
3Generatescaffold the function
4Validategatereviewed before merge
Discovery, analysis, generation, and validation turn a new limit into a reviewed candidate instead of an ad hoc script.

Around the runtime sits tooling that scaffolds new checks (discovery, analysis, generation, validation), turning “we want to govern X” into a reviewed implementation candidate.

Builder zoneA separate scaffolding layer turns a new limit into a reviewed implementation candidate.

Where it surfaces

Thresholds live in configuration; results flow out as metrics and alerts.

Thresholds live in configuration. Results surface as CloudWatch metrics and alerts.

CloudWatch metrics
DynamoDB

Tooling & discipline

Portfolio graph

Hover nodes · click empty canvas to zoom/pan

Maps how the work here connects. Open the Portfolio graph →

  • Professional
  • Personal
  • Skill
  • Writing