Ch1. ネットワーク
Multi-AZ
1つのリージョンには複数のAZが存在する。各AZ間は高速なインターネット回線で結ばれているのでレイテンシはほとんど問題にならない。
単一のAZのみでシステムを構築した場合、システムの信頼性はオンプレミスと大差ない。 リージョンを跨いだ構成を構築するMulti-AZでは、全てのトラフィックをAZ間でロードバランシングしつつ、AZ間でDBをリプリケーション(Master-Slave構成)として両方のAZのサーバーに片方のDBを参照させることが出来る。
マネージドサービスであったとしてもMulti-AZを選択しない理由にはならない。
例えば、RDSはマネージドサービスではあっても複数のAZに構築してMaster-Slave構成としておく。その上でAZを跨いで２つのプライベートサブネットを作り、各拠点のDBを配置するのがGood Practiceとなる。
VPC
VPCには2つの出口を作る。
【VGW】の方は、その先にVPNやDirectConnetを経由してオンプレミス拠点との接続を行う。
AWS Direct Connect とは - AWS Direct Connect
例えばDirectConnectの場合Amazonの各AZのエンドポイントから顧客のエンドポイントまでが直接VLANとして結ばれるので、インターネットを介す必要が無い。
お客様のネットワークパスの中でインターネットサービスプロバイダーをバイパスできるようになります。
Direct Connect
Direct Connect はオンプレ拠点との接続を行うサービスで、VPNを利用せずにAWSのVPCと接続を行うため極めて転送効率が高い。またアウトバウンドのトラフィックについてはVPNよりも安価に利用できる。
また関連サービスであるDirect Connect Gatewayを利用すると、
VPCの中に入れないサービス群として
- S3
- DynamoDB
- CloudWatch
- lambda
などがある。これらのサービスをどのようにVPC無いのサービスと連携するのか考える必要がある。
サブネット
一つのVPC空間の中には複数のサブネット(上限200)を作成することが出来る。 サブネットには１つのルートテーブルと１つのACLを設定する。
サブネットは「AZを跨ぐことが出来ない」ので、先述したDBレプリケーションによる「Master-Slave」構成を行うとき、各DBは別のサブネットに属することになる。
ルートテーブル
ルーティングテーブルのこと。 一つのサブネットにつき一つ設定していくが、特に設定しなければVPC全体に対するメインルートテーブルがデフォルトのルートテーブルとして選択されている。
メインルートテーブルは以下のようになっている。
| 送信先 | ターゲット |
|---|---|
| 10.0.0.0/16 | local |
| 0.0.0.0/0 | IGW_id |
このVPCは10.0.0.0/16として作成したので、10.0.0.1から10.0.255.255までのIPアドレスに対するトラフィックはlocal(つまり内向きのインターフェースに)ルーティングされる。
それ以外のトラフィックはIGW_id、つまりインターネットゲートウェイへと転送される。
VPCのアクセス制御
セキュリティグループ
EC2、RDSなどのインスタンス単位で設定する。
インバウンド・アウトバウンドの通信に対してプロトコル、IPアドレス、セキュリティグループを指定できる。
ステートフルで、応答トラフィックはルールに関係なく通信が許可される。 エフェメラルポート - Wikipedia
ネットワークACL
サブネット単位で設定する。
ネットワーク機器でのACLと同じ。 インバンド・アウトバウンドに対してポート番号・IPアドレス・プロトコルが指定できるが、セキュリティグループは指定できない。
ネットワークのACLと同じように、応答トラフィックであってもポート番号が許可されていなければDenyされる(ステートレス)。
ゲートウェイ
【IGW】と【VGW】に関しては先述している。
サブネットには必ず一つルートテーブルが割り当てられることは既に述べた。各サブネットのうち、ルーティングテーブルに【0.0.0.0/0】が存在しインターネットへのルーティングが行われるサブネットをパブリックサブネットという。
一方、ルーティングテーブルに【0.0.0.0/0】がなくルーティング先に他のVPCサブネットしかない場合はプライベートサブネットという。
最初に設定されるルーティングテーブルには【0.0.0.0/0】しか設定されていないため、デフォルトでは「パブリックサブネット」になる。
NATゲートウェイ
パブリックサブネットからなら必ずインターネットへの通信が出来る訳ではなく、当然パブリックIPアドレスを持っていない限りインターネットへの通信は出来ない。
インスタンスに直接Public IPアドレスを割り当ててしまうことも出来るが、家庭のインターネットと同じく一つのIPアドレスを同じサブネットの中で使いまわすNATも利用できる。ここでのNAT機能をAWSでは特別に「NATゲートウェイ」と呼ぶ。
通常のネットワーク構成と同じく「NATゲートウェイ」も冗長性が求められる。またAZを跨いだサブネットが構築できない都合上、Multi-AZの構成を実現しようと思うと当然NATゲートウェイもAZごとに必要になる。
VPCエンドポイント
VPCに入れることのできないサービスとして
- S3
- DynamoDB
などがある事を述べた(ちなみにRDSはVPC内に配置するのに対してDynamoDBはVPC内に配置しないという特徴がある)。
これらのサービスに対してVPC内から接続するにはVPCエンドポイントを利用する。これは【IGW】や【VGW】とも異なる出口である。 更にVPCエンドポイントにも【ゲートウェイエンドポイント】と【インターフェースエンドポイント】が存在する。
ゲートウェイエンドポイント
ゲートウェイエンドポイントはS3やDynamoDBに対するエンドポイントで、サブネットに対して指定されたルーティングテーブルにS3やDynamoDBに対するエンドポイントを自動で指定する。これを指定した場合、S3やDynamoDBに対する通信は【IGW】ではなく「ゲートウェイエンドポイント」にルーティングされる。
S3との接続をセキュアに保つためにはゲートウェイエンドポイントの設定が欠かせない。
インターフェースエンドポイント
S3やDynamoDB以外の大部分の通信に「インターフェースエンドポイント」が利用される。他のVPCに対する接続を実施する場合【AWS PrivateLink】と呼ばれる。 またVPC↔Salesforce Heroku間の接続もできるらしい。
VPCピアリング
VPC間の接続を行う際利用される。 アカウントの異なるVPC同士を接続できるが、接続相手は1つに制限されるため「VPC-VPC-VPC」や「VPC-VPC-【IGW】-Internet」のような接続は出来ない。
VPCフローログ
VPC内のトラフィックはVPCフローログによって記録されている。 VPC内の全てのネットワーク機器には【ENI】(Elastic Network Interface)という仮想的なネットワークカードが設定され、それを介した接続が行われている。
