AWSのネットワーク設計ついて
現在仕事でWEBサービスをAWSで構築しているため、備忘録程度にそのことについて書こうとおもいます。
今回はAWSのVPCのサブネットとセキュリティグループについて、実際に業務で触ったので、その際のネットワークの設計方針に関して書いていきたいと思います。
VPCのサブネット設計方針
VPCのサブネットを分ける考え方として、以下方針でサブネットを設計しました。
- Availability Zone
- 外部(インターネット)へ出る際のルーティング
※私が構築している環境では、Private固定IPアドレスを設定しないため考慮しませんでしたが、固定IPアドレスを使用する場合は、DHCPを使用するサブネットと固定IPのサブネットを分ける必要があると思われます。
以下に大枠のネットワーク構成図を記載します。
ネットワーク構成図
MultiAZ環境
AZに関しては、AZレベルの障害を考慮しMultiAZ環境としています。MultiAZにすることにより、AZ間のレイテンシが発生します。(※上記図はざっくり書きましたが、SubnetはAZを跨げないので、Subnetの数は各AZに3つずつ、計6個必要となります)
ルーティング設計
サブネットの数に関しては、ルーティングの設計をどうするかにより変わってきます。私の環境では、以下の3つの区分でサブネットを分けています。
・Front層:外部へのInbound/outbound通信可能なサブネット(GatewayがInternetGateway)
・App層:外部へはProxyを経由してoutbound通信可能(GatewayがProxyサーバ)
・DB層:外部とは通信不可(外部へ出るGatewayが設定されてない)
基本的には、Publicサブネット(インターネットへ通信可能)とPrivateサブネット(インターネットへ通信不可)の2つで、環境によっては、NatやProxyサーバを使うところでは、3つになります。
Natサーバなどを使うかどうかは、システム要件とあとは好みによってもわかれると思います。NatやProxyを使う要件としては、例えば外部の会社と連携しており、向こうでこちらのGlobalIPアドレスをファイアウォールで通信可能にしているなど、GlobalIPアドレスを固定しないといけないケースなどがあると思います。
そういったシステム要件がなく、単純にYumなどでインターネットへ通信したいだけならば、PublicIPアドレスを各EC2に付与しても通信できるため、Natを使うかどうかは好みの問題なると思います。
セキュリティの設計方針について
セキュリティの考え方としては、以下方針で設計しました。
- セキュリティは基本的にセキュリティグループを使用
- 各セキュリティグループはInboundで制御し、Outboundは使用しない(似たような設定が重複し、設定が複雑になり修正漏れが発生するので)
- セキュリティグループの種類としては、全インスタンス共通のDefaultグループと各サービスごとのセキュリティグループで構成
- 外部からAWSのサーバへのSSH接続は、Bastion(踏み台サーバ)を経由
セキュリティグループの使用
AWSにはセキュリティグループのほかにもNetworkACL(サブネット単位でファイアウォールの制御)もありますが、基本的にインスタンスレベルで制御できるセキュリティグループを使用し、NetworkACLは使用しません。
また、セキュリティグループのSourceの制御は、基本的にSecurityGroupのIDを使用します。IPアドレスのレンジでも許可できますが、セキュリティグループの方が許可範囲をセキュリティグループを付与したインスタンスに絞れるためです。
SSH接続
AWS環境へのSSH接続は、Bastion(踏み台サーバ)を経由して行います。
そうすることで、セキュアな構成になります。また、AWS環境へSSH接続の必要のないときには、Bastionサーバを停止することにより、外部からはSSH接続できず、セキュリティの向上にもつながります。(※一応AZ障害を考慮し、各AZに踏み台サーバ設定していますが、片方のAZの踏み台サーバは障害が発生しないと使用しないため、常時停止しています。)踏み台サーバのセキュリティグループは、社内からのGlobalIPアドレスのみを許可し、その他へのサーバへはBastionからのみ接続許可とする方針としています。