AWS Cloud Practitioner Study Notes · Part 47
Amazon CloudWatch Hard and Soft Limits
AWS Cloud Practitioner study notes explaining CloudWatch adjustable quotas, hard limits, alarm actions, metrics, dashboards, and CloudWatch Logs filters.
Amazon CloudWatch has service quotas and functional limits. The key exam skill is knowing what to do when a limit is reached:
Adjustable quota
→ Request an increase through Service Quotas or AWS Support
Hard limit
→ Cannot be increased by a customer
→ Redesign, split, aggregate, or use another featureThis is Part 47 of the AWS Cloud Practitioner Study Notes. AWS changes service quotas over time and the quota can vary by Region or account, so use the current CloudWatch service-quota page as the authority for an actual deployment.
What is a soft limit?
In AWS terminology, an adjustable service quota is often called a soft limit. It is a default quota that AWS may increase after you submit a request.
Current CloudWatch alarm quota reached
↓
Open Service Quotas
↓
Request an increase for the Region
↓
Wait for AWS approval or processing
↓
Create more alarms if approvedThe request is not always automatically approved. AWS may evaluate the account’s usage and the requested amount. A quota increase in one Region does not automatically increase the quota in every Region.
Examples of commonly adjustable CloudWatch quotas include account or Region-level resource counts and many API request rates. The current CloudWatch quota table labels each item as adjustable or not adjustable.
What is a hard limit?
A hard limit is a fixed functional or per-resource constraint that customers cannot increase through Service Quotas. When the architecture reaches it, request a different design rather than a quota increase.
One log group reaches its metric-filter limit
↓
Quota request will not solve it
↓
Consolidate filters, split log groups, or redesign detectionHard does not necessarily mean that AWS can never change the product. It means that the customer cannot raise the limit for the account through the normal quota-request process.
CloudWatch quota categories
CloudWatch limits apply at different scopes. Always ask whether a number applies to:
- The account or Region
- One alarm
- One dashboard
- One log group
- One metric expression
- API requests per second
- A data-query result or time-series count
This scope is often more important than the number itself.
Alarms
CloudWatch alarms evaluate metrics, expressions, or log queries and can trigger actions such as notifications, Lambda invocations, EC2 actions, Auto Scaling actions, Systems Manager actions, or investigations.
Alarm count: usually an adjustable quota
The number of alarms an account can create in a Region is an account-level quota. If a monitoring platform needs more alarms than the current quota, check the current quota’s adjustable status and request an increase when available.
5,000 alarms needed
20,000 alarms required
↓
Check the CloudWatch quota
↓
Request an adjustable quota increaseDo not assume that every alarm-related number is adjustable simply because the total alarm count is. Per-alarm and expression limits can be hard limits.
Alarm actions
An alarm can invoke supported actions when it changes state. Common actions include:
- Amazon SNS notifications
- Lambda function invocation
- EC2 stop, terminate, reboot, or recover actions
- Auto Scaling actions
- Systems Manager OpsItem or Incident Manager actions
- CloudWatch investigations where supported
The CloudWatch API supports up to five action ARNs in an alarm-action list for a state. Treat this as a per-alarm configuration limit, not as the total number of alarm actions that an account can perform.
If more than five downstream responses are required, use a fan-out design such as SNS subscribers, EventBridge rules, or a Lambda dispatcher instead of trying to attach every action directly to one alarm.
Metrics in an alarm expression
An alarm based on a metric-math expression can reference a maximum of 10 metrics. AWS documents this as a hard limit. If the logic needs more inputs:
- Use a Metrics Insights query when the metrics fit the same query model.
- Pre-aggregate the values into a custom metric.
- Split the calculation across multiple alarms.
- Combine alarms with a composite alarm.
This is a classic example of a per-resource hard limit: creating more alarms does not allow one metric-math alarm to reference more than the fixed number of metrics.
Metrics Insights alarm limits
Metrics Insights has its own limits. AWS currently documents a default of 200 Metrics Insights alarms per account per Region, along with limits on metrics matched, time series returned, and contributors in the ALARM state. These are different from the classic metric-math limit and should not be mixed together.
Dashboards
Dashboards have both account-level and per-dashboard limits.
Number of dashboards
→ Account or Region quota; commonly adjustable
Widgets in one dashboard
→ Per-dashboard functional limit; redesign if reachedThe commonly memorised values are 500 dashboards per Region and 500 widgets per dashboard, but quotas and feature behavior can change. Confirm the current quota table and API documentation before relying on a number.
If one dashboard becomes too large, split it into service, team, or environment dashboards. A dashboard hierarchy or links between focused dashboards is usually easier to operate than one huge page.
Metrics and API request rates
CloudWatch separates the number of metrics from the rate at which an API can read or write data.
Custom metrics
Custom metric quotas are account and Region related and may be adjustable. Do not treat a commonly quoted custom-metric number as universal; the current quota depends on the CloudWatch feature, account, Region, and metric model.
API throttling
CloudWatch API calls such as these have request-rate quotas:
PutMetricDataGetMetricDataGetMetricStatisticsPutMetricAlarmPutDashboard- Metric-stream operations
Many request-rate quotas are adjustable, but not all are. If an application is throttled, first determine whether the issue is an API rate quota, request payload size, datapoint quota, or a hard query limitation. Then apply retries with backoff, batching, caching, or a quota increase where appropriate.
CloudWatch Logs
CloudWatch Logs contains several important per-log-group limits.
Log groups
The number of log groups per account per Region is a quota and is currently listed as adjustable in the CloudWatch Logs quota documentation. A large organisation can request more capacity when the quota is adjustable, but should still establish log-retention and naming policies.
Metric filters: 100 per log group
CloudWatch Logs supports a maximum of 100 metric filters associated with one log group. AWS documents this as a non-adjustable quota.
Metric filters turn matching log events into CloudWatch metrics:
Application logs
↓
Metric filter
↓
CloudWatch custom metric
↓
CloudWatch alarmIf one log group already has 100 filters, do not request a quota increase. Instead:
- Consolidate related patterns.
- Move workloads into separate log groups where appropriate.
- Use CloudWatch Logs Insights for interactive queries.
- Use a central log-processing pipeline.
- Generate fewer, more useful metrics.
Be careful with high-cardinality dimensions in metric filters. They can create many custom metrics and unexpected charges.
Subscription filters
Subscription filters route log events to destinations such as Kinesis Data Streams, Firehose, Lambda, or OpenSearch Service. The commonly tested per-log-group limit is two subscription filters.
If more destinations are required, send the stream to a fan-out or delivery service rather than adding unlimited direct filters. Check the current CloudWatch Logs quota and destination behavior for the Region and architecture.
Regular-expression filter quotas
Filter patterns have their own constraints. For example, AWS documents limits on the number of regular-expression patterns in a filter and per log group. These are separate from the number of metric filters or subscription filters.
Contributor Insights and anomaly detection
Contributor Insights rules and anomaly-detection models also have quotas. The current CloudWatch quota documentation lists a default of 100 Contributor Insights rules per Region and marks that quota adjustable.
Anomaly detection has feature-specific quotas and API-rate limits. Do not assume that the number of anomaly detectors is the same as the number of alarms or custom metrics. Check the feature-specific row in the current quota table.
Hard versus soft comparison
| CloudWatch resource or limit | Scope | Typical response |
|---|---|---|
| Number of alarms | Account/Region | Check for adjustable quota and request increase |
| Number of dashboards | Account/Region | Check quota; request increase if adjustable |
| Widgets in one dashboard | One dashboard | Split dashboard if fixed limit is reached |
| Metrics in one metric-math alarm | One alarm expression | Use query, aggregation, multiple alarms, or composite alarm |
| Actions in one alarm state | One alarm | Fan out through SNS/EventBridge/Lambda if needed |
| Metric filters | One log group | Consolidate or split log groups |
| Subscription filters | One log group | Fan out through a delivery architecture |
| API request rate | Account/Region/API | Retry, batch, throttle, or request increase if adjustable |
| Contributor Insights rules | Account/Region | Request increase if current quota is adjustable |
The exact default values can change. The adjustable column in AWS’s current quota page is the source of truth.
The exam pattern: count versus attachments
A useful memory rule is:
How many resources can the account create?
→ Often an account/Region service quota
→ May be adjustable
How many things can one resource contain or reference?
→ Often a functional hard limit
→ Redesign may be requiredThis rule is not universal, but it helps interpret questions:
More CloudWatch alarms needed
→ Check Service Quotas
One alarm needs more metric-math inputs
→ Aggregate or split the design
One log group needs more metric filters
→ Consolidate or split the log groupsHow to request an adjustable quota increase
For a quota marked adjustable:
- Identify the account and Region where the quota is reached.
- Open the Service Quotas console.
- Select Amazon CloudWatch or CloudWatch Logs.
- Find the exact quota, not just a similarly named quota.
- Check whether the quota is adjustable.
- Request the required value with a reasonable justification.
- Monitor the request and update deployment automation after approval.
If the quota is not available through Service Quotas, follow the AWS documentation’s Support process. A support case cannot override a documented hard functional limit.
Common exam questions
The account needs more CloudWatch alarms than the current quota. What should you do?
Check the adjustable service quota and request an increase.
A metric-math alarm needs more than 10 metrics. What should you do?
Do not request a quota increase for that hard limit. Use Metrics Insights, aggregate metrics, split alarms, or use a composite alarm.
A log group already has 100 metric filters. What should you do?
Redesign the filters or split/consolidate log groups; the per-log-group quota is not adjustable.
A dashboard needs more widgets than one dashboard allows.
Split the dashboard into focused dashboards rather than assuming an account quota increase will solve a per-dashboard limit.
What is the difference between a quota and a hard functional limit?
A quota may be adjustable for the account or Region. A hard functional limit cannot be increased by a customer and requires a design change.
Final memory sheet
Adjustable quota
→ Service Quotas / AWS Support
Hard limit
→ Redesign
Alarms, dashboards, log groups, metrics
→ Often account or Region quotas
Alarm actions, metrics in one expression,
metric filters per log group, subscription filters
→ Per-resource limits; verify whether fixedRemember the most useful hard-limit examples: 10 metrics in a metric-math alarm, 100 metric filters per log group, and the commonly tested two subscription filters per log group. For changing account-level numbers, always verify the current AWS quota page instead of relying on an old cheat sheet.