AWS 初心者失敗事例あるある 4選

はじめに

この記事では、AWSを学び始めたばかりの方や個人開発や小規模プロジェクトで初めてAWSインフラを構築する方を対象としています。

新しい環境を構築する際の参考に役立てて頂ければと思います。

【失敗事例1】気づいたらサービス停止！EC2のディスク枯渇

• [シチュエーション]
  • EC2インスタンスでWebサーバーを動かしていたら、ある日サイトが表示されなくなった。
  • 調査のためのSSH接続やSession Managerでの接続も失敗してしまう。
• [原因]
  • ログファイルなどが溜まり続け、EBSボリュームの使用率が100%になっていた。
  • EC2では、デフォルトではディスク使用率のメトリクスは収集されない。
• [対策]
  • やるべきこと: CloudWatchエージェントをEC2に導入し、ディスク使用率（disk_used_percent）を監視しましょう。
  • 具体的な手順:
    1. EC2にCloudWatchエージェントをインストールし、設定ファイルでディスク使用率のメトリクスを収集するよう構成する。
    2. CloudWatchコンソールで「アラームの作成」を選択。
    3. メトリクスとして収集したdisk_used_percentを指定し、しきい値を設定する。
    4. アクションとして、指定したメールアドレスに通知が飛ぶようにSNSトピックを設定する。
  • 監視だけでなく、logrotateなどで定期的にログを圧縮・削除する設定も忘れずにしましょう。

【失敗事例2】混ぜるな危険！開発・本番環境のごちゃ混ぜVPC

• [シチュエーション]
  • 手軽さから、一つのVPC内に開発環境（dev）、ステージング環境（stg）、本番環境（prd）のリソースをすべて作成してしまった。
• [問題点]
  • セキュリティリスク: 開発中の作業で、誤って本番データベースを更新・削除してしまう事故が起こりうる。
  • 運用上の混乱: IPアドレスやセキュリティグループの管理が複雑化し、意図しない通信を許可してしまうリスクが高まる。
  • 権限管理の限界: 環境ごとにIAMロールでのアクセス権限を厳密に分離することが難しくなる。
• [対策]
  • やるべきこと: 環境ごとに論理的な境界を設ける。
  • 方法1: VPCで分離
    • dev-vpc, stg-vpc, prd-vpc のように、環境ごとにVPCを分けてリソースを作成する。
  • 方法2: AWSアカウントで分離
    • セキュリティとガバナンスレベルをより高めたベストプラクティスです。
    • dev-account, stg-account, prd-account のようにアカウント自体を分ける。
    • AWS Organizationsを利用することで、複数アカウントの請求や管理を一元化できる。
  • 小さなプロジェクトでも将来の成長を見越して、最低でも環境毎のVPC分離が推奨です。

【失敗事例3】塵も積もれば…CloudWatch Logsの無制限保存

• [シチュエーション]
  • アプリケーションログをCloudWatch Logsに出力していたら、数ヶ月後に請求額がじわじわと増加してしまっていた。
• [原因]
  • ロググループの保存期間がデフォルトの「失効しない（無期限）」になっていたため、不要なログが溜まり続けていたこと。
• [対策] ログには「賞味期限」を設定しよう
  • やるべきこと: ロググループに適切な保持期間を設定する。
  • 具体的な手順:
    1. CloudWatchコンソールの「ロググループ」を開く。
    2. 対象のロググループを選択し、「アクション」から「保持設定を編集」をクリック。
    3. 「失効しない」から、要件に合わせた期間（例: 30日、90日など）に変更する。
  • 発展的な対策:
    • 監査要件などでログの長期保存が必要な場合は、S3へのエクスポート機能を検討する。
    • S3のライフサイクルポリシーを組み合わせることで、「90日後に低コストなS3 Glacierへ移動する」といったコスト最適化も可能。
  • ロググループを作成したら、セットで保持期間を設定する癖をつけましょう。

【失敗事例4】通信料にびっくり！NAT Gatewayの高額請求

• [シチュエーション]
  • プライベートサブネットから外部APIにアクセスするため、NAT Gatewayを設置。
  • ある月、データ転送量が跳ね上がり、NAT Gatewayの通信料金（データ処理料金）が数万円〜数十万円に高騰してしまった。
• [原因]
  • NAT Gatewayは、通過するデータ量に応じて課金されます。特に、S3やECRのようなAWSサービスへのアクセスでも、インターネットを経由するとこの料金が発生し、コストを圧迫する可能性があります。
• [対策]
  • やるべきこと: AWSサービスへのアクセスには、VPCエンドポイントの利用を第一に検討する。
  • 具体的な手順:
    • S3やDynamoDBの場合: ゲートウェイ型VPCエンドポイントを作成する。これは無料で利用でき、ルートテーブルを編集するだけでプライベートな通信経路を確保できる。
    • その他の多くのAWSサービス（Systems Manager, ECRなど）の場合: インターフェイス型VPCエンドポイントを作成する。こちらは時間料金とデータ処理料金がかかるため、どちらが安くなるかは比較が必要です。
  • コスト比較の視点:
    • NAT Gatewayの通信料金と、インターフェイスエンドポイントの通信料金を比較する。
    • 固定費（時間課金と月額目安）

※通信量が多い場合は、VPCエンドポイントを設置する方がコストメリットが出ます。

最後に

AWSの運用では、初期設定の「一手間」が将来の安定運用やコスト削減に大きく繋がります。

これらの失敗は、誰しも一回は経験しがちなものです。他にも様々なベストプラクティスが存在するため、一緒に堅牢なAWS運用を目指しましょう。