Create your own
Lesson illustration

Identify AWS Account, Region, Resource ARNs, and Tags

Good to see you again. In the previous lesson, you secured the root user and created a separate administrator identity for normal work. You will now use that administrator session to establish a habit that prevents a large share of early AWS mistakes: before inspecting, changing, or creating anything, confirm which account, which Region, and which identity you are operating in.

By the end of this lesson, you will be able to find these details in both the AWS Management Console and AWS CloudShell, read the essential parts of an Amazon Resource Name (ARN), and inspect resource tags. These are foundational operational skills for labs, production troubleshooting, and SAA-C03 scenarios.


The four pieces of context to confirm

An AWS console page can look familiar even when you are in the wrong operational context. Use this short pre-flight check:

  1. Account — Which AWS account will receive the action and any associated charges?
  2. Identity — Which IAM user or role is making the request?
  3. Region — Which regional endpoint will a regional service use?
  4. Resource metadata — Which precise resource is involved, and what do its ARN and tags tell you?

The first three are especially important because AWS lets you sign in to more than one account or identity in the same browser. A console tab for a development account and a console tab for a production account may look nearly identical, while having very different consequences.

Account ID versus signed-in identity

Every AWS account has a 12-digit account ID, such as 111122223333. It identifies the AWS account boundary. It is not secret, but it is important: use it to distinguish accounts reliably, especially if account aliases or display names are similar.

Your identity is the user or role currently authenticated in that account. In this course, it is likely the named IAM administrator you created in the prior lesson. In a company, it may be a role obtained through IAM Identity Center.

In the upper-right account menu, AWS normally shows both useful clues: the signed-in identity and the account ID.

The AWS Management Console account menu displays the signed-in IAM user “Carlos” and the 12-digit Account ID. AWS may format the ID with hyphens visually; commands and ARNs use the 12 digits without hyphens.

Do not confuse the two:

ItemExampleWhat it tells you
Account ID111122223333The AWS account boundary
IAM user nameyourname-adminA named long-term IAM identity
Role nameReadOnlyRoleA set of permissions assumed temporarily
ARNarn:aws:iam::111122223333:user/yourname-adminThe formal identifier of a specific AWS identity or resource

AWS Management Console - Getting Started Guide

Read the relevant parts of the official AWS Management Console Getting Started Guide. It gives the exact console navigation for locating account information, identifying or switching the Region, and launching CloudShell.

In “Launching AWS CloudShell from the navigation bar in the AWS Management Console” (p. 8), read the CloudShell overview and note the two launch locations. Then, in “Accessing account information in the AWS Management Console” (p. 26), follow the account procedure. Finally, in “Choosing a Region from the navigation bar in the AWS Management Console” (p. 15), read the Region procedure. Focus on the navigation bar: it is your fastest source of account and Region context.

Hands-on: verify your account in the console

Sign in as the separate administrator identity from the previous lesson, not as root.

  1. In the upper-right navigation bar, choose the account name or identity menu.
  2. Record your Account ID in secure notes or your password manager.
  3. Confirm that the displayed identity is your expected administrator user or role.
  4. Choose Account if you want to view the account-management page.

Do not record passwords, access keys, or MFA codes in these notes. An account ID is fine to record.


Region: where a regional request is directed

The Region selector in the navigation bar shows the Region currently selected in the console, for example United States (N. Virginia), whose Region code is us-east-1.

Many resources you will work with later, including EC2 instances, VPCs, subnets, RDS databases, and Lambda functions, are regional. If you cannot find a resource you know exists, your first diagnostic question should be:

Am I viewing the correct account and Region?

This is more productive than immediately assuming that the resource was deleted or that your permissions are broken.

Some services are global, including IAM. An IAM user does not belong to a particular Region, even though you access the IAM console while a Region is displayed in the navigation bar. In contrast, an EC2 instance created in us-east-1 will not appear when you switch the EC2 console to eu-west-1.

Hands-on: identify and deliberately switch Region

  1. Find the Region name in the upper-right navigation bar.
  2. Write down both its friendly name and its Region code if it is shown, for example us-east-1.
  3. Select the Region name and choose a different Region.
  4. Notice that service pages such as EC2 now show the resources for the newly selected Region.
  5. Switch back to your intended learning Region before continuing.

For a personal learning account, keeping most lab resources in one planned Region makes them easier to find and clean up. The exact Region choice will sometimes matter later for service availability, latency, resilience, and price; for now, concentrate on recognizing which Region is active.


