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へのクエリ頻度が上がり、コストに影...

Webアプリに「サインアップ」と「サインイン」を実装しようとしたとき、AWSコンソールを開くと『Cognito User Pools』と『Cognito Identity Pools』という2つの選択肢が並んでいる。どちらを使えばいいのか迷うのは当然で、名前が似ているせいで混同しやすい。結論から言うと、ユーザーのログイン管理には User Pools を使う。Identity Poolsはまったく別の目的のサービスだ。 TL;DR — AWS Cognitoの使い分け早見表 目的 使うべきサービス 主な機能 サインアップ / サインイン / ユーザー管理 Cognito User Pools ユーザーDB、JWT発行、MFA、パスワードポリシー AWSリソース（S3, DynamoDBなど）への一時的アクセス Cognito Identity Pools フェデレーテッドID、STS一時認証情報の払い出し ログイン後にAWSリソースも直接操作させたい 両方を組み合わせる User PoolsでJWT取得 → Identity Poolsで一時認証情報に交換 AWS Cognito User Poolsの仕組みを理解する User Poolsは、アプリケーション専用のユーザーディレクトリだ。メールアドレスとパスワードでサインアップしたユーザーの情報を保持し、認証が成功するとOpenID Connect準拠のJWTトークン（IDトークン、アクセストークン、リフレッシュトークン）を発行する。バックエンドAPIはこのJWTを検証するだけでよく、セッション管理の複雑さをCognitoに委譲できる。 sequenceDiagram participant Browser as ブラウザ participant UserPool as Cognito User Pools part...

API Gateway で Lambda 関数を呼び出す方法を調べると、必ず『プロキシ統合』と『標準統合（非プロキシ統合）』という2つの選択肢に行き当たる。設定画面でチェックボックスひとつの違いに見えるが、Lambda 関数が受け取る event オブジェクトの構造、そしてレスポンスの返し方が根本的に変わる。どちらを選ぶかを誤ると、関数側でリクエストヘッダーが取れない、ステータスコードが固定されてしまうといった問題が本番環境で表面化する。 TL;DR — Lambda プロキシ統合 vs 標準統合 観点 Lambda プロキシ統合 標準統合（非プロキシ） マッピングテンプレート 不要（API Gateway が自動生成） 必須（VTL で自分で定義） event オブジェクト 固定スキーマ（headers, pathParameters, body など） テンプレートで自由に成形 HTTP ステータスコード制御 関数の戻り値で指定 API Gateway のメソッドレスポンスで設定 レスポンス変換 関数が JSON 構造を返す責務を持つ API Gateway 側でマッピング可能 向いているユースケース REST API の新規開発、マイクロサービス 既存バックエンドとの統合、レガシー変換 Lambda プロキシ統合の仕組みを理解する プロキシ統合を有効にすると、API Gateway は受信した HTTP リクエストをほぼそのまま Lambda に転送する。『ほぼそのまま』というのがポイントで、実際には API Gateway が決められたスキーマの JSON オブジェクトに変換して Lambda を呼び出す。このスキーマが Lambda プロキシ統合イベント と呼ばれる構造だ。 逆方向も同様で、Lambda 関数は API Gateway が期待する特定の JSON 構造をレスポンスとして返さなければならない。この構造を満たさない場合、API Gateway はクライアントに 502 Bad Gateway を返す。 graph LR Client[...

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

S3バケットのファイルを誤って削除してしまった — 本番環境でこれが起きると、まず確認するのは「バージョニングを有効にしていたか」という一点だ。バージョニングが有効であれば、S3上の削除は実際にはデータを消去しておらず、削除マーカーと呼ばれるオブジェクトを追加する操作に過ぎない。この仕組みを理解していれば、復元は数分で完了する。 TL;DR — S3削除ファイルの復元手順 ステップ 操作 目的 1 バージョニング有効化を確認 復元可能かを判断する 2 削除マーカーを特定 どのバージョンIDが削除操作かを確認 3 削除マーカーを削除 直前バージョンを最新として復元 4 特定バージョンを直接コピー 任意の過去バージョンに戻す場合 S3バージョニングの仕組み — 削除とは何か バージョニングが有効なバケットでは、オブジェクトに対するすべての書き込みと削除が履歴として保持される。通常の DELETE リクエスト（バージョンIDを指定しない削除）は、オブジェクト本体を消去するのではなく、 削除マーカー（Delete Marker） という特殊なバージョンを最新として追加する。GETリクエストはこの削除マーカーを参照して404を返すが、以前のバージョンはストレージ上にそのまま残っている。 一方、バージョンIDを明示した DELETE リクエストは、そのバージョンを完全に消去する。この2つを混同すると復元操作を誤る。削除マーカー自体もバージョンIDを持つオブジェクトであり、これを削除することで直前バージョンが最新に昇格する、というのが復元の基本原理だ。 sequenceDiagram participant Client as クライアント participant S3 as S3 バケット Note over S3: v1 (古いバージョン) Note over S3: v2 (削除前の最新) Client->>S3: DELETE key.txt (バージョンID指定なし) S3-->>S3: 削除マーカー追加 (IsLa...

「Lambda関数からRDSに接続しようとしたら、タイムアウトが返ってくる。セキュリティグループは開いているはずなのに」——この症状で詰まるエンジニアは多い。原因の大半はVPC設定の誤解にある。LambdaをプライベートサブネットのRDSに接続するには、Lambda自身もVPC内に配置する必要があり、その設定には正確なサブネットとセキュリティグループの指定が必要だ。 TL;DR — Lambda × プライベートRDS 接続チェックリスト 確認項目 正しい状態 LambdaのVPC設定 VPC・サブネット・セキュリティグループが明示的に指定されている Lambdaのサブネット RDSと同じVPC内のプライベートサブネット（複数AZ推奨） RDSのセキュリティグループ LambdaのSGからのインバウンドを許可するルールが存在する LambdaのIAMロール VPC ENI作成権限（AWSLambdaVPCAccessExecutionRole）が付与されている インターネットアクセス（必要な場合） NATゲートウェイ経由でのルーティングが設定されている なぜLambdaにVPC設定が必要なのか — 接続の仕組み デフォルト状態のLambda関数はAWSが管理するVPC内で動作しており、ユーザーのVPCリソース（RDS、ElastiCacheなど）には直接到達できない。プライベートサブネットに置かれたRDSはパブリックインターネットからアクセス不可能なため、Lambda側もそのVPCに参加する必要がある。 Lambda関数にVPC設定を行うと、AWSはHyperplane ENI（Elastic Network Interface）をユーザー指定のサブネットに作成し、Lambda実行環境をそのVPCに論理的に接続する。この仕組みにより、Lambda関数はRDSと同じネットワークセグメントから通信できるようになる。 graph LR subgraph AWSManaged["AWSマネージドVPC"] LambdaDefault[...