AWSの運用は「動かして終わり」ではありません。本記事では、現場で繰り返し遭遇する困難と、そこで効いた対策を整理します。
目次
困難1：突然のコスト爆増
「気付いたら請求が10倍」は誰にでも起き得ます。原因の上位は次の3つ。
- NAT Gateway通信：プライベートサブネットからのS3/ECRアクセスがNAT経由になり1日数万円
- CloudWatch Logs：DEBUGログを垂れ流し、データ取込料金で爆発
- S3のリクエスト課金：オブジェクトを1個ずつLISTする処理が大量実行される
対策：VPC Endpoint（S3・ECR・SSM）で抜けたデータをVPC内に閉じ込める／ログ保管期間を短くする／Cost Anomaly Detectionで通知。
困難2：IAM権限の肥大化
「とりあえず動かす」で AdministratorAccess を渡すと、数年後には誰がどの権限を持っているか分からなくなります。
- IAM Identity Center で権限セットとして管理する
- IAM Access Analyzer で未使用権限を可視化
- 本番への直接書き込みは原則禁止、IaC経由のみ
困難3：マルチアカウント運用が破綻
環境分離のためにアカウントを増やしたら、ログやネットワーク管理が破綻するパターン。
- Control Tower / Organizationsでアカウント構成を最初から整理
- ログ集約用アカウント・監査アカウントを最初に作る
- VPCはTransit Gatewayで集約。アドレス重複を避けるためIPAMを使う
困難4：障害時のログがバラバラ
障害が起きてからログを集めようとしても遅いです。事前に集約しておくのが鉄則。
- CloudWatch Logsを Subscription Filter でKinesis Firehose → S3 / OpenSearchに転送
- X-Ray でリクエストトレースを取得
- アラート発火時にRunbook（手順書）リンクを通知に含める
困難5：リージョン障害
AZ障害は割と起きますが、リージョン障害はまれ。とはいえ「絶対起きない」ではないので、SLAに合わせて対策します。
- RTO/RPOを定義してから方式を決める（過剰投資を避ける）
- S3クロスリージョンレプリケーション、Auroraグローバルデータベース
- Route 53のヘルスチェックでDNSフェイルオーバー
- 定期的に DR訓練を実施しないと「いざ」のとき動かない
困難6：古くなったAMIとLambdaランタイム
1年も放置すると、Amazon LinuxのEOLやLambdaランタイム廃止通知に追われます。
- Image Builder で AMIを定期再生成
- SSM Patch Manager で OS パッチを自動化
- Lambdaは Container Image 化すると、ランタイム強制廃止の影響が小さい
困難7：人の入れ替わり
担当者が抜けた瞬間「これ何のために動いてるんだっけ?」となるリソースが必ず出てきます。タグ運用とドキュメント整備が事前対策です。
- 必須タグ：
Owner・Project・Env・CreatedBy - AWS Configルールで「タグなしリソース」を検知
- ドキュメントは「構成図 + Runbook + 連絡先」をConfluence等で1セットに
まとめ
困難の多くは「事前に少し手を入れておけば防げた」ものです。プロジェクト初期に運用設計を巻き込めるかどうかが分かれ目になります。
