> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Accessing Bedrock With Command Line Part 2
> Explains four AWS CLI authentication methods for accessing Amazon Bedrock and Bedrock Runtime, comparing long lived keys, CLI v2 browser login, IAM Identity Center SSO, and CloudShell.
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.
***
## Method 2 — AWS CLI v2 `login` (browser-backed, short-lived credentials)
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):
```bash theme={null}
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](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.
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](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.
From CloudShell you can run both Bedrock control plane operations and Bedrock Runtime requests. Example: list Bedrock guardrails from CloudShell.
Command (bash):
```bash theme={null}
~ $ aws bedrock list-guardrails
```
Sample output (JSON):
```json theme={null}
{
"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](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](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](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](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.