同じCIDRブロックを持つ複数のVPCを共有VPCに接続する
私の会社のAWSクラウドには、主要なAPI環境（開発、テスト、ステージ、製品）ごとに1つずつ、合計4つのVPCがあります。これらの環境を互いに可能な限り類似させるために、すべての環境でCIDRブロックが10.0.0.0/16に設定されています。
現在、これらの環境間で共有される内部サービスを作成する必要が生じています。議論のために、この新しいサービスがこれらすべての環境からのログデータを格納するとしましょう。このサービスは、CIDRブロックが10.1.1.0/24の独自のVPCに存在します。
最初は、すべての環境VPCからのピアリング接続をロギングVPCに簡単に追加できると思いました。しかし、ルートテーブルの設定を開始したときにハードルに遭遇しました。 Dev-> Loggingからルートテーブルを作成しました。これにより、すべてのトラフィックが宛先10.1.1.0/24にルーティングされます。しかし、それでもdev内からロギングサーバーに接続できません。宛先10.0.0.0/16ですべてのトラフィックをルーティングするLogging-> Devのルートテーブルを追加する必要があるようです。これにより、開発サーバーからロギングサーバーに接続できますが、他の環境をロギングVPCに接続できなくなりました。
ロギングサーバーは、APIサーバーとの接続を開始する必要はなく、接続を受信して応答するだけで済みます。したがって、次の考えは、各環境VPCでNATゲートウェイを使用して、それらをロギングVPCにルーティングできるということでした。残念ながら、NATゲートウェイはインターネットに直接接続されており、ロギングVPCをインターネットに接続したくありません。
これを機能させる方法があるに違いないと思いますが、私には考えられません。現時点では、4つのロギングVPCを作成し、それぞれで個別のロギングサーバーを実行することが唯一の選択肢であると感じていますが、コストの観点からは、これはあまり魅力的ではありません。
まず、言及する必要があります。VPCでサブネットを複製することにより、非常に重大なエラーが発生しました。それらの間でトラフィックをルーティングする必要がある可能性がほぼゼロであっても、RFC1918アドレス空間は、各VPCに一意のサブネットを与えるのに十分な大きさです。 AWSのトピックについて多くの企業と相談し、「マスターサブネットリスト」スプレッドシートを維持して、顧客にVPCを割り当てるときに使用中のサブネットを記録し、重複するサブネットがないことを確認します。
あなたの質問に対する明白な答えは、重複するVPCに番号を付け直すことです。これは苦痛になりますが、これはこの問題に対する正しい答えであり、この問題を完全に解決します。
それが選択肢ではない場合、私は他のいくつかの選択肢を考えることができます：
- ログにSQSを利用する-アプリVPCからSQSキューにログを送信し、各アプリVPCのソースIDで注釈を付けてから、ロギングVPCからのSQSからのログを消費します。あなたが述べた問題を解決することに加えて、これはあなたのログプロデューサーとログコンシューマーの間にvery高可用性バッファーを置きます。これにより、インフラストラクチャに問題が発生した場合、またはメンテナンスのためにログを停止する必要がある場合に、ログが失われるのを防ぐことができます。
- パブリックIP（ELB、EIPなど）を介してロギングエンドポイントを公開し、ファイアウォールで保護して、アプリサーバーのパブリックIPのみがヒットし、この方法でログを送信できるようにします。トラフィックはAWSのネットワークに残り、暗号化および認証されている限り、セキュリティの問題はそれほど多くありません。ただし、帯域幅にはより多くの費用がかかります。