CloudShell: a command line already authenticated to your session

AWS CloudShell is a browser-based shell within the console. It includes the AWS CLI and uses temporary credentials associated with your current console session, so you do not need to create or paste access keys merely to run the commands in this lesson.

That distinction is important. Creating long-lived access keys for an administrator just to practice the CLI is an unnecessary security risk. CloudShell offers a controlled alternative.

How to use AWS CloudShell

Watch “How to use AWS CloudShell” by A Cloud Guru for a concise visual introduction to the browser-based terminal and its pre-authenticated AWS CLI environment.

Watch the CloudShell purpose for the reason CloudShell is useful when you do not want to configure a local terminal. Then watch the console launch to see where it appears in the Console and why it does not require you to set up secret access keys.

Open CloudShell from its icon in the Console navigation bar or footer. It can take a short time to initialize on its first launch.

The AWS CloudShell interface shows the command prompt, the Region-specific terminal tab, the new-tab control, Actions menu, full-screen control, and Preferences. The terminal tab’s Region is a useful visible confirmation of CloudShell’s working context.

AWS CloudShell Concepts - AWS CloudShell

Read the official CloudShell interface and Region guidance before running commands. It clarifies which controls affect the shell and why its persistent files and session context are Region-specific.

In “Navigating the AWS CloudShell interface,” read the interface description, using the numbered screenshot to locate the terminal tab and Actions menu. Next, in “Working in AWS Regions,” read the Region behavior. Notice that changing the console Region refreshes CloudShell into an environment for that Region.

Verify account, identity, and Region from CloudShell

At the CloudShell prompt, run:

aws sts get-caller-identity

The result has three fields:

{
  "UserId": "example-unique-identity-value",
  "Account": "111122223333",
  "Arn": "arn:aws:iam::111122223333:user/yourname-admin"
}

Your own output will differ. In particular, the Arn may identify an IAM user or an assumed role, depending on how you signed in. What matters is that:

  • Account is the active AWS account ID for the credentials CloudShell is using.
  • Arn identifies the credential identity making the API call.
  • UserId is another AWS-specific identity identifier, useful in audit records but usually less readable than an ARN.

Compare the Account value from this command with the account ID you found in the console menu. They should match. If they do not, stop and investigate the browser tab, account selection, and role history before doing anything else.

Now inspect the CLI’s effective configuration:

aws configure list

You should see a Region value. You can also display the CloudShell session’s Region environment variable:

printf 'AWS_REGION=%s\n' "$AWS_REGION"

CloudShell normally starts in the Region selected in the Console. However, a CLI command can explicitly target another Region with the --region option, and environment settings can also change the CLI default. Therefore, distinguish:

  • Console Region: the Region shown in the navigation bar.
  • CloudShell tab Region: the Region where the shell environment is running.
  • Effective CLI Region: the Region a particular AWS CLI command actually uses.

For routine work, keep these aligned. If you intentionally use a different Region for one read-only command, make that choice explicit:

aws ec2 describe-regions --region us-east-1

This command lists available EC2 Regions and does not create resources. Avoid using aws configure in CloudShell just to change its Region; the active CloudShell environment settings take precedence. Use the Console Region selector for normal work, or --region when you need a deliberate one-command override.


ARNs: the formal names AWS uses in policies and APIs

An Amazon Resource Name (ARN) is the standard identifier AWS uses to name an identity or resource precisely. You will see ARNs in IAM policies, CloudTrail events, event rules, resource configuration pages, and architecture documentation.

The common ARN structure is:

For a typical commercial AWS account, the partition is aws. Consider this EC2 instance ARN:

arn:aws:ec2:us-east-1:111122223333:instance/i-0123456789abcdef0
ARN componentExample valueMeaning
arnarnIndicates that this is an ARN
PartitionawsThe standard commercial AWS partition
Serviceec2The AWS service namespace
Regionus-east-1The Region for this regional EC2 resource
Account ID111122223333The owning AWS account
Resourceinstance/i-0123456789abcdef0The service-specific resource type and identifier

Do not assume that every ARN contains a value in every field. The structure adapts to the service:

arn:aws:iam::111122223333:user/yourname-admin
arn:aws:s3:::example-learning-bucket

The IAM user ARN has an empty Region field because IAM is global. The S3 bucket ARN has empty Region and account fields in its ARN format, even though the bucket is owned by an account and is created in a Region. ARN formats are service-specific; read them rather than trying to force every ARN into the EC2 pattern.

