SW BBANG J

DynamoDBで『このアイテムを注文日でも検索したい』と思った瞬間、テーブル設計を見直す羽目になった経験は少なくないはずだ。プライマリキー以外の属性でクエリを実行したいとき、LSI（ローカルセカンダリインデックス）とGSI（グローバルセカンダリインデックス）のどちらを選ぶかは、後から変更できない制約も絡むため、設計段階での判断が特に重要になる。 TL;DR: LSI vs GSI 早見表 項目 LSI（ローカルセカンダリインデックス） GSI（グローバルセカンダリインデックス） パーティションキー ベーステーブルと同一 任意の属性を指定可能 ソートキー 異なる属性を指定 任意の属性を指定可能（省略可） 作成タイミング テーブル作成時のみ テーブル作成後でも追加可能 整合性モデル 強整合性読み取り可能 結果整合性のみ ストレージ制限 パーティションあたり10GB上限 制限なし（テーブル全体と同様） スループット ベーステーブルと共有 独立したキャパシティ設定が可能 テーブルあたりの上限 最大5個 最大20個（デフォルト） DynamoDB セカンダリインデックスの仕組み DynamoDBのセカンダリインデックスは、ベーステーブルのデータを別のキースキーマで参照できるようにした、内部的には独立したデータ構造だ。インデックスへの書き込みはDynamoDBが自動的に管理する非同期プロセスで、ベーステーブルへの書き込みが成功した後にインデックスへ反映される。LSIの場合はこの反映が同一パーティション内で行われるため強整合性読み取りをサポートできるが、GSIは非同期レプリケーションのため結果整合性のみとなる。 インデックスに射影（Projection）する属性の選択も重要だ。 KEYS_ONLY 、 INCLUDE 、 ALL の3種類があり、射影する属性が多いほどストレージコストと書き込みコストが増加する。クエリで必要な属性だけを射影するのが基本的な最適化方針になる。 sequenceDiagram participant App as アプリケーション...

新しい開発者が入社するたびに、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"] ...

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

SESでテストメールは自分宛に届くのに、実際のユーザーへ送信すると失敗する。このAWS SESサンドボックスの制約は、初めてSESを本番利用しようとしたエンジニアが必ず一度は踏む落とし穴だ。なぜ制限されているのか、どう解除するのかを実際の申請フローとともに整理する。 TL;DR：SES サンドボックスモードの要点 項目 サンドボックス 本番環境 送信先 検証済みメールアドレス・ドメインのみ 任意のアドレスへ送信可能 送信レート上限 1秒あたり1通（デフォルト） 申請した上限値 1日の送信上限 200通（デフォルト） 申請した上限値 解除方法 AWSサポートへ本番アクセス申請 — 申請後の反映 通常24時間以内（SLAなし） — SES サンドボックスモードの仕組み AWSはすべての新規SESアカウントをサンドボックス環境に配置する。これはメール配信インフラの悪用防止が目的で、スパム送信者がSESを踏み台にするリスクを下げるための設計だ。サンドボックス内では、送信先が『検証済みID（Verified Identity）』として登録されたメールアドレスまたはドメインに限定される。自分のアドレスを検証済みIDとして登録すれば自分宛には届く。しかし顧客のアドレスは当然登録されていないため、送信しようとするとエラーになる。 検証済みIDには2種類ある。メールアドレス単位の検証と、ドメイン単位の検証だ。ドメイン検証を通過すれば、そのドメイン配下のアドレス宛には送信できる。ただしこれはサンドボックス内での話であり、本番移行前に顧客ドメインをすべて検証するのは現実的ではない。 graph TD A["アプリケーション 送信リクエスト"] --> B["Amazon SES"] B --> C{"アカウントモード確認"} C -->|"サンドボックス"| D{"送信先は検証済みID?"} C -->|"本番環境"| ...

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: スクリプト内容を返...

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