AWS CLI - コマンドラインでAWSを完全制御

AWS CLIは、Amazon Web Servicesの公式コマンドラインツール。200以上のAWSサービスをターミナルから叩ける。2025年9月現在、v2が主流でかなり使いやすくなった。

日本の開発環境でAWS CLIが解決する現実的な問題

深夜障害対応の救世主

東京リージョン（ap-northeast-1）で運用してる人なら分かるよね。深夜2時にSlackでアラート爆発、寝ぼけ眼でSSHしようとしたらインスタンス死んでる。

EC2インスタンス障害時の対応

またかよ...AWSコンソールをブラウザで開いて、MFAでログインして、リージョン切り替えて...なんてやってる間にダウンタイムは延びる一方。

AWS CLIがあれば、パジャマ姿でも寝ぼけ眼でもターミナルから1発で復旧できる。AWSコンソールのMFA地獄と違って、configファイル1回設定すれば後は楽勝：

## 死んでるインスタンス特定（よく使うから覚えとけ）
aws ec2 describe-instances --filters \"Name=instance-state-name,Values=stopped\" \\
  --query 'Reservations[].Instances[].[InstanceId,Tags[?Key==`Name`].Value|[0]]' --output table

## 緊急再起動（寝ぼけててもコピペで済む）
aws ec2 start-instances --instance-ids $(aws ec2 describe-instances \\
  --filters \"Name=tag:Name,Values=web-server\" \"Name=instance-state-name,Values=stopped\" \\
  --query 'Reservations[].Instances[0].InstanceId' --output text)

CI/CDパイプラインの自動化

GitHub ActionsやJenkinsでAWSリソースをdeployする際、AWS CLIは必須です。特に日本の企業でよくある「staging環境とproduction環境の切り替え」や「複数アカウント管理」が楽になります。AWS CodePipelineやAWS CodeDeployとの連携も簡単です。

コスト管理の自動化

AWSコスト管理の自動化

「また今月のAWS請求額がヤバい...」経理から連絡来て、「何この請求額？」って聞かれた時の絶望感。前月の倍近い請求で、調べたらt3インスタンスが大量に放置されてた。しかも設定したやつもう辞めてるし。AWS CLIなら定期的なコスト監視script組めるから、こういう事故も防げる。

S3とストレージ管理

S3バケットの管理はAWS CLIの得意分野。ファイルのsyncやcp、権限設定、lifecycle管理まで全部コマンドラインで済む。特に大量ファイルの一括操作は、ブラウザじゃ絶対に無理。

v2になってやっと使い物になった

Python地獄から解放されたのが一番デカい。v1だとpython 3.8とboto3のバージョンが合わなくて、「ImportError: No module named 'botocore'」で朝からハマることがよくあった。macOSのシステムPythonが勝手にアップデートされて、pipの依存関係がぐちゃぐちゃになったり。v2は独立してるから、そういうクソみたいな問題はない。

Tab補完がまともに動くようになったのも助かる。aws s3 <Tab><Tab>で候補が出るから、もうStackOverflowでsyncコマンドの構文をググる必要もない。Bash、Zsh、PowerShellどれでも動く。fish shellもプラグインがある。

大企業だとSSO認証が必須だが、IAM Identity Centerにちゃんと対応したのもv2のメリット。前のAWS SSOから名前変わったやつ。Active DirectoryやSAMLとか、大手企業でよくある認証システムとも連携できる。

MFA関連のエラーも減った。以前は「InvalidUserID.NotFound」で何回もロックアウトされて、IT部門に解除してもらうハメになったり。ただし、v2の初期バージョン（2.0.50台）はEKSで「unable to decode certificate」エラーが出て、kubectl使えなくなることがある。これで丸一日ハマった。v2.0.56以降なら大丈夫だけど。

操作ログもCloudTrailで自動記録されるから、「誰がproductionのEC2を止めた？」みたいな犯人探しも楽になった。

日本で使うときのハマりどころ

東京リージョンでのレイテンシ最適化

AWS CLIは東京リージョン（ap-northeast-1）との通信を最適化できます。--region ap-northeast-1をデフォルトに設定すれば、毎回指定する手間も省けます。

日本語ドキュメントとコミュニティ

AWS公式の日本語ドキュメントも結構充実してる。JAWS-UGとかの日本のAWSコミュニティで活発に情報交換されてるし、クラスメソッドのDevelopersIOは実用的な記事が多い。AWSサミットの発表資料も参考になる。

企業のCompliance要件

日本企業でよくある「操作ログをすべて残す」要件も、CloudTrail連携で対応できる。監査で「このEC2誰が削除した？」って聞かれても、ちゃんと証跡が残ってるから安心。

