A marketing launch will multiply your AWS workload's traffic next month. Using Service Quotas and Trusted Advisor, how do you make sure an AWS account limit is not the thing that fails first?

## Why quotas are the classic launch failure A quota failure does not look like a capacity failure. Autoscaling quietly stops adding instances, function invocations get throttled, API calls start returning throttling errors, and the dashboards show a system that is *not* saturated. Everything looks healthy except what your customers are experiencing. That is why quota readiness is a distinct pre-launch activity rather than something a load test alone catches — unless you load test at real scale in the real Region. ## Step one: enumerate what the path consumes Walk the request path and, for each service, ask what unit it charges against a limit. Compute concurrency. Instance vCPUs by family. Load balancer targets and rules. Connections through a NAT gateway. Request rates at the API tier. Available IP addresses in each subnet — an underprovisioned subnet CIDR is effectively a quota, and it is not adjustable at all once the subnet exists. Also count the things that scale with success but sit off the request path: log ingestion, metric cardinality, queue and topic counts, tables and indexes. ## Step two: read the real numbers Service Quotas is the authoritative source. Two properties matter and both are routinely forgotten: - Quotas are **per account and per Region**. The us-east-1 value tells you nothing about eu-west-1. A multi-Region launch needs the exercise repeated per Region, and a multi-account estate per account. - Every quota has an **applied value** that may differ from the AWS default because someone raised it two years ago, and an **adjustable** flag saying whether it can move at all. Trusted Advisor's service-limit checks are a useful second view, but they cover a subset of quotas and refresh on a lag. Use them as a warning surface, not as the inventory. ## Step three: adjustable versus not For **adjustable** quotas, request the increase early through Service Quotas. The request is reviewed — sometimes automatically, sometimes by a human, sometimes routed into a support case — and lead time is measured in days, not minutes. Requesting the day before launch is how teams discover this. Ask for what you need at peak plus headroom, and be ready to explain the workload; a request for a hundredfold increase with no context attracts questions. For **non-adjustable** quotas, no amount of asking helps. These are architectural constraints: you shard across accounts, spread across Regions, or change the design so the limit is not on the critical path. Recognising early that a limit is hard is worth more than a week of negotiation. In an organisation, quota request templates let you pre-apply increases to newly created accounts, which stops every new team rediscovering the same three limits. ## Step four: make quota usage observable Service Quotas publishes usage metrics to CloudWatch in the `AWS/Usage` namespace, with the metric name `ResourceCount` and dimensions identifying the service and resource. You can alarm on usage relative to the applied quota, and the Service Quotas console will create that alarm for you for supported quotas. Trusted Advisor additionally publishes a `ServiceLimitUsage` metric in the `AWS/TrustedAdvisor` namespace. The rule is simple: anything the readiness review flagged as tight gets an alarm at a threshold well below the limit, wired to a channel a human reads. Discovering a quota at 100% during the launch is a failure of preparation, not of AWS. ## Step five: rehearse Load test in the Region and the account you will launch in, at the concurrency you expect, and watch specifically for throttling errors rather than only latency and error rate. Throttling usually surfaces as a distinct error code, and the number of teams whose load test ran in a pre-production account carrying different applied quotas is large. ## What a strong answer adds Two things. First, that headroom is not free of consequences: a very large On-Demand footprint concentrated in one Availability Zone can hit insufficient-capacity errors that have nothing to do with your account limits, so quota headroom and capacity availability are separate risks. Second, the after-action habit — record the applied values you actually needed, so the next launch starts from evidence instead of a blank page.