MENU
  1. ホーム
  2. Column
  3. AWS CLIで開発が爆速になる！セットアップからCloudWatch・Lambda活用まで実用コマンド付き

AWS CLIで開発が爆速になる！セットアップからCloudWatch・Lambda活用まで実用コマンド付き

Column
目次

「またAWSコンソール開くの…？」というストレスから解放されよう

AWS開発者なら、誰もが一度は感じたことがあるはずです。

「Lambdaの環境変数だけ確認したいのに、わざわざブラウザ開いてMFA入れてリージョン切り替えて…」「CloudWatchのログ画面、なんでこんなに重いの？」「複数アカウントを行き来してたら、今どっちの環境にいるか分からなくなった」

AWSコンソールは便利ですが、毎日の「ちょっと確認したい」作業には正直オーバースペック。ページ遷移は遅いし、リージョン間違いで事故るリスクもあるし、なにより画面操作の履歴が残らないから「あれ、さっき何見たっけ？」になりがちです。

そんな日常作業を一気に効率化してくれるのが AWS CLI（Command Line Interface） です。ターミナルから1行コマンドを打つだけで、Lambdaの呼び出しもCloudWatchログの確認もS3のファイル操作も完結します。慣れればコンソールを開くより圧倒的に速い。これがCLIの威力です。

この記事では、AWS CLIをまだ触ったことがない人でも、今日から実務で使えるレベルに到達できるよう、インストールから日常運用コマンドまでまるっと解説します。記事を読み終わる頃には、コンソールをポチポチする回数が確実に減るはずです。

AWS CLIとは？GUIに対する3つの強み

AWS CLI は、AWSの全サービスをコマンドラインから操作できる公式ツールです。現行はv2系（2020年正式リリース）が標準で、Python依存が解消されてスタンドアロンで動くようになりました。

「コマンドって難しそう…」と思うかもしれませんが、AWS CLIはaws <サービス名> <アクション> という超シンプルな構造なので、慣れるとむしろGUIより直感的です。

強み1：圧倒的に速い

「Lambdaの環境変数を確認する」という作業を比較してみましょう。

方法 ステップ数 所要時間
コンソール ログイン → MFA → Lambda画面 → 関数選択 → 設定タブ → 環境変数 30〜60秒
AWS CLI aws lambda get-function-configuration 一発 2〜3秒

1日に何度も繰り返す作業だと、この差は積み上がって大きな時間節約になります。

強み2：自動化・スクリプト化できる

CLIコマンドはシェルスクリプトに組み込めます。「毎朝、本番環境のエラーログをまとめて取得する」「CI/CDの中でLambdaをデプロイする」といった定型作業を完全自動化できるのが、GUIには真似できない最大の利点です。

強み3：操作履歴がターミナルに残る

「さっき何のコマンド打ったっけ？」は history コマンドで一発確認。GUI操作だと「どの画面で何を変更したか」を記録するのが難しいですが、CLIなら全操作がテキストで残ります。トラブルシュート時の証跡としても優秀です。

インストール手順（OS別）

AWS CLI v2を、お使いのOSに合わせてインストールしましょう。すべて公式の手順をベースにした、最も簡単な方法を紹介します。

macOSの場合（Homebrew推奨）

Macユーザーは Homebrew でインストールするのが一番楽です。

# Homebrewでインストール
brew install awscli

# バージョン確認（aws-cli/2.x.x が出ればOK）
aws --version

Homebrewが入っていない方は、公式の.pkgインストーラーでもOKです。

# 公式インストーラー版
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

Windowsの場合（MSIインストーラー）

Windowsは公式のMSIインストーラーをダウンロードして実行するのが一番簡単です。

  • https://awscli.amazonaws.com/AWSCLIV2.msi をダウンロード
  • ダブルクリックでインストール（ウィザードに従うだけ）
  • PowerShellまたはコマンドプロンプトで aws --version を実行して確認

WSL2を使っている方は、Linuxの手順でインストールする方が普段の開発フローと馴染みが良いです。

Linuxの場合（公式バンドル）

# インストーラーをダウンロード
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# 解凍
unzip awscliv2.zip

# インストール
sudo ./aws/install

# 確認
aws --version

ARM環境（Apple Silicon Mac上のLinuxコンテナなど）の場合は、URLの x86_64 を aarch64 に置き換えてください。

初期設定：aws configure で認証情報を登録

インストールが終わったら、AWSアカウントへのアクセス情報を設定します。ここがAWS CLIの「最初の関門」ですが、流れさえ押さえれば3分で終わります。

Step 1：IAMユーザーとアクセスキーを作成

CLIから操作するには、AWSアカウントの認証情報（アクセスキー）が必要です。ルートユーザーは絶対に使わず、必ずIAMユーザーを作成してください。

  1. AWSコンソールにログインして、IAM画面を開く
  2. 「ユーザー」→「ユーザーを作成」
  3. ユーザー名（例：cli-user）を設定
  4. 必要な権限を持つポリシーをアタッチ（最小権限の原則で）
  5. 作成後、ユーザー詳細から「アクセスキーを作成」
  6. アクセスキーIDとシークレットアクセスキーをメモ（シークレットは二度と表示されないので注意）

権限ポリシーは、最初は AdministratorAccess でも構いませんが、本格運用に入る前に必要最小限に絞り込むのがセキュリティのベストプラクティスです。

Step 2：aws configure を実行

ターミナルで以下のコマンドを実行します。対話形式で4つの項目を聞かれるので、順番に入力してください。

$ aws configure
AWS Access Key ID [None]: AKIAXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: ap-northeast-1
Default output format [None]: json

各項目の意味はこちら。

  • Access Key ID / Secret Access Key：先ほどIAMで作成したキー
  • Default region name：普段使うリージョン（東京は ap-northeast-1、米国東部なら us-east-1）
  • Default output format：CLIの出力形式。json（推奨）/ yaml / text / table から選択

Step 3：設定ファイルの保存先を理解する

aws configure で入力した情報は、ホームディレクトリ配下の2つのファイルに保存されます。

# 認証情報（アクセスキーなどの機密情報）
~/.aws/credentials

# 設定情報（リージョンや出力形式）
~/.aws/config

中身はこんな感じのテキストファイルです。

# ~/.aws/credentials
[default]
aws_access_key_id = AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# ~/.aws/config
[default]
region = ap-northeast-1
output = json

credentialsファイルは絶対にGitにコミットしないこと。.gitignore に .aws/ を入れて、間違って共有しないようにしましょう。

Step 4：動作確認

設定がうまくいったか、簡単なコマンドで試してみましょう。

# 自分のアカウント情報を確認
aws sts get-caller-identity

こんな出力が返ってきたら成功です。

{
    "UserId": "AIDAXXXXXXXXXXXXXXXXX",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/cli-user"
}

複数環境の切り替え：プロファイル機能をマスターしよう

実務では「開発環境」「ステージング環境」「本番環境」など、複数のAWSアカウントを使い分けるのが普通です。CLIではプロファイル機能を使うことで、コマンドごとに環境を切り替えられます。

追加プロファイルの作成

--profile オプションを付けて aws configure を実行するだけ。

# 開発環境用プロファイル
aws configure --profile dev

# 本番環境用プロファイル
aws configure --profile prod

これで ~/.aws/credentials に複数の認証情報が並びます。

[default]
aws_access_key_id = AKIA...DEFAULT
aws_secret_access_key = ...

[dev]
aws_access_key_id = AKIA...DEV
aws_secret_access_key = ...

[prod]
aws_access_key_id = AKIA...PROD
aws_secret_access_key = ...

プロファイルを使う2つの方法

方法1：コマンドごとに --profile を指定する

# 開発環境のS3バケット一覧
aws s3 ls --profile dev

# 本番環境のLambda一覧
aws lambda list-functions --profile prod

方法2：環境変数 AWS_PROFILE でセッション全体に適用

# 現在のシェルで使うプロファイルを切り替え
export AWS_PROFILE=dev

# これ以降のコマンドはすべて dev プロファイルが使われる
aws s3 ls
aws lambda list-functions

「いま自分がどのプロファイルにいるか」を常に意識するために、シェルのプロンプトに表示する設定を入れている開発者も多いです。本番環境への誤操作を防ぐためにも、強くおすすめします。

実用コマンド集①：CloudWatchログを爆速で確認

CLIの真価が発揮される代表例が、CloudWatchログの調査です。コンソールでログを追うのは正直遅くて辛いですが、CLIならほぼリアルタイムで快適にログを追えます。

ロググループ一覧の取得

# すべてのロググループを表示
aws logs describe-log-groups

# 名前でフィルタ（Lambdaのログだけ見る）
aws logs describe-log-groups --log-group-name-prefix "/aws/lambda/"

リアルタイムでログを追う（tail）

logs tail コマンドを使うと、Linuxの tail -f のようにリアルタイムでログを流し見できます。Lambdaのデバッグ時に超便利。

# Lambda関数のログをリアルタイム監視
aws logs tail /aws/lambda/my-function --follow

# 過去30分のログを表示
aws logs tail /aws/lambda/my-function --since 30m

# エラーだけフィルタ
aws logs tail /aws/lambda/my-function --filter-pattern "ERROR" --since 1h

--follow を付けるとログが流れ続けるので、テストでLambdaを叩きながら出力をリアルタイムで見る、なんて使い方ができます。

特定の時刻範囲でログ検索

# 昨日の特定時刻からのログを取得
aws logs filter-log-events \
  --log-group-name /aws/lambda/my-function \
  --start-time $(date -v-1d +%s)000 \
  --filter-pattern "Exception"

「昨日の本番障害、何時何分に何が起きてたっけ？」を調査するときに、ピンポイントでログを引ける強力な機能です。

実用コマンド集②：Lambdaの確認・実行

Lambdaも、CLIで操作するとコンソールより断然速い領域です。「環境変数だけ確認したい」「テスト実行だけしたい」というケースでは、CLI一択。

関数一覧と詳細取得

# 関数一覧を取得
aws lambda list-functions

# 関数名だけ抽出（--queryでJSONを絞る）
aws lambda list-functions --query "Functions[*].FunctionName" --output text

# 特定関数の詳細
aws lambda get-function --function-name my-function

環境変数の確認

# 関数の設定を全部取得
aws lambda get-function-configuration --function-name my-function

# 環境変数だけピンポイントで取得
aws lambda get-function-configuration \
  --function-name my-function \
  --query "Environment.Variables"

これだけで「APIキーちゃんと設定されてる？」「DB接続文字列、正しい値入ってる？」が一瞬で確認できます。コンソールで開いてタブ切り替えて…という手間がゼロ。

Lambdaを手動実行（invoke）

# シンプルな呼び出し（戻り値はoutput.jsonに保存）
aws lambda invoke \
  --function-name my-function \
  --payload '{"key1": "value1"}' \
  --cli-binary-format raw-in-base64-out \
  output.json

# 結果を確認
cat output.json

黄金パターン：invoke + tail でデバッグ

2つのターミナルを開いて、片方でログを tail しながら、もう片方で invoke する。これがLambdaデバッグの最強コンボです。

# ターミナル1：ログをリアルタイム監視
aws logs tail /aws/lambda/my-function --follow

# ターミナル2：関数を実行（ターミナル1にログが即流れる）
aws lambda invoke \
  --function-name my-function \
  --payload '{"test": true}' \
  --cli-binary-format raw-in-base64-out \
  /tmp/result.json

