How AWS CLI access to the four BESS accounts works on Andras’s mac since 2026-07-21: AWS IAM Identity Center (SSO) profiles in ~/.aws/config, replacing the old saml2aws (AzureAD) flow. Verified end to end on 2026-07-21.
All four profiles use sso_session = alpiq-sso, sso_role_name = Developer, region = eu-central-1, output = json.
Profile
Account ID
Account name
bessos-dev
794038257734
bit-bessos-dev-interintra-1
bessos-test
071128452852
bit-bessos-test-interintra-1
bessos-int
621553445748
bit-bessos-int-interintra-1
bessos-prod
282467977019
bit-bessos-prod-interintra-1
These are the same four accounts as the deployment matrix in mando AGENTS.md section 14.1 (see Mando Deployment Ceremony).
Login flow
aws sso login --sso-session alpiq-sso opens the browser PKCE flow. One login covers all four profiles; the token is cached under ~/.aws/sso/cache/. aws sso logout ends the session.
With the RTK hook active, plain aws ... prints AWS: ? ? instead of the real result. Always prefix with rtk proxy:
rtk proxy aws sts get-caller-identity --profile bessos-dev.
Same class of hazard as the cargo test RTK false-green documented in AGENTS.md section 11.
Enumerating accounts before profiles exist
To discover accounts/roles when ~/.aws/config has no profiles yet, pull accessToken from the newest ~/.aws/sso/cache/*.json and call the SSO portal API directly:
eu-west-1 is a read-only Identity Center replica. If eu-central-1 is down, a second [sso-session alpiq-sso-dub] with sso_region = eu-west-1 can be added. Not configured today.
saml2aws is left in place but unused.~/.saml2aws (AzureAD provider) still exists; nothing should be driven through it anymore.
Practical use
Primary purpose is reaching AWS resources behind the mando deployment ceremony: