今日はAWSのSecurity Group(以下，SG)に詳しくなった。
EC2でインスタンスを作ろうとしたとき，何の考え無しにインスタンスを公開してパブリックIPなんざ付けた日には全宇宙にインスタンスが公開されて危ない。 なのでAWSには各種のアクセス制御機構が様々な形，様々なレベルで実装されているのは知っていると思う。
例えばVPCは同じAWSアカウントの中に仮想ネットワークを作り，異なるVPCどうしでコンピューティングリソースを隔離する*1効果があるし，サブネットはさらにVPCのネットワークをIPアドレスレンジで分割して名前を付けることで，アクセス制御をやりやすくする。 例えば事業ごとにVPCを分割し，その中でも公開したいインスタンス(e.g. WebサーバやProxy)と隠したいインスタンス(e.g. DBやKVS)とを別のサブネットに配置する，といった具合でアクセス制御を行うことができるようになる。
EC2レベルで動作するSecurity Group
VPCレベルではネットワークの隔離と分割，という手段でアクセス制御を行うが，より下のEC2のレベルにもアクセス制御機構がある。SGはこのEC2のレベルで動作する。SGはEC2インスタンスにひっつけるファイヤウォール(以下，FW)みたいなもの。 一般的なFWはマシンごとに設定するが，SGは複数のインスタンスの通信を1つのSGで制御できるのでより柔軟である。 これは，SGが「EC2インスタンスにSGを割り当てる」という構成で動作するためである。SGによって，特定のIPアドレスレンジ，特定のポートのinbound/outbound通信を許可することができるようになる。
さて，今回は「特定のSGを許可対象のソースに割り当てる」というテクを覚えた。ソースというのは普通はIPアドレスレンジ，例えば10.0.0.0/8とか，::/0といったものを指定する箇所だ。ここに入力したアドレスレンジ(から/行き)の通信が許可される。
ここにSGを指定すると，そのSGがアタッチされているインスタンスのIPアドレス をソースに指定したのと同じ効果になる。
例を挙げよう。private-sg，dmz-sg，public-sgといったSGがあったとする。public-sgに属するインスタンスはどこからでも通信させたいが，private-sgはdmz-sgのみと疎通させたい。そしてdmz-sgは両方のSGと通信できる必要があるとする。
普通ならサブネットを切っておいて，そのアドレスレンジをソースとして指定するが，SG単位でアクセス制御をする場合は対象インスタンスが属するSGをソースとして指定できる。例えば以下のような設定ができる:
private-sg- インバウンド ポート: 任意 ソース:
dmz-sg
- インバウンド ポート: 任意 ソース:
dmz-sg- インバウンド ポート: 任意 ソース:
public-sg - インバウンド ポート: 任意 ソース:
private-sg
- インバウンド ポート: 任意 ソース:
public-sg- インバウンド ポート: 443 ソース: 任意
また応用として，ソースとして自分と同じSGを指定する，というテクニックがある。これは同じSGがついているインスタンス同士の通信を許可するのに使える。
ハマりどころ
ハマりどころとして注意したいのが，ソース指定はインクルードではない，という点である。別SGを指定できるので「ひょっとして別SGの設定を取り込むことができるのでは？」と思ってしまうが，ソースはあくまでも通信先を指定するもので，別SGの設定をインクルードするために使うことはできない。 自分はこれでハマった。カンでやらずにちゃんとマニュアルを読めという話でもある。
SGを使って柔軟なアクセス制御ができることがわかった。
*1:VPC間での疎通はけっこう面倒な印象がある