コンソールでログ画面をリロードし続ける作業から完全に解放されます。Lambda開発の生産性が体感3倍くらい上がる手法なので、絶対に習得を推奨します。

実用コマンド集③：S3・EC2・IAM

その他のよく使うサービスもまとめて押さえておきましょう。コピペで使えるよう実用コマンドを並べます。

S3：ファイル操作の定番

# バケット一覧
aws s3 ls

# 特定バケットの中身を表示
aws s3 ls s3://my-bucket/

# サブディレクトリも含めて再帰的に表示
aws s3 ls s3://my-bucket/ --recursive

# ファイルをアップロード
aws s3 cp ./local-file.txt s3://my-bucket/path/

# ファイルをダウンロード
aws s3 cp s3://my-bucket/path/file.txt ./

# ディレクトリ全体を同期（差分のみ転送）
aws s3 sync ./local-folder s3://my-bucket/remote-folder/

sync は特に便利で、変更があったファイルだけ転送してくれます。静的サイトのデプロイなどに重宝します。

EC2：インスタンスの確認・起動・停止

# インスタンス一覧（要点だけ表示）
aws ec2 describe-instances \
  --query "Reservations[*].Instances[*].[InstanceId,State.Name,Tags[?Key=='Name'].Value|[0]]" \
  --output table

# 特定インスタンスを起動
aws ec2 start-instances --instance-ids i-0123456789abcdef0

# 停止
aws ec2 stop-instances --instance-ids i-0123456789abcdef0

IAM：自分の権限を確認

# 自分のIAMユーザー情報
aws iam get-user

# 自分にアタッチされているポリシー
aws iam list-attached-user-policies --user-name cli-user

# 所属しているグループ
aws iam list-groups-for-user --user-name cli-user

CLI作業を快適にする3つのTips

ここからは、AWS CLIをさらに快適に使うためのちょっとしたコツを紹介します。これを知ってるか知らないかで、生産性が大きく変わります。

Tip 1：–query でJSONを絞り込む（jq不要）

AWS CLIのレスポンスは情報が多すぎて、目当ての値を見つけるのが大変。そこで活躍するのが --query オプション。JMESPath という記法で、JSONから必要な値だけを抜き出せます。

# Lambda関数の名前だけ一覧で取得
aws lambda list-functions \
  --query "Functions[*].FunctionName" \
  --output text

# 実行中のEC2インスタンスIDだけ取得
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[*].Instances[*].InstanceId" \
  --output text

# S3バケットの作成日とサイズ順にソート
aws s3api list-buckets \
  --query "Buckets[*].[Name,CreationDate]" \
  --output table

jqをパイプで繋がなくてもAWS CLI単体で完結するので、シェルスクリプトでも簡潔に書けます。

Tip 2：エイリアスで頻出コマンドを短縮

よく使うコマンドはシェルのエイリアスに登録すると、打鍵数が劇的に減ります。~/.zshrc や ~/.bashrc に追加しましょう。

# ~/.zshrc に追記
alias awsme="aws sts get-caller-identity"
alias awslogs="aws logs tail --follow"
alias awsls="aws s3 ls"
alias awswho='echo "Profile: $AWS_PROFILE"'

# 設定を反映
source ~/.zshrc

これで awsme 一発で「いまどのアカウントにいるか」が確認できます。

Tip 3：aws-vault でセキュアに認証情報を管理

~/.aws/credentials に平文でアクセスキーが書かれているのは、実はセキュリティ的に推奨されません。aws-vaultを使うと、OSのキーチェーンに暗号化して保存できます。

# Macでインストール
brew install aws-vault

# プロファイル追加（キーチェーンに暗号化保存）
aws-vault add dev

# プロファイルを使ってコマンド実行
aws-vault exec dev -- aws s3 ls

本番環境のキーを扱うなら、aws-vaultやAWS SSO（IAM Identity Center）などの仕組みを使うのが現代のベストプラクティスです。

