SW BBANG J

本番EC2インスタンスが深夜に突然ダウンした経験があるなら、DNSフェイルオーバーの重要性は身に染みているはずだ。Route 53のヘルスチェックとフェイルオーバールーティングを組み合わせれば、EC2が応答しなくなった瞬間にS3の静的サイトへ自動的にトラフィックを切り替えられる。このガイドでは、 Route 53 DNSフェイルオーバー の仕組みから実際の設定手順まで、プロダクション環境で使える形で解説する。 TL;DR：Route 53 DNSフェイルオーバーの全体像 項目 内容 目的 EC2障害時にS3静的サイトへ自動DNS切り替え 主要コンポーネント Route 53ヘルスチェック、フェイルオーバールーティングポリシー、S3静的ウェブサイトホスティング 切り替えの目安 ヘルスチェック失敗判定後、TTL経過で切り替わる（TTL設定値に依存） 必要なレコードタイプ PRIMARY（EC2向け）とSECONDARY（S3向け）の2レコード コスト要因 ヘルスチェック料金、Route 53クエリ料金（最新料金は公式ドキュメント参照） 主な注意点 S3静的ウェブサイトエンドポイントはHTTPSを直接サポートしない Route 53フェイルオーバーの仕組み フェイルオーバールーティングポリシーは、レコードをPRIMARYとSECONDARYの2種類に分類する。Route 53はPRIMARYレコードに紐付けられたヘルスチェックを定期的に実行し、失敗と判定した場合にSECONDARYレコードを返すよう切り替える。ヘルスチェックはRoute 53のグローバルなヘルスチェッカーネットワークから実行されるため、単一リージョンの問題ではなく、広域での到達不能を検知する。 重要なのは、DNS応答の切り替えはTTLに依存するという点だ。ヘルスチェックが失敗を検知してもTTLが長ければ、クライアントはキャッシュされた古いIPアドレスを使い続ける。フェイルオーバーの応答速度を重視するなら、TTLを低く設定する必要がある。ただし、TTLを下げるとRoute 53へのクエリ頻度が上がり、コストに影...

5台のEC2インスタンスで同じディレクトリをマウントしたい——この要件を受けて、まずEBSのマルチアタッチを試みたエンジニアは少なくない。結論から言うと、EBSは原則として複数インスタンスへの同時共有には向いておらず、EC2間でフォルダを共有するには Amazon EFS（Elastic File System） が正しい選択肢になる。 TL;DR：EBS vs EFS、複数インスタンス共有の判断基準 観点 EBS EFS 複数インスタンスへの同時マウント 原則不可（Multi-Attachは限定的） 可能（同一リージョン内） 対応ストレージプロトコル ブロックストレージ NFSv4.1 / NFSv4.0 ファイルシステム共有 不可（Multi-Attach時もファイルシステム層は非共有） 可能（POSIX準拠） 対応インスタンス数 Multi-Attachは最大16インスタンス（io1/io2のみ） 数千インスタンスまでスケール AZ制約 同一AZのみ リージョン内複数AZに対応 ユースケース 単一インスタンスのOSディスク、DB 共有コンテンツ、ログ集約、CMS EBSとEFSの仕組み：なぜEBSでは共有できないのか EBSはブロックストレージデバイスとして動作する。EC2インスタンスにアタッチされると、インスタンス側でext4やxfsなどのファイルシステムをフォーマットして使う構造になっている。ファイルシステムのメタデータ（inode、ジャーナル）はEBSボリューム上に書き込まれるため、複数のインスタンスが同じボリュームを同時にマウントすると、メタデータが競合してファイルシステムが破損する。 EBSにはio1/io2ボリュームタイプ限定で Multi-Attach という機能があり、最大16インスタンスへの同時アタッチが可能だ。ただし、これはブロックデバイスレベルの共有であり、ファイルシステムの同時書き込みを安全に扱うには クラスタ対応ファイルシステム（例：GFS2） をアプリケーション側で実装する必要がある。通常のext4/xfsでMulti-Attachを...

