Accessing Bedrock With Command Line Part 2

In this lesson we cover four supported ways to authenticate the AWS Command Line Interface (CLI) when interacting with Amazon Bedrock (management plane) or Bedrock Runtime (inference). All four approaches use the AWS CLI; they differ in how credentials are obtained and managed. Choose the method that best fits your security posture, operational model, and whether you work locally or in the browser. Overview — four authentication methods

Method 1: Long-lived programmatic credentials (IAM user)
Method 2: AWS CLI v2 login (browser-based, short-lived)
Method 3: AWS IAM Identity Center (SSO) with a trusted IdP
Method 4: CloudShell (console-embedded terminal using your console session)

Use this quick comparison to pick an approach:

Method	Best for	Credentials type	Notes
Long-lived programmatic credentials (IAM user)	Legacy scripts or CI systems that can’t use STS	Long-lived access key ID + secret	Simple but higher risk — rotate frequently
AWS CLI v2 `login`	Individual developers who want short-lived CLI sessions	Short-lived, browser-backed credentials	Good for local work without storing long-lived keys
AWS IAM Identity Center (SSO)	Enterprises with many accounts and centralized identity	STS temporary credentials via Identity Center	Scales across accounts and maps groups to roles
CloudShell	Quick tasks from browser; no local CLI install	Temporary credentials inherited from console session	Convenient and region-aware; ideal for quick testing

Method 1 — Long-lived programmatic credentials (IAM user)

Historically, developers created an IAM user and generated programmatic credentials (an access key ID and a secret access key). These keys are stored locally (for example in ~/.aws/credentials) and the AWS CLI reads them for every API call.

Programmatic credentials cannot be used to sign in to the AWS Management Console.
Typically stored in ~/.aws/credentials on a developer workstation or in environment variables for automation.
Simple to use, but high risk if leaked.

Long-lived access keys are high risk: if they are leaked, an attacker can use them until you rotate or revoke them. Prefer short-lived credentials (browser/OIDC/SAML/STS-based) where possible.

When you must use programmatic keys (for legacy tooling or constrained CI), enforce strict rotation, minimal IAM permissions, and use service control policies or session boundaries where available.

AWS CLI v2 provides a login command that opens a browser to authenticate your console identity and issues short-lived credentials for the CLI to use. This avoids storing long-lived keys on disk and maps CLI sessions to your browser authentication.

The CLI attempts to open your default browser. If it cannot, it prints a URL you can copy/paste to authenticate.
A named profile keeps session contexts separated so you can maintain multiple logged-in identities.

Example invocation (bash):

alistair@HODEI-LEGION5:~$ aws login --profile current-console-user-profile
Attempting to open your default browser.
If the browser does not open, open the following URL:

https://eu-west-1.signin.aws.amazon.com/v1/authorize?response_type=code&client_id=arn%3Aaws%3Asignin%3AASIsignin%3Asame-device&state=95555403-5298-4392-be4a-d038e71180e9&code_challenge_method=SHA-256&scope=openid&redirect_uri=http%3A%2F%2F127.0.0.1%3A40857%2Foauth%2Fcallback&code_challenge=Q1aNJFluBnLxDjsxkMW3hSaTN4gJbYEx-ydegWPlXhc

After you authenticate in the browser, the CLI caches temporary programmatic credentials for the named profile.
These credentials automatically expire and reduce long-term exposure compared to static access keys.

Tip: Use descriptive profile names (for example bedrock-dev-profile) and keep different profiles for different accounts or roles to avoid accidental cross-account calls.

Reference: AWS CLI v2 documentation — https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Method 3 — AWS IAM Identity Center (SSO) with a trusted identity provider

Identity Center (formerly AWS Single Sign-On) is designed for organizations that manage multiple AWS accounts and want centralized authentication and authorization.

Identity Center is configured to trust an external identity provider (IdP) such as Microsoft Entra (formerly Azure AD).
Users authenticate with their corporate identity; Identity Center issues temporary STS credentials and provides role mappings for different AWS accounts.
The issued credentials are temporary and expire after the session duration configured in Identity Center.

A diagram titled "Workflow: Method 03 – Identity Center" showing Microsoft Entra and a user authenticating to AWS IAM Identity Center, which then generates temporary credentials to assume IAM roles across AWS accounts.

