AWS CLI 実践リファレンス｜よく使うコマンドとユースケース逆引き

「AWS CLI、結局どのコマンドをどう打てばいいの？」——未経験〜駆け出しの方に向けて、AWS CLI v2 を前提に「やりたいこと→コマンド→注意点」で逆引きします。SSO 認証・出力整形・S3・EC2/VPC 調査・ログ追尾・踏み台レス接続まで、コピペで動く断片と早見表つき。

01なぜ CLI か — 再現性・自動化・調査の速さ

マネジメントコンソール（GUI）は、初めて触るサービスの探索や、画面で全体像をつかむのに向いています。一方 AWS CLI が強いのは、同じ操作を何度でも同じ手順で流せること（再現性）、スクリプトに組み込めること（自動化）、そして grep や jq と組み合わせた調査の速さです。

• 再現性：コマンドをそのまま手順書に貼れる。「画面のどこを押したか」より確実で、レビューもしやすい。
• 自動化：棚卸し・タグ付け・バックアップ確認などをシェルや CI に載せられる。
• 調査の速さ：数百リソースから条件に合うものだけを --query や jq で瞬時に抜ける。

この記事は AWS CLI v2 前提です。v2 は Python を同梱し、システムの Python に依存しません。SSO・自動補完・既定のページャなど新機能はすべて v2 側に入ります。v1 は 2026年7月15日にメンテナンスモード（新機能追加なし）へ入り、2027年7月15日にサポート終了予定なので、これから始めるなら v2 一択です。

02導入と認証 — v2 と IAM Identity Center

まず v2 を入れ、バージョンを確認します。

# バージョン確認（aws-cli/2.x なら v2）
aws --version
# 例: aws-cli/2.17.0 Python/3.11.9 Darwin/23.5.0 ...

認証は大きく3通り。おすすめは IAM Identity Center（旧 AWS SSO）です。期限付きの一時認証が自動更新され、長期アクセスキーを手元に置かずに済みます。

① IAM Identity Center（SSO）：ウィザードで対話設定し、ログインします。

# 対話ウィザード（SSOセッション名／開始URL／リージョン／スコープを入力）
aws configure sso
#   SSO session name (Recommended): my-sso
#   SSO start URL [None]: https://my-sso-portal.awsapps.com/start
#   SSO region [None]: us-east-1
#   SSO registration scopes [None]: sso:account:access
#   → ブラウザが開き、アカウントとロールを選ぶ
#   → 既定リージョン・出力形式・プロファイル名を決める

# ログイン（ブラウザで承認。期限切れたら再実行）
aws sso login --profile my-dev-profile

# ログアウト（キャッシュした認証情報を削除）
aws sso logout

ウィザードが書き出す ~/.aws/config はこんな形です。sso-session を複数プロファイルで使い回せます。

[profile my-dev-profile]
sso_session = my-sso
sso_account_id = 123456789011
sso_role_name = ReadOnly
region = ap-northeast-1
output = json

[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

② プロファイルの明示と③ 環境変数。どのアカウント／リージョンに対して打っているかを、常にはっきりさせます。

# コマンドごとにプロファイル・リージョンを明示
aws s3 ls --profile my-dev-profile --region ap-northeast-1

# 環境変数でまとめて指定（そのシェルの間ずっと有効）
export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-northeast-1
aws sts get-caller-identity   # 以後 --profile 省略でOK

03出力を操る — output / query(JMESPath) / jq / pager

CLI の読みやすさは出力整形で決まります。まず --output の使い分けから。

• --output table：人が目で見るとき。整形された表で一覧しやすい。
• --output json：jq や他ツールに渡すとき。既定でもよく使う。
• --output text：1つの値をスクリプトの変数に入れるとき。タブ区切りで扱いやすい。

--query（JMESPath）で、返ってきた結果から必要な列だけを抜き、名前も付け替えられます。

# InstanceId と状態と private IP だけを表で
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name,IP:PrivateIpAddress}' \
  --output table

# text で1値だけ取り出してシェル変数へ
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
echo "$ACCOUNT"

複雑な加工は json 出力 ＋ jq が楽なこともあります。役割分担は「サーバ側で件数を減らす --filters → 見たい形に整える --query か jq」。

# json で出して jq に渡す（running のインスタンスIDを一覧）
aws ec2 describe-instances --output json \
  | jq -r '.Reservations[].Instances[] | select(.State.Name=="running") | .InstanceId'

04ユースケース：S3 — 一覧・コピー・同期・公開確認・容量

日々いちばん打つのは S3 でしょう。ls / cp / sync と、事故防止の --dryrun をセットで覚えます。

# 一覧（プレフィックス配下）
aws s3 ls s3://amzn-s3-demo-bucket/logs/

# コピー（ローカル→S3）
aws s3 cp ./report.csv s3://amzn-s3-demo-bucket/reports/

# 同期は必ず先に --dryrun で「何が起きるか」を確認してから
aws s3 sync ./dist s3://amzn-s3-demo-bucket/site --delete --dryrun
# 問題なければ --dryrun を外して実行

バケットが公開になっていないかの確認。ポリシー起因の公開判定は get-bucket-policy-status の IsPublic、アカウント／バケットのブロック設定は get-public-access-block で見ます。