本番環境でT3インスタンスを運用していると、ある時点から突然レスポンスタイムが悪化し、CPUが張り付いたように動かなくなる現象に遭遇することがある。アプリケーションのバグを疑い、メモリリークを調査し、それでも原因が見つからない。実はその原因がCPUクレジットの枯渇だったというケースは、T3インスタンスを使い始めたエンジニアが最初にはまる落とし穴の一つだ。 TL;DR：T3インスタンスのCPUクレジット早見表 項目 内容 CPUクレジットとは ベースライン未満のCPU使用時に蓄積し、バースト時に消費するトークン クレジット枯渇時の挙動 CPUパフォーマンスがベースラインに制限される（Standardモード） Unlimitedモード クレジット枯渇後も性能を維持するが、余剰クレジット分が課金される 診断の起点 CloudWatchの CPUCreditBalance メトリクスを確認する 主なリスク Unlimitedモードでの予期しない追加料金 T3インスタンスのCPUクレジット機構：仕組みから理解する T3インスタンスはバースト可能なパフォーマンスインスタンスファミリーに属する。「バースト可能」とは、常時高いCPU性能を保証するのではなく、ベースラインCPU使用率を定義し、それを下回る期間にクレジットを蓄積し、高負荷時にそのクレジットを消費して一時的に高い性能を発揮できる仕組みを指す。 各T3インスタンスタイプにはベースラインCPU使用率が定められており、例えばt3.microであれば10%、t3.smallであれば20%といった値が設定されている（正確な値はAWS公式ドキュメントを参照）。インスタンスがベースラインを下回るCPU使用率で稼働している間、1時間あたり一定数のCPUクレジットが自動的に付与される。逆にベースラインを超えてCPUを使用すると、クレジットが消費される。 CPUクレジットは銀行口座の残高に似ている。低負荷期間に少しずつ貯金し、高負荷時に引き出す。残高がゼロになれば、それ以上の引き出しはできない。 クレジットには上限（最大蓄積量）があり、インスタン...

EC2インスタンスを起動するたびに手動でSSH接続してNginxをインストールしていた経験があるなら、User Dataの仕組みを理解することで、その作業を完全に自動化できる。AMIからインスタンスを量産する場面や、Auto Scalingグループで新しいインスタンスが追加される場面では、この自動化が運用品質を左右する。 TL;DR — EC2 User Dataの要点 項目 内容 実行タイミング インスタンスの 初回起動時のみ （デフォルト動作） 実行ユーザー root （sudoなしで実行される） スクリプト形式 シェルスクリプト（ #!/bin/bash ）またはcloud-init directive 文字数上限 16 KB（Base64エンコード後） ログ出力先 /var/log/cloud-init-output.log 設定場所 コンソール起動ウィザード / AWS CLI / Launch Template User Dataの仕組みを理解する EC2インスタンスが初回起動すると、 cloud-init というデーモンがインスタンスメタデータサービス（IMDSv2）からUser Dataを取得し、実行する。このフローを理解しておかないと、「スクリプトを貼ったのに動かない」という状況で原因の見当がつかない。 sequenceDiagram participant HV as ハイパーバイザー participant OS as Linux OS participant CI as cloud-init participant IMDS as IMDS (169.254.169.254) participant SH as シェルスクリプト HV->>OS: インスタンス起動 OS->>CI: cloud-initデーモン起動 CI->>IMDS: GET /latest/user-data IMDS-->>CI: スクリプト内容を返...

