Around the World

すとぶろ

シンプルなVPC設計を考える

この記事はAWS Advent Calendar 2014の24日目の記事です。メリークリスマス!

今日は、最近イチから構成を考える機会があったVPCの設計について、その一部を晒してみたいと思います。

前提

以前からAWSは運用していましたが、今後複数アカウントが乱立したり、利用する人がより増えることが想定されたため、以下のような要件を前提に見直しました。

  • Web/Appサーバとデータベースで構成されるWebサービスがメイン
  • 複数アカウントで汎用的に利用できること
  • なるべくNWレベルの意識をしなくても良いこと
  • 運用の発生する部分を減らすこと
  • シンプルでわかりやすいこと

基本構成

Functional Firewallパターンをベースにしました。Functional Firewallパターンは、各レイヤーのセキュリティルールをグループ化して適用することで煩雑になりにくく、シンプルに管理することができます。

CDP:Functional Firewallパターン - AWS-CloudDesignPattern

f:id:strsk:20141224155422p:plain

※bastionはsshの踏み台マシンです

VPC/サブネット

サブネットは、パブリックサブネットのみ作成します。プライベートサブネットは、NATインスタンス冗長化や運用が面倒なのでセキュリティグループでカバーします。最近ではプライベートサブネットを用意せず、全台にPublic IPを振る構成は割と多いとも聞きます。

ただ外部との連携でこちらのGIPが制限されることもあるため、その場合は改めてNATインスタンスかProxyを立てます。

セキュリティグループ

Functional Firewallパターンを元に以下のルールを決めています。

  • セキュリティの担保はセキュリティグループで行う
  • Network ACLはつかわない
  • 基本的にはInboundで制御しOutboundは変更しない
  • インスタンスはdefault+機能ごとのセキュリティグループを付与する
  • Sourceには必ずセキュリティグループを指定する
  • development,staging,productionごとに作り、互いの干渉を防ぐ

Network ACLVPCメニュー内にありわかりづらいこと、セキュリティグループと二重管理になりやすいため避けました。Outboundを利用しないのもセキュリティグループ間の重複を避けるためです。また、グループを抽象化することによって、ある程度の構成の違い(ミドルウェアやポート)は吸収でき、設定箇所が多くならないため管理が煩雑になりにくくなります。

下記はSecurity Groupの利用イメージです。

default

Type Protocol Port Range Source
SSH TCP 22 sg-bastion(踏み台)
All ICMP All N/A default

prd-front(elb)

Type Protocol Port Range Source
HTTP TCP 80 0.0.0.0/0
HTTPS TCP 443 0.0.0.0/0

prd-middle(web/app)

Type Protocol Port Range Source
HTTP TCP 80 sg-prd-front

prd-back(db/cache)

Type Protocol Port Range Source
MYSQL TCP 3306 sg-prd-middle
Custom TCP Rule TCP 11211 sg-prd-middle

まとめ

このような初期設定を行うことで、利用者はVPCをあまり意識しなくても良くなり、セキュリティグループでの制御だけ設定する環境ができます。ただし自由度は下げたくないので、あくまでベースとして設定し、利用者に合わせて変更するところは変更しています。

※この構成は、所属している会社全体の方針ではありませんm(_ _)m