#1 AWS上にセキュアなプライベートネットワーク空間を作成する
背景
久しぶりの投稿になります。
現在、都内の金融系SI企業でインターンをさせて頂いており、大変ありがたいことにAWSハンズオンを自由に進められる検証環境を用意していただきました。
以前、個人開発をした際には無料利用枠にこだわり、サービスの想定外の課金におびえながらインフラ構築をすすめていたのですが、今は好奇心の赴くままにサービスを触れており、とても恵まれていると日々、感じております。
本題
最初のハンズオンとして、「AWS Hands-on for Beginners - Network編#1 AWS上にセキュアなプライベートネットワーク空間を作成する」を進めていきました。
ハンズオンでは、最初にハンズオンのゴールの全体像について大まかに説明し、その後は具体的にAWSマネジメントコンソール上での操作が説明されます。ハンズオンに従って手を動かしていけば、あっという間に目的のシステムができてしまいます(汗)
ハンズオン自体はYoutube動画なので、個人でも登録をすれば視聴可能です。
もっと早く知りたかった!
以下が、今回のハンズオンの全体像になります。
ネットワーク構成図
ルートテーブル一覧
本ハンズオンの最終形: ① + ②'' + ③
・Public Route Table:Public subnet に適用したルートテーブル
・Private Route Table:Private subnet に適用したルートテーブル
・VPC Endpointsでは、ルートテーブルに①, ②''の両方を指定したため、実質的に③のルートテーブルに等しい
セキュリティグループ一覧
次に、大まかな手順について説明します。
- VPCを作成する
- IGWをVPCにアタッチする
- サブネットを作成する
- Private, Publicな設定のルートテーブルを作成する
- 作成したルートテーブルを適切なサブネットに割り当てる
- パブリックサブネットにEC2(Webサーバ)を立てる
- WebブラウザからサーバーへHTTPリクエストし、ページを確認
- SSMの許可を付与したIAMロールを作成
- SSMの設定を行い、適切なエンドポイントをパブリックサブネットに設定
- プライベートサブネットにEC2を立てる
- NAT Gateway のエントリをプライベートサブネットのルートテーブルに加え、SSMに接続
- NAT Gateway のエントリを削除
- PrivateLinksのインターフェイスをパブリックサブネットに設定し、SSMに接続
- S3を立て、プライベートサブネットのEC2のロールにS3へのアクセス権のポリシーを追加
- Endpointsのエントリをルートテーブルに加え、S3に接続
- 作成したシステムを全て削除
また、EC2はWebサーバとしての挙動を期待するため、以下の設定をしました。
①セキュリティグループ(インバウンド)のプロトコルにTCPを指定
②以下のスクリプトをユーザーデータに記述 (EC2起動時に実行)
yum -y update
# httpdパッケージをインストール
yum -y install httpd
# httpdのサービスを有効化
systemctl enable httpd.service
# httpdのサービスをスタート
systemctl start httpd.service`
ブラウザからのHTTPリクエストで、実行中のWebサーバー(Apache)が確認できます。
まとめ
本ハンズオンでは、プライベートサブネットに立てたインスタンスからVPC外部のサービス(SSM)にアクセスする手段 が4通り紹介されていました。
-
Internet Gateway 経由でのアクセス
① NAT Instance:インスタンス単位で管理するNAT(EC2の機能)
② NAT Gateway:複数のインスタンスに適用可能なNAT(VPCの機能) ← (推奨)
NAT Instace の場合、以下が相違点です。
(1) NAT-Gatewayの代わりにNATインスタンスを立てて、NATを実現する点
(2) デフォルトゲートウェイのターゲットに NAT Instance の NIC(ENI) を指定する点
-
Internet Gatewayを経由せずにアクセス
③ Gateway Endpoint
Gateway型のエンドポイント。2種のサービス(S3, DynamoDB)にのみ対応し、サブネットに紐づけられます。
④ Interface Endpoint
AWS PrivateLink で利用される。 多くのサービスに対応し、ルートテーブルに紐づけられます。
その他
ハンズオンの内容は視聴者の理解を深めるための工夫が多いと感じました。
例えば、実行中のEC2サーバーについて、それが置かれたパブリックサブネットに割り当てたルートテーブルを、プライベートルートテーブルに変更するとどうなるか、という実験です。
実際のサービスではこのような実験はできないのでありがたいです。その他、EC2を誤ったサブネットに建てるというミスをしたが、そのようなケース対応が公式情報にあったので、手動でAMIを作成して事なきを得ました(冷や汗)。
また、以下の不要なサービスは忘れずに削除しました。
- 誤って作成した停止中のEC2
- 一時バックアップ目的のAMI(課金対象)
参考サイト
※ VPC Endpoint について、理解が不十分な点がございました。上の参考サイトをもとに、記事を一部修正しましたのでご了承ください。
最後まで記事を読んでくださり、ありがとうございます。もし内容に誤りがございましたら、ご指摘いただけますと幸いです。