[mplaws]

Summary

• The deactivate workflow's ui scale-up now waits until the load balancer counts the new ui tasks healthy (WaitELBTargetGroupHealthy: enabled on scale-ui), so DNS moves only onto tasks that receive requests. ui is the only service behind a target group. The other five use ECS Service Connect, and ARC skips the wait for a service without one.
• The plan sets ServiceQuotaChecksEnabled: true explicitly, because the default depends on when a plan was created and an update without the field keeps the old setting. ARC compares the two Regions' quotas for what the scaling steps launch (Fargate vCPUs here) and lists a lower one as a warning.
• The execution role gets the reads the wait and the quota check use, and the reads ARC's plan evaluation tests for the quota check (CloudTrail shows plan evaluation making these calls in the e2e runs of 2026-10-14, 10-19 and 10-23):
  • ecs:ListTasks and elasticloadbalancing:DescribeTargetHealth on *, and ecs:DescribeTasks on every task in the two Regions, because plan evaluation tests it on a task outside any cluster.
  • ecs:DescribeTaskDefinition, ecs:DescribeCapacityProviders and servicequotas:GetServiceQuota.
  • ecs:DescribeContainerInstances in the two Regions, and ec2:DescribeInstances, ec2:DescribeLaunchTemplateVersions and autoscaling:DescribeLaunchConfigurations on *, the only resource those three accept. These are for services on EC2 container instances; plan evaluation tests them although all six services run on Fargate. They let the role read every EC2 instance, launch template and launch configuration in the account, including the user data of launch templates and launch configurations.
• The role cannot request quota increases, so ARC opens no AWS Support case in the account that deploys the sample. Plan evaluation keeps one warning, naming servicequotas:RequestServiceQuotaIncrease and servicequotas:GetRequestedServiceQuotaChange.
• The README describes the wait, the quota checks and what plan evaluation shows, and says the measured failover timings predate the wait: a new ui task needs about two minutes to pass the health check.

Testing

• pytest tests/: 1,860 passed, 13 of them new.
• Reverting each part of the change makes at least one new test fail (12 reverts across the two commits).
• The pr-validation cfn-lint command (cfn-lint 1.58.0), and checkov 3.3.30 with .checkov.yaml: no findings.
• IAM Access Analyzer validate-policy on the role's policy: no findings. Policy simulation: the resource names plan evaluation tests and the clusters' tasks and container instances are allowed in the two Regions; the same names in another Region, ec2:DescribeInstanceAttribute, ec2:GetLaunchTemplateData, every write tested and the increase-request permissions are denied.

Not verified yet

• The e2e deploys the plan, doesn't run it, and deletes it about 20 minutes later, before ARC's first quota comparison (within 30 minutes of creation). The ui wait first runs at the next failover of a long-lived deployment.
• ARC does evaluate the plan while it exists. On this PR's e2e, its quota-check calls with the plan's role should all succeed in CloudTrail, and plan evaluation should read actionRequired with a quota-check warning naming only the two increase-request permissions. After merge, test2's plan should show the same; any other permission named there is a gap in this change.