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

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...

S3のファイルを差し替えたのに、CloudFrontが古いバージョンを返し続ける。デプロイ直後にこの状況に直面したエンジニアは多い。原因はCloudFrontのエッジキャッシュにある。 CloudFront Invalidation を使えばエッジロケーションのキャッシュを即時パージできるが、実行タイミングや対象パスの指定を誤ると、コストが無駄になるか、キャッシュが残り続ける。 TL;DR — CloudFront Invalidationの要点 項目 内容 問題 S3更新後もCloudFrontが古いオブジェクトを返す 原因 エッジロケーションにキャッシュされたオブジェクトのTTLが残っている 解決策 Invalidationリクエストで対象パスのキャッシュを強制削除 注意点 月1,000パス超は有料。ワイルドカード /* は1パスとしてカウント 推奨アプローチ ファイル名バージョニング + Invalidationの組み合わせ CloudFrontのキャッシュ動作を理解する CloudFrontはオリジン（S3など）から取得したオブジェクトを、世界中のエッジロケーションにキャッシュする。ビューワーからのリクエストはオリジンではなく最寄りのエッジに到達し、キャッシュヒットすればオリジンへの通信は発生しない。 キャッシュの有効期間はCache-Controlヘッダー（ max-age ）またはCloudFrontのディストリビューション設定（デフォルトTTL / 最大TTL）によって決まる。S3でファイルを上書きしても、エッジのキャッシュエントリが生きている限りCloudFrontは古いオブジェクトを返し続ける。TTLが切れるのを待つか、Invalidationで強制削除するかの二択だ。 graph LR Viewer["ビューワー （ブラウザ）"] Edge["エッジロケーション （CloudFrontキャッシュ）"] Origin["オリジン （S3バケット）"] Invalid...

S3バケットの暗号化設定を検討していると、必ずぶつかるのが「AWS管理キーで十分か、それともCustomer Managed Key（CMK）が必要か」という判断だ。コスト、制御レベル、監査要件——どれを優先するかによって答えが変わる。この記事では、AWS KMSの仕組みを実際の運用視点で整理し、S3暗号化における選択基準とコスト計算の考え方を具体的に解説する。 TL;DR：AWS管理キー vs Customer Managed Key（CMK） 比較項目 AWS管理キー（aws/s3） Customer Managed Key（CMK） キーポリシーの制御 不可（AWSが管理） 可能（完全制御） キーローテーション 1年（約365日）自動・変更不可 有効化すると1年ごとに自動（設定可能） クロスアカウントアクセス 不可 可能（キーポリシーで制御） キーの無効化・削除 不可 可能（削除は7〜30日の待機期間あり） CloudTrail監査 KMS API呼び出しはログに記録される KMS API呼び出しはログに記録される KMSキー料金 無料 月額料金あり（最新料金はAWS公式参照） APIリクエスト料金 発生する 発生する 主なユースケース シンプルな暗号化、コスト優先 コンプライアンス、クロスアカウント、アクセス制御 AWS KMSの仕組み：S3暗号化のデータフロー KMSを理解する上で最も重要な概念は、KMSが直接データを暗号化するわけではないという点だ。KMSはデータキー（Data K...

非公開のS3バケットに保存されたファイルを、認証なしのユーザーに一時的にダウンロードさせたい場面は頻繁に発生する。IAMユーザーを発行するわけにもいかず、バケットをパブリックにするのは論外だ。そこで使うのがS3署名付きURL（Presigned URL）で、これはAWS SDKを使って1時間などの有効期限付きで発行できる。 TL;DR：S3署名付きURLの要点 項目 内容 目的 非公開S3オブジェクトへの一時的なHTTPアクセスを付与する 有効期限 生成時に指定（例：3600秒 = 1時間） 認証情報 生成者のIAM認証情報がURLに埋め込まれる 主な用途 ファイルダウンロードリンク、アップロード委譲 バケットポリシー パブリックアクセス設定の変更は不要 SDK Python（boto3）、JavaScript（AWS SDK v3）など主要言語対応 S3署名付きURLの仕組み 署名付きURLは、IAM認証情報（アクセスキーまたはIAMロール）を使ってリクエストに署名したURLを事前に生成する仕組みだ。URLを受け取ったユーザーは、AWSの認証情報を持っていなくても、そのURLにHTTP GETリクエストを送るだけでオブジェクトを取得できる。有効期限が切れるか、署名に使った認証情報が無効になれば、URLも機能しなくなる。 ホテルのルームキーに近い。フロントが発行した一時的なカードで、チェックアウト後は使えなくなる。マスターキーを渡しているわけではない。 重要な点として、署名付きURLの有効性は 生成時に使用したIAM認証情報の有効性に依存する 。IAMロールの一時的な認証情報（例：EC2インスタンスプロファイルやAssumeRoleで取得したトークン）を使って生成した場合、そのトークンの有効期限が署名付きURLの有効期限より先に切れると、URLも無効になる。これは見落としやすい落とし穴だ。 sequenceDiagram participant App as アプリケーションサーバー participant SDK as AWS SDK ...

S3バケットへのアップロードをトリガーにLambdaが起動し、処理結果を同じバケットに書き戻す——この構成は一見シンプルだが、Lambda無限ループという本番障害の定番パターンだ。気づいたときにはLambdaの同時実行数が上限に張り付き、コストが爆発している。 TL;DR：Lambda S3再帰トリガー対策まとめ 対策 難易度 確実性 適用場面 プレフィックス／サフィックスフィルタ 低 中 入出力パスが明確に分離できる場合 出力バケットを完全分離 低 高 新規設計・構成変更が可能な場合 オブジェクトメタデータで処理済みフラグ 中 中 同一バケット・同一パスが必須の場合 なぜLambda S3再帰トリガーが発生するのか S3のイベント通知は、バケット上で発生したオブジェクト操作イベント（ s3:ObjectCreated:* など）をLambdaに配信する仕組みだ。Lambdaが処理結果を同じバケットに PutObject すると、それ自体が新たな ObjectCreated イベントを発生させる。S3はそのイベントを再びLambdaに送り、Lambdaはまた書き込み、以降これが繰り返される。 graph LR User["ユーザー"] -->|"PutObject"| S3["S3バケット"] S3 -->|"ObjectCreated イベント"| Lambda["Lambda関数"] Lambda -->|"処理結果をPutObject"| S3 S3 -->|"再びObjectCreated"| Lambda Lambda -->|"また書き込み..."| S3 style S3 fill:#FF9900,color:#fff style Lambda fill:#FF6B6B,color:#fff Upload ：ユーザーがオブジェクトを...

EC2上のアプリケーションにS3アクセスを与えようとしたとき、最初に思いつくのは「IAM Userを作ってアクセスキーを発行すればいい」という方法だ。実際、多くの現場でこのパターンが使われてきたが、これは後になって必ず問題を起こす。IAM UserとIAM Roleの違いを正確に理解していないと、セキュリティインシデントの温床になる設計を量産することになる。 TL;DR — IAM UserとIAM Roleの比較 観点 IAM User IAM Role 認証方式 長期クレデンシャル（アクセスキー／パスワード） 一時的なSTSトークン（自動ローテーション） 主な用途 人間のオペレーター、CLIを使う開発者 AWSサービス、アプリケーション、クロスアカウントアクセス EC2からS3アクセス 非推奨（アクセスキーをインスタンスに配置するリスク） 推奨（インスタンスプロファイル経由で自動取得） クレデンシャル管理 手動ローテーションが必要 STSが自動でローテーション 最小権限の実装 ユーザー単位またはグループ単位 ロール単位、引き受けるエンティティを信頼ポリシーで制御 IAM UserとIAM Roleの仕組みを理解する IAM Userは「人」に対応するアイデンティティだ。ユーザー名とパスワード、またはアクセスキーID／シークレットアクセスキーというロングタームクレデンシャルを持つ。このクレデンシャルは明示的にローテーションしない限り有効であり続ける。 IAM Roleはそれとは根本的に異なる。Roleは「引き受けるもの」であり、それ自体はクレデンシャルを持たない。エンティティ（EC2インスタンス、Lambda関数、別アカウントのユーザーなど）がRoleを引き受けると（AssumeRole）、AWS Security Token Service（STS）が一時的なクレデンシャルを発行する。このトークンは有効期限付きで、自動的に更新される。 IAM Userのアクセスキーは、金庫の鍵を複製して誰かに渡すようなものだ。IAM Roleは、必要なときだけ開く電子錠に近い。鍵そのもの...