AWS開発チートシート 2026年版——現場で毎日使うコマンドと設定をまとめた
この記事について
AWSで開発をしていると「あのコマンド、何だっけ?」と手が止まる瞬間がある。公式ドキュメントは正確だが、必要な情報にたどり着くまでに時間がかかる。
この記事は、自分が開発中に繰り返し参照するコマンドや設定パターンをチートシート形式でまとめたものだ。2025〜2026年にかけて追加された新機能も含めて、実務で使う頻度が高い順に整理した。
なお、このブログは2026年5月までNext.js + S3 + CloudFront構成でAWS上に構築・運用していた(現在はCloudflare Pagesへ移行済み)。以下のコマンド、特にS3操作とCloudFrontのキャッシュ無効化は、当時このブログを更新するたびに実行していたものだ。
この記事で学べること・対象読者
想定する読者は、AWSをある程度触ったことがあり「コマンドの細部を都度調べ直すのが面倒」と感じている開発者だ。各セクションは次の観点で整理している。
- AWS CLI / IAM: 認証まわり——なぜ永続キーを避けるのか、SSO(IAM Identity Center)への移行で何が変わったか
- S3 / Lambda / CloudFront / ECS: 実務で頻度の高い操作と、覚えておくべき制限値
- CloudFormation / CDK: IaC運用、特に2025〜2026年に追加された差分検出・リファクタリング系の新機能
- コスト管理・小技: 日々の運用で効いてくる確認系コマンド
網羅性より「実際に手が止まる場面で引ける」ことを優先した。詳細な仕様やオプションの全列挙は公式ドキュメントに譲り、ここでは使う頻度と判断のポイントに絞っている。
AWS CLI 基本操作
プロファイルとリージョン
# プロファイル一覧を確認
aws configure list-profiles
# デフォルトリージョンを設定
aws configure set region ap-northeast-1
# 特定のプロファイルでコマンドを実行
aws s3 ls --profile my-profile
# 現在の認証情報を確認(誰としてログインしているか)
aws sts get-caller-identity
IAM Identity Center(SSO)認証(推奨)
2026年現在、永続的なアクセスキーの使用は非推奨で、IAM Identity Centerによる一時認証が標準になっている。理由はシンプルで、aws configureで設定する永続キーは~/.aws/credentialsに平文保存され、しかも無期限で有効だからだ。PC紛失・gitへの誤コミット・スクリーンショットへの映り込みで漏れた場合、気づくまで不正利用され続ける。一時認証ならセッション期限で自動的に失効するため、漏洩時の影響範囲が短い時間に限定される。
セットアップはaws configure ssoを実行し、対話形式でSSOセッション名・スタートURL・リージョンを入力するだけだ。完了後の利用フローは次の3つを覚えておけば足りる。
# SSOログイン(ブラウザが開いて認証)
aws sso login --sso-session my-session
# 現在の認証情報を確認
aws sts get-caller-identity
# SSOログアウト
aws sso logout
この方式では~/.aws/credentialsにアクセスキーが保存されない点が永続キー方式との大きな違いだ。
押さえておくと実務で効くポイントを2つだけ挙げる。
- セッション有効期限: SSOセッションはデフォルト8時間、ロールセッションはデフォルト1時間。ロールの1時間は個人利用だと短く再ログインが頻発するので、IAM Identity Centerの「許可セット」からセッション時間を最大12時間まで延ばしておくと快適になる
- 環境変数でプロファイル固定: 毎回
--profileを打つのが面倒なら、.zshrc等にexport AWS_PROFILE=devを入れておくと省略できる
なお、aws configure ssoの詳細な入力項目、~/.aws/configの記述例、個人アカウントでのIAM Identity Center有効化手順といったセットアップ寄りの内容は本チートシートの範囲を超えるため割愛する。ここでは「永続キーをやめてSSOに寄せる」という方針と、日々叩くコマンドの確認に絞る。
S3 操作
基本操作
# バケット一覧
aws s3 ls
# バケット内のオブジェクト一覧(再帰的)
aws s3 ls s3://my-bucket/ --recursive --human-readable
# ファイルのアップロード
aws s3 cp ./file.txt s3://my-bucket/path/file.txt
# ディレクトリの同期(ローカル → S3)
aws s3 sync ./dist/ s3://my-bucket/ --delete
# 署名付きURLの生成(1時間有効)
aws s3 presign s3://my-bucket/file.txt --expires-in 3600
S3の主な制限値
| 項目 | 制限値 |
|---|---|
| バケット数の上限 | 10,000個/アカウント |
| マルチパートアップロードの最小パートサイズ | 5 MB |
| 整合性モデル | 強い読み取り一貫性 |
制限値は仕様変更で更新されることがある(オブジェクトの最大サイズ上限など)ため、上限ギリギリの設計をする場合は最新の公式ドキュメントで確認すること。
S3 チェックサム検証
2025年からSHA-256やCRC32Cなど追加のチェックサムアルゴリズムに対応した。データ整合性の検証が柔軟になっている。
# SHA-256チェックサム付きでアップロード
aws s3api put-object \
--bucket my-bucket \
--key file.txt \
--body ./file.txt \
--checksum-algorithm SHA256
Amazon S3 Files(2026年4月発表・未検証)
S3をファイルシステムとしてマウントできるとされる新サービス。EFSのような使い方がS3の料金体系で可能になる、というのが発表時の触れ込みだ。
ただし、自分はまだ実際に触っていない。下のコマンドは発表情報をもとにした想定であり、検証して動作を確認したものではないため、参考程度にとどめてほしい。
# S3 Filesバケットの作成(ファイルシステムモード)※未検証
aws s3api create-bucket \
--bucket my-file-bucket \
--create-bucket-configuration LocationConstraint=ap-northeast-1
# ※ファイルシステムとしてのマウントにはVPCエンドポイントが必要とされる
S3 Filesは2026年4月に発表された新サービス。本記事執筆時点では未検証であり、東京リージョンでの一般提供開始後に実際に試してから加筆する予定。
Lambda
関数のデプロイ・更新・ログ確認は開発サイクルで何度も回す操作だ。ここでは「作って・直して・ログを見る」の最小ループに絞る。全オプションは公式の aws lambda リファレンスに委ねる。
関数の管理
# 関数一覧
aws lambda list-functions --region ap-northeast-1
# 関数の作成
aws lambda create-function \
--function-name my-function \
--runtime nodejs20.x \
--role arn:aws:iam::123456789012:role/lambda-role \
--handler index.handler \
--zip-file fileb://function.zip
# コードの更新
aws lambda update-function-code \
--function-name my-function \
--zip-file fileb://function.zip
# 環境変数の更新
aws lambda update-function-configuration \
--function-name my-function \
--environment "Variables={DB_HOST=mydb.example.com,STAGE=prod}"
関数の実行とログ
# 同期実行(レスポンスを受け取る)
aws lambda invoke \
--function-name my-function \
--payload '{"key": "value"}' \
--cli-binary-format raw-in-base64-out \
response.json
# 最新のログを確認
aws logs tail /aws/lambda/my-function --follow
Lambda の制限値
| 項目 | 制限値 |
|---|---|
| メモリ | 128 MB〜10,240 MB |
| タイムアウト | 最大15分 |
| デプロイパッケージ | 50 MB(zip)/ 250 MB(展開後) |
| コンテナイメージ | 最大10 GB |
| 同時実行数 | 1,000(デフォルト) |
| 一時ストレージ | 最大10,240 MB |
CloudFormation / IaC
IaCで詰まるのはたいてい「デプロイが失敗した原因の特定」と「テンプレートと実態のズレ(ドリフト)」だ。基本のスタック操作に加えて、デバッグに効くイベント確認と、2025〜2026年に追加された差分検出・リファクタリング系を押さえておくと運用が楽になる。
スタック操作
# スタックのデプロイ(変更セット経由)
aws cloudformation deploy \
--template-file template.yaml \
--stack-name my-stack \
--capabilities CAPABILITY_IAM
# スタックの状態確認
aws cloudformation describe-stacks --stack-name my-stack
# スタックイベントの確認(デバッグ用)
aws cloudformation describe-stack-events \
--stack-name my-stack \
--query 'StackEvents[?ResourceStatus==`CREATE_FAILED`]'
# スタックの削除
aws cloudformation delete-stack --stack-name my-stack
Drift-Aware Change Sets(2025年11月〜)
手動変更で実態とテンプレートがずれた場合でも、3方向の差分を検出できるようになった。
# ドリフト検出を開始
aws cloudformation detect-stack-drift --stack-name my-stack
# ドリフト検出結果の確認
aws cloudformation describe-stack-drift-detection-status \
--stack-drift-detection-id <detection-id>
# リソースごとのドリフト詳細
aws cloudformation describe-stack-resource-drifts \
--stack-name my-stack
Stack Refactoring(2025年2月〜)
スタック間でリソースを安全に移動できる機能。大きくなりすぎたスタックの分割に便利。
# リファクタリングの作成
aws cloudformation create-stack-refactor \
--description "APIリソースを分離" \
--stack-definitions \
StackName=monolith-stack,TemplateBody=file://monolith-updated.yaml \
StackName=api-stack,TemplateBody=file://api-stack.yaml \
--resource-mappings '[
{
"Source": {"StackName": "monolith-stack", "LogicalResourceId": "ApiGateway"},
"Destination": {"StackName": "api-stack", "LogicalResourceId": "ApiGateway"}
}
]'
CDK 基本操作
# プロジェクトの初期化
npx cdk init app --language typescript
# 差分の確認
npx cdk diff
# デプロイ
npx cdk deploy --require-approval broadening
# 全スタックのデプロイ
npx cdk deploy --all
# スタックの破棄
npx cdk destroy
IAM
権限まわりのトラブルは「誰が」「何を」許可されているか分からないことが原因になりやすい。確認系コマンドと、権限のシミュレーションを覚えておくと「なぜか403が返る」の切り分けが速くなる。
よく使う確認コマンド
# 自分のユーザー情報
aws sts get-caller-identity
# ユーザー一覧
aws iam list-users
# ロールの一覧
aws iam list-roles --query 'Roles[].RoleName'
# ポリシーの確認
aws iam get-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
# ロールにアタッチされたポリシー一覧
aws iam list-attached-role-policies --role-name my-role
アクセス権限のデバッグ
# 特定のアクションが許可されているかシミュレーション
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/my-user \
--action-names s3:GetObject \
--resource-arns arn:aws:s3:::my-bucket/*
CloudFront
# ディストリビューション一覧
aws cloudfront list-distributions \
--query 'DistributionList.Items[].{Id:Id,Domain:DomainName,Status:Status}'
# キャッシュの無効化(デプロイ後に必要)
aws cloudfront create-invalidation \
--distribution-id E10DXZCUDPW3F \
--paths "/*"
# 無効化のステータス確認
aws cloudfront get-invalidation \
--distribution-id E10DXZCUDPW3F \
--id <invalidation-id>
CloudWatch Logs
# ロググループ一覧
aws logs describe-log-groups --query 'logGroups[].logGroupName'
# リアルタイムでログを表示
aws logs tail /aws/lambda/my-function --follow
# 特定期間のログを検索(macOSの場合)
aws logs filter-log-events \
--log-group-name /aws/lambda/my-function \
--start-time $(date -v-1H +%s000) \
--filter-pattern "ERROR"
# Linuxの場合は date -d '1 hour ago' +%s000 を使用
ECS / Fargate
# クラスター一覧
aws ecs list-clusters
# サービスの一覧
aws ecs list-services --cluster my-cluster
# サービスの強制デプロイ(新しいタスクに入れ替え)
aws ecs update-service \
--cluster my-cluster \
--service my-service \
--force-new-deployment
# タスクのログを確認
aws ecs execute-command \
--cluster my-cluster \
--task <task-id> \
--container my-container \
--interactive \
--command "/bin/sh"
コスト管理
# 今月の概算コスト
aws ce get-cost-and-usage \
--time-period Start=2026-04-01,End=2026-04-11 \
--granularity MONTHLY \
--metrics BlendedCost \
--group-by Type=DIMENSION,Key=SERVICE
# 特定サービスの日別コスト
aws ce get-cost-and-usage \
--time-period Start=2026-04-01,End=2026-04-11 \
--granularity DAILY \
--metrics BlendedCost \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Simple Storage Service"]}}'
便利な小技
よく使うクエリパターン(--query)
# 名前でフィルタリング
--query 'Items[?contains(Name, `prod`)]'
# 特定フィールドだけ取得
--query 'Items[].{Name:Name, Id:Id}'
# ソートして最初の1件
--query 'sort_by(Items, &CreatedDate)[-1]'
# 出力フォーマットの切り替え
--output table # 表形式(ターミナルで見やすい)
--output json # JSON形式(jqと組み合わせる)
--output text # タブ区切り(シェルスクリプト向き)
AWS IaC MCP Server
2025年にAWSが公開したIaC用MCPサーバーを使えば、Claude Codeから直接CloudFormation/CDKのドキュメント検索やテンプレート検証ができる。
// .claude/settings.local.json
{
"permissions": {
"allow": ["mcp__plugin_deploy-on-aws_awsknowledge__*"]
}
}
Claude CodeのAWSプラグインについてはClaude CodeのAWSプラグインが便利すぎるを参照。
当時このブログの運用で使っていたデプロイフロー
このブログをNext.js + S3 + CloudFrontで運用していた頃(2026年5月まで)、デプロイは deploy.sh で自動化していた。実際に動かしていたコマンドは以下の4ステップだった。SSO認証・S3同期・CloudFront無効化という、ここまで挙げたコマンドが実運用でどう組み合わさるかの一例として残しておく。
# 1. SSO 未ログインなら自動でログイン
aws sts get-caller-identity --profile "$AWS_PROFILE" > /dev/null 2>&1 \
|| aws sso login --profile "$AWS_PROFILE"
# 2. 静的ビルド
npm run build
# 3. S3に同期(機密ファイル・ドット配下を除外、削除も反映)
aws s3 sync out/ "s3://${S3_BUCKET}/" --profile "$AWS_PROFILE" --delete \
--exclude "*.env*" --exclude ".claude/*" --exclude ".git/*"
# 4. CloudFront のキャッシュを全無効化
aws cloudfront create-invalidation \
--distribution-id "$CF_DISTRIBUTION_ID" --paths "/*" \
--profile "$AWS_PROFILE"
運用当時に感じていた改善余地
- S3 syncの差分検知:
--deleteで常に全体同期していたが、--size-onlyや--exact-timestampsで差分のみ反映するように変えればアップロード時間を短縮できそうだった。記事・ツールページが増えるにつれ、この非効率が気になっていた - CloudFront invalidation の範囲指定: 毎回
/*で全無効化していたが、更新したファイルだけ指定すれば無料枠(月1,000パス)に収まる可能性があった。ただしNext.jsの静的エクスポートでは関連ページが複数生成されるため、範囲指定は慎重に設計する必要がある
こうした「動いてはいるが最適ではない」部分に気づけたのは、手で動かしながら運用していたからだと思う。
まとめ
AWSのCLIやサービスは毎年進化している。特に2025〜2026年は以下の変化が大きい。
- IAM Identity Center(SSO)が認証の標準に。永続アクセスキーは非推奨
- S3にチェックサムアルゴリズムの選択肢が増え、データ整合性検証が柔軟に。S3 Files(未検証)のような新サービスの発表も続いている
- CloudFormationにDrift-Aware Change SetsとStack Refactoringが追加。IaCの運用が格段に楽に
- AWS IaC MCP ServerでAI連携も進化
このチートシートは自分用のメモを兼ねているので、新しいコマンドや設定パターンを覚えたら随時更新していく予定だ。