Why the does AWS CLI use different AWS services on darwin (mac) vs. linux? When does the rds describe-db-instances command use STS?

Question

Running

aws --profile=REDACTED --region=REDACTED rds describe-db-instances

fails for me on linux but succeeds on darwin (mac).

It seems that on my linux, a call is made to AWS's Simple Token Service that I don't have permissions to. But for some reason, that call is skipped on my mac.

Why might the first call run by the AWS CLI vary by system? Why would a call to the Simple Token Service be required when using the AWS CLI?

Is there perhaps something related to authentication or session management that I don't have configured properly on the linux machine I'm running on?

---

I confirmed I'm using the same version, aws-cli/1.25.76 Python/3.10.8 Linux/6.0.11 botocore/1.27.75 , on each machine.

At first, the error appeared permissions-related

An error occurred (AccessDenied) when calling the AssumeRole operation: User: REDACTED is not authorized to perform: sts.AssumeRole on resource: REDACTED

I confirmed I do not have sts.AssumeRole .

However, while investigating, I accidentally made a typo and noticed something strange: on darwin, the first call made by the above command appears to be to the rds service, while on linux the first call is to the sts service.

For example,

aws --profile=REDACTED --region=typo-region rds describe-db-instances

yields this on my darwin machine

Could not connect to the endpoint URL: "https://rds.typo-region.amazonaws.com/"

and this on my linux machine

Could not connect to the endpoint URL: "https://sts.typo-region.amazonaws.com/"

I'm not yet familiar enough with how the aws command and it's boto internals work to understand why the extra call to sts is being made on one machine and not the other.

Answer 1

Most likely the profiles are differently configured on the two machines, one is using a "regular" role / profile with ordinary credentials simply set while the other is using a profile with a role_arn set prompting the CLI to perform an AssumeRole call into that target role.

Alternatively it may be the case that one machine has the nested credentials already retrieved and cached, while the other one does not. And if you removed the permissions / changed the trust relationship in the meantime the old credentials are still valid while the new credentials cannot be retrieved.