# バケットポリシーによる公開判定（IsPublic: true なら公開）
aws s3api get-bucket-policy-status --bucket amzn-s3-demo-bucket
# → {"PolicyStatus": {"IsPublic": false}}

# パブリックアクセスブロックの状態
aws s3api get-public-access-block --bucket amzn-s3-demo-bucket

容量とオブジェクト数の把握は、再帰＋サマリで。

aws s3 ls s3://amzn-s3-demo-bucket --recursive --summarize --human-readable
# 末尾に Total Objects と Total Size が出る

05ユースケース：EC2 / VPC 調査 — 必要な列だけ抜く

調査は「全部 JSON を眺める」のではなく、--filters で母数を絞り、--query で列を抜くのが基本です。

# 稼働中インスタンスの Id / 状態 / private IP / 名前タグ を表で
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].{Id:InstanceId,State:State.Name,IP:PrivateIpAddress,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

セキュリティグループの中身を確認するとき（インバウンドの穴を洗い出す）。

# SG のインバウンドを、ポートと許可元CIDRだけ抜いて確認
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions[].{From:FromPort,To:ToPort,Proto:IpProtocol,CIDR:IpRanges[].CidrIp}' \
  --output table

06ユースケース：運用 — ログ追尾・踏み台レス接続・パラメータ

ログの追尾は aws logs tail が便利。--follow で新着を流し続け、--since で開始時刻、--filter-pattern で絞れます。

# 直近を表示しつつ新着を追い続ける
aws logs tail /aws/lambda/my-func --follow

# 30分前から、短い書式で、ERROR を含む行だけ
aws logs tail /aws/lambda/my-func --since 30m --format short --filter-pattern "ERROR"

踏み台（Bastion）レスの接続は Session Manager。SSH ポートを開けずにシェルへ入れます。

# インスタンスにシェル接続（22番ポート開放も鍵配布も不要）
aws ssm start-session --target i-0123456789abcdef0

使う前提は3つ。(1) 手元に Session Manager プラグイン（session-manager-plugin）が入っていること（CLI 本体とは別インストール）。(2) 対象に SSM エージェントが動き、インスタンスプロファイルに AmazonSSMManagedInstanceCore が付いていること。(3) 自分に ssm:StartSession 権限があること。プライベートサブネットなら SSM 用 VPC エンドポイントも要ります。

設定値・機密の取得は Parameter Store。SecureString は --with-decryption で復号します。

# SecureString を復号して取得
aws ssm get-parameter --name /myapp/db/password --with-decryption \
  --query Parameter.Value --output text

07ユースケース：本人確認・コスト・雛形

「いま自分は誰として叩いているか」の確認は、破壊的操作の前の儀式にしてください。

aws sts get-caller-identity
# → UserId / Account / Arn が返る。Account 番号とロール名を必ず目視

コストのさわりは Cost Explorer API。月次の発生コストをサービス別に集計できます（詳細な分析はコンソールの Cost Explorer が見やすい）。

# 今月の日次コストをサービス別に集計（さわり）
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-07-16 \
  --granularity DAILY --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

コマンドの雛形は --generate-cli-skeleton で。入力 JSON のひな形を出し、埋めてから --cli-input-json で流すと、複雑なコマンドを再現しやすくなります。

# 入力の雛形を JSON で出力
aws ec2 run-instances --generate-cli-skeleton input > run-instances.json
# 値を埋めてから流す（レビュー・再現がしやすい）
aws ec2 run-instances --cli-input-json file://run-instances.json

08事故らないコツ — 取り違え・破壊操作・権限

CLI は速い分、間違いも速く広がります。現場で効く順に。

• プロファイル取り違え防止：操作前に aws sts get-caller-identity でアカウントとロールを確認。--profile は省略せず明示、シェルのプロンプトに $AWS_PROFILE を表示させると事故が激減します。
• 破壊的操作は --dryrun から：s3 sync/rm、ec2 の削除系はまず --dryrun。対応していないコマンドは、影響範囲を describe で先に洗う。
• リージョン確認：--region 未指定だと既定リージョンに飛ぶ。別リージョンのつもりが本番に…を防ぐため、重要操作は --region を明示。
• MFA と最小権限：日常は read-only ロールで入り、変更操作のときだけ権限の高いロールへ切り替える（assume-role）。人の権限には MFA を必須に。
• 本番は「読む」から：新しい環境ではまず describe/list 系で現状把握。書き込みは影響を理解してから。

複数アカウント・複数クラウドをまたぐ権限の統制は、CLI 単体ではなく組織設計の話になります。考え方は Entra × AWS の ID 統制で整理しています。ネットワークや権限の土台からやり直したい方は クラウドエンジニアの基礎（TCP/IP）もどうぞ。

09早見表 — やりたいこと→コマンド 逆引き

コピペ用の逆引きです。<...> は自分の値に置き換えてください。

--query（JMESPath）の頻出パターンも小さくまとめます。

10よくある質問（FAQ）

EMW は札幌の AWS コンサルです。基礎を積む姿勢を大切にする仲間を探しています。採用情報・カジュアル面談はこちら。