SW BBANG J

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

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

新しい開発者が入社するたびに、IAM ユーザーを作成してポリシーを一枚一枚アタッチしていた運用が、ある日突然破綻する。10人のユーザーに同じポリシーを直接アタッチしていた環境で権限変更が必要になったとき、10回の手作業が発生する。IAM グループはこの問題を構造的に解決するための仕組みだ。 TL;DR：IAM グループ vs. ユーザーへの直接アタッチ 観点 ユーザーへの直接アタッチ IAM グループ経由 権限変更のコスト 対象ユーザー数分の操作が必要 グループポリシーを1回変更するだけ 新規ユーザーへの権限付与 毎回ポリシーを手動アタッチ グループに追加するだけ 権限の一貫性 ユーザーごとにズレが生じやすい グループ単位で統一される 監査・レビューのしやすさ ユーザーごとに確認が必要 グループのポリシーを見れば全体像が分かる IAM ポリシー上限への影響 ユーザーあたりのアタッチ上限を消費 グループ側で集約できる IAM グループの仕組みを理解する IAM グループはユーザーの集合体であり、それ自体がプリンシパルとして AWS リソースにアクセスするわけではない。グループにアタッチされたポリシーは、そのグループに所属するすべての IAM ユーザーに対して有効になる。ユーザーが複数のグループに所属している場合、各グループのポリシーはすべて評価される。 重要な点として、IAM グループは IAM ロールとは異なり、フェデレーションユーザーや AWS サービスに対してアタッチすることはできない。また、グループをネストする（グループの中にグループを入れる）ことも IAM ではサポートされていない。 graph TD GroupDev["IAM グループ: Developers"] GroupOps["IAM グループ: Operators"] PolicyS3["ポリシー: S3ReadOnly"] PolicyEC2["ポリシー: EC2FullAccess"] ...

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["メッセージ配信されない 再サブ...

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

「リポジトリはプライベートだからDBパスワードをコードに書いても大丈夫」——この判断が、本番インシデントの引き金になるケースを何度も見てきた。AWS Secrets Managerを使った自動ローテーションの仕組みを理解すれば、なぜハードコーディングが構造的なリスクなのかが明確になる。 TL;DR：Secrets Managerとハードコーディングの比較 観点 ハードコーディング Secrets Manager 認証情報の漏洩経路 Gitログ、CI/CDログ、コアダンプ IAMポリシーで制御、監査ログあり パスワードローテーション 手動。デプロイが必要 自動。アプリ再起動不要 アクセス制御 コードを読める人全員 IAMロール単位で最小権限 監査証跡 なし CloudTrailに全API呼び出しを記録 複数環境管理 環境ごとに別ファイル管理が必要 シークレット名のパスで分離可能 なぜ「プライベートリポジトリだから安全」は成立しないのか プライベートリポジトリはアクセス制御の一層に過ぎない。問題はそこではなく、認証情報がコードに埋め込まれた瞬間に複数の経路で漏洩リスクが生まれる点にある。 Gitの履歴は削除できない ：一度コミットされたパスワードは、後からファイルを修正しても git log -p で復元できる。 git filter-repo で履歴を書き換えても、フォークやローカルクローンには残る。 CI/CDパイプラインのログ ：環境変数として渡した場合でも、デバッグログやエラートレースに平文で出力されることがある。 コアダンプとヒープダンプ ：アプリケーションがクラッシュした際、メモリ上の文字列がダンプファイルに含まれる。 内部脅威 ：リポジトリへのアクセス権を持つ開発者が退職した後も、その認証情報は有効なまま残る。 ハードコーディングされたパスワードは、金庫の鍵を金庫の扉に貼り付けているようなものだ。扉が閉まっていても、鍵が見えていれば意味がない。 Secrets Managerはこれらの問題を、認証情報をコードから完全に分離することで解...

月曜の朝、本番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[...