Use this operation for provider quotas, API throttling, retries, backoff, queueing, worker/concurrency limits, and other control-plane operations. It runs a bounded, synchronous workload through Cloud World Model's deterministic provider-limit scheduler and models throttling, queueing, throughput, completion, retries, timeouts, failures, dependency blocking, and optional concurrency comparisons.

This is simulated provider-control-plane data, not a provider SDK or a live quota lookup. It never calls AWS, Azure, GCP, DigitalOcean, OCI, or any other provider API, discovers negotiated quotas, creates resources, persists the workload, or changes the simulation's resource graph or /step state. Provider throttling in the result is distinct from CWM's own HTTP 429/rate-limit middleware. Use resource /step for cloud workload behavior and use /simulations/stateless for the separate stateless resource simulation; neither substitutes for this provider-limit operation.

Supply one service per request: the top-level service applies to every operation group in the DAG. To compare services, submit separate requests. Supported exact provider/service/operation/category tuples resolve with result.policyResolutions[].policySource set to catalog_default; unsupported tuples return unsupported_policy without a scoped caller override.

Execution is protected by a 2-second wall-clock deadline and a process-local admission limit of two concurrent runs. Identical active or recently interrupted workloads, and workloads submitted while execution capacity is full, are rejected with HTTP 409 and must not be automatically retried. Deadline expiry is an HTTP 422 non-retryable failure.

Catalog defaults cover aws.ec2.mutating-api (service: ec2, operation: mutating, category: compute), AWS Elastic Load Balancing v1 and v2 (service: elbv1 or elbv2, category: network), and Azure Resource Manager read/write buckets. For each ELB service the exact supported operations are resource-intensive, registration, non-mutating, and mutating, yielding aws.elbv1.resource-intensive, aws.elbv1.registration, aws.elbv1.non-mutating, aws.elbv1.mutating, aws.elbv2.resource-intensive, aws.elbv2.registration, aws.elbv2.non-mutating, and aws.elbv2.mutating. These are documented API action categories, not arbitrary AWS action names. Do not infer an ELB category for an uncategorized action or interchange ELBv1 and ELBv2 buckets. Aurora Serverless v1 Data API has two independent catalog models (service: rds-data-api-aurora-serverless-v1, category: database): operation: requests-per-second resolves aws.rds-data-api-aurora-serverless-v1.requests-per-second (1,000 requests/second per account in the current Region); operation: concurrent-requests resolves aws.rds-data-api-aurora-serverless-v1.concurrent-requests (500 concurrent requests to ONE cluster using the SAME secret, with excess requests queued). Do not interpret them as joint enforcement of one workload. A request mixing these two selectors is rejected; send separate requests and do not treat results as simultaneous enforcement. Both require quotaScope.account; concurrency additionally requires quotaScope.resource, an opaque cluster-secret-pair label, never an actual secret. The rate model has no documented burst; its fixed 1-second scheduler window approximates the AWS rate limit, not AWS's documented timing. Source: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html Generic RDS control-plane, Aurora Serverless v2 Data API, and provisioned Aurora Data API are not covered by these selectors. AWS IAM, generic RDS control-plane, EC2 Auto Scaling, Application Auto Scaling, and S3 control-plane requests have no numeric scheduler-compatible public baseline in this catalog. S3 object per-prefix throughput is data-plane guidance, not a control-plane quota. Such tuples, as well as GCP, DigitalOcean, and OCI tuples without a caller-supplied quota override, return unsupported_policy rather than HTTP 429. Overrides must use a concrete account, subscription, or project scope and include caller-supplied provenance. The catalog policy source, documentation reference, confidence, and as-of date are returned in provenance and result.policyResolutions.

EC2 Auto Scaling (service: ec2-auto-scaling, category: compute) initially models DescribeAutoScalingGroups, DescribeScheduledActions, CreateAutoScalingGroup, UpdateAutoScalingGroup, SetDesiredCapacity, and DeleteAutoScalingGroup. AWS documents one shared account API token bucket, RateExceeded on throttle, and no public numeric capacity/refill pair. Use one account/Region-scoped caller operation: all token-bucket override with caller-verified burst capacity and refill for these six operation groups. Put operation: all on the override policy and its policy scope, not on the request's quotaScope; the latter can omit operation for a mixed workload. They contend for the same bucket. Other operations do not inherit this six-action override. Mark throttled retryable and configure exponential backoff to model client retry behavior. This is not an Auto Scaling resource/configuration quota or an EC2 API bucket. AWS advises IncludeInstances=false for DescribeAutoScalingGroups to omit instance details; this advice does not change modeled token consumption, latency, or quota. See https://docs.aws.amazon.com/autoscaling/ec2/APIReference/Welcome.html and docs/aws-api-limit-evidence.md for the evidence gap.

