Q&A
素朴な疑問なのですが、その複数のお客様はAWS上の同じVPCを参照するんですか？
ネットワーク及びAWSについての知識に乏しいため、たどたどしい説明になってしまって申し訳ございませんが、ご教授ください。
現在の状況
現在、お客様のオンプレ環境とAWSをDirect Connect で接続しています。
そこに別の複数のお客様のオンプレ環境もAWSに接続する事になりました。
現在は最初のお客様から払い出されたローカルIPのセグメント上にAWSを構築しているのですが、追加されるお客様の払い出されるCIDRブロックと重複する可能性もあるため、この辺りの見直しが必要だと考えております。
やりたい事
- お客様から見ると自分のローカルの環境にあるAWSに接続しているように扱いたい
- オンプレとAWS間はDirectConnect or インターネットVPNで接続したい
- 相手のオンプレ環境同士は全く関わりが無いため、払い出されるCIDRブロックは重複する可能性がある
- AWSから各お客様環境上に構築されたAPIを実行する必要がある
- お客様同士は関わりは無いため、アクセスする必要はない
知りたい事
通過するゲートウェイ毎にAWS内のローカルIPアドレスと各お客様のIPアドレスを変換する必要があるのかなと思っているのですが、この辺りを解決するにはどのようなAWSのサービスを使用すればよいでしょうか？
追記
色々調べてみたところ、技術的には双方向NAT（Twice NAT）ってやつでしょうか？これがAWSで実現できれば何とかなるような。。。
はい。その予定です。
セキュリティ的にはよろしくないのでしょうか？
そうすると、もし複数のお客様が同じVPCに対してプライベート接続できた場合そのVPCを介して無関係のお客様のネットワーク同士がつながってしまうと思うのですが、問題ありませんか…？
そのへんを適切にアクセス制御するならいいのかもしれませんけど…。
お客様同士はアクセスできちゃうのはマズイので、アクセスできないよう制御する前提なのですが、基本的にアンチパターンなのでしょうか？
そのため、各お客様も自分のネットワークからのアクセスしか受け付けない事になると思うため、双方向NATで、各顧客に合ったIPの書き換えも必要なのかなと、想像しておりました。
アンチパターンというほどそういったケースがあるのかわからないですが、場合によってお客様のセキュリティポリシーにも絡んでくる部分なのではないでしょうか？
どうしても必須でなければVPCを分けてそれぞれにVPN接続させたほうが無難だと思います。
NATでの変換はプライベートIPとグローバルIPの変換になっちゃう気がするのですが、それは実現可能なんでしょうかね？（そのあたりあまり詳しくないので自分もよくわからないとこですが…）
質問に対して、追加質問で申し訳ありません。
各お客様からアクセスされるWebサーバ（EC2）やDBは同じものを使用したいため、
VPCを分けるという事は、
Aユーザ は Aユーザ専用のVPCへVPNで接続し、 Aユーザ専用VPCから本丸VPC（Webサーバ等があるVPC）へアクセス（VPCピアリング？）するイメージでしょうか？
踏み台VPC的な。
または、アクセスするWebサーバもユーザ毎に分けた方がよいという事でしょうか？
正直、ユーザが増えるたびにWebサーバ増やすのはしたくないなという事と思ってます。。。
そういう用途なんですね…。
WEBサーバに対するアクセスをプライベートネットワーク内で行いたい、ということでしょうか？
できれば分けたほうがいいですが、WEBサーバに対するアクセスとなると考えものですね。
望む回答になるかわかりませんが、それっぽい案のようなものが一応見つかったので回答として貼っておきます。
説明していると少し自分でも整理できてきました。
Webサーバ自体はインターネットに公開されています。
重要なのは、
AWSから各お客様環境上に構築されたAPIを実行する
というところで、
各お客様環境に用意されたAPIを、1つのWebサーバ（EC2）から叩きに行くのですが、
お客様のネットワークはクローズであるため、どうやってインターネットに出ずに、それぞれのお客さんのAPIまで辿りつけるのか？
という所が分からない感じでした。
（Webがインターネットに公開されている時点で、完全なクローズじゃないといえばそれまでなのですが）
要はお客様は自分のアカウントでWebシステムへログインすると、自分の会社のAPIから取得した情報が表示されるという感じでしょうか。
結構複雑な要件ですね…。この件に関しては要件を無視して考えることはできませんね。
結局の所頑張ってアクセス制御をするしかないような気はします。
WEBサーバにあるVPCと直接接続するのではなく、VPCを一つ挟んでそこにNATなりプロキシなりを立てて、という形が現実的な線だと思います。
お客様ごとにNATを立てるなら結局それぞれに専用のものを用意することになりそうですが、同じシステムを複製するよりはマシですね…。
複製するほうが実現は楽ですがおっしゃるとおり懸念はコストですね。
この要件だとWEBサーバからお客様側のAPIにアクセスできればよく、向こうからWEBサーバへプライベートネットワークでアクセスできる必要はないので、それを加味した上でVPCに大してVPNを貼るのはアリかもしれません。
ただ、前述の通り直接該当のVPC同士をつなぐとお客様側のセキュリティポリシーが絡んでくると思うのでそこは確認が必要です。（別VPCを挟むなら恐らく問題はないでしょうけど）
既に利用しているお客様はVPNじゃなくてDirect Connectですからね…。
あと、WEBサーバをALB配下に置いて、WEBサーバそのものにはインターネットからアクセス出来ないようにしたほうがいいかなと。
ユーザが増えることが見込まれるなら将来的にはそのほうが楽です。
親身にありがとうございます。嬉しいです。
おっしゃるとおり、
VPCを一つ挟んでそこにNATなりプロキシなりを立てる
が良さそうですね。
導入後のメンテは軽そうですが、ここがボトルネックになりそうな懸念もありますが。
間に挟んだVPCへのアクセス周りは、恐らくリンクを頂いた内容の何か(Transit Gatewayとか使えそう？）が使えそうですね。
いろいろ勉強してみます。
回答1件
0
ベストアンサー
一応、下記のようなものがありました。
ハイブリッドネットワーク アーキテクチャ (IP重複対策)
ユーザが増えるごとに同VPCにアクセスする相手を増やすとなると中々難易度が高いですね…。
投稿2020/07/30 07:05
総合スコア7588
あなたの回答
tips
プレビュー