月曜の朝、本番EC2インスタンスが消えていた。Slackに通知が飛んで、誰もやっていないと言う。こういう状況で最初に開くべきツールが CloudTrail Event History だ。 TerminateInstances アクションは必ずCloudTrailに記録されており、どのIAMユーザーまたはロールが実行したかを数分で特定できる。 TL;DR — CloudTrailでEC2削除者を特定する ステップ 操作 確認ポイント 1 Event Historyを開く リージョンが正しいか確認 2 イベント名で TerminateInstances をフィルタ 削除時刻の前後30分を絞り込む 3 イベント詳細を展開 userIdentity フィールドを確認 4 CLIで同じクエリを実行 インスタンスIDで絞り込み精度を上げる 5 再発防止策を実施 Termination ProtectionまたはSCP適用 CloudTrail Event Historyの仕組みを理解する CloudTrailはAWSアカウント内のAPI呼び出しを記録するサービスだ。EC2の TerminateInstances も例外ではなく、マネジメントコンソール、CLI、SDK、Auto Scalingなど、どの経路で実行されても同じイベントとして記録される。 Event Historyは追加設定なしで有効になっており、過去90日間のマネジメントイベントを保持する。S3バケットへの長期保存にはTrailの設定が必要だが、90日以内の調査であればEvent Historyだけで完結する。 graph LR A["コンソール操作"] --> CT["CloudTrail"] B["AWS CLI"] --> CT C["SDK / アプリ"] --> CT D["Auto Scaling"] --> CT CT --> EH[...

同一AWSアカウント・同一リージョンに2つのVPCがあり、EC2インスタンス間をプライベートIPで通信させたい場面は頻繁に起きる。マイクロサービスの分割、共有サービスVPCとの接続、レガシーVPCからの段階移行など、理由は様々だ。VPCピアリングはその最もシンプルな解決策だが、接続リクエストの承認とルートテーブルの更新という2段階の操作を両方のVPCに対して行わないと通信は一切成立しない。片方だけ設定して「なぜ繋がらないのか」と悩むケースが多い。 TL;DR：VPCピアリング設定の全体像 ステップ 操作対象 内容 1 VPC-A（リクエスター） ピアリング接続リクエストを作成 2 VPC-B（アクセプター） ピアリング接続リクエストを承認 3 VPC-Aのルートテーブル VPC-BのCIDRへのルートを追加 4 VPC-Bのルートテーブル VPC-AのCIDRへのルートを追加 5 両VPCのセキュリティグループ 相手VPCのCIDRからのインバウンドを許可 VPCピアリングの仕組みを理解する VPCピアリングは、2つのVPC間にAWSのバックボーンネットワークを経由したプライベートルーティングパスを確立する機能だ。インターネットゲートウェイ、VPNゲートウェイ、NAT装置は一切介在しない。トラフィックはAWSネットワーク内に留まる。 重要な制約として、VPCピアリングは推移的ルーティング（Transitive Routing）をサポートしない。VPC-AがVPC-Bとピアリングし、VPC-BがVPC-Cとピアリングしていても、VPC-AからVPC-Cへは直接通信できない。A-C間の通信が必要なら、別途A-C間のピアリングが必要になる。 また、ピアリングするVPC同士のCIDRブロックが重複していると接続は作成できない。事前にCIDRの重複がないことを確認すること。 graph LR A["VPC-A 10.0.0.0/16"] -->|"1. ピアリングリクエスト作成"| PCX["VPCピアリング接続 pc...

「インスタンスは起動しているのに、ASGが勝手に終了させる」——この現象に直面したとき、最初に疑うべきはヘルスチェックの設定だ。EC2タイプのヘルスチェックはインスタンスの 存在 しか見ていない。アプリケーションがクラッシュしていても、OSが起動していれば「正常」と判断される。Auto Scaling Groupのヘルスチェック設定を正しく理解することは、不要なインスタンス終了を防ぐだけでなく、本当に異常なインスタンスを確実に置き換えるためにも不可欠だ。 TL;DR — ヘルスチェックタイプの選択基準 状況 推奨タイプ 理由 ELBを使用していない EC2 ELBタイプはロードバランサーなしでは機能しない ELBを使用、アプリ死活監視が必要 ELB アプリレイヤーの応答をヘルスチェックに反映できる ELBを使用、インスタンス起動直後に終了される ELB + ウォームアップ期間の確認 ヘルスチェックグレースピリオドの設定ミスが原因のことが多い カスタムアプリ監視が必要 EC2 + カスタムスクリプト ASGのカスタムヘルスチェックAPIで外部から不健全マークを付与 Auto Scaling Groupのヘルスチェックの仕組み ASGのヘルスチェックを理解するには、 誰が ヘルス状態を判定するのかを明確にする必要がある。ASG自身がインスタンスをポーリングするわけではない。ASGは複数のソースからヘルス情報を受け取り、それを元に終了・置換の判断を行う。 graph LR EC2SVC["EC2サービス システムステータス監視"] -->|"Impaired / Stopped"| ASG["Auto Scaling Group ヘルス判定エンジン"] TG["ターゲットグループ アプリHTTPチェック"] -->|"Unhealthy"| ASG CUSTOM["外部スクリプト SetInstanceHealth API"] --...