普段からAWSを使用している場合には当たり前なお話なのですが、VPCをきちんと作成して無駄なリソースはネットワーク上に公開されないようにしておくことでサービスの安全を守ることができたり、ネットワークへの送信時のIPアドレスを全てのサーバーで固定にできたりと多くのメリットが得られます。
しかし、Natゲートウェイは割と料金が高いことやルートテーブルの設定が面倒だったりと個人の検証環境で作成しているケースは多くないのではないでしょうか。
今回は別件で検証を行うためにきちんとプライベートサブネットの作成をする必要があったので、復習も兼ねて検証環境でVPCの設定を行いました。
公式のテンプレートでVPCを作成
今回はGithubのawslabsに公開されているCloudFormationのテンプレートを利用して面倒なVPCの作成をスキップすることにしました。
注意点としてこのテンプレートは古いようで、東京リージョンで作成する際にはアベイラビリティゾーンbの指定をcかdへ変更しておく必要があります。
最近発行されるAWSアカウントではAZ-bは使用できない状態なため、この指定を残したままにするとこのCloudFormationは失敗してしまいます。
正常に作成できることを確認してください。
しっかりと運用する予定があるのであれば、必要に応じてIPのマスクの範囲を変更したり、アベイラビリティゾーンを3つ分作成するようにするように変更するなど用途に応じて書き換えると良いでしょう。
パブリックサブネットを確認
画像のようにパブリックサブネットのルートテーブルではインターネットゲートウェイが指定されています。
そのため、パブリックサブネットで作成したEC2やRDSなどのリソースはネットワークへの送信も受信も可能な公開された状態となります。
プライベートサブネットを確認
一方でプライベートサブネットではNatゲートウェイにルーティングされています。
Natゲートウェイはパブリックサブネット内に配置されており、このNatゲートウェイを経由してプライベートサブネットで作成したEC2やRDSはネットワークへ送信することができます。
一方で、インターネットからの受信はすることができない非公開な状態になります。
ちなみにNatゲートウェイへのルーティングが存在しない場合は、VPC内からしかアクセスができない完全に非公開なサブネットになります。
ちなみにNatゲートウェイにはElasticIPをアタッチする必要があります。
そのためプライベートサブネットからインターネットへ送信する際には、Natゲートウェイに設定しているIPアドレスに固定化されます。
複数のサーバーからの送信が特定のIPアドレスに固定化されるため、IP制御で通信をする外部のサービスやAPIを利用する際には便利です。
LambdaやFargateのIPアドレスを固定する時などにも使えますね。
構成のおさらい
プライベートサブネットに配置したEC2インスタンスなどはインターネットへの送信は可能ですが、インターネットからアクセスすることはできません。
送信が可能ということはプライベートサブネットに配置したEC2からyum installコマンドでパッケージをインストールしたり、pingコマンドで疎通確認をすることはできる状態ですが、直接EC2インスタンスのIPアドレスを指定してブラウザなどからアクセスはできない状態です。
このEC2インスタンスがWebサーバーの場合、インターネットからアクセスできないのは問題になります。
そのケースでは例えばパブリックサブネットに配置したELBをエンドポイントに指定して、ELBを経由してWebサーバーと疎通をすることで対応できます。
その他にも、Webサーバーはパブリックサブネットで公開して、EFSやRDSはプライベートサブネットに配置するなどインターネットへ公開したくはない部分をプライベート領域に配置するのが良いでしょう。
おわりに
VPCの作成についておさらいをしました。
私が実際に業務でAWSを扱っている場合では厳密にプライベートIPアドレスの範囲を管理したり、サブネットマスクの範囲を定めたりと様々なルールの元で運用しているのですが、今回はお試しでVPCを試すためサンプルのCloudFormationを使用しました。
Natゲートウェイの通信コストが結構かかるので個人利用のAWSアカウントではきちんと設定している人は少ないかもしれませんが、AWSを扱う上で必須なサービスではあるため構築を体験しておいて損はないと思います。
コメントを残す