Amazon VPCについて勉強
AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
この本を一読したうえで機能単位で勉強していく。
- VPC(Virtual Private Cloud)とは
- VPCの作成イメージ
- CIDR(Classless Inter-Domain Routing)
- VPCエンドポイント
- VPN vs DirectConnect
- VPCピアリング接続 vs AWS Transit Gateway
- VPCエンドポイントを使ってS3に接続できない場合
- 踏み台サーバを使用したセキュアなリモートアクセス
- オンプレミス側との接続
- オンプレミス側との接続冗長化した高可用性を担保する
VPC(Virtual Private Cloud)とは
- AWS上にプライベートネットワーク空間を構築することが可能できる。任意のIPアドレスの範囲を選択することで仮想ネットワークを構築することができる。
- 論理的なネットワーク分離が可能。必要に応じてAWS内との接続やオンプレミスとの接続を実施することが可能。
- プライベートネットワーク空間内で細かく設定・制御できる。サブネットやルートテーブル、ネットワークゲートウェイ設定など。
- 様々な接続オプションを利用できる。インターネット経由 or VPN/専用線(Direct Connect)
冗長性や、セキュアな接続を担保しつつ、様々なところへ接続するために使用される機能という感じ。
VPCの作成イメージ
以下のような形でVPCを構築し、VPCの中にそれぞれ設定を実施していく。
AWS入門者向け 初心者が最初に理解すべきEC2とVPCの基本的な用語解説 | Avintonジャパン株式会社 より引用
手順としては以下のような形。
- VPCを作成
- Subnetを作成(Public or Private、もしくは両方)
- Subnetの中にEC2などのインスタンスを起動させる
- Internet GatewayをVPCにセットする（VPC←→インタネットができるように）
- ルートテーブルにPublicのIPを追加
- Private Subnetを作っている場合、NAT Gatewayを作成し、privateのインスタンス→インターネットができるようにする
ひとつのリージョンに対して、複数のVPCを設定できる（上限5）
ひとつのVPCに対し、複数アベイラビリティゾーンを設定できる。
また、ひとつのVPCに対し、複数サブネットを設定できる。
複数のアベイラビリティゾーンに対し、ひとつのサブネットがまたぐことはできない。
アベイラビリティゾーンは地域（リージョンよりも細かい）なので、1拠点につき1サブネットサブネットということか。
関連機能としては以下
サブネット
VPC内に構成するネットワークセグメント。サブネットは大きく分けて２つで構成することが可能。片方だけでも可。
- パブリックサブネット
- プライベートサブネット
この二つの違いはルーティング。
ルートテーブル内のデフォルトゲートウェイ（0.0.0.0/0）へのルーティングにインターゲットを指定したものがパブリックサブネット。
なければプライベートサブネット。
RDSなどマルチAZ機能があるものを利用する際には、異なるアベイラビリティゾーン上でサブネットを作成する必要がある。
パブリックサブネットはインターネットからの接続を許容する場合、フロントの画面などが該当する。
プライベートサブネットはインターネットからの接続は許容しないが、プライベートサブネットからパッチの入手などでインターネットへ接続したい場合に使用する。DBなどの情報がそちらに存在される。
インターネットゲートウェイ
VPCからインターネットへでるためのゲートウェイ。ルートテーブル
サブネット内の静的ルーティングを定義するもの。設定単位はサブネット。NATゲートウェイ
プライベートサブネットからインターネットに出るために実施する設定。サブネットにも記載したが、サブネットに紐づくルートテーブルにインターネットゲートウェイのルーティングが存在しないものが、プライベートサブネット
つまり単独ではインターネットに出ることができない。
プライベートサブネットにはDBサーバがあったり、誰かにアクセスされると非常に困るため。
プライベートサブネットからインターネットに出たい場合に使用するのが、NATゲートウェイ。
AWS側が用意しているNATゲートウェイの代わりにEC2インスタンスを代わりに使用することができる。（NATインスタンス）
高可用性なのはNATゲートウェイ。
CIDR(Classless Inter-Domain Routing)
同じネットワークとして扱うIPアドレスの個数を調整する。
https://wa3.i-3-i.info/word11989.html
172.31.0.0/16 の場合、
2進法で10101100 00011111 11000000 00000000となるが、16はネットワーク部をどこにするのかということを決められる。（この場合10101100 00011111 ）
これを実施することで、同じネットワークに所属するものが何かというものを決めることができる。
つまり、172.31.0.0/16と172.31.1.0/16は同じネットワークにいるといえる。
CIDRの数によって設定できるIPアドレスの数が異なるが、冗長性を考えて設定する必要がある。
VPCのCIDRは16が推奨されている。サブネットは24。
CIDRが16が65,536のIPを設定できる。
24は256、23が512、32が1。
VPCエンドポイント
VPCからリージョンサービス（S3など）を利用したい場合、VPCの外に存在するサービスに対し接続を行わなければならないので、インターネットの外に出てしまう。
それだとセキュアな接続にはならないので、インターネットに出ないようにするためにVPCエンドポイントを使用する。
https://devlog.arksystems.co.jp/2018/05/11/4896/ より引用
VPC エンドポイントでは、PrivateLink を使用する AWS サービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。
VPC エンドポイント - Amazon Virtual Private Cloud
つまりインターネットを経由せずに接続することが可能。
デフォルトではIAM ユーザーにはエンドポイントを使用するためのアクセス権限がないので、IAMポリシーに権限追加する必要がある。
具体的には２つのつなぎ方が存在。
ゲートウェイ型
ネットワークレイヤー層のVPCエンドポイント。
ルートテーブルに指定されたターゲットを追加することでインターネットを経由せずにプライベート接続できる。
エンドポイントのIDと接続したいサービスのIDを設定することでアクセス制御が可能（
VPC エンドポイント - Amazon Virtual Private Cloud）
料金は無料で、AWS側にて冗長性を担保してくれているものとなる。
以下が使用できる対象。
- Amazon S3
- DynamoDB
S3とDynamoDBだけなので、SAAの試験でVPCエンドポイントの問題が出た場合、S3とDynamoDBのワード出てたら確実にゲートウェイ型。
インターフェイス（AWS PrivateLink）型
アプリケーションレイヤー層のVPCエンドポイント。AWS PrivateLinkとも呼ばれる。
APIコールに対してインターネットを経由せずにプライベート接続できる。
具体的にはVPC内サブネットのDNSに対して問い合わせを行うとプライベートIPアドレスで回答される。その情報でVPCエンドピントからAPIに対し転送が行われる仕組み。
ゲートウェイ型とは、Elastic Network Interface（ENI）を使用する点で違うので、そもそも転送する場所が違う（ゲートウェイはVPCからだが、privateLink型はサブネット）。
ENIのためアクセス制御はセキュリティグループを使用できるが、ENIを使用するために料金がかかる。
以下が使用できる対象。APIが存在する系のものには大体あるイメージか。
- Amazon API Gateway
- Amazon CloudWatch
- Amazon CloudWatch Events
- Amazon CloudWatch Logs
- AWS CodeBuild
- Amazon EC2 API
- Elastic Load Balancing API
- AWS Key Management Service
- Amazon Kinesis Data Streams
- Amazon SageMaker ランタイム
- AWS Secrets Manager
- AWS Service Catalog
- Amazon SNS
- AWS Systems Manager
- 他の AWS アカウントによってホストされるエンドポイントサービス
- サポートされる AWS Marketplace パートナーサービス
VPC エンドポイント - Amazon Virtual Private Cloud
VPN vs DirectConnect
VPCとの接続として、VPNを使用した接続と、DirectConnectを使用した専用線接続の2種類が存在する。VPN接続：バーチャルプライベートゲートウェイを利用したサイト間VPN
専用線接続：DirectConnectを利用した接続。安定しているので本番環境向け。日本では閉域性という点で利用される傾向がある。
VPCからオンプレミスを接続する場合は、必ずサブネットのルートテーブルに設定が必要。
VPN接続と専用線接続の違い
専用線接続は物理的に接続する準備しなければならないので、リードタイムがかかる。
データ移行などでリードタイムを気にする場合はVPN接続をするのが良い。
VPN接続は障害時の切り分けが難しかったり、ネットワーク品質に難がある。
それぞれの特徴については以下に記載。
VPN接続
いわゆるサイトtoサイトVPN（サイト間VPN）を指す。
単一および複数の Site-to-Site VPN 接続の例 - AWS Site-to-Site VPNより引用
ひとつのVPN接続はふたつのIPsec暗号化プロトコルで冗長化している状態。
専用線接続
AWSとオンプレミス側で専用線契約を結び専用線接続を実施する。
AWS Direct Connect とは - AWS Direct Connectより引用
接続はVPCに向けたプライベート接続と、S3やDynamoDBなどのAWSサービスへの接続としてパブリック接続がある。
サイト間VPNよりも一貫性があり、帯域のパフォーマンス向上、ネットワークコストも削減できる。
AWS Direct Connect Gateway は中国を除くAWSのすべてのリージョンにおいて、グローバル IP ルートを受信するパブリック仮想インターフェイスを作成することや、エンドポイントへのアクセスの有効化機能が提供されます。
また、複数の AWS リージョンに渡り Virtual Private Cloud (VPC) で接続性を確立することができ、それぞれ複数の BGP セッションを確立する必要がないので、管理作業を減らしネットワークデバイスへの負担も軽減することができます
AWS Direct Connect の AWS Transit Gatewayサポートが東京リージョンに対応しました | Amazon Web Services ブログ
AWS Direct Connect の AWS Transit Gatewayサポートが東京リージョンに対応しました | Amazon Web Services ブログより引用
複数のオンプレミスから複数リージョンのVPCに接続するためにはAWS Direct Connect Gatewayを使用することで可能。
ただし、VPC側は同一アカウントでなければらない点と中国には接続できない。
VPN接続と専用線接続の冗長化
VPNとDirectConnectを同じVGWに接続することができる。その場合はDirectConect側が優先される。
そのため、DirectConectはアクティブ、VPNはスタンバイにさせて、DirectConectが障害が起きた場合にVPNにするのがよい。
VPNにフェイルオーバーする際の注意事項として、接続回線が違うのでパフォーマンス懸念が発生する可能性がある。
VPCピアリング接続 vs AWS Transit Gateway
VPN間を通信する手段として、VPCピアリング接続 と AWS Transit Gatewayのふたつが存在する。似たような機能だが、若干違う。
VPCピアリング接続
異なるVPC間をプライベート接続するサービス。無料のサービスとなる。
VPC ピア機能とは - Amazon Virtual Private Cloudより引用
VPC ピアリングの基本 - Amazon Virtual Private Cloudより引用
通常はVPC間はそれぞれ独立したプライベートネットワークのため、通信を行えない。
VPCピアリング接続を行うことで、インターネット経由せずにAWSプライベートネットワーク内で直接通信することが可能。
リージョンをまたぐことも可能。日本<-->北米。
ただし、VPC-A<-->VPC-B<-->VPC-Cの場合、VPC-AはVPC-Aとだけ接続しているので、VPC-Cにアクセスすることができない。
ピアリング先のVPCを使ってインターネットに出ることはできない。
VPC-A<-->VPC-Bの場合、VPC-Aの中のサブネットがVPC-Bのサブネットからインターネットに接続しようとしてもそれはできない。
AWS Transit Gateway
VPCピアリング接続と大きく違うのは、オンプレミスとの接続も使用できるという点。ただし、VPCピアリング接続とは違い有料サービス。
VPC同士の接続のほかに、
という構成も可能。
DirectConnectGatewayのイメージは以下。
Direct Connect ゲートウェイへのトランジットゲートウェイアタッチメント - Amazon Virtual Private Cloudより引用
同じリージョンにある複数の VPN または VPC に対して 1 つの接続をAWS Transit Gatewayで管理する形。
VPCエンドポイントを使ってS3に接続できない場合
ネットワークアクセスまたは Amazon VPC から Amazon S3 への接続を許可するセキュリティルールが原因で、ゲートウェイ VPC エンドポイントとの接続問題が発生している場合があります。
VPC エンドポイントから S3 への接続問題のトラブルシューティング
- VPCでDNS設定が有効になっているか確認
- ルートテーブルをS3に設定（上記ゲートウェイ型の設定がされているか確認）
- 対象インスタンスのセキュリティグループのoutboundがS3を許可しているか
- ネットワークACLのinbound側がS3からのトラフィックを許可しているか
- VPCエンドポイントやS3へのIAMポリシーが許可されているか。（S3のバケットポリシー権限も含め確認）
テストの観点だと、ルートテーブルとセキュリティグループ、ネットワークACL、IAMポリシーが正しくないという理由で問題がでそう。
踏み台サーバを使用したセキュアなリモートアクセス
VPC内のEC2インスタンスに対し、リモートからセキュアにアクセスするために踏み台サーバを使用することができる。
踏み台サーバーを利用する理由はそれぞれの環境により異なりますが、以下が挙げられます。
1. セキュリティ的な観点
– 各サーバーに直接アクセスできないため外部から侵入されるリスクを軽減できる2. 運用的な観点
– パブリックIPを各サーバーに割り振る必要がないため運用不可を軽減できる
– 外部通信に対するアクセス制御の対象を踏み台サーバーに限定できるため運用不可を軽減できる
http://awsinfra.site/2018/05/17/post-14/
踏み台サーバ構成のポイント
- SSHやRDBなどリモートアクセスが必要な場合のみ、踏み台サーバを起動
- 踏み台サーバはパブリックサブネット上に設置し、パブリックIPを設定する
- 踏み台サーバのセキュリティグループはSSH・RDBからのアクセスを許可。アクセス元は不特定多数(0.0.0.0/0)ではなく、特定のIPにする
- 踏み台サーバから接続されるインスタンスには、必要に応じて「踏み台サーバからのSSHやRDBのみ許可」の設定をセキュリティグループにする
オンプレミス側との接続
Direct Connectと仮想プライベートゲートウェイ
Direct Connect
オンプレミス環境とAWSの間を専用線で接続するサービス。構想句なネットワーク帯域で安定した通信を実現可能。
オンプレミス側<-->接続ポイント<-->AWSで接続する。
接続ポイント<-->AWS側の可用性はAWSが提供するが、オンプレミス側<-->接続ポイントはユーザ側が考慮する。
オンプレミス環境とAWSの間をインターネットプロトコルセキュリティ (IPsec) VPN 接続するサービス。
各メーカーのルータに最適化された設定ファイルをAWSコンソールからダウンロードし、設定ファイルを元にオンプレミス側のルーター設定を行う。
専用線ではなく、あくまでインターネット回線を使用するので、速度や安全性がDirect Connectには劣る。
以下Direct Connect vs 仮想プライベートゲートウェイ
オンプレミス側との接続冗長化した高可用性を担保する
Direct Connect冗長化パターン
Direct Connectを2回線分用意することで、速度・安全性を維持したまま冗長化することが可能。ただし、コスト面が高くなる。
Direct Connect+仮想プライベートゲートウェイ複合パターン
Direct Connect側に障害が発生した場合、仮想プライベートゲートウェイに切り替える。仮想プライベートゲートウェイへフェイルオーバーした場合、通信品質やパフォーマンスに影響が発生する可能性がある。
