Best Practices for Handling and Requesting AWS Service Limit Increases

Best Practices for Handling and Requesting AWS Service Limit Increases

AWS Service Limits, often referred to as quotas, are a critical component of the cloud environment. They ensure operational efficiency, prevent resource abuse, and protect users from accidentally incurring massive costs. However, poorly managed limits can lead to application throttling, scaling failures, and service unavailability.

This guide provides expert strategies for identifying potential resource bottlenecks, proactively monitoring current usage against quotas, and establishing an efficient, streamlined process for submitting limit increase requests to AWS Support. By adhering to these best practices, engineering teams can maintain high availability and support continuous growth without hitting unexpected barriers.

---

Understanding AWS Service Quotas

Before initiating any requests, it is essential to understand the nature of AWS limits. These limits are typically categorized based on resources (e.g., number of EC2 instances), throughput (e.g., IOPS), or API requests per second (RPS).

Soft Limits vs. Hard Limits

Most quotas fall into one of two categories:

• Soft Limits (Adjustable Quotas): These are the vast majority of quotas. They are default values that AWS sets for new accounts and can generally be increased by submitting a request to AWS Support, provided there is sufficient business justification.
• Hard Limits (Non-Adjustable Quotas): These limits are often dictated by physical infrastructure constraints, architectural design, or security requirements. Examples include the maximum number of VPCs per Region or the maximum size of a specific resource. Hard limits generally cannot be increased.

Tip: Always check the AWS Service Quotas console first. Limits listed there are usually soft limits and are the preferred way to submit requests.

Common Limits That Require Attention

In highly scalable environments, the following limits are often the first to be reached and should be monitored closely:

1. EC2 On-Demand Instance Count: The total number of vCPUs running across all EC2 instance types in a Region.
2. EBS Volume Count/Size: Limits on the total number or cumulative size of attached volumes.
3. VPC Resources: Limits on the number of VPCs, Internet Gateways, NAT Gateways, and Elastic IPs (EIPs).
4. API Throttling Limits: Requests Per Second (RPS) limits for services like S3, DynamoDB, or Lambda invocation rates.

Proactive Monitoring and Anticipation

Reacting to throttling is expensive and disruptive. The goal is to proactively anticipate limit breaches long before they impact production.

1. Utilizing the Service Quotas Console

The AWS Service Quotas console is the single authoritative source for viewing current quotas and tracking utilization across many services. It replaces the need to check limits across various service consoles.

Actionable Step: Regularly audit the quotas for services critical to your application (e.g., Lambda, EC2, RDS) within the Service Quotas console. Look for services where utilization is consistently above 50%.

2. Implementing CloudWatch Alarms

For critical limits, set automated alarms that notify your team when usage approaches a dangerous threshold.

Many resource metrics (like EC2 vCPU usage, Lambda concurrency) are published to CloudWatch. For quotas that are directly integrated with Service Quotas, you can create alarms directly from the Quotas console, typically setting them at 80% utilization.

# Example: Setting an 80% utilization alarm for Lambda Concurrent Executions
# (Often configured via the Service Quotas console integration or CloudFormation)

AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [Current Limit * 0.80] 
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching

3. Forecasting and Planning

Align quota management with development milestones and marketing campaigns. If a major scaling event or product launch is scheduled, calculate the maximum required capacity and submit the increase request at least two weeks in advance.

The Efficient Service Limit Increase Request Procedure

AWS prefers that limit increase requests be submitted through the Service Quotas console, as this automates routing and accelerates the approval process.

Step 1: Submitting via Service Quotas Console (Recommended)

1. Navigate to the AWS Service Quotas console.
2. Search for the specific service (e.g., 'Amazon EC2').
3. Click on the relevant quota (e.g., 'Running On-Demand All Standard Instances').
4. Click the Request increase button.
5. Specify the new desired limit and the Region.
6. Provide a detailed justification (see Step 3).

If the quota is not listed in the Service Quotas console, you must submit the request through the traditional AWS Support Center under the 'Service Limit Increase' case type.

Step 2: Key Information to Include in the Request

To prevent back-and-forth communication with AWS Support, ensure your request is comprehensive:

• AWS Region: Specify the exact Region (e.g., us-east-1) where the increase is needed.
• Specific Limit Name: Provide the precise name of the quota (e.g., number of running Fargate tasks).
• Current Limit: (Optional, but helpful) Confirm the existing limit you are hitting.
• Requested New Limit: State the exact final number you require (e.g., increase from 100 to 500).
• Business Justification: This is the most crucial element.

Step 3: Crafting a Strong Business Justification

AWS engineers require concrete evidence that the requested limit is necessary, sustainable, and accurate. Vague requests are often delayed or denied.

Do not use: "We need more resources for testing."
Do use: "We require 500 additional vCPUs (totaling 750) in eu-west-1 to accommodate a new application rollout scheduled for Q3 2024. This application utilizes ECS Fargate and is projected to handle 15,000 requests per minute, requiring 100 concurrent tasks during peak hours. We calculated the need based on extensive load testing results."

Justification Component	Example Detail
Use Case	New application launch, client onboarding, seasonal promotion, database migration.
Calculation Basis	Load test results, projected traffic growth (RPS), number of users, concurrency requirements.
Timeline	When the capacity is needed (e.g., Need capacity operational by 2024-11-01).
Duration	Is this a permanent increase or temporary spike?

Advanced Best Practices and Handling Denial

Architectural Strategies to Avoid Limits

Sometimes, increasing a limit is the right approach, but often, the bottleneck indicates an architectural inefficiency. Consider these mitigation techniques before requesting extremely large increases:

1. Implement Exponential Backoff and Jitter: Use this pattern for retrying failed API calls (especially relevant for S3 or DynamoDB limits) to prevent overwhelming the service and minimize throttling impact.
2. Optimize Batching: Consolidate multiple individual API calls into single batch operations where supported (e.g., DynamoDB BatchWriteItem).
3. Utilize Caching: Implement ElastiCache or CloudFront to reduce the number of requests hitting backend services, decreasing the probability of hitting RPS limits.

Handling Rejected Requests

If AWS rejects or significantly lowers your requested limit, it usually means the justification was insufficient, or the request exceeded safety parameters.

Action Plan for Rejection:

• Do not re-submit immediately. Review the denial reason provided by AWS Support.
• Refine the Justification: Provide more specific data points, internal metrics, and a clearer calculation methodology.
• Contact Support Directly: If the issue is urgent or complex, respond to the support case asking for an explanation and offering to schedule a call to review the architectural requirements.

Post-Increase Review

After a limit is increased, update your CloudWatch alarms to reflect the new 80% threshold. Simply getting the increase is not the end; continuous monitoring ensures you do not hit the new limit unexpectedly in the future.

Conclusion

Managing AWS Service Limits is a continuous operational task, not a one-time setup. By proactively monitoring key utilization metrics via the Service Quotas console and CloudWatch, and by providing detailed, data-driven justifications for every request, engineering teams can ensure seamless scalability. Treat the Service Limit Increase request not as a bureaucratic hurdle, but as a critical technical requirement that requires precision and foresight.