signin:GetConsoleAuthorizationConfiguration ignores --endpoint-url

[Frichetten]

Describe the bug

tl;dr: aws signin get-console-authorization-configuration accepts --endpoint-url, but the request is not sent to that endpoint. Instead, the Signin endpoint rules mark this operation as a control-plane operation and resolve it to the normal AWS Signin endpoint: https://signin.{Region}.api.aws

That is surprising because --endpoint-url is a global AWS CLI option, and I would expect it to override the service endpoint. It can also create false positives during testing: the command may appear to work against a supplied endpoint even though that endpoint was never called.

Relevant Source Code

I believe the reason for this is that GetConsoleAuthorizationConfiguration is marked as IsControlPlane=true in the service model.

The endpoint rules define IsControlPlane here.

The control-plane rule matches first and returns https://signin.{Region}.api.aws: https://github.com/aws/aws-cli/blob/2.35.11/awscli/botocore/data/signin/2023-01-01/endpoint-rule-set-1.json#L38-L106

The generic custom endpoint rule exists, but it appears later in the rule set: https://github.com/aws/aws-cli/blob/2.35.11/awscli/botocore/data/signin/2023-01-01/endpoint-rule-set-1.json#L934-L989

Since the control-plane branch does not check whether Endpoint is set, it wins before the custom endpoint rule can apply.

Impact

This makes endpoint override testing unreliable for this operation. A user can provide an explicit endpoint and get a valid-looking response, while the actual request went to AWS’s default Signin endpoint.

For security testing and endpoint validation, that creates an easy false positive.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

The CLI should send the request to: https://api.eu-west-1.prod.kams.kuiperces.aws.dev/get-console-authorization-configuration

If custom endpoints are intentionally unsupported for this Signin operation, the CLI should fail with a clear error instead of silently routing the request elsewhere.

Current Behavior

The debug output shows that the custom endpoint is passed into the endpoint provider:

botocore.endpoint - DEBUG - Sending http request: <AWSPreparedRequest stream_output=False, method=POST, url=https://signin.us-east-1.api.aws/get-console-authorization-configuration

Reproduction Steps

AWS CLI version tested: aws-cli/2.35.11 Python/3.14.6 Darwin/25.5.0 source/arm64

Run:

aws signin get-console-authorization-configuration \
  --endpoint-url https://api.eu-west-1.prod.kams.kuiperces.aws.dev \
  --debug

Possible Solution

Possible fixes

One of these would make the behavior clearer:

• Let an explicit --endpoint-url take precedence over the Signin control-plane rule.
• Add an Endpoint check to the control-plane branch so it only applies when no custom endpoint was provided.
• If this behavior is intentional, return a clear CLI error when --endpoint-url is used with this operation.

Additional Information/Context

Apologies if this should have been filed against the AWS CLI repo, I wasn't sure which would be the right one.

SDK version used

aws-cli/2.35.11 Python/3.14.6 Darwin/25.5.0 source/arm64

Environment details (OS name and version, etc.)

MacOS

[adev-code]

Thanks for reaching out @Frichetten . After checking the service model, this is expected behavior driven by the Sign-In service model (not botocore or the CLI). Sign-In operations are tagged as either control plane or data plane, and each family resolves to a different endpoint. I've reached out to the service team and asked them to document the control-plane vs data-plane endpoint behavior.

Internal Ref: P472610274