aws-limits

name	aws-limits
description	Reviews infrastructure code for AWS service quota violations. Use when reviewing Terraform, CloudFormation, CDK, Pulumi, or SDK code that provisions AWS resources.

AWS Limits Review

Goal

Catch AWS service limit/quota violations in infrastructure code before they cause production issues.

When to use

• Reviewing Terraform, CloudFormation, CDK, or Pulumi code
• Code that provisions or configures AWS resources
• PR reviews involving AWS infrastructure changes
• Before deploying infrastructure changes to production

When not to use

• Non-AWS cloud providers (future skills: cloudflare-limits, gcp-limits)
• Application code without infrastructure components
• AWS SDK usage for read-only operations

Inputs

• Infrastructure code files (.tf, .json, .yaml, .yml, .ts, .py)
• Context about expected scale/traffic patterns (if available)

Outputs

• List of potential limit violations with severity
• Links to official AWS documentation
• Recommended mitigations

Default workflow

1. Identify AWS services in the code:

   • Scan for resource types (e.g., aws_lambda_function, AWS::Lambda::Function)
   • Note service patterns in SDK calls

2. Check against known limits in REFERENCE.md:

   • Hard limits (cannot be increased)
   • Soft limits at default values
   • Limits that commonly cause production issues

3. Flag violations with context:

   • Quote the specific code
   • Explain the limit and why it matters
   • Link to AWS documentation
   • Suggest mitigation if applicable

4. Prioritize by severity:

   • Critical: Hard limits that will fail immediately
   • High: Default limits likely to be hit at moderate scale
   • Medium: Limits that may cause issues at high scale
   • Low: Informational, worth noting for awareness

Key patterns to watch

Lambda

• Functions with >15 min expected runtime (hard limit: 15 min)
• Synchronous payloads >6MB
• VPC-connected functions without sufficient ENI capacity
• High concurrency without reserved/provisioned concurrency

API Gateway

• Integrations expecting >29s response time (default timeout)
• Missing throttling configuration for public APIs
• WebSocket connections without connection management

S3

• Single-prefix designs with high throughput expectations
• Missing retry logic for 503 responses

DynamoDB

• Items approaching 400KB
• Single-table designs without GSI capacity planning
• On-demand tables without understanding burst limits

Step Functions

• Long-running workflows approaching 25,000 event limit
• Map states without concurrency limits
• Large payloads (>256KB state data)

Load Balancing

• Multiple load balancers sharing target groups (limit: 5 LBs per target group)
• Target groups with many targets without health check tuning
• Weighted routing with many target groups per action

Cognito

• Auth flows without rate limit handling (default: 120 RPS)
• Bulk user imports without throttling

Validation checklist

• All identified AWS services checked against REFERENCE.md
• Hard limits flagged as Critical
• Soft limits noted with current defaults
• Links to AWS docs included for each finding
• Mitigations suggested where applicable

Output format

## AWS Limits Review

### Critical
- **[Service]: [Limit name]**
  - File: `path/to/file.tf:42`
  - Issue: [Description]
  - Limit: [Value] ([hard/soft])
  - Docs: [AWS link]
  - Mitigation: [Suggestion]

### High
...

### Medium
...

### Low / Informational
...

### No Issues Found
- [List of services reviewed with no concerns]

Examples

Example 1: Lambda timeout

Input: Terraform defining Lambda with Step Functions integration

resource "aws_lambda_function" "processor" {
  timeout = 900  # 15 minutes
}

Output:

High: Lambda timeout at maximum

• File: lambda.tf:12
• Issue: Lambda timeout set to maximum (900s). Any operation exceeding this will fail.
• Limit: 900 seconds (hard)
• Docs: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• Mitigation: For longer processes, use Step Functions with Lambda iterations or switch to Fargate.

Example 2: Multiple LBs per target group

Input: Terraform with shared target groups

resource "aws_lb_target_group" "shared" {
  name = "shared-targets"
}

resource "aws_lb_listener" "lb1" {
  default_action {
    target_group_arn = aws_lb_target_group.shared.arn
  }
}
# ... repeated for 6 load balancers

Output:

Critical: Target group shared across too many load balancers

• File: alb.tf:15-45
• Issue: Target group "shared-targets" referenced by 6 load balancers. Maximum is 5.
• Limit: 5 load balancers per target group (hard)
• Docs: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html
• Mitigation: Create separate target groups for additional load balancers.