AWS NACLとセキュリティグループのステートレス/フルの違いを体験してみた

#はじめに
AWSの通信制御の仕組みとして「NACL (Network ACL)」と「セキュリティグループ」がありますが、自分の中で両者を混同しがちであったため、今一度整理すると共に、「ステートレス」、「ステートフル」の違いについて、実際に体験してみました。

#前提
まずはNACLとセキュリティグループの違いをまとめた表と検証を実施したAWSの構成図を以下に記載します。

<table>
<tr>
 <td><b>-</b></td>
  <td><b>NACL<b></td>
  <td><b>セキュリティグループ</b></td>
</tr>
<tr>
  <td><b>適用範囲</b></td>
  <td>サブネット単位</td>
　<td>インスタンス単位</td>
</tr>
<tr>
  <td><b>State</b></td>
  <td>ステートレス(往路の通信は手動で制御)</td>
  <td>ステートフル(往路の通信は動的に許可)</td>
</tr>
<tr>
  <td><b>ルール</b></td>
  <td>IN/OUTの通信に対し、許可/拒否のいずれも制御可能</td>
　<td>IN/OUTの通信に対し、許可のみ制御可能</td>
</tr>
</table>


![インフラ構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/f8a83720-aa69-e742-7f1b-b73ff65a6f99.png)

#ping疎通確認によるステートレス/フルの違いについて
上記の構成でEC2インスタンスを2台構築し、双方のping疎通確認を通して、ステートレス/フルの違いを体験しました。以下の2パターンで検証をしましたのでひとつずつ整理していきます。

<table>
<tr>
 <td><b>パターン</b></td>
  <td><b>内容<b></td>
</tr>
<tr>
  <td><b>１</b></td>
  <td>セキュリティグループによるICMPの制御<br>( NACLはIN／OUT共にすべてのトラフィックを許可 )</td>
</tr>
<tr>
  <td><b>２</b></td>
  <td>NACLによるICMPの制御<br>( セキュリティグループはIN／OUT共にすべてのトラフィックを許可 )</td>
</tr>
</table>

※ VPC内の通信において、NACLとセキュリティグループの双方で許可されたものが疎通可能になりますので、違いが分かりやすくなるよう、パターン1の場合はNACLを全許可、パターン2の場合はセキュリティグループを全許可しました。

###パターン1
NACL#1、2の設定を全許可し、Security group#1、2の設定でICMPの制御をした場合、EC2#1、2間のping疎通確認の結果は次の通りになりました。
![結果1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/7bcd078c-ab68-95db-32fa-cc32d99e1813.png)

No.1ではSecurity group#1、#2共にICMPの受信許可をしていないため、EC2#1からEC2#2に対してpingを打っても、EC2#2からEC2#1に対してpingを打っても応答はありませんでした。

順番が前後しますが、No.4ではSecurity group#1、2共に受信、送信でICMPの許可設定をしているため、EC2#1からEC2#2に対してpingを打っても、EC2#2からEC2#1に対してpingを打っても応答がありました。

**セキュリティグループでの設定がステートフルであることが体験できたのはNo.2とNo.3の赤丸のところです。**
No.2でEC2#1からEC2#2にpingを打った場合、Security group#1ではICMPの受信許可をしていないため、pingの戻りの通信は届かないかと思いましたが、結果は応答ありの○となりました。以上よりセキュティグループはステートフルであり、戻りの通信は動的に許可されることが体験できました。(No.3の赤丸も同様です。)

参考としてNo.2の場合のセキュリティグループの設定画面を置きます。
【Security group#1】
端末からのssh接続用のルールのみ設定
![スクリーンショット 2021-01-31 17.18.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/1cac3172-4fe4-9a5e-25a1-3355df520eb5.png)
![スクリーンショット 2021-01-31 17.18.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/f0c8b6d7-a4fe-c605-54ef-d29c81880036.png)
【Security group#2】
端末からのssh接続用のルールと、ping疎通用のルールを設定
![スクリーンショット 2021-01-31 17.25.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/10e71c38-feea-478a-8bf9-7e66dff5e1ad.png)
![スクリーンショット 2021-01-31 17.18.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/4ccc7b14-4262-5bbb-6b65-7125fe9c9e2c.png)

###パターン2
セキュリティグループの設定を全許可し、NACL#1、2の設定でICMPの制御をした場合、EC2#1、2間のping疎通確認の結果は次の通りになりました。
![スクリーンショット 2021-01-31 17.30.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/979eb7cc-9bf4-e95d-0c0e-a1f4df755d09.png)
**NACLでの設定がステートレスであることが体験できたのはNo.2とNo.3の赤い×のところです。**
No.2でEC2#1からEC2#2にpingを打った場合、NACL#1ではICMPの送信の許可はしているが、受信の許可をしていないため、pingの戻りの通信は届きませんでした。以上よりNACLはステートレスであり、往復の通信を許可するためにはNo.4のようにIN/OUT双方に許可設定をいれる必要があることが体験できました。

参考としてNo.2の場合のNACLの設定画面を置きます。
【NACL#1】
端末からのssh接続用のルールのみ設定
![スクリーンショット 2021-01-31 17.42.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/428e295c-fe23-b0d6-98a8-82c114352256.png)
![スクリーンショット 2021-01-31 17.42.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/cf52988d-7d42-697d-650b-3203b5dd33c4.png)
【NACL#2】
端末からのssh接続用のルールと、ping疎通用のルールを設定
![スクリーンショット 2021-01-31 17.44.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/95319c43-952d-b775-2791-f9aa03863361.png)
![スクリーンショット 2021-01-31 17.44.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1067765/ea915300-7a69-a992-1d10-4f9b402be00a.png)

#まとめ
今回、EC2インスタンス間のping疎通確認を通して、ステートレス/フルの違いを体験しました。最後に、実際に手を動かしてみて得られたことをまとめて終わります。

- セキュリティグループはステートフルであり、ping疎通確認の際、戻りの通信を許可していなくても応答を受け取れる。
- NACLはステートレスであり、ping疎通確認の際、戻りの通信も許可しないと応答は受け取れない。

以上、最後まで読んで頂きありがとうございました！