SW BBANG J

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

RDSのスロークエリログを眺めていると、同じSELECT文が毎秒何十回も実行されているのに気づくことがある。商品カタログ、ユーザープロファイル、設定値など、更新頻度が低いのに読み取り頻度が高いデータがRDSを圧迫しているケースだ。ElastiCache Redisをキャッシュ層として導入することで、そのような読み取りクエリの大半をデータベースに到達させずに処理できる。 TL;DR：ElastiCache Redis導入の判断基準 観点 内容 主な用途 読み取り頻度が高く、更新頻度が低いデータのキャッシュ 効果が出やすいパターン 同一クエリの繰り返し実行、セッション管理、ランキング集計 効果が薄いパターン 書き込み主体のワークロード、データが常に変化するケース 主要な構成要素 レプリケーショングループ、プライマリエンドポイント、リーダーエンドポイント キャッシュ戦略 Cache-Aside（Lazy Loading）が最も一般的 注意点 キャッシュ無効化（TTL設計）とコールドスタート対策が必要 ElastiCache Redisの仕組みとアーキテクチャ ElastiCache for Redisは、AWSが管理するインメモリデータストアだ。RDSへのクエリがキャッシュ層でヒットすれば、ディスクI/Oもネットワークラウンドトリップも発生しない。レイテンシはミリ秒単位からサブミリ秒単位に短縮される。 クラスターモード無効（Cluster Mode Disabled）構成では、1つのプライマリノードと最大5つのリードレプリカで構成されるレプリケーショングループを作成する。プライマリエンドポイントへの書き込みは非同期でレプリカに伝播し、リーダーエンドポイントはラウンドロビンでリードレプリカに読み取りを分散する。 graph LR App["アプリケーション"] --> Redis["ElastiCache Redis リーダーエンドポイント"] Redis -->|"キャッシュヒット"...

RDS Multi-AZを有効にしたのに「パフォーマンスが上がるはず」と期待して、後から「何も変わっていない」と気づく — これは本番環境でよく見かける誤解だ。Multi-AZはパフォーマンス機能ではなく、 高可用性とフェイルオーバー のための機能であり、その設計思想を正しく理解しないと、コストと効果のバランスを見誤る。 TL;DR — RDS Multi-AZの要点 観点 Multi-AZの動作 目的 高可用性・自動フェイルオーバー スタンバイインスタンス 読み取り/書き込みトラフィックを受け付けない（通常時） レプリケーション 同期レプリケーション（プライマリ → スタンバイ） フェイルオーバー所要時間 通常1〜2分（DNSエンドポイント切り替え） 読み取りスケールアウト 対象外（Read Replicaが別途必要） コスト シングルAZ比でインスタンス料金が約2倍 RDS Multi-AZの仕組み — 有効化する前に理解すべきこと Multi-AZを有効にすると、RDSはプライマリインスタンスとは 別のアベイラビリティゾーン にスタンバイインスタンスを自動的にプロビジョニングする。プライマリへの書き込みはすべて同期的にスタンバイへレプリケートされる。つまり、プライマリがコミットを返す前にスタンバイへの書き込みも完了していることが保証される。 この同期レプリケーションが、Multi-AZがパフォーマンス向上に寄与しない理由でもある。書き込みレイテンシはスタンバイへの往復時間分だけ増加する可能性がある。アプリケーションからは単一のDNSエンドポイントしか見えず、スタンバイインスタンスへの直接アクセスは通常時は不可能だ。 graph TD App["アプリケーション"] -->|"単一DNSエンドポイント"| Primary["プライマリインスタンス (AZ-A)"] Primary -->|"同期レプリケーション (コミット前に完了)"| Standby[...

「リポジトリはプライベートだから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はこれらの問題を、認証情報をコードから完全に分離することで解...

本番環境でデータ破損が発生し、RDSスナップショットから急いで復元しようとしたとき、多くのエンジニアが同じ疑問にぶつかる。「既存のインスタンスが上書きされるのか、それとも別のエンドポイントを持つ新しいインスタンスが作られるのか」——この挙動を誤解したまま復元操作を実行すると、アプリケーションの接続先が変わらず、復元したはずのデータに誰もアクセスできないという状況が生まれる。RDSスナップショット復元の動作原理を正確に理解しておくことは、障害対応の成否を左右する。 TL;DR：RDSスナップショット復元の要点 項目 挙動 既存インスタンスの上書き 行われない。常に新しいインスタンスが作成される エンドポイント 新しいインスタンス固有のエンドポイントが割り当てられる 元のインスタンス 復元操作後も変更されずそのまま稼働し続ける パラメータグループ / セキュリティグループ デフォルト設定が適用される。元の設定は引き継がれない アプリケーション切り替え エンドポイントの手動変更またはRoute 53 CNAMEの更新が必要 マルチAZ / リードレプリカ 復元時に再設定が必要。スナップショットには含まれない RDSスナップショット復元の仕組み RDSのスナップショット復元は、既存インスタンスへの変更操作ではなく、スナップショットを元にした 新規インスタンスのプロビジョニング として実装されている。これはAWSの設計上の意図であり、復元操作が元のデータを誤って破壊するリスクを排除するための安全機構でもある。 スナップショット自体はS3上に保存されたストレージボリュームのポイントインタイムコピーであり、インスタンスの設定情報（パラメータグループ、セキュリティグループ、マルチAZ設定など）は含まれない。復元時にAWSは新しいDBインスタンス識別子を要求し、そのIDに基づいた新しいエンドポイントを生成する。 graph TD A["稼働中のRDSインスタンス prod-db"] -->|"スナップショット取得"| B[...