Lesson 263 · AWS Learning Path

AWS 263: Service Quotas and License Manager

· Published · 13 min read

Labelled process diagram for AWS 263: Forecast demand and license terms to Quota and license rules to Placement or request to Utilization, compliance, and fallback evidence, with decision, proof and rejection evidence.

Why this matters to an architect

Autoscaling can request more resources only while account, Region, resource, and API quotas permit them - and a higher quota does not reserve physical capacity. Licensed software adds another boundary: a deployment can be technically possible but contractually noncompliant, or License Manager can deliberately block it.

These are different control planes. Service Quotas describes administrative maximums; workload capacity depends on actual regional/AZ supply, addresses, dependencies, reservations, and application limits. AWS License Manager turns customer-understood license terms into discovery, counting, placement, alerts, and optional enforcement; it does not interpret contracts or replace legal/vendor advice.

Outcomes

By the end, you can:

  • distinguish quota, throttle, capacity, reservation, application limit, budget, and license entitlement;
  • inventory account/Region/global/resource-level quotas and identify adjustable versus fixed limits;
  • forecast demand and request increases with lead time and fallback;
  • monitor supported utilization, custom counts, request history, and deployment errors;
  • use quota request templates and Automatic Management without assuming approval;
  • model licenses by instance, vCPU, core, or socket, including tenancy and stopped-instance behavior;
  • choose hard versus soft License Manager limits from business-risk requirements;
  • discover/associate resources and AMIs, share self-managed licenses, and delegate administration safely;
  • reconcile technical consumption to procurement/vendor entitlements;
  • test scale, failover, license exhaustion, migration, and decommissioning.

Keep the boundaries separate

BoundaryMeaningExample evidence
service quotaAWS administrative maximum in a scopeapplied quota/API response
API throttleallowed request rate/burstthrottling metrics/errors and retry behavior
physical capacityresources AWS can supply at requested place/timesuccessful launch/capacity error/reservation
subnet/address capacityusable IPs and ports/connectionsIPAM/subnet/NAT metrics
application capacityload meeting SLOlatency/error/saturation load test
budgetfinancial alert/controlbilling forecast/action; not capacity
license entitlementcontractual right to use softwaresigned agreement/procurement ledger
License Manager ruletechnical representation of understood termsconfiguration, associations, consumption, violation

Increasing EC2 vCPU quota does not reserve an instance type in one AZ. A Capacity Reservation does not increase quota. A Savings Plan/RI is primarily billing/discount and may not reserve capacity. A license count does not prove a vendor accepts your rule interpretation.

Service Quotas terminology and scope

  • AWS default value: initial value AWS defines.
  • Applied value: account/resource-specific override; if none exists, effective value normally follows default.
  • Adjustable: an increase can be requested through supported workflow; approval/value/time are not guaranteed.
  • Fixed: cannot be raised through the normal request path; redesign or distribute demand.
  • Usage: current count/rate where AWS exposes it.
  • Utilization: usage divided by quota.
  • Global quota: applies account-wide; in the commercial partition, request increases from us-east-1.
  • Regional/account quota: separate applied value per account and Region.
  • Resource-level quota: applies in the context of a resource, such as each supported domain.

Not every service limit appears in Service Quotas, supports utilization, or is adjustable. Service documentation can contain additional limits. Some quotas are shared across related resources, some are per AZ/resource, and some count pending/stopped/deleting state. Record the exact service code, quota code, context, unit, adjustment support, and timestamp instead of relying on a remembered number.

Build a quota register from architecture

Start with every scaling and recovery action, then walk dependencies:

request load -> ALB/API Gateway -> compute concurrency/vCPU
-> ENIs/subnet IPs/security rules -> database/cache connections/capacity
-> queues/streams/functions -> KMS/Secrets/CloudWatch API rates
-> backup/copy/restore -> network/DNS/endpoints/logging

For each account/Region/resource capture:

FieldRequired decision
workload/actionnormal growth, launch, deployment, failover, restore, incident burst
service/quota codestable API identifier, not only display name
unit/scopeaccount/Region/AZ/resource/global and shared pool
applied/defaultcurrent authoritative value and date
current/peak/forecastmeasurement source and uncertainty
headroompeak plus failure/migration/test margin
lead timeinternal approval + AWS processing + validation
alarmthreshold, missing-data behavior, owner/escalation
fallbackshed/degrade, alternate account/Region/AZ, fixed-limit redesign

