AWS CLI Commands Cheat Sheet

#The AWS CLI Is Your Incident Response Console, Not Just a Provisioning Tool#link

In July 2019, a misconfigured web application firewall exposed an IAM role that could list and read from S3 buckets. The attacker did not need a fancy exploit framework; they used the AWS CLI. Within hours, they enumerated buckets, found a bucket with overly permissive policies, and exfiltrated over 100 million records. The Capital One breach is a reminder that the same command-line interface you use to spin up infrastructure is also the fastest way to understand what an attacker did and to lock things down before they do it again.

IAM: Who Can Do What, and How to Prove It

IAM is the control plane for everything else. The most underused security command in the AWS CLI is `simulate-principal-policy`. It answers the question, 'If this role tried to put an object in that bucket, would it succeed?' without actually granting the permission. That is invaluable during incident response, when you need to confirm whether a compromised role had the access it appears to have.

For a broader view, the credential report is the fastest way to see every IAM user, their access keys, and when those keys were last rotated. The report is base64-encoded, so you need to decode it before it is readable.

S3: The Bucket That Should Not Be Public

S3 misconfigurations remain the most common cause of cloud data leaks. The `put-public-access-block` command is the single most effective guardrail you can apply at the bucket level. It overrides both ACLs and bucket policies, and it takes effect immediately. The Capital One breach exploited an S3 bucket that was readable because of a permissive bucket policy; this command would have blocked that policy from being applied in the first place.

For temporary sharing, presigned URLs are safer than making an object public. They expire, and they do not change the bucket policy. The default expiration is one hour, but you can set it up to seven days.

EC2: Metadata, Security Groups, and the IMDSv2 Mandate

The Capital One attacker used SSRF to reach the EC2 instance metadata service and retrieve IAM role credentials. That attack relied on IMDSv1, which accepts a simple GET request. IMDSv2 requires a session token obtained via a PUT request, which SSRF cannot easily perform. Enforcing IMDSv2 is one of the highest-leverage defensive changes you can make.

Security groups are the other half of EC2 network security. The `describe-security-groups` command is verbose, but `--query` makes it usable. The following command lists every security group that allows SSH from anywhere on the internet.

CloudTrail: The Audit Log You Actually Read

CloudTrail records every API call, but the console is slow for investigation. The `lookup-events` command lets you filter by event name, user, or time range directly from the CLI. This is how you answer, 'Who deleted that S3 bucket policy last Tuesday at 3 a.m.?'

Log file validation is the quiet feature that makes CloudTrail logs tamper-evident. Without it, an attacker with sufficient permissions could delete or modify log files without detection. Enable it once, and CloudTrail will include digest files that let you verify integrity later.

KMS and Secrets Manager: Encryption and Rotation

KMS key rotation is not enabled by default for customer-managed keys. Turning it on is a single command, and it limits the blast radius if a key is ever compromised. The rotation happens annually, and old key material is retained so that previously encrypted data remains decryptable.

Secrets Manager rotation is more involved, but the CLI gives you a way to inspect and trigger it. The `rotate-secret` command requires a Lambda function ARN, so this is not a one-liner. Still, checking the rotation status is a quick way to find secrets that have not been rotated in months.

Common Mistakes That Break Scripts and Security

The AWS CLI defaults are designed for interactive use, not for automation. Two defaults cause the most trouble: pagination and output format. By default, commands like `aws s3api list-buckets` return only the first page of results. In a script, that means you might miss buckets, users, or log entries. The `--no-paginate` flag forces the CLI to retrieve all pages, but it also increases the risk of hitting API rate limits. For large accounts, you should paginate deliberately with `--max-items` and `--starting-token` rather than relying on `--no-paginate`.

Region misconfiguration is the other silent failure. If you do not set `AWS_DEFAULT_REGION` or pass `--region`, the CLI uses the region from your profile, which may not be where your resources live. A `describe-instances` call in the wrong region returns an empty list, which looks like 'no instances' rather than 'wrong region.' Always verify with `aws sts get-caller-identity` and `aws configure get region` before drawing conclusions from an empty result.

• ▪Set `AWS_DEFAULT_REGION` in your environment or pass `--region` explicitly in every script.
• ▪Use `--dry-run` on any command that modifies or deletes resources before running it for real.
• ▪Run `aws sts get-caller-identity` at the start of an investigation to confirm which principal you are actually using.
• ▪Pipe JSON output through `jq` rather than parsing it with `grep` or `cut`; the structure is not guaranteed to be stable across services.
• ▪Enable MFA for any IAM user that can call `iam:*` or `organizations:*`; the CLI will prompt for the token when the session requires it.