AWS CLI is most useful when the commands are explicit, repeatable, and safe to copy into a terminal. This guide focuses on practical EC2, EBS, and S3 workflows after the CLI is already installed. If you still need setup help, start with the AWS CLI installation guide for Ubuntu first.
For the broader route map, see our AWS services for developers guide.
Quick takeaway: Before running EC2, EBS, or S3 commands, verify identity with
aws sts get-caller-identity, pass--profileand--regionexplicitly, and start with read-only commands. Save destructive commands for after you confirm the account, region, and resource IDs.
Who This Guide Is For
This guide is for DevOps engineers, cloud engineers, and developers who already have AWS CLI installed and need a practical command path for everyday AWS work. It is not an installation article; it is a workflow guide for using the CLI without guessing which account or region you are touching.
- You need safe EC2 instance discovery, start, and stop commands.
- You need to inspect EBS volumes before changing storage.
- You need S3 list, copy, and sync examples with guardrails.
- You want copy-paste commands that keep account and region explicit.
Start With Identity, Profile, and Region
Most AWS CLI mistakes start before the service command. The terminal is using a profile, credentials, and a region. Make those explicit in examples and runbooks so the command does not quietly run against the wrong environment.
aws sts get-caller-identity --profile dev --region us-east-1Code language: JavaScript (javascript)aws configure list --profile dev
aws configure get region --profile devCode language: JavaScript (javascript)| Check | Command | Why it matters |
|---|---|---|
| Current identity | aws sts get-caller-identity | Confirms the account, role, or user before touching resources. |
| Configured region | aws configure get region | Avoids querying or changing the wrong region. |
| Profile source | aws configure list | Shows whether values come from config, credentials, or environment variables. |
Safe EC2 Commands
Start with read-only EC2 commands. Once the instance ID and region are confirmed, start or stop operations are straightforward. Avoid terminate commands in shared docs unless the article is specifically about deletion workflows.
aws ec2 describe-instances \
--profile dev \
--region us-east-1 \
--query "Reservations[].Instances[].{ID:InstanceId,State:State.Name,Name:Tags[?Key=='Name']|[0].Value,Type:InstanceType}" \
--output tableCode language: CSS (css)aws ec2 stop-instances \
--profile dev \
--region us-east-1 \
--instance-ids i-0123456789abcdef0aws ec2 start-instances \
--profile dev \
--region us-east-1 \
--instance-ids i-0123456789abcdef0EBS Volume Checks
For EBS, inspect before you change anything. The two most useful questions are: which volumes exist, and which instance is each volume attached to?
aws ec2 describe-volumes \
--profile dev \
--region us-east-1 \
--query "Volumes[].{VolumeId:VolumeId,Size:Size,Type:VolumeType,State:State,Instance:Attachments[0].InstanceId}" \
--output tableCode language: CSS (css)aws ec2 describe-snapshots \
--owner-ids self \
--profile dev \
--region us-east-1 \
--query "Snapshots[].{SnapshotId:SnapshotId,VolumeId:VolumeId,StartTime:StartTime,State:State}" \
--output tableCode language: CSS (css)S3 List, Copy, and Sync Commands
S3 commands are easy to run and easy to overrun. Listing and copying one object are safe starting points. Sync is powerful, but it deserves extra care, especially if you add --delete.
aws s3 ls --profile devaws s3 ls s3://my-app-logs/ --profile dev --region us-east-1Code language: JavaScript (javascript)aws s3 cp ./report.csv s3://my-app-logs/reports/report.csv \
--profile dev \
--region us-east-1Code language: JavaScript (javascript)aws s3 sync ./site-assets s3://my-static-site/assets \
--profile dev \
--region us-east-1Code language: JavaScript (javascript)Command Safety Table
Use this table when turning AWS CLI commands into a team runbook. It separates read-only checks from commands that change running resources or data.
| Command pattern | Changes resources? | Safe default? |
|---|---|---|
aws sts get-caller-identity | No | Yes. Run this first. |
aws ec2 describe-* | No | Yes. Good for discovery. |
aws ec2 stop-instances | Yes | Only after confirming instance ID and owner. |
aws s3 cp local s3://... | Yes | Usually safe for one object, but confirm destination. |
aws s3 sync | Yes | Use carefully; avoid --delete unless intentional. |
Troubleshooting Common AWS CLI Errors
When AWS CLI fails, the error usually points to one of four layers: credentials, permissions, region, or resource ID. Fix those before rewriting the command.
| Error | Likely cause | What to check |
|---|---|---|
Unable to locate credentials | No active credentials for the profile. | Run aws configure list --profile dev and check environment variables. |
AccessDenied | The identity lacks IAM permissions. | Confirm aws sts get-caller-identity and the required policy action. |
| Empty EC2 result | Wrong region or filters. | Pass --region explicitly and remove filters temporarily. |
| S3 bucket not found | Wrong bucket name, region, or account. | List buckets and confirm the expected account ID. |
| Invalid instance or volume ID | Resource ID from another region/account. | Check the region and account before rerunning. |
FAQ
These quick answers cover the AWS CLI mistakes that usually cause production runbook confusion: account identity, profile choice, region drift, and S3 sync risk.
How do I check which AWS account the CLI is using?
Run aws sts get-caller-identity with the same profile and region you plan to use. It returns the account ID, ARN, and user or role identity, which is the fastest sanity check before touching EC2, EBS, or S3.
Should I use named profiles or environment variables?
Use named profiles when you want commands to be explicit and repeatable in documentation or runbooks. Environment variables are useful in automation, but they are easier to forget in a terminal session.
What is the safest AWS CLI command to test access?
Start with read-only commands such as aws sts get-caller-identity, aws ec2 describe-instances, or aws s3 ls. They confirm credentials and permissions without changing resources.
How do I avoid running AWS CLI commands in the wrong region?
Pass –region explicitly in examples and runbooks, or set a default region in the named profile. For production work, explicit –profile and –region flags reduce surprises.
Is aws s3 sync safe to use?
It can be safe, but it is powerful. Always run the source and destination carefully, avoid –delete until you understand the blast radius, and test with a small prefix before syncing a large bucket.
Bottom Line
A good AWS CLI workflow is explicit before it is clever. Verify identity, pass profile and region, use read-only commands first, and only then run commands that change EC2, EBS, or S3 resources.
Leave a Reply