AWSのネットワーク設計ついて

現在仕事でWEBサービスをAWSで構築しているため、備忘録程度にそのことについて書こうとおもいます。

今回はAWSのVPCのサブネットとセキュリティグループについて、実際に業務で触ったので、その際のネットワークの設計方針に関して書いていきたいと思います。

VPCのサブネット設計方針

 VPCのサブネットを分ける考え方として、以下方針でサブネットを設計しました。

  • Availability Zone
  • 外部（インターネット）へ出る際のルーティング

※私が構築している環境では、Private固定IPアドレスを設定しないため考慮しませんでしたが、固定IPアドレスを使用する場合は、DHCPを使用するサブネットと固定IPのサブネットを分ける必要があると思われます。

以下に大枠のネットワーク構成図を記載します。

ネットワーク構成図

f:id:hangyoun:20150712222857p:plain

 

MultiAZ環境

 AZに関しては、AZレベルの障害を考慮しMultiAZ環境としています。MultiAZにすることにより、AZ間のレイテンシが発生します。（※上記図はざっくり書きましたが、SubnetはAZを跨げないので、Subnetの数は各AZに３つずつ、計６個必要となります）

ルーティング設計

サブネットの数に関しては、ルーティングの設計をどうするかにより変わってきます。私の環境では、以下の３つの区分でサブネットを分けています。

・Front層：外部へのInbound/outbound通信可能なサブネット（GatewayがInternetGateway）

・App層：外部へはProxyを経由してoutbound通信可能（GatewayがProxyサーバ）

・DB層：外部とは通信不可（外部へ出るGatewayが設定されてない）

基本的には、Publicサブネット（インターネットへ通信可能）とPrivateサブネット（インターネットへ通信不可）の２つで、環境によっては、NatやProxyサーバを使うところでは、３つになります。

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からのみ接続許可とする方針としています。