Customers with restricted AWS regions may see Octopus AWS resources that rely on credentials impacted due to AWS Global STS endpoint changes.

[Clare-Octopus]

Severity

Blocking customers from verifying certain AWS resources aka AWS Accounts, only applies if AWS region restrictions are configured via AWS. Workaround may exist.

Version

All Octopus versions

Latest Version

I could reproduce the problem in the latest build

What happened?

### This issue only applies to customers who have restricted AWS regions or Networking restrictions to AWS regions!

Customers who have restricted AWS regions (specifically US East (N. Virginia) us-east-1) may see issues verifying AWS accounts with the verification error showing a connection issue to sts.us-east-1.amazonaws.com:

Octopus will use the AWS global endpoint when trying to connect to an AWS account. You can see this if I switch my firewall on on my VM:

This global endpoint is controlled by AWS and they have been steadily rolling out some changes to the AWS sts global endpoint Octopus uses for some AWS resources.

According to the AWS website here, the AWS Global endpoint should now point to the region the resource was initiated in (with caveats!):

AWS STS requests to the global endpoint are automatically served in the same AWS Region as your workloads

You can read more about the changes here. But there is a more detailed blog post of the changes here.

There are caveats to that though and it is in this documentation that you can see why this has changed:

With this change, requests to the STS global endpoint will be served locally **if your request originated from AWS Regions that are enabled by default. However, requests to the STS global endpoint will continue to be served in US East (N. Virginia) Region if your request originated from opt-in Regions or if you used STS from outside AWS, such as in your on-premises network or data centers.

US East (N. Virginia) is sts.us-east-1.amazonaws.com which is why customers that have that region blocked are now seeing issues when trying to verify their AWS account.

AWS then goes on to mention:

In addition, for your requests to be served locally, your DNS request for sts.amazonaws.com must be handled by an Amazon DNS Server in Amazon Virtual Private Cloud (Amazon VPC).

If those conditions are not met it looks like:

Requests made to the sts.amazonaws.com endpoints will have a value of us-east-1 for the aws:RequestedRegion condition key, regardless of which Region served the request.

This is also in the AWS official documentation on this website.

It looks like AWS have been rolling out the changes mid 2025 so this will hit customers at different times.

Reproduction

1. Logon to AWS and block the us-east-1 region.
2. Try verifying a previously working AWS account.
3. See the verification fail with us-east-1 being denied access.

Error and Stacktrace

Unable to verify account:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (sts.us-east-1.amazonaws.com:443)

More Information

Initial customer ticket - https://octopuscd.zendesk.com/agent/tickets/184292
RnD - https://octopusdeploy.slack.com/archives/CNHBHV2BX/p1770890777539039

Workaround

You will need to enable the us-east-1 region for now , or allow your networking restrictions to access it until our enginners can find a resolution for this.

Our engineers may be able to code a region field into our AWS resource pages which will default to the global endpoint if left blank but can be hardcoded to a region of chosing.

[Clare-Octopus]

We had another customer reach out about this using a Run an AWS CLI Script step.

In that step you are able to hardcode a region (box in green). However, it looks like this is getting ignored in favour of the AWS Account settings (box in red):

The AWS account is using the global sts endpoint (US-East-1) so that gets used first and will then error out on a deployment as its the AWS account that is used to authenticate to AWS first even before you are deploying to a region.

[Clare-Octopus]

For any customers currently impacted by this, our engineers are working on an Octopus Code change which will add the ability to type in an AWS region to be used (if left blank it will default to the Global endpoint and AWS will decide how that gets routed).

Unfortuantely we have not been able to identify another workaround for this so you will need to unblock the us-east-1 region for now.

We had a similar issue not so long ago with S3 Buckets and so we are producing a similar fix for AWS Accounts. An example of what our S3 Bucket feed looks like is below:

This will be similar to how the AWS Accounts page will look once the fix is in place.

You will need to upgrade to the relevant Octopus version stated in the Fix bot comment when it is available on this Github issue, as we are unable to provide a fix without a code change to Octopus, unfortunately.