latency is required because it is a Cloud World Model client-side model input: provide measured client values when available. If no measurements are available, use the canonical baseline meanMs: 40, p95Ms: 80, and timeoutMs: 5000 shown below. These values are simulation guidance, not AWS service defaults and not a live AWS latency claim. The same applies to every latency and retry value in this operation.

For mixed workloads, each result.policyResolutions entry is keyed by operation category, operation, and resource group (resource is omitted when absent). Multiple operation IDs with the same three values share one resolution. Its accounting counts that group's planned units, attempts, retries, throttles, and completions; summing these fields across resolutions gives the corresponding result.accounting totals. Attempts count initial and retry attempts, while retries and throttles can count the same work, so do not sum different fields together. For the mixedAwsEc2Groups request example below, the modeled result contains this fragment (other result fields are omitted):

{
  "policyResolutions": [
    {"operationCategory":"compute","operation":"mutating","resource":"fleet-a","policySource":"catalog_default","accounting":{"plannedOperations":3,"attemptedOperations":3,"retryOperations":0,"throttledOperations":0,"completedOperations":3,"denominator":"planned_operations"}},
    {"operationCategory":"compute","operation":"mutating","resource":"fleet-b","policySource":"catalog_default","accounting":{"plannedOperations":2,"attemptedOperations":2,"retryOperations":0,"throttledOperations":0,"completedOperations":2,"denominator":"planned_operations"}}
  ],
  "accounting": {"plannedOperations":5,"attemptedOperations":5,"retryOperations":0,"throttledOperations":0,"completedOperations":5,"failedOperations":0,"timedOutOperations":0,"dependencyBlockedOperations":0,"unsupportedOperations":0,"pendingOperations":0,"terminalOperations":5,"denominator":"planned_operations"}
}

Omitting retry without selecting awsSdkRetryProfile selects the legacy one-attempt, no-backoff baseline: maxAttempts: 1, baseBackoffMs: 0, maxBackoffMs: 0, backoffMultiplier: 2, and jitterRatio: 0; although generic retry conditions are allowed by the default schema, one attempt means no retry is made. An explicitly selected awsSdkRetryProfile models the shared retry layer of JavaScript v3 Standard and Adaptive. Adaptive's per-client request-rate limiter and cross-operation coupling are not modeled. Explicit retry settings override the selected profile. Provider quota policies remain a separate catalog concern.

The aws-js-v3-standard-pre-2026 profile has transient and throttling base delays of 100 ms, 10 transient / 5 throttling retry tokens, a 500-token client budget, and 3 maximum attempts. The separately selectable aws-js-v3-standard-2026 profile uses 50 ms transient and 1,000 ms throttling bases, 14 transient / 5 throttling tokens, and a 500-token budget. For DynamoDB and DynamoDB Streams, the 2026 profile uses a 25 ms transient base and 4 attempts; the pre-2026 profile stays at 100 ms and 3 attempts. Both profiles use seeded full jitter with a 20,000 ms cap. AWS's x-amz-retry-after is clamped to the computed jittered delay through 5,000 ms above it, up to 25,000 ms, without extra client jitter.

AWS sources: https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html https://github.com/aws/aws-sdk-js-v3/issues/8037 https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/ AWS describes default rollout as no sooner than November 2026; the exact date is unconfirmed here. Profiles remain explicitly selectable and no saved or historical simulation is automatically rewritten.

Bounds: up to 256 operation groups, 100,000 aggregate planned units across all distinct concurrency-sweep runs, 500,000 estimated attempts (aggregate planned units multiplied by the effective maximum attempts), 1,000 workers, 1,000 concurrency, 16 concurrency sweep values, 10 retry attempts, and 1,000,000 scheduler events. Aggregate work-budget checks run before authentication billing or demo-quota consumption and return HTTP 413 when exceeded. Results with more than 1,000 planned operations omit per-unit detail: result.operations is empty and result.outputDetail is summary_only. This endpoint is a modeled simulation, not a provider SDK or drop-in provider API.

{
  "modeled": {
    "namespace": "simulated-provider-api-quota",
    "platformRateLimitNamespace": "cwm-api-rate-limit"
  },
  "provenance": {
    "catalogVersion": 3
  }
}