As part of our migration to AWS SDK v2, we're updating how AWS Security Token Service (STS) calls are handled. The most significant change is the switch from global STS endpoints to regional STS endpoints. This update aligns with AWS best practices and improves resilience and latency, but it also brings some important considerations for customers.

🔄 What’s Changing?

✅ Default Behavior Moving Forward

1. If no region is specified in the AWS integration:

   • We will use us-east-1 as the default region for all STS calls.

2. If a region is specified in the AWS integration settings:

   • We will use that explicit region for all STS calls.

   • This can be done in the UI in the cloud integration or via the provider.

     

3. If the role being assumed is in GovCloud:

   • We will automatically use us-gov-west-1 for STS calls in that case.

4. If running on a private worker:

   • You can override the STS region by setting the appropriate AWS region environment variables, such as AWS_REGION and AWS_DEFAULT_REGION

📊 Order or Precedence

• Environment variables on private worker

• Region set on integration

• Default region (us-east-1)

👤 What This Means for You

• You don’t need to take any action if you're using standard AWS regions and haven’t specified a region in the integration.

• You can start specifying a region in your AWS integration if you want tighter control over which endpoint is used for STS.

• Customers with GovCloud accounts are automatically handled—no manual configuration is needed.

• If you previously relied on the global endpoint and have region restrictions in your AWS account, using the default region us-east-1 avoids most issues.

• Instead of routing all requests through a single global endpoint, requests go to the AWS region closest to the resources or IAM roles you're working with. This enhances:

  • Performance by reducing latency.

  • Compliance, as some accounts restrict usage of global services.

If you have any questions, please feel free to reach out to our support team.