こんにちは、Mashです。
本記事は私自身がAWSをお勉強で触ってみた経験を共有するシリーズ Mash式AWSチュートリアル です。
今回はAmazon VPC編の第３回となります。
本記事では、VPC内でよりセキュアにインスタンスを展開するための 多層サブネット構成 について学んで行きたいと思います。
それではいきましょう！
前回のおさらい：セキュリティグループを設定しました
前回記事までのおさらいをします。
外部公開したEC2に対してセキュリティグループ（SG）を設定し、必要な通信だけインターネットから受け付けるように構成できました。
このままどんどんインスタンスを構築していけばよい？
さて。
それでは、今後インスタンスを展開していく際には、作成済みのサブネットにどんどんセットアップしていけばよいのでしょうか。
答えは No です。
What is Private Subnet?
例えばAWS上にWebアプリケーションシステムを構築しようとしている場合、当然エンドユーザがシステムへアクセスできる必要があるので、Webサーバはインターネットからアクセスできる必要があります。
しかし、反対に機密情報を保持するようなデータベースサーバについてはインターネットからアクセスできる必要はありません。
むしろアクセスできてはいけません。
こういった具合に、よりセキュアに、外部の脅威から保護したいインスタンスについてはインターネットとの接続経路がないサブネットを構成し、そのサブネット内に構築することが推奨されます。
この “インターネットとの接続経路がないサブネット” のことを プライベートサブネット と呼びます。
イメージはこんな感じです。
プライベートサブネットの実体
それでは “インターネットとの接続経路がないサブネット” とは、技術的な観点で説明するとどのようなものなのでしょうか。
VPC編その１で実施した作業を思い出しつつ、前述イメージ図を見て少し考えてみてください。
答えは、 パブリックサブネットとは インターネットゲートウェイ（IGW）へのルーティングがないサブネット のこと です。
AWS環境においては、
- IGWへのルーティングあり → パブリックサブネット
- IGWへのルーティングなし → プライベートサブネット
というように呼び分けます。
プライベートサブネットを作成する
プライベートサブネットの必要性についてはわかってもらえたかと思いますので、実際に作成していきましょう。
サブネットの作成はVPC編その１で実施済みですので、新しい知識は不要です。
サブネット作成
AWS管理コンソールからVPCへアクセスし、左側メニュー [サブネット] を選択します。
そして [サブネットの作成] ボタンをクリックします。
必要なパラメータを定義していきます。
AZは、前回作成したパブリックサブネットと同じに。
CIDRブロックについては、VPCのCIRD範囲内かつ作成済みパブリックサブネットと重複しないよう注意が必要です。
パラメータを入力したら [作成] ボタンをクリックします。
はい。さくっと作成できましたね。
ルートテーブルの作成とサブネットへの関連付け
作成したサブネットのルートテーブルを確認してみましょう。
おっと。
IGWへのルーティングがあります。
IDを確認したところ、これは前回作成したパブリックサブネット用のルートテーブルに紐付いてしまっている状態のようですね。
このルートテーブルはパブリックサブネット用に使用しているため、別途プライベートサブネット用のルートテーブルを作成していきましょう。
左側メニュー [ルートテーブル] を選択して、[ルートテーブルの作成] ボタンをクリックします。
ルートテーブルの名前とVPCの選択、そして必要に応じてタグを設定して [作成] ボタンをクリックします。
ルートテーブル作成が成功したら、リンクになっているルートテーブルIDをクリックします。
ルート情報を確認します。IGWへのルーティングはありませんね。
このルートテーブルを、さきほど作成したサブネットに関連付けましょう。
[サブネットの関連付け] タブを選択します。
現時点では関連付けられたサブネットが存在しないことが確認できます。
[サブネットの関連付けの編集] ボタンをクリックします。
関連付けるサブネットの選択画面が表示されるので、さきほど作成したサブネットにチェックをいれて [保存] ボタンをクリックします。
以上でプライベートサブネットとしての準備は完了です。
プライベートサブネットにEC2を作成
ここまででプライベートサブネットが作成できましたので、EC2を作成しましょう。
EC2の構築手順はVPC編その１をご参照ください。
※サブネットの選択で、今回作成したプライベートサブネットを指定してくださいね↓
あともうひとつ。
新規構築したEC2のSGは、前回構築したWebサーバからの通信をすべて許可とします。
このような場合、通信元（ソース）をSG指定とすることで簡単に対応できます。
ここまでの作業で下記のような構成ができあがりました。
作成したEC2の情報を確認してみると、パブリックIPアドレスが付与されていないことが確認できます。
つまり、インターネットとの接点を持っていない状態ですね。
SSH接続確認
プライベートサブネット内のEC2へSSH接続するためには、一度パブリックサブネットのEC2へSSH接続し、そこから更にSSH接続する必要があります。
コマンド例はこのようになります。-l でユーザ名、-i で秘密鍵ファイルを指定しています。
IPアドレスはみなさんの環境のものに読み替えてください。
$ ssh -l ec2-user -i mash-key.pem 10.0.1.91
The authenticity of host '10.0.1.91 (10.0.1.91)' can't be established.
ECDSA key fingerprint is SHA256:ZPXednifFFmmSVXzhkroc4UAnEVMtBvQxHfDwF3ds3g.
ECDSA key fingerprint is MD5:71:6a:1d:ca:b5:00:dd:d3:8d:99:be:00:9b:30:1d:24.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.1.91' (ECDSA) to the list of known hosts.
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-0-1-91 ~]$プライベートサブネット内のEC2にも無事にSSH接続できましたね！
まとめ
今回の記事では外部の脅威から保護する必要のあるインスタンス（例えばデータベースなど）がある場合は、プライベートサブネットが必要であること。また、プライベートサブネットの構成手順を確認することができました。
このような２層（もしくはもう１層増やして計３層）のサブネットというのはVPCの基本構成で、AWS認定試験にも必ず登場するトピックですので必ずマスターしておきましょう。
で、ここからは次回予告になるのですが本記事時点の構成だと１つ大きな課題があります。
それは、プライベートサブネットに配置したEC2がインターネットに接続できないこと です。
「インターネットに晒さないために新規サブネットを作ったんだからあたりまえじゃん！」というのはそのとおりなのですが、例えばプライベートサブネット内のEC2に追加パッケージをインストールしたり、セキュリティパッチを適用したり、様々な理由でインターネット接続が必要になるケースが出てきます。
もちろん、AWSではこのようなケースに対応するためのサービスも用意されているんですね～。
次回はこれについて記事にしたいと思います！お楽しみに！
今回は以上です。
それじゃあまたね。