結論：AWS CLIは「あったら便利」じゃなくて「ないと死ぬ」レベルの必須ツール。特にDevOps、インフラエンジニア、そして深夜障害で寿命を削ってる全てのエンジニアにとって、これ以上頼りになるツールはない。一度覚えたら手放せなくなる。

各OSでのインストール方法

macOS: 素直にpkgを使え

Homebrewを使ってる人がほとんどだろうけど、実はAWS公式のpkg installerの方が確実で後でハマらない。macOS Big Sur以降ならApple Silicon対応版もあります：

## 公式installer（推奨）
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

## Homebrew（手軽だがバージョン管理が面倒）
brew install awscli

企業環境あるある: プロキシ設定でcurlが通らない。「curl: (7) Failed to connect to awscli.amazonaws.com port 443: Connection refused」ってエラーが出て詰む。IT部門にファイアウォール申請出しても、「セキュリティチェックが必要」とか言われて2週間待ち。結局ブラウザで手動ダウンロードすることになる。これで朝の時間潰されるの、マジでイライラする。

Windows: WSLじゃないと死ぬ

WindowsでAWS開発するなら、素直にWSL2使え。Nativeでやると文字化けとPATHの問題で地獄を見る。PowerShellでも動くが、Windows Terminalと組み合わせた方が確実：

## WSL2 Ubuntu内で
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Linux（Docker環境含む）

Ubuntu、CentOS、Amazon Linuxなど本番環境やCI/CDでよく使うパターン。AWS EC2での運用やEKSクラスターでの利用も想定：

## 通常のLinux
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

## Docker container内（rootless）
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install --bin-dir ~/.local/bin --install-dir ~/.local/aws-cli

IAM認証とセキュリティ設定

認証設定 - 会社ごとの地獄パターン別攻略法

パターン1: IAM User（個人開発・小規模チーム）

一番シンプルだが、key漏洩で死ぬ：

aws configure
## AWS Access Key ID: AKIA...
## AWS Secret Access Key: ...
## Default region name: ap-northeast-1  # 東京リージョン
## Default output format: json

パターン2: IAM Role + MFA（企業環境）

多くの日本企業で採用されているセキュリティ要件の高い設定。ISO 27001やSOC 2準拠が必要な企業でよく使われる：

## ~/.aws/config
[profile prod]
role_arn = arn:aws:iam::123456789012:role/DevOpsRole
source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/your-username
region = ap-northeast-1

## 使用時
aws sts get-caller-identity --profile prod
## MFA token入力を求められる

パターン3: SSO（大企業でよくある）

aws configure sso
## SSO session name: company-sso
## SSO start URL: https://company.awsapps.com/start
## SSO region: us-east-1
## Account ID: 123456789012
## Role name: DevOpsRole
## CLI default client region: ap-northeast-1

よくあるトラブルと解決法

「No credentials found」エラー

## 現在の設定確認
aws configure list
aws sts get-caller-identity

## 環境変数が邪魔している場合
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

Proxy環境での設定

日本の企業環境でよくある問題：

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

## 環境変数設定
export HTTPS_PROXY=http://proxy.company.com:8080
export HTTP_PROXY=http://proxy.company.com:8080
export NO_PROXY=169.254.169.254  # EC2 metadata service除外

複数アカウント管理

開発・staging・productionで別アカウントを使っている場合：

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

[profile staging]
region = ap-northeast-1
output = json

[profile prod]
region = ap-northeast-1
output = json
mfa_serial = arn:aws:iam::123456789012:mfa/your-username

## 使い分け
aws s3 ls --profile dev
aws s3 ls --profile prod  # MFA required

パフォーマンス最適化

東京リージョンでの最適化

## ~/.aws/config
[default]
region = ap-northeast-1
output = json
cli_pager =
max_concurrent_requests = 10
max_bandwidth = 100MB/s
cli_read_timeout = 120  # 企業プロキシだと60秒でコケることがある

プロキシ環境だとタイムアウトで死ぬことがある。デフォルト60秒だけど、会社のプロキシだと遅くて途中で切れる。--cli-read-timeout 120 で長めに設定するとマシになる。これ、ドキュメントにちゃんと書いといてほしい。

CloudFront経由でのAPI最適化

AWS CLIは自動的に最適なendpointを選択しますが、明示的に指定も可能：

## 東京リージョンでS3を操作
aws s3 ls --region ap-northeast-1

セキュリティ設定

Credential rotation自動化

#!/bin/bash
## 定期的にaccess keyをrotateするscript
aws iam create-access-key --user-name $USER
## 新しいkeyで動作確認後、古いkeyを削除
aws iam delete-access-key --user-name $USER --access-key-id $OLD_KEY

Session timeout設定

## ~/.aws/config
[profile prod]
duration_seconds = 3600  # 1時間でsession timeout

これで基本的な設定は完了です。次は実際にコマンドを実行して動作確認してみましょう。