Hands-on: identify an ARN for your administrator IAM user

Use the IAM user you created in the previous lesson. This is a no-cost way to inspect a real AWS resource without creating infrastructure.

In the Console:

  1. Open IAM.
  2. Choose Users.
  3. Choose your administrator user, such as yourname-admin.
  4. On the user details page, locate the ARN field and copy it.
  5. Identify the partition, service, account ID, and resource portion in that ARN.

Then use CloudShell to obtain the same ARN. Replace the placeholder with your actual IAM user name:

aws iam get-user \
  --user-name yourname-admin \
  --query 'User.Arn' \
  --output text

The console and CLI should show the same IAM user ARN. If the sts get-caller-identity ARN from the earlier command was an assumed-role ARN, it may differ from this IAM user ARN. That is not necessarily an error:

  • get-caller-identity identifies the credentials currently used by CloudShell.
  • iam get-user identifies the specified IAM user resource.

This distinction becomes central when you work with IAM roles in the next module.


Tags: resource metadata that supports ownership and operations

A tag is a key-value pair attached to a supported AWS resource. Tags let people and AWS tools classify resources using meaningful business or operational context.

Examples:

Tag keyTag valueTypical use
EnvironmentdevSeparate development from test or production
Ownerdata-platformIdentify the responsible team
Applicationorder-serviceGroup resources serving one workload
CostCenterfinance-42Attribute and analyze costs
PurposeAWS-LearningMark temporary learning resources clearly

Tags are metadata, not magic. Adding Environment=prod does not protect a resource or make it production-ready. Later, IAM policies can evaluate tags as conditions, and billing tools can use activated cost-allocation tags, but a tag alone does not grant permissions, deny access, encrypt data, or establish ownership.

Also note these practical points:

  • Tag keys and values are generally case-sensitive. Environment and environment are different keys.
  • A resource normally has one value for a given tag key; changing that key updates its value.
  • Not every AWS resource supports tags, and services can differ in their tag limits and rules.
  • Never place passwords, API keys, personal data, or other secrets in tag values. Tags can be visible in consoles, APIs, logs, and cost reports.

Hands-on: add and inspect one harmless tag

On the IAM user details page you opened above:

  1. Select the Tags tab.
  2. Choose Add new tag.
  3. Use Purpose as the key and AWS-Learning as the value.
  4. Save the change.
  5. Confirm that the tag appears in the user’s Tags tab.

Now inspect that same metadata in CloudShell:

aws iam get-user \
  --user-name yourname-admin \
  --query 'User.{Arn:Arn,Tags:Tags}' \
  --output json

You should see both the user’s ARN and the Purpose tag. This demonstrates an important operational pattern: the Console and CLI are different interfaces to the same AWS APIs and resource metadata.

For the remainder of the course, tag any temporary resource you create with a clear purpose and, where appropriate, an owner. When cleanup time comes, those tags make it much easier to locate the resources that belong to a lab.


A practical troubleshooting sequence

When a resource appears to be missing, or when an action produces an unexpected result, check these items in order:

  1. Confirm the account ID in the Console menu or with aws sts get-caller-identity.
  2. Confirm the signed-in identity or role and whether it has the expected permissions.
  3. Confirm the Region in the Console navigation bar and with aws configure list in CloudShell.
  4. Use the ARN to verify the exact resource, its owning account where applicable, service, and Region where applicable.
  5. Inspect tags for environment, application, owner, and purpose clues.

This sequence separates common causes that can otherwise look alike. For example, an empty EC2 console could mean that no instances exist, but it could also mean that you selected the wrong Region, switched accounts, or assumed a role without permission to view them.


Key takeaways

The AWS account ID tells you the account boundary; the signed-in IAM user or role tells you who is acting. The Console navigation bar shows the selected Region, while CloudShell gives you a pre-authenticated CLI environment where aws sts get-caller-identity and aws configure list confirm your active account, identity, and Region.

ARNs provide formal, service-specific identifiers for AWS resources and identities. They often include partition, service, Region, account, and resource components, but global services and S3 use formats with empty fields. Tags are key-value metadata that make ownership, purpose, environment, and cost tracking visible across Console and CLI workflows.

Next, you will set up an AWS Budget alert and verify Free Tier and billing settings, turning the account context you can now identify into a safer cost-management baseline.

Can't find a good explanation? Sign up and we'll make it for you

Sign up