よくあるエラーと対処法

AWS CLIを使い始めて最初にぶつかりがちなエラーをまとめておきます。

エラー1：Unable to locate credentials

Unable to locate credentials. You can configure credentials by running "aws configure".

原因：認証情報が見つからない。aws configure をまだ実行していないか、AWS_PROFILE 環境変数が存在しないプロファイル名を指している。

対処法：

# 設定済みのプロファイル一覧を確認
aws configure list-profiles

# 現在使われている設定を表示
aws configure list

# 必要なら再設定
aws configure --profile dev

エラー2：You must specify a region

You must specify a region. You can also configure your region by running "aws configure".

原因：リージョンが設定されていない、もしくはコマンドで指定されていない。

対処法：3つの方法のどれかで指定できます。

# 方法1：コマンドで都度指定
aws s3 ls --region ap-northeast-1

# 方法2：環境変数で指定
export AWS_REGION=ap-northeast-1

# 方法3：プロファイルにデフォルトリージョン設定
aws configure set region ap-northeast-1 --profile dev

エラー3：AccessDenied / not authorized

An error occurred (AccessDenied) when calling the ListBuckets operation: 
User: arn:aws:iam::123456789012:user/cli-user is not authorized to perform: s3:ListAllMyBuckets

原因：IAMユーザーに該当の操作を行う権限がない。

対処法：IAMコンソールでユーザーにポリシーを追加するか、必要な権限を持つロールにスイッチします。エラーメッセージに必要なアクション（上記なら s3:ListAllMyBuckets）が書いてあるので、それを許可するポリシーを当てればOKです。

まとめ：今日からCLIを日常運用に組み込もう

AWS CLIの基本セットアップから、日常運用で使う代表的なコマンドまで一気に解説してきました。最後にポイントを整理しておきます。

  • セットアップ：インストール → aws configure で認証情報登録 → aws sts get-caller-identity で動作確認
  • プロファイル：複数環境は --profile または AWS_PROFILE で切り替え。本番事故防止の最重要ポイント
  • CloudWatch：logs tail --follow でリアルタイム監視。デバッグ生産性が劇的に上がる
  • Lambda：get-function-configuration で環境変数を即確認、invoke + tail の黄金コンボでデバッグ加速
  • –query：JSONレスポンスを絞り込んで、必要な情報だけ抽出する必修テクニック

「コンソールでやってたあれ、CLIならどうやるんだろう？」と疑問に思ったら、まずは aws <サービス名> help で調べてみてください。AWS CLIは公式リファレンスもよくできているので、AWS CLI Command Reference をブックマークしておくと最強です。

慣れるまでは「コンソールの方が早かったな…」と思うかもしれませんが、3日も使えば必ず逆転します。毎日触るからこそ、ちょっとした効率化の積み重ねが大きな差になるのがCLIの世界。今日からあなたの開発フローに組み込んで、AWS作業を爆速化してください。

【次回予告】AI × AWS CLI でログ調査を革命的に変える

ここまでで「AWS CLIの基礎」は完璧。でも、これだけで終わるのはもったいない。次回は、AIをAWS CLIに組み合わせて、CloudWatchのエラー調査を自動化する方法を解説します。

「ログを大量に取得して、AIに渡してエラー原因を要約させる」「障害発生時のログから、関連する複数サービスの動きを横断的に分析させる」など、CLIとAIを組み合わせたモダンな運用テクニックを実践形式で紹介する予定です。お楽しみに。

AWS CLIをマスターしたら読みたい関連記事

AWS CLIの基本を押さえたら、次はサーバーレス開発やインフラ管理の領域も強化していきましょう。CLIスキルが活きる関連トピックの記事を厳選しました。

AWS・サーバーレス開発を深める

ターミナル・開発環境を整える

Column
AWS AWS CLI CloudWatch Lambda S3 インフラ クラウド 開発者ツール
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

関連記事

目次