Script icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

AWS App Runner Service Active Instance Scaling Sentinel

Audits AWS App Runner active container instances and concurrency metrics to detect autoscaling saturation and notify platform teams via Slack.

Categories
CloudInfrastructure

Audits AWS App Runner regional container services for active instance exhaustion and concurrent request saturation.

How it works

  1. Triggers hourly on schedule to poll CloudWatch telemetry for AWS App Runner services.
  2. Executes a containerized Python script querying AWS/AppRunner metric namespace for ActiveInstances and Concurrency.
  3. Calculates peak instance counts and average request concurrency across a 30-minute rolling evaluation window.
  4. Evaluates if active instances reached the configured threshold or request concurrency exceeded bounds using an If condition.
  5. Dispatches an alert to Slack with the service ARN and AWS CLI update commands when autoscaling ceiling is reached.
  6. Logs nominal metrics and exports an audit manifest for audit trails.

Architecture diagram

flowchart TD
    A[Schedule Trigger: 15 * * * *] --> B[Task: evaluate_apprunner_scaling]
    B --> C{Task: check_scaling_saturation}
    C -- Threshold Breached --> D[Task: notify_slack_saturation_alert]
    C -- Nominal Operation --> E[Task: log_healthy_scaling_state]
    D --> F[Task: export_scaling_manifest]
    E --> F

What you get

  • Continuous proactive detection of App Runner container scaling limits before 504 gateway timeouts occur.
  • Automated calculation of average concurrent requests per instance and peak provisioned instance counts.
  • Immediate actionable Slack notifications including the exact AWS CLI command to bump max instance capacity.
  • Structured JSON execution audit reports exported for capacity planning and compliance archives.

Who it's for

  • Platform Engineers managing serverless container deployments on AWS App Runner.
  • Site Reliability Engineers (SREs) monitoring API availability and p99 response times.
  • Cloud Operations teams conducting quarterly infrastructure sizing and cost optimization.

Why orchestrate this with Kestra

AWS App Runner manages automatic instance scaling internally, but provides no native alert when a service reaches its configured MaxSize limit. Without external monitoring, services silently queue incoming requests when traffic surges past provisioned bounds. Kestra provides a scheduled, declarative sentinel with credential isolation, automated conditional branching, and instant multi-channel alerting without maintaining heavy monitoring servers.

Use cases

  • Production API Autoscaling Ceilings: Detect when containerized microservices hit the App Runner MaxSize instance limit during traffic spikes.
  • Noisy Neighbor Concurrency Isolation: Identify when high concurrent requests cause container queueing before requests encounter HTTP 504 gateway timeouts.
  • Platform SRE Capacity Planning: Maintain longitudinal visibility into peak instance usage across business hours to right-size minimum and maximum autoscaling configurations.

Inputs

Name Type Default Description
awsRegion STRING us-east-1 Target AWS region hosting App Runner services.
serviceArn STRING arn:aws:apprunner:... Amazon Resource Name (ARN) of the App Runner service to audit.
maxActiveInstancesThreshold INT 20 Maximum active container instance count threshold before flagging autoscaling saturation.
requestConcurrencyThreshold FLOAT 80.0 Average concurrent requests per active instance triggering scaling alerts.
slackWebhookUri SECRET None Encrypted Slack Incoming Webhook endpoint for alerting platform SRE teams.

Expected outputs

Primary execution outputs exported by export_scaling_manifest:

  • service_name: Parsed identifier of the App Runner service.
  • active_instances: Maximum active container instances recorded in the evaluation window.
  • avg_concurrency: Mean request concurrency per container instance.
  • is_saturated: Boolean flag indicating whether scaling thresholds were breached.
  • recommended_action: Exact AWS CLI command to adjust autoscaling configuration.

Example expression: {{ outputs.export_scaling_manifest.value.is_saturated }}

Prerequisites

  • An active AWS Account with deployed AWS App Runner services.
  • IAM credentials with apprunner:DescribeService and cloudwatch:GetMetricData permissions.
  • A Slack Incoming Webhook channel URL configured in Kestra secrets.

Secrets

  • AWS_ACCESS_KEY_ID: AWS IAM access key ID.
  • AWS_SECRET_ACCESS_KEY: AWS IAM secret access key.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL.

Quick start

  1. Ensure AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secrets are registered in Kestra.
  2. Deploy this flow into your target Kestra namespace.
  3. Set serviceArn to the target App Runner service ARN you wish to monitor.
  4. Execute the flow manually or allow the hourly schedule trigger to run automated checks.

Common pitfalls and troubleshooting

  • Metric Latency: App Runner CloudWatch metrics report at 1-minute to 5-minute intervals. Using an evaluation window under 10 minutes can produce incomplete readings.
  • Zero Metric Data on Inactive Services: If an App Runner service receives zero incoming requests, Concurrency metrics report empty. The Python task handles empty datasets gracefully by defaulting to zero.
  • Custom Domain vs Direct Domain: This workflow monitors container instances at the App Runner service level regardless of whether requests arrive via default domains or custom CNAME associations.

How to extend

  • Automated Scale Up: Integrate an AWS CLI task to automatically call apprunner:UpdateService and bind a higher-capacity AutoScalingConfigurationArn.
  • Multi-Service Scanning: Extend the Python script with apprunner.list_services to audit every App Runner service in the AWS region sequentially.
  • PagerDuty Escalation: Route high concurrency saturation alerts directly into PagerDuty for immediate on-call engineer paging.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.