SW BBANG J

本番環境で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クレジットは銀行口座の残高に似ている。低負荷期間に少しずつ貯金し、高負荷時に引き出す。残高がゼロになれば、それ以上の引き出しはできない。 クレジットには上限（最大蓄積量）があり、インスタン...

SNSトピックを作成してメールアドレスを登録したのに、アラートが一切届かない——本番環境の監視を設定した直後にこの状況に陥ると、「SNSが壊れているのか、IAMが間違っているのか」と疑い始めてしまう。ほとんどの場合、原因はずっとシンプルだ。 サブスクリプション確認メールのリンクをクリックしていない 、それだけである。 TL;DR：SNSメール通知が届かない場合の確認ポイント 確認順序 確認内容 期待される状態 1 サブスクリプションのステータス confirmed （ PendingConfirmation は未確認） 2 確認メールの受信（迷惑メールフォルダ含む） 件名「AWS Notification - Subscription Confirmation」 3 SNSトピックのアクセスポリシー パブリッシュ権限が正しく設定されている 4 送信元サービスのIAMロール SNSトピックへの sns:Publish 権限を保持 5 CloudWatchアラームのアクション設定 正しいSNSトピックARNが指定されている SNSメール通知の仕組み：なぜ確認が必要なのか Amazon SNSのEmailサブスクリプションは、スパム防止のためにダブルオプトイン方式を採用している。エンドポイント（メールアドレス）を登録した時点では、サブスクリプションは PendingConfirmation 状態になる。この状態では、トピックにメッセージがパブリッシュされても、そのエンドポイントには配信されない。確認リンクをクリックして初めて confirmed 状態に遷移し、通知が届くようになる。 graph TD A["sns:Subscribe 呼び出し"] --> B["PendingConfirmation 確認メール送信"] B --> C{"確認リンクを クリックしたか？"} C -- "No（期限切れ含む）" --> D["メッセージ配信されない 再サブ...

Lambda 関数が 3 秒で強制終了されるのに、処理には 10 秒必要——このギャップに気づくのは大抵、本番で初めてタイムアウトエラーを踏んだときだ。デフォルトの 3 秒という設定は「軽量な同期処理」を想定したものであり、外部 API 呼び出しやデータ変換処理を含む関数には最初から合っていない。この記事では Lambda タイムアウトの変更手順、上限値、そして設定ミスが引き起こす実運用上の問題を具体的に解説する。 TL;DR：Lambda タイムアウト設定の要点 項目 内容 デフォルト値 3 秒 最大値 900 秒（15 分） 変更スコープ 関数レベル（バージョン・エイリアス単位ではない） 変更方法 AWS コンソール / AWS CLI / IaC（CloudFormation・Terraform） 課金への影響 タイムアウト値ではなく実際の実行時間で課金される 関連する上流サービスの制限 API Gateway の統合タイムアウトは最大 29 秒（変更不可） Lambda タイムアウトの仕組みを理解する Lambda のタイムアウトは「関数が起動してから強制終了されるまでの最大壁時計時間」だ。CPU 時間でも I/O 待機時間でもなく、呼び出しから終了までの経過時間で計測される。設定値に達した瞬間、Lambda ランタイムはハンドラーを問答無用で終了させ、呼び出し元には Task timed out after X.XX seconds というエラーを返す。 重要なのは、タイムアウトは関数設定に紐づくという点だ。同一コードを使う複数の関数があれば、それぞれ独立して設定できる。また、Lambda レイヤーや VPC 設定はタイムアウト値に影響しないが、コールドスタートの初期化時間はタイムアウトのカウントに含まれる。 graph LR A["呼び出し開始 タイマースタート"] --> B["関数処理中"] B --> C{"タイムアウト 到達？"} C -- ...

EC2インスタンスのCPU使用率はCloudWatchコンソールで即座に確認できるのに、メモリ使用率を見ようとすると何も表示されない——この状況に直面したエンジニアは多い。アラームを設定しようとして初めて「なぜRAMのメトリクスが存在しないのか」に気づく。これはAWSの設計上の理由があり、CloudWatch Agentをインストールすることで解決できる。 TL;DR：EC2メモリ監視の要点 項目 内容 デフォルトで取得できるメトリクス CPUUtilization、ネットワーク、ディスクI/O（ハイパーバイザーレベル） デフォルトで取得できないメトリクス メモリ使用率、ディスク空き容量、スワップ使用率 解決策 CloudWatch Agentをインスタンスにインストールし、OSレベルのメトリクスを送信 必要なIAM権限 CloudWatchAgentServerPolicyをインスタンスプロファイルにアタッチ メトリクス名前空間 CWAgent（デフォルト） なぜEC2メモリ使用率はCloudWatchに表示されないのか CloudWatchがデフォルトで収集するEC2メトリクスは、AWSのハイパーバイザー（基盤となる仮想化レイヤー）が観測できる情報に限定される。CPUの使用サイクル数やネットワークパケット数はハイパーバイザーから見えるが、ゲストOS内部のメモリ割り当て状況はハイパーバイザーには見えない。 ハイパーバイザーとゲストOSの関係は、ビルのオーナーと入居テナントに似ている。オーナーは電力消費量（CPU）や出入りする荷物の量（ネットワーク）は把握できるが、部屋の中で何がどこに置かれているか（メモリの中身）は見えない。 これはAWSの制限ではなく、クラウド仮想化の構造的な特性だ。ゲストOS内部の状態を取得するには、OS内部で動作するエージェントプロセスが必要になる。それがCloudWatch Agentの役割だ。 graph TD HV["AWSハイパーバイザー 仮想化レイヤー"] EC2["EC2インスタンス ゲ...

AWSアカウントを作成したばかりのとき、フリーティアの範囲内で収まっているつもりが、月末に予想外の請求が届いた——そういう経験をしたエンジニアは少なくない。CloudWatchの請求アラームを使えば、推定料金が指定した閾値を超えた時点でメール通知を受け取れる。この記事では、推定料金が$5を超えた場合にアラートを送る設定を、CLIとコンソール両方の手順で解説する。 TL;DR：請求アラーム設定の概要 手順 内容 注意点 1. 請求アラートを有効化 アカウントの請求設定でモニタリングを有効にする us-east-1リージョン限定の操作 2. SNSトピック作成 メール通知用のSNSトピックとサブスクリプションを作成 サブスクリプション確認メールへの承認が必要 3. CloudWatchアラーム作成 EstimatedChargesメトリクスに$5の閾値を設定 メトリクスはus-east-1にのみ存在する 4. 動作確認 アラームの状態とSNS連携を確認 メトリクスデータは数時間遅延する場合がある 請求アラームの仕組みを理解する CloudWatchの請求アラームは、AWSが内部で集計する推定請求額（EstimatedCharges）メトリクスを監視する。このメトリクスはAWSサービス全体の推定コストを反映しており、 us-east-1リージョンにのみ存在する 。他のリージョンでは参照できないため、アラームの作成もus-east-1で行う必要がある。 メトリクスの更新頻度はおおよそ数時間ごとであり、リアルタイムの課金状況を反映するものではない。あくまで推定値であることを前提に運用する必要がある。 通知の経路はSNS（Simple Notification Service）を経由する。CloudWatchアラームがSNSトピックにメッセージをパブリッシュし、そのトピックにサブスクライブしたメールアドレスへ通知が届く。 graph LR A["AWSサービス利用 EC2 / S3 など"] --> B["推定料金を集計 数時間ごとに更新"...

ターゲットグループのヘルスチェックは全台 Healthy なのに、ALB が 502 を返し続ける。このパターンは本番障害の中でも特に混乱しやすい。ヘルスチェックが通っているという事実が「アプリは正常」という誤った確信を生み、実際の原因であるHTTPプロトコル違反やコネクション管理の問題を見落とさせる。 TL;DR — ALB 502 の主要原因と対処 原因カテゴリ 具体的な症状 対処の方向性 不正な HTTP レスポンス ステータス行・ヘッダーの形式違反 アプリのレスポンス形式を修正 Keep-Alive タイムアウトのミスアライン 断続的な 502、ピーク時に増加 アプリ側の idle timeout を ALB より短く設定 接続リセット (RST) ALB がレスポンス受信前に RST を受け取る アプリのクラッシュ・OOM を調査 プロトコルミスマッチ HTTPS ターゲットに HTTP で応答、またはその逆 ターゲットグループのプロトコル設定を確認 レスポンスヘッダーサイズ超過 特定リクエストのみ 502 レスポンスヘッダーを削減 ALB 502 の仕組み — なぜ Healthy でも発生するか ALB のヘルスチェックとリクエスト転送は独立したコネクションで動作する。ヘルスチェックは設定したパス（例: /health ）に対して単純な HTTP GET を発行し、期待するステータスコードが返れば Healthy と判定する。これはアプリが 生きているか を確認するだけで、任意のリクエストに対して正しい HTTP レスポンスを返せるかは検証しない。 502 は ALB がバックエンドから有効な HTTP レスポンスを受け取れなかったことを意味する。具体的には以下のいずれかが発生している。 バックエンドが接続を確立したが、整形式の HTTP レスポンスを返さなかった バックエンドがレスポンスを返す前に接続をリセット (TCP RST) した ALB がレスポンスを受信する前にバックエンドが接続を閉じた sequenceDiagram ...