AWS ARC Region Switch: Configure Quota Checks and ECS Health Waiting

Four additions address different recovery checks

AWS announced four additions to ARC Region switch on October 14, 2026 at 17:38 UTC: an SSM Run Command execution block, payloads for custom-action Lambda blocks, service quota parity checks, and optional target-group health waiting after compute scaling. The latter two help identify quota differences and distinguish capacity counts from readiness to receive traffic.

The Run Command block runs commands on managed instances and VMs during failover, with plan evaluation checking document targets and IAM configuration. Lambda payloads support reusing functions across recovery plans. These details come from the announcement; they do not establish command-document requirements, payload formats or complete permission policies.

Existing plans do not inherit the new-plan default

The plan setting serviceQuotaChecksEnabled controls quota checks. New plans default to enabled, while plans created before the feature became available default to disabled. Updating a plan without specifying the field preserves its current setting rather than automatically enabling it.

Before changing the setting, check the plan’s current state on Edit plan details. The console provides Enable service quota warnings and Disable service quota warnings; the setting is also available through the Region switch API, AWS CLI and CloudFormation.

A quota request is not approval, and parity is not capacity

Checks compare applied quotas across Regions and accounts for compute and database resources used by the plan’s execution blocks. If one side has a lower limit, Region switch can request an increase to match the higher value. It checks parity rather than recalculating quota needs from current consumption, and it does not guarantee that physical capacity will be available during a failure.

Checks run within 30 minutes of plan creation or update and then every 24 hours, independently of plan evaluation. Region switch uses at most half the allowed open quota requests to leave room for your own submissions: up to five concurrent requests per account per commercial Region, or one concurrent request per account for opt-in Regions. Other mismatches remain warnings until a later cycle.

Requests can take hours or days to apply. A warning remains while its request is open and is removed on a subsequent check only after approval and application of the new quota. A denied request leaves the warning in place and may be resubmitted after a cooldown. Quota warnings do not block execution, so being able to start a plan does not establish that its capacity requirements are satisfied.

Check role permissions and use the right warning surface

Review the execution role and applicable cross-account roles. Reading quotas requires servicequotas:GetServiceQuota; automatic requests also need servicequotas:RequestServiceQuotaIncrease and servicequotas:GetRequestedServiceQuotaChange, plus the relevant resource Describe/List permissions. The requesting account needs the Service Quotas service-linked role; the corresponding iam:CreateServiceLinkedRole permission is needed when Region switch must create that role for a first request.

Look for quota mismatches and request status under Service quota warnings within Plan evaluation, or through ListServiceQuotaWarnings. Evaluation warnings returned by GetPlanEvaluationStatus identify missing IAM permissions for quota checks; they do not return quota mismatches or request-processing status. An absence of permission warnings is not evidence that quota parity has been achieved.

ECS can wait for healthy targets after reaching its task count

The ECS block offers optional Wait for target group health. Its API field waitELBTargetGroupHealthy accepts enabled or disabled; the document states no default. Disabled, the step completes at its desired running-task count. Enabled, it also waits for the required number of this service’s tasks to be healthy in every associated target group, even if no scaling was necessary.

Consider a hypothetical graceful execution with a calculated target of four tasks. All four are running, but the target group reports only two healthy. With health waiting enabled, reaching four running tasks is not enough to advance; if the required healthy count is not reached before the timeout, the step fails. Ungraceful execution uses its configured minimum percentage for both scaling and health waiting.

Only ALB and NLB target groups are supported. The check is skipped if the service has no load balancers; enabling it has no effect for a service using only a Classic Load Balancer. Target-group health is not end-to-end business validation, and the document does not promise automatic retries, rollback or a particular application recovery time after a timeout.

Monitoring has cost differences, and ECS rules are not EC2 rules

For ECS capacity monitoring, sampledMaxInLast24Hours samples running-task counts. The document says it adds no cost but may be less accurate than the alternative. autoscalingMaxInLast24Hours uses Container Insights metrics, requires Container Insights to be enabled and incurs its additional costs. That does not establish that ARC or every new capability is free.

The announcement also adds target-group health waiting to EC2 Auto Scaling blocks, but the task counts, target-group behavior and timeout details above come from the ECS document and should not be treated as EC2 configuration rules. The inspected sources provide no complete supported-Region list, overall price table or universal rollout completion time. Confirm applicability to the actual plan and resources before adoption.