QUESTION

運用チームは、台数が 4 台から 20 台まで変動する Amazon EC2 の Auto Scaling グループをプライベートサブネットで運用しています。インスタンス群は外部の決済事業者の API を呼び出します。決済事業者は、あらかじめ登録された固定の送信元 IPv4 アドレスからの接続だけを受け付けます。インターネットゲートウェイは構成済みです。 最小限の運用上のオーバーヘッドで、これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか。

1 / 1
回答を選択してください
正解B

解説

台数が変動するインスタンス群からの外向きの通信の送信元アドレスを、1 つに固定する構成を選ぶ

  • 1台数が 4 台から 20 台まで変動する送信元になりうるインスタンスの数が固定されていません。1 台ずつにアドレスを割り当てて登録する案は、増減と入れ替えのたびに登録作業が発生し続けるため、運用上のオーバーヘッドを最小にするという条件で落ちます。
  • 2プライベートサブネットで運用インスタンス自身は、インターネットから直接届かない場所に置かれています。インスタンスにパブリックのアドレスを持たせる案はこの配置そのものを崩すことになり、外へ出る経路の側で送信元を 1 つにまとめる案が残ります。
  • 3あらかじめ登録された固定の送信元 IPv4 アドレスからの接続だけを受け付けます判定されるのは受信の宛先ではなく、外向きの通信の送信元アドレスです。起動のたびに払い出されるアドレスでは登録済みの値と一致せず接続が拒否されるため、台数が変わっても変わらないアドレスを送信元にできるかどうかが正誤を分けます。
A不正解

Network Load Balancer を作成してインスタンス群をターゲットに登録し、そのアドレスを決済事業者へ通知する。

Network Load Balancer (NLB) は、有効にしたアベイラビリティーゾーンごとに固定の IP アドレスを持ち、クライアントからの接続を受ける入口になります。「アドレスを固定したい」という言葉だけを見ると当てはまりそうに読めます。

しかし、ターゲットのインスタンスから決済事業者へ向かう外向きの通信はロードバランサーを通らないため、NLB の固定アドレスが送信元になることはありません。プライベートサブネットのインスタンスは NAT デバイスが無いとインターネットへ出られないので、この構成のままでは決済事業者へ接続すること自体ができません。

B正解

Elastic IP を関連付けた NAT ゲートウェイを作成し、プライベートサブネットのルートをそこへ向ける。

パブリック NAT ゲートウェイ は、プライベートサブネットのインスタンスの送信元アドレスを NAT ゲートウェイのアドレスに置き換え、インターネットゲートウェイがそれを NAT ゲートウェイに関連付けた Elastic IP アドレスに変換して外へ出します。送信元の置き換えはインスタンスではなく経路の側で起きるため、20 台まで増えても決済事業者から見える送信元は常に同じ Elastic IP 1 つです。

インスタンスの入れ替えや台数の変化があっても、決済事業者へ登録し直す作業は発生しません。NAT ゲートウェイはマネージドサービスとしてアベイラビリティーゾーン内で冗長化され、決済事業者へは Elastic IP を 1 つ登録するだけで済むため、運用上のオーバーヘッドという条件にも合います。

C不正解

インスタンスをパブリックサブネットへ移し、各インスタンスのパブリック IPv4 アドレスを決済事業者へ通知する。

パブリックサブネットでパブリック IPv4 アドレスの自動割り当てを有効にすれば、各インスタンスは起動時にアドレスを受け取り、インターネットゲートウェイ経由で外と通信できます。追加の構成要素なしで外へ出られる手軽な構成です。

ただし自動割り当てのパブリック IPv4 アドレスは AWS のプールから起動のたびに払い出されるもので、停止や入れ替えで別のアドレスに変わります。Auto Scaling で新しく起動したインスタンスも毎回異なるアドレスになるため、あらかじめ登録した固定のアドレスとは一致せず、決済事業者に接続を拒否されます。台数分のアドレスを都度通知し直す運用も残り、送信元を固定するという条件を満たせません。

D不正解

各インスタンスに Elastic IP を関連付け、パブリックサブネットへ移してルートをインターネットゲートウェイへ向ける。

Elastic IP アドレス をインスタンスに関連付ければ、そのインスタンスの送信元は固定され、パブリックサブネットに置けばインターネットゲートウェイ経由で直接外へ出られます。台数が固定で少なければ成立する構成です。

しかし Auto Scaling グループでは、インスタンスが増減と入れ替えを繰り返します。起動のたびに Elastic IP の関連付けと決済事業者への登録が必要になり、台数分のアドレスを管理し続けることになるため、送信元は固定できても運用上のオーバーヘッドは最小になりません。インスタンスがインターネットから直接到達できる場所へ移る点も、プライベートサブネットで運用しているという前提から離れます。

ポイント

「外部の相手が送信元 IP を許可リストで制限している」「台数が変動する」と読んだら、送信元を 1 か所に集約して固定する設計を考えます。使うのはパブリック NAT ゲートウェイと Elastic IP の組み合わせです。
NAT ゲートウェイ — 送信元を NAT ゲートウェイのアドレスに置き換え、インターネットゲートウェイがそれを関連付けた Elastic IP に変換します。台数が増減しても外から見える送信元は同じです。
インスタンスごとの Elastic IP — 入れ替えのたびに関連付けと相手側への登録が要り、アドレスの数も台数分になります。
受信側の仕組みと混同しない — Network Load Balancer や AWS Global Accelerator の固定 IP アドレスはクライアントから受ける側の入口で、外へ出ていく通信の送信元には関与しません。