| name | arc-region-switch |
| description | Answers questions about Amazon Application Recovery Controller (ARC) Region switch including architecture, plans, execution blocks, workflows, triggers, active/active vs active/passive, cross-account support, recovery time, dashboards, and customer positioning. Applicable when users ask about ARC Region switch adoption, design, or troubleshooting. |
| version | 1 |
ARC Region switch Expert
Overview
Makes the agent an expert on Amazon Application Recovery Controller (ARC) Region switch — the feature for orchestrating cross-Region workload failover and switchover. Supports technical questions, customer positioning, and SA engagement preparation.
Region switch orchestrates recovery for applications already deployed multi-Region. It does not create multi-Region architecture or handle data replication — it orchestrates failover of existing replicas and resources.
Guardrail — where this skill's own files live (MCP vs local install)
Before reading a reference file, determine how this skill was loaded:
- Loaded via the AWS MCP
retrieve_skill tool: the skill's reference files are not on the local filesystem. Fetch each one through retrieve_skill with the file parameter (e.g. file="references/positioning.md" or file="references/doc-links.md") — do NOT file_read these paths locally or search the filesystem for them.
- Installed locally (e.g.
.kiro/skills/arc-region-switch/ or ~/.claude/skills/arc-region-switch/): read reference files from the local skill directory using the relative paths shown here.
This applies only to the skill's own reference files; always read and write user or session data in the working directory, never through retrieve_skill.
When Not to Use
- In-Region failover — Region switch is for cross-Region recovery only. Use AZ-level mechanisms (ALB, Auto Scaling) for in-Region resilience.
- Data replication design — Region switch orchestrates failover of existing replicas; it does not set up or manage replication. Use Aurora Global Database, DynamoDB Global Tables, S3 Cross-Region Replication, etc.
- AZ-level resiliency — For Availability Zone failures within a single Region, use multi-AZ architecture patterns instead.
Terminology Constraints
- ALWAYS use "Region switch" (lowercase 's') for the product name
- Use "Routing Controls" only when referring to the Routing Controls execution block or the legacy cluster-based approach — do not use it as a synonym for Region switch
- Do NOT conflate triggers (CloudWatch alarms that start execution) with application health alarms (measure actual recovery time)
- Region switch orchestrates failover — it does NOT replicate data
Critical Warnings
- Irreversible in-progress steps: Plan executions can be paused or cancelled, but any step that is already started cannot be reversed without another plan execution.
- Monitor during events: Customers should still monitor their application health during an event, even if they configure plan triggers to automatically start a plan execution.
- Regional endpoint matters: When deactivating a Region, call
start-plan-execution from the healthy Region, not the Region being deactivated. When activating a Region, call from the Region being activated. See StartPlanExecution API.
Workflow
- Classify the question: technical architecture, customer positioning, how-to, troubleshooting, or comparison
- Answer from embedded knowledge in this skill
- If the knowledge base is insufficient, search official AWS documentation (
docs.aws.amazon.com)
- Format the response for the audience (engineer, SA, customer)
Always validate:
- Correct terminology (Region switch, not routing controls for plan-based features)
- Include doc links where helpful (see Documentation Links section)
- Use positioning language from the Positioning section
Architecture
Components
| Component | Description |
|---|
| Plan | Top-level resource scoped to a multi-Region application. Contains workflows. |
| Child Plan | A self-contained plan nested within a parent plan (one level deep). |
| Workflow | Ordered sequence of steps within a plan. Defines activation/deactivation logic. |
| Step | Container for one or more execution blocks, run in parallel or sequence. |
| Execution Block | Performs a specific recovery action (e.g., scale up, reroute traffic, failover DB). |
| Trigger | CloudWatch alarm-based automation that initiates plan execution. |
| Application Health Alarms | CloudWatch alarms indicating app health per Region; used to calculate actual recovery time. |
| Post-recovery Workflow | Optional workflow that runs after recovery to prepare for future events. |
| Plan Evaluation | Automated checks verifying plan execution readiness. Verifies IAM permissions, resource existence and configuration, capacity, etc. |
| Automatic Execution Reports | PDF reports delivered to S3 after each plan execution for compliance/audit. |
Execution Modes
Recommend using graceful execution unless not possible (e.g., when an execution block has a dependency on the impaired Region — such as Aurora/DocumentDB/Neptune switchover requiring connectivity to the impaired Region, or a Custom Action Lambda deployed in the impaired Region).
- Graceful: Runs all steps in orderly sequence. Preferred for planned switchovers, DR tests, and any scenario where the source Region is still healthy.
- Ungraceful: Skips or modifies certain execution blocks — only critical steps run. Use only when the source Region is impaired and graceful execution is not possible.
- Post-recovery: Runs after successful recovery in the previously-impaired Region. Requires both Regions to be healthy. Supports a subset of execution blocks — see the Add execution blocks documentation for the current set.
Active/Passive vs Active/Active
| Approach | Workflows Needed | Behavior |
|---|
| Active/Passive | 1 activation workflow (either Region) OR 2 separate activation workflows (one per Region) | Failover from primary to standby; failback when primary recovers |
| Active/Active | 1 activation workflow + 1 deactivation workflow per Region | Shift-away from impaired Region + return when healthy |
Supported Execution Blocks
Execution blocks are the individual step types a Region switch workflow is composed of — each performs one recovery action, spanning traffic/DNS rerouting, compute scaling, database failover, custom-action Lambdas, manual-approval gates, and nested child plans.
Do not rely on a hardcoded list of block types — ARC adds and changes execution blocks over time. Retrieve the current supported set at query time from the Components & concepts and Add execution blocks documentation.
Recovery Time Tracking
- Recovery Time Objective (RTO): Set when creating a plan
- Actual Recovery Time: Plan execution time + time for application health alarms to return to green
- Visible on plan execution details page for comparison against RTO
Plan Evaluation
- Validates: IAM permissions, resource configurations, running capacity
- Warnings surfaced in console, EventBridge, and API
- Passing evaluation alone is NOT sufficient — always test by executing plans
Automatic Execution Reports
- PDF reports generated after each plan execution
- Delivered to customer-specified S3 bucket (within ~30 min)
- Customers must configure the S3 bucket and update permissions for the PlanExecutionRole to enable reporting
- Contents: executive summary, plan config, execution timeline, resource states, alarm history, child plan details, glossary
- Useful for regulatory compliance and DR audit evidence
- See Security Considerations for encryption and access control guidance
Cross-Account Support
Plans can orchestrate resources across multiple AWS accounts via IAM roles with cross-account trust policies. This is a key enterprise differentiator — always mention it for large customers.
When configuring cross-account trust policies:
- Include condition keys (
aws:SourceArn, aws:SourceAccount, sts:ExternalId) to prevent confused deputy attacks
- Scope IAM policies to least privilege — avoid
* resource wildcards and FullAccess managed policies
- Scope permissions to only the specific resources (ASG ARNs, Aurora cluster ARNs, Route 53 health check ARNs, etc.) referenced in execution blocks
Regional Availability
Available in multiple commercial AWS Regions and AWS GovCloud (US) Regions — always verify the current list before stating availability to a customer, as Region coverage changes over time. Each Region has its own data-plane endpoint (arc-region-switch.<region>.api.aws), ensuring execution doesn't depend on the impaired Region.
Verify the complete list of available regions/endpoints at AWS Regions & endpoints.
Security Considerations
IAM Least Privilege
- Scope cross-account IAM roles to only the specific resources referenced in execution blocks (ASG ARNs, Aurora cluster ARNs, Route 53 health check ARNs, Lambda function ARNs, etc.)
- Avoid
* resource wildcards and FullAccess managed policies
- Include condition keys (
aws:SourceArn, aws:SourceAccount, sts:ExternalId) in cross-account trust policies to prevent confused deputy attacks
Execution Reports S3 Bucket
- Enable default encryption (SSE-KMS preferred) on the reports S3 bucket
- Add a bucket policy denying requests where
aws:SecureTransport is false (enforce TLS)
- Restrict bucket access to authorized personnel only — reports contain sensitive infrastructure details (plan config, execution timeline, resource states, alarm history)
- Enable S3 bucket versioning and MFA Delete for tamper protection
- Ensure the bucket is not publicly accessible
Custom Action Lambda Security
- Apply least-privilege execution roles to Custom Action Lambda functions
- Validate inputs within Lambda functions
- Do not embed secrets in Lambda environment variables — use Secrets Manager or Parameter Store
Notification & Event Targets
- Restrict EventBridge rule targets (SNS topics, Lambda functions, etc.) that receive plan-evaluation warnings and execution events to authorized recipients only
- Lock down SNS topic subscription policies and Lambda resource policies so sensitive infrastructure details (plan configuration, resource ARNs, execution state) are not exposed to unauthorized parties
Logging and Monitoring
- Enable AWS CloudTrail for auditing all ARC Region switch API calls
- Configure CloudWatch alarms for unexpected or unauthorized plan executions
- Enable S3 access logging on the execution reports bucket
- See Logging and monitoring for Region switch
Positioning
Customer-facing framing, the Region switch vs Routing Controls comparison, analyst talking
points, and per-audience conversation guidance are maintained in
Positioning. Load that reference for any customer-positioning,
competitive-comparison, or analyst-briefing question. Key rules that always apply:
- Use "Region switch" (plan-based orchestration) framing; do NOT present legacy "routing controls"
/ "ARC clusters" language as the Region switch (plan-based) approach.
- Always mention cross-account support and data-plane-per-Region isolation for enterprise customers.
Documentation Links
The curated documentation index and the "when to link which doc" guidance live in
Documentation Links. Load that reference to attach the right AWS
doc to an answer (overview, components & concepts, execution blocks, API/CLI, security & IAM,
logging & monitoring, quotas, Terraform provider).
Troubleshooting
Customer confuses triggers with health alarms
Triggers are CloudWatch alarms that start plan execution. Application health alarms measure when recovery is complete. They serve different purposes and are configured separately.
Customer assumes Region switch handles data sync
Clarify: Region switch orchestrates failover of existing replicas (e.g., Aurora Global DB promotion). The customer must set up multi-Region data replication independently.
Cross-account execution fails
Usually missing IAM permissions. Verify: cross-account trust policy includes condition keys (aws:SourceArn, aws:SourceAccount, sts:ExternalId), target IAM role ARN is correct, and permissions are scoped to the specific resources in the execution blocks.
Plan evaluation warnings
Warnings indicate IAM, resource, or capacity issues. Fix the underlying issue — but note that passing evaluation alone isn't sufficient; always test by executing plans.
Wrong Regional endpoint used
When deactivating a Region, start-plan-execution MUST be called from the healthy Region. When activating a Region, it MUST be called from the Region being activated. Using the wrong endpoint will fail or produce unexpected behavior. See StartPlanExecution API.