Why use Identity Center:

Centralizes identity and access management for large orgs.
Simplifies role assignment across many accounts.
Provides auditability and short-lived credentials for CLI/API access.

Reference: AWS IAM Identity Center docs — https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

Method 4 — CloudShell (console-embedded terminal)

CloudShell is a browser-based shell that runs inside the AWS Management Console. It inherits the security context of your console session, so you don’t need to create or store keys locally.

CloudShell includes the AWS CLI preinstalled and supports multiple tabs, file upload/download, and split panes.
The terminal session automatically uses temporary credentials from your console login and respects the currently selected AWS Region.
Ideal for quick administrative tasks or when you can’t install a local CLI.

A dark-blue infographic titled "Workflow: Method 04 – CloudShell" showing a four-step flow: AWS Console → click the CloudShell icon → CloudShell panel opens (browser terminal) → runs under the current security system with no long-lived credentials required.

From CloudShell you can run both Bedrock control plane operations and Bedrock Runtime requests. Example: list Bedrock guardrails from CloudShell. Command (bash):

~ $ aws bedrock list-guardrails

Sample output (JSON):

{
  "guardrails": [
    {
      "id": "o3sfyk8es33h",
      "arn": "arn:aws:bedrock:us-east-1:485186561655:guardrail/o3sfyk8es33h",
      "status": "READY",
      "name": "bedrock-course-guardrail",
      "description": "Blocks unsafe and restricted content\n",
      "version": "DRAFT",
      "createdAt": "2026-02-23T19:30:40+00:00",
      "updatedAt": "2026-02-23T19:43:19.014232+00:00"
    }
  ]
}

Notes:

The above is a control plane operation (AWS Bedrock API). Inference requests against Bedrock Runtime use separate runtime endpoints and may require different parameters.
CloudShell runs in the region selected in the Management Console; open tabs in different regions if needed.

Summary and recommendations

Avoid long-lived access keys for everyday developer use. Use them only when unavoidable and rotate frequently.
Prefer short-lived credentials: AWS CLI v2 login, Identity Center (SSO), or CloudShell.
For enterprise multi-account environments, Identity Center with a trusted IdP (e.g., Microsoft Entra) offers the best scalability and centralized control.
For quick, ad-hoc tasks in a browser, CloudShell provides a secure, zero-install CLI experience.

Links and references

AWS CLI v2 SSO/login: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html
AWS IAM Identity Center: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
AWS CloudShell: https://docs.aws.amazon.com/cloudshell/latest/userguide/what-is-cloudshell.html
Amazon Bedrock documentation: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html

Introduction to Gen AI and LLMs

Introduction to Amazon Bedrock

Getting Started With Amazon Bedrock

Foundation Models in Amazon Bedrock

Basic Concepts of Prompt Engineering

Introduction to Text Generation With Amazon Bedrock

How Foundation Models Process Input

Extract Insights Using Prompt Engineering

Working With Different Task Types

Integrating Amazon Bedrock With Other AWS Services

Build a Marketing Email Generation Application

Introduction to Retrieval Augmentation With Bedrock Knowledge Bases

Best Practices and Optimization

Governance, Safety in Responsible AI

Security

Monitoring and Logging

Taking action with Bedrock Agents

Advanced Topics (Optional)

Final Project

Wrap Up

Accessing Bedrock With Command Line Part 2

Method 1 — Long-lived programmatic credentials (IAM user)

Method 3 — AWS IAM Identity Center (SSO) with a trusted identity provider

Method 4 — CloudShell (console-embedded terminal)

Summary and recommendations

Watch Video

​Method 1 — Long-lived programmatic credentials (IAM user)

​Method 2 — AWS CLI v2 login (browser-backed, short-lived credentials)

​Method 3 — AWS IAM Identity Center (SSO) with a trusted identity provider

​Method 4 — CloudShell (console-embedded terminal)

​Summary and recommendations

Watch Video

Method 1 — Long-lived programmatic credentials (IAM user)

Method 2 — AWS CLI v2 `login` (browser-backed, short-lived credentials)

Method 3 — AWS IAM Identity Center (SSO) with a trusted identity provider

Method 4 — CloudShell (console-embedded terminal)

Summary and recommendations