SVRBC Developers

Appearance

AWS ​

SVRBC has one AWS account, named svrbc, in an AWS Organization. People sign in through IAM Identity Center, not as IAM users, and never as the root user.

Signing in ​

Everyone signs in at the access portal:

https://d-906661105f.awsapps.com/start

The portal lists the svrbc account and the roles you have in it. Choose a role (for example AdministratorAccess) to open the console, or Access keys for short-lived CLI credentials.

The portal’s own Preferences page holds only language and display mode. Everything else about your user is changed by an administrator.

Regions ​

Put new resources in us-west-2 (Oregon). SVRBC is in California, so a West Coast region keeps latency low. Oregon is preferred over us-west-1 (N. California), which is a little closer but costs more, has fewer availability zones, and gets new services later.

IAM Identity Center is the exception: it lives in us-east-1. It was enabled there, and an instance can’t be moved. Opening Identity Center in any other region doesn’t show the instance. Instead it shows either “[InstanceGuard] unexpected state” or a page offering to Enable an instance of IAM Identity Center. Don’t click that. Switch the console to US East (N. Virginia).

Users ​

Users live in the Identity Center directory itself; nothing is synced from an outside identity provider. Administrators manage them under IAM Identity Center → Users (in us-east-1).

Changing a username ​

The console shows the username as read-only, but the API will change it. Verified 2026-10-01 by renaming xcco3x to cco3. From CloudShell in us-east-1:

sh
aws identitystore update-user \
  --region us-east-1 \
  --identity-store-id d-906661105f \
  --user-id <user-id> \
  --operations '[{"AttributePath":"userName","AttributeValue":"<new-name>"}]'

The user ID is the UUID in the URL of the user’s page in the console. The ID doesn’t change, so groups, account assignments and MFA devices, which hang off the ID, should carry over. Confirmed 2026-10-01: cco3 signs in to the portal and the CLI (aws sso login) with its AdministratorAccess assignment intact.

Two traps:

  • --operations must be JSON. The AttributePath=…,AttributeValue=… shorthand is rejected because AttributeValue is a document type.
  • Typing into CloudShell through browser automation corrupts input. It doubled the hyphens inside UUIDs and turned straight quotes into curly ones. Paste the command by hand. If it has to be typed, build the ID and the JSON in shell variables without literal - or " characters.