Include EC2 On-Demand/Spot vCPU families, EIPs/public IPv4, ENIs, security groups/rules, VPC/TGW/routes/endpoints, load balancers/targets/certificates, Lambda concurrency/storage, API Gateway, queues/streams, database instances/storage/connections, KMS rates/grants, IAM/STS, CloudFormation/StackSets, logs/alarms, backup jobs/vaults, Direct Connect/VPN/BGP routes, DNS/Resolver, and account/security-service scale.

Forecast headroom and failure demand

Use forecasted peak, not average. Include blue/green overlap, rolling deployment surge, retries, seasonal event, one-AZ loss, Regional failover, DR restore, incident logging, acquisition, and quota consumed by unrelated tenants in the same account.

Example reasoning:

required = peak production + deployment surge + failover capacity + safety margin
headroom = applied quota - current peak usage
request date = needed date - internal/AWS lead time - validation time

Avoid extreme speculative requests: AWS may need a business case, unused limits can increase blast radius, and quota is not free capacity. Also avoid using low quotas as the only security or cost control; many are adjustable and legitimate bursts can fail.

Request, track, and verify increases

Use list-service-quotas/get-service-quota to inspect applied values and list-aws-default-service-quotas for defaults. Submit only adjustable quotas in the correct account/Region/context and retain requested value, case/request ID, requester, business reason, status, timestamps, and response.

aws service-quotas request-service-quota-increase \
  --service-code replace-service \
  --quota-code replace-quota \
  --desired-value replace-value \
  --region ap-south-1

API acceptance means a request exists, not approval. Poll request history to a terminal status. After approval, read the applied quota again and perform a bounded capacity/deployment test. Update runbook/IaC assumptions. Some increases require Support/service workflows outside Service Quotas.

Monitoring quota utilization

For quotas with AWS usage metrics, Service Quotas can create CloudWatch alarms. An alarm needs notification/action routing; creating it alone does not notify anyone. Choose thresholds from growth and request lead time, not a universal 80 percent.

Many quotas lack usage metrics. Build scheduled inventory from service APIs/Config/resource graph and publish custom metrics. Monitor throttling/error codes (LimitExceeded, TooManyRequests, ResourceLimitExceeded, capacity errors), failed deployments, subnet IPs, connection pools, and request-status age. Reconcile account/Region coverage and new services.

Test alarms below production impact. Handle pagination, eventual consistency, deleted/pending resources, API throttling, stale metrics, and missing data. A percentage can hide a small absolute remainder or a shared pool exhausted by another workload.

Organization templates and Automatic Management

A quota request template automatically submits selected increase requests when new accounts are created in the same all-features organization. It does not update existing accounts, guarantee approval, cover opt-in/China Regions, or hold more than the current template limit of ten quota requests. Account vending must poll each request and block workload handoff until required applied values are proven.

Service Quotas Automatic Management supports current eligible quotas with modes such as notify-only or notify-and-auto-adjust. It monitors supported utilization and can generate requests at documented thresholds. This is a backstop, not capacity planning: unsupported quotas, sudden spikes, fixed quotas, approval delay, missing signals, failure notifications, and physical capacity remain. Define owner, allowlist, maximum desired growth, event routing, cost/security review, and reconciliation before auto-adjust.

Scale and failover tests

Before launch or DR declaration:

  1. verify all prerequisite applied quotas in every target account/Region;
  2. create/load resources in bounded non-production or approved window;
  3. test blue/green and one-AZ/Region failure demand;
  4. confirm service capacity/reservation, subnet IP, downstream and API rates;
  5. observe alarms/retries/backpressure and business SLO;
  6. clean up and prove consumption returns as expected.

Do not intentionally exhaust a production quota. Use safe supplied evidence/tabletop where no approved test boundary exists.

License Manager capability map

AWS License Manager includes several related capabilities. Select only what matches the agreement/product:

  • self-managed licenses (formerly license configurations): customer-authored counting/placement rules for BYOL;
  • AWS managed licenses/entitlements and grants: publisher/Marketplace-issued rights and distribution;
  • license asset groups: centralized discovery/governance views with applicable rulesets;
  • Linux subscriptions: discover/aggregate commercial Linux subscription usage;
  • user-based subscriptions: supported per-user software through an identity directory and Marketplace subscriptions;
  • RDS/EC2 integrations and conversion tooling: product-specific workflows.

Names, product support, Regions, prerequisites, and pricing evolve. Start from the current License Manager guide and vendor agreement.

Model self-managed license rules

The business/legal owner interprets the signed contract; procurement records purchased quantity, term, geography, transfer/affinity, disaster-recovery rights, virtualization, cores/sockets/vCPUs, minimums, hyperthreading, stopped/non-production use, and audit obligations. Technical staff encode the approved interpretation.

Self-managed counting types include Instances, vCPUs, Cores, and Sockets. Rules can restrict minimum/maximum cores/sockets/vCPUs, tenancy (shared, Dedicated Instance, Dedicated Host according to type), host affinity, vCPU optimization, included stopped instances, expiry, and product information for supported discovery.

Core/socket counting requires Dedicated Hosts. If vCPU optimization is honored, customized cores/threads affect counting; otherwise default instance-type vCPUs are used. Stopped instances are normally released unless includedStoppedInstances=true. Host affinity can keep a license bound for a configured period. These settings must match approved terms, not cost preference.

Hard versus soft limits

  • Hard limit: blocks additional supported launches/usage when the configured limit/rule would be exceeded. Use when the organization accepts availability impact to prevent overdeployment.
  • Soft limit: allows deployment and reports/alerts on excess. Use when continuity is more important and a rapid true-up/remediation process exists.

Neither is universally safer. Test launch mechanisms, Auto Scaling, recovery, DR, AMI copy/share, launch templates, container/virtualized scenarios, and failure messages. A hard license limit can defeat scaling or failover; a soft limit can create contractual/financial exposure.

Discovery, association, and reconciliation

License Manager can associate self-managed rules with supported AMIs/resources and discover supported software/products. Manual association of rules with golden AMIs before broad sharing helps ensure launched instances are tracked. Automated discovery depends on product metadata/support and inventory prerequisites; unknown/custom software still needs another evidence path.

Reconcile at least:

procured entitlement
vs License Manager configured quantity/rules
vs associated AMIs/resources
vs discovered running + contractually countable stopped resources
vs CloudWatch consumption/violations
vs CMDB/vendor portal/invoice

Investigate unassociated instances, duplicated images, stale terminated resources, cross-Region copies, host replacement/affinity, discovery delay, and products outside support. Preserve contract version and rule-change approvals.

Multi-account License Manager

Enable trusted access and register supported delegated administrators. Managed-license and Linux-subscription features use distinct service principals; the Console expects one consistent delegate for supported features, while CLI/API can create split delegates that complicate operation. Delegation gives visibility and organization-wide power, so isolate and audit the account.

Share self-managed license configurations through RAM with accounts/organization as supported. The owner maintains the rule; consumers associate/use it. External account sharing is supported for this RAM resource type, but identity, invitation, Region, contract, and revocation requirements remain. A share does not grant legal entitlement.

New-account onboarding must enable discovery/inventory, accept/receive shares, install required roles/agents/integrations, associate approved AMIs, and pass a compliant/noncompliant launch test. Offboarding must reconcile consumption, grants/shares, images, hosts, subscription users, retained records, and contract transfer rights.

User subscriptions, grants, and product-specific models

User-based subscriptions can require AWS Managed Microsoft AD, Marketplace subscriptions, directory/network/IAM prerequisites, and user-instance association. Current cross-account designs use a directory owner/license admin plus consumer accounts; Region and billing restrictions apply. Do not treat user subscription count as instance-based BYOL count.

Managed entitlements/grants represent issuer-defined rights, with grant acceptance/distribution and usage records. Keep publisher entitlement, Marketplace agreement, procurement, and AWS technical records aligned. Product terms override a generic architecture assumption.

Monitoring, evidence, and incident response

Service Quotas changes/requests and License Manager API activity appear in CloudTrail. License Manager publishes supported CloudWatch consumption metrics. Alert on approaching entitlement, violations, failed/blocked launches, expired configurations, unassociated discoveries, discovery gaps, delegate/trusted-access changes, shares/grants, rule/quantity/limit-mode edits, and alarms disabled.

Evidence must include actor/time/approval, contract/entitlement version, configuration ARN/rules, resource/AMI/host association, account/Region, discovered consumption, exception/true-up ticket, and resolution. Restrict access because inventory reveals commercial products and infrastructure.

Cost and risk model

Service Quotas usually has no separate request fee, but a higher approved quota enables billable scale. Automatic increases can expand cost and attack blast radius. License Manager feature pricing varies; connected Systems Manager inventory, directory, Marketplace/user subscriptions, Dedicated Hosts, data collection, CloudWatch, RAM, and operations can cost money.

Model license purchase/subscription/support, Dedicated Host underutilization, mobility/affinity, DR/non-production rights, true-up penalties, discovery tooling, and blocked-capacity business impact. Optimize only with procurement/legal approval; technical core/vCPU optimization that violates terms is not savings.

Read-only evidence audit

Redact account IDs, quotas that expose scale, software/products, contract counts, instance/AMI/host/directory/license ARNs:

aws service-quotas list-services --region ap-south-1
aws service-quotas list-service-quotas --service-code ec2 --region ap-south-1
aws service-quotas list-requested-service-quota-change-history --region ap-south-1
aws service-quotas list-service-quota-increase-requests-in-template --region ap-south-1
aws license-manager list-license-configurations --region ap-south-1
aws license-manager list-resource-inventory --region ap-south-1
aws license-manager list-usage-for-license-configuration \
  --license-configuration-arn replace-with-arn --region ap-south-1
aws organizations list-delegated-administrators \
  --service-principal license-manager.amazonaws.com

Follow pagination and repeat all target Regions/accounts. The API names may retain license-configuration terminology for self-managed licenses. Inventory is not contractual proof.

Troubleshooting matrix

SymptomEvidence orderFrequent cause
request submitted, launch still failsrequest status, applied quota, correct account/Region/context, service capacity/errorsubmission mistaken for approval/capacity
alarm never firesquota supports usage, metric/dimension/Region, data and alarm actionunsupported/stale utilization
new account starts at defaultcreation time, template association/Region/item, request historytemplate disabled/unsupported/only future accounts
DR fails despite normal headroomtarget Region applied quotas and full failover demandnormal peak mistaken for DR requirement
license usage lower than inventoryassociations/discovery, product support, stopped rule, Region/accountincomplete discovery/rule semantics
Auto Scaling blockedhard limit, consumption, AMI association, counting/tenancycompliance enforcement conflicts with availability
rule permits contractually invalid hostrule versus approved agreement/versionLicense Manager mistaken for legal interpretation
shared license not visibleRAM Region/invitation/principal and organization integrationshare lifecycle incomplete
terminated host remains counteddiscovery lag, affinity/include-stopped, resource staterelease semantics misunderstood
delegated view misses accountstrusted access, feature principal, Region, discovery onboardingdelegate assumed universal

Change and decommissioning

Version quota register and license-rule mappings. Canary hard-limit/rule changes against approved AMIs and launch/failover paths; monitor, batch, and preserve rollback. Quantity increases require procurement evidence; reductions require consumption headroom and blocked-launch analysis.

Before deleting/unsharing a configuration, AMI, host, directory, subscription, grant, delegate, alarm, or account, reconcile active/stopped/discovered resources, affinity, recovery images, DR, user assignments, invoices, retention/audit, and vendor transfer/termination. Remove associations and consumers in documented order, verify consumption/release, then retain evidence for the contract period.

Practical lab

Download the AWS263 quota and license governance pack. It contains a capacity register, launch/DR forecast, license-rule translation, reconciliation matrix, eight failure cases, and answer directions.

Submit quota dependency graph for EC2/EIP/ALB/TGW/Lambda/DX plus downstream services; request/alarm/template/automatic-management plan; scale/failover tests; approved license rule for two contrasting agreements; hard/soft ADR; organization/RAM/discovery model; reconciliation, cost, exceptions, change, and decommissioning.

Knowledge check

  1. How do quota, throttle, physical capacity, reservation, budget, and entitlement differ?
  2. Why must quota evidence include account, Region/context, and quota code?
  3. Why does approval not prove launch capacity?
  4. What demand belongs in a DR quota forecast?
  5. Which quotas need custom inventory rather than native utilization?
  6. What do request templates omit?
  7. Why is Automatic Management a backstop rather than a plan?
  8. Who is responsible for translating a license contract?
  9. How do instance/vCPU/core/socket counting and tenancy differ?
  10. What changes when stopped instances or vCPU optimization are counted?
  11. When should a limit be hard versus soft?
  12. Why can License Manager consumption differ from procurement records?
  13. What does RAM sharing a configuration not grant?
  14. Which evidence is required before decommissioning a license rule?

Lesson acceptance

Pass requires quota/capacity boundary explanation; complete scoped register and dependency forecast; request/status/applied verification; alarms/custom inventory; template/automatic-management limits; safe scale/DR test; contract-approved license translations; hard/soft decision; discovery/association; multi-account delegation/sharing; entitlement-consumption reconciliation; cost/risk; eight diagnoses; controlled changes; and audit-safe decommissioning.

Official sources

Advertisement