シンプルなVPC設計を考える
この記事はAWS Advent Calendar 2014
の24日目の記事です。メリークリスマス!
今日は、最近イチから構成を考える機会があったVPCの設計について、その一部を晒してみたいと思います。
前提
以前からAWSは運用していましたが、今後複数アカウントが乱立したり、利用する人がより増えることが想定されたため、以下のような要件を前提に見直しました。
- Web/Appサーバとデータベースで構成されるWebサービスがメイン
- 複数アカウントで汎用的に利用できること
- なるべくNWレベルの意識をしなくても良いこと
- 運用の発生する部分を減らすこと
- シンプルでわかりやすいこと
基本構成
Functional Firewallパターンをベースにしました。Functional Firewallパターンは、各レイヤーのセキュリティルールをグループ化して適用することで煩雑になりにくく、シンプルに管理することができます。
CDP:Functional Firewallパターン - AWS-CloudDesignPattern
※bastionはsshの踏み台マシンです
VPC/サブネット
サブネットは、パブリックサブネットのみ作成します。プライベートサブネットは、NATインスタンスの冗長化や運用が面倒なのでセキュリティグループでカバーします。最近ではプライベートサブネットを用意せず、全台にPublic IPを振る構成は割と多いとも聞きます。
ただ外部との連携でこちらのGIPが制限されることもあるため、その場合は改めてNATインスタンスかProxyを立てます。
セキュリティグループ
Functional Firewallパターンを元に以下のルールを決めています。
- セキュリティの担保はセキュリティグループで行う
- Network ACLはつかわない
- 基本的にはInboundで制御しOutboundは変更しない
- インスタンスはdefault+機能ごとのセキュリティグループを付与する
Source
には必ずセキュリティグループを指定する- development,staging,productionごとに作り、互いの干渉を防ぐ
Network ACL
はVPCメニュー内にありわかりづらいこと、セキュリティグループと二重管理になりやすいため避けました。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