インターフェースエンドポイント | トランジットゲートウェイ | VPCピアリング | Route 53 | クロスアカウント | コストとセキュリティ
AWSでは、「異なるVPC間でVPCエンドポイントを共有する」ことの中核は、単にエンドポイントを複数のVPCに直接アタッチすることではなく、むしろ次の点にあります。
インターフェイス VPC エンドポイントを単一の中央/共有サービス VPC に集中させ、Route 53 を使用して DNS を統合しながら、トランジット ゲートウェイまたは VPC ピアリングを介して他の VPC からこのエンドポイントのプライベート IP にアクセスできるようにします。
AWSはこのモデルを公式には次のように呼んでいます... Centralized access to VPC private endpoints。
しかし、まず最初に、両者を区別することが不可欠である。 Interface Endpoint そして Gateway Endpoint。
まず、最も重要な結論を述べましょう。
現在、以下のような状況にあると仮定します。
VPC-A
VPC-B
VPC-C3つのVPCすべてに必要なもの：
SSM
EC2 API
ECR
CloudWatch
KMS
Secrets Manager
STS
...デザインは2種類あります。
オプションA：各VPCが独自のエンドポイントを作成します。
VPC-A
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpoint
VPC-B
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpoint
VPC-C
├─ SSM Endpoint
├─ EC2 Endpoint
├─ ECR Endpoint
├─ Logs Endpoint
└─ KMS Endpointこれは最もシンプルで、最も独立した設計です。
しかし、エンドポイントの数は急速に増加するだろう。
例えば：
10個のVPC × 20個のAWSサービスエンドポイント × 2つのAZ = 400個のエンドポイントENIインターフェースエンドポイントは 終点 × AZ × 時間料金に加え、データ処理手数料がかかります。
したがって、規模が大きくなるにつれて、コストとメンテナンス費用も大幅に増加する。
II. 集中型VPCエンドポイントのアーキテクチャ
確立する：
Network VPC / Shared Services VPCすべてのエンドポイントはここに配置されます。
例えば：
AWS Services
│
PrivateLink
│
┌───────────────────┐
│ Network VPC │
│ 10.0.0.0/16 │
│ │
│ SSM Endpoint │
│ KMS Endpoint │
│ ECR Endpoint │
│ Logs Endpoint │
│ STS Endpoint │
│ Secrets Endpoint │
└─────────┬─────────┘
│
Transit Gateway
┌─────────┼─────────┐
│ │ │
│ │ │
VPC-A VPC-B VPC-C
10.10/16 10.20/16 10.30/16それから：
VPC-A 内の EC2 ↓ ssm.ap-northeast-1.amazonaws.com ↓ Route 53 ↓ 共有 VPC 内の SSM エンドポイントのプライベート IP に解決 ↓ トランジット ゲートウェイ ↓ インターフェイス エンドポイント ENI ↓ AWS PrivateLink ↓ SSMAWSはこの集中型設計を公式にサポートしています。
III. 特に重要な例外：S3 / DynamoDB
これは別途議論する必要がある。
ゲートウェイエンドポイントは、このような方法では共有できません。
S3とDynamoDBには以下の特徴があります。
Gateway VPC Endpoint例えば：
com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.dynamodbこれは通常のインターフェースエンドポイントとは全く異なります。
Gateway Endpoint：
- PrivateLinkは使用しないでください
- ENIを作成しないでください
- 基本的には、ルートテーブルとAWSマネージドプレフィックスリストを組み合わせたものです。
- 無料
- これは、それが存在するVPC内でのみ使用できます。
AWSは公式に以下の声明を発表しました。
ゲートウェイエンドポイントはVPCの範囲を超えて拡張することはできません。VPCピアリング、トランジットゲートウェイ、VPN、またはダイレクトコネクトの反対側のリソースは、このゲートウェイエンドポイントからリソースを借りることはできません。
したがって、以下のように設計すべきではない。
VPC-A ──TGW── Shared VPC ── S3 Gateway Endpoint次に、VPC-Aが共有VPCのS3ゲートウェイエンドポイントを使用するように設定したい。
いいえ。
IV. S3 / DynamoDB の正しい運用方法
通常は以下のようになるはずです。
VPC-A → お客様専用のS3ゲートウェイエンドポイント VPC-B → お客様専用のS3ゲートウェイエンドポイント VPC-C → お客様専用のS3ゲートウェイエンドポイントなぜなら：
ゲートウェイのエンドポイントには追加料金はかかりません。
したがって、「エンドポイントの数を減らす」ためにS3ゲートウェイエンドポイントを集中管理する必要はありません。
推薦する：
S3
↑ ↑ ↑
│ │ │
GW EP GW EP GW EP
│ │ │
VPC-A VPC-B VPC-Cそして：
SSM
KMS
STS
ECR
ECR Docker
CloudWatch
CloudWatch Logs
Secrets Manager
SNS
SQS
etc.これら Interface VPC Endpoint それが中央集権化が適している理由だ。
5. インターフェースエンドポイントは、なぜVPCをまたいで使用できるのですか？
インターフェースエンドポイントは基本的に次のとおりです。
指定したサブネット内にプライベートIPアドレスを持つENIを作成します。
AWSの公式ドキュメントによると、インターフェイスエンドポイントは、選択したサブネット内にエンドポイントネットワークインターフェイスを作成し、そのサブネットにプライベートIPアドレスを割り当てます。
例えば：
Shared VPC
10.0.0.0/16
AZ-a:
Endpoint ENI
10.0.10.50
AZ-c:
Endpoint ENI
10.0.20.60もう一方のVPCについては、以下の条件を満たしていれば：
VPC-A → 10.0.10.50 へルーティング可能そして：
セキュリティグループ10.0.10.50はVPC-Aを許可します実際には、ネットワークは既にエンドポイントにアクセスできる状態にある。
したがって、いわゆる：
共有VPCエンドポイント
実際に起こったことは以下のとおりです。
その他のVPC ↓ VPC間ネットワーク ↓ アクセスセントラルVPCエンドポイントENIいいえ：
vpce-xxxは同時に3つのVPCに接続できます。これらは全く異なる概念です。
VI．３つの実践的な実施方法
実際には、3つのタイプに分類できます。
| 方法 | 推奨レベル | 適切な |
|---|---|---|
| Transit Gateway | ⭐⭐⭐⭐⭐ | 大規模なマルチVPC |
| VPC Peering | ⭐⭐⭐⭐ | 2～5個のVPC |
| エンドポイントDNSを直接使用する | ⭐⭐⭐ | テスト／特殊用途 |
| VPCごとに独立したエンドポイント | ⭐⭐⭐⭐⭐ | 隔離を優先し、小規模な |
VII. 方法1：トランジットゲートウェイ＋セントラルエンドポイント
これは企業環境において最も一般的なソリューションです。
東京地域を想定すると：
ap-northeast-1ネットワーク：
Network VPC
10.0.0.0/16
App VPC-A
10.10.0.0/16
App VPC-B
10.20.0.0/16
App VPC-C
10.30.0.0/16建築：
AWS SSM
▲
│
PrivateLink
│
SSM Interface EP
10.0.10.50
10.0.20.50
│
┌─────────────────┐
│ Network VPC │
│ 10.0.0.0/16 │
└────────┬────────┘
│
TGW
┌──────────┼──────────┐
│ │ │
VPC-A VPC-B VPC-C
10.10/16 10.20/16 10.30/16Transit Gateway (TGW) は、複数の VPC にまたがる集中ルーティングのために AWS によって設計されており、一時的なルーティングをサポートしています。AWS は、大規模なマルチ VPC ネットワークでは TGW を優先的に使用することを推奨しています。
VIII．具体的な操作手順
以下は、実際の構成の詳細です。
ステップ1：ネットワークVPCを作成する
例えば：
VPC:
shared-endpoint-vpc
CIDR:
10.0.0.0/162つのAZ：
ap-northeast-1a
Endpoint subnet:
10.0.10.0/24
ap-northeast-1c
Endpoint subnet:
10.0.20.0/24少なくとも2つのAZ（アベイラビリティゾーン）を用意することをお勧めします。
9. ステップ2：トランジットゲートウェイを作成する
VPC Console：
Transit Gateways
→ Create transit gateway例えば：
Name:
core-tgw次に、VPCアタッチメントを作成します。
core-tgw
│
├─ shared-endpoint-vpc
├─ app-vpc-a
├─ app-vpc-b
└─ app-vpc-c複数のAWSアカウントをお持ちの場合は、AWS RAMを介してTransit Gatewayを共有することもできます。AWSは、アカウント間でのTGWの共有を公式にサポートしています。
10. ステップ3：VPCルートテーブルの設定
予測：
Shared VPC:
10.0.0.0/16
VPC-A:
10.10.0.0/16
VPC-B:
10.20.0.0/16VPC-A：
Destination Target
10.10.0.0/16 local
10.0.0.0/16 tgw-xxxxxxxxVPC-B：
Destination Target
10.20.0.0/16 local
10.0.0.0/16 tgw-xxxxxxxxShared Endpoint VPC：
Destination Target
10.0.0.0/16 local
10.10.0.0/16 tgw-xxxxxxxx
10.20.0.0/16 tgw-xxxxxxxxそうでない場合、以下の事態が発生します。
VPC-A → Endpoint行ってもいいけど、ただし：
Endpoint → VPC-A彼らは戻って来られない。
11. ステップ4：TGWルートテーブルの設定
TGW Route Table：
10.0.0.0/16
→ shared-endpoint-vpc attachment
10.10.0.0/16
→ VPC-A attachment
10.20.0.0/16
→ VPC-B attachment
10.30.0.0/16
→ VPC-C attachmentネットワーク分離に特別な必要性がない場合は、経路伝播を利用できます。
企業環境は通常、以下のように分類されます。
Spoke TGW RT
Shared Services TGW RT
Inspection TGW RTデフォルトで全てのVPCが相互に通信できるようにすることは避けてください。
12. ステップ5：インターフェースエンドポイントを作成する
例えば、共有が必要な場合：
AWS Systems Manager作成する：
VPC
→ Endpoints
→ Create endpointService：
com.amazonaws.ap-northeast-1.ssmVPC：
shared-endpoint-vpcSubnets：
ap-northeast-1a
10.0.10.0/24
ap-northeast-1c
10.0.20.0/24したがって、以下のことが生じる。
vpce-0123456789
ENI-A:
10.0.10.50
ENI-C:
10.0.20.5013番目、そして最も重要なこと：プライベートDNSを直接有効にしないでください。
VPCが通常独自のエンドポイントを使用する場合：
Enable Private DNS
✓とても便利です。
例えば、元々は：
ssm.ap-northeast-1.amazonaws.com自動的に以下のように解析されます。
10.0.10.50
10.0.20.50AWS SDKは一切変更を必要としません。
しかし、集中型アーキテクチャには問題がある。
プライベートDNSは、AWSが管理するプライベートホストゾーンを自動的に作成します。このプライベートホストゾーンは、エンドポイントが存在するVPC内でのみ機能します。
したがって：
Shared VPC知る：
ssm.ap-northeast-1.amazonaws.com
=
10.0.10.50しかし：
VPC-A
VPC-Bわからない。
したがって、AWSの公式中央エンドポイントアーキテクチャでは、以下のことを推奨しています。
中央エンドポイントのシナリオでは、エンドポイントの自動プライベートDNSを無効にしてから、Route 53プライベートホストゾーンを手動で作成します。
14. ステップ6：Route 53プライベートホストゾーンを作成する
作成する：
Route 53
→ Hosted zones
→ Create hosted zoneDomain：
ssm.ap-northeast-1.amazonaws.comType：
Private Hosted Zoneまず、関連付けます。
shared-endpoint-vpc15. ステップ7：エイリアスを作成する
入力：
ssm.ap-northeast-1.amazonaws.comCreate record。
Record：
ssm.ap-northeast-1.amazonaws.comType：
A選ぶ：
Aliasターゲットの選択：
VPC Endpointそれから：
vpce-0123456789...AWSの公式中央エンドポイントソリューションは以下のとおりです。
AWS Service DNS
↓
Route53 PHZ
↓
Alias
↓
Central Interface EndpointアプリケーションにエンドポイントIPを手動で使用させる代わりに。
16. ステップ8：PHZをすべてのVPCに関連付ける
Private Hosted Zone：
ssm.ap-northeast-1.amazonaws.com関連している：
shared-endpoint-vpc
app-vpc-a
app-vpc-b
app-vpc-cAWS Route 53 のプライベートホストゾーンは、複数の VPC に関連付けることができます。
それから：
VPC-A
埋め込む：
nslookup ssm.ap-northeast-1.amazonaws.com得る：
10.0.10.50
10.0.20.50VPC-B
同じ：
nslookup ssm.ap-northeast-1.amazonaws.comあまりにも：
10.0.10.50
10.0.20.50現時点では：
VPC-A
│
│ DNS
▼
ssm.ap-northeast-1.amazonaws.com
│
▼
10.0.10.50
│
▼
Transit Gateway
│
▼
Central VPC
│
▼
SSM VPC Endpointこれで物語は終わりです。
17. ステップ9：エンドポイントセキュリティグループ
これは2番目によくある落とし穴です。
エンドポイントENIにはセキュリティグループがあります。
例えば：
endpoint-sgInbound：
HTTPS
TCP 443
Source:
10.10.0.0/16
10.20.0.0/16
10.30.0.0/16さらに細かくすることも可能です。
例えば、以下のもののみ：
10.10.10.0/24
10.20.20.0/24エンドポイントへのアクセスを許可します。
通行が許可されていない場合：
DNS OK
Routing OK
TGW OKまだ：
timeout18. 最終データフロー
例えば、VPC-A内のEC2インスタンスの場合：
aws ssm describe-instance-information \
--region ap-northeast-1SDKリクエスト:
https://ssm.ap-northeast-1.amazonaws.com① DNS：
ssm.ap-northeast-1.amazonaws.com
↓
Route53 Private Hosted Zone
↓
10.0.10.50② Routing：
EC2
10.10.1.50
↓
VPC-A route table
↓
10.0.0.0/16 → TGW③ TGW：
10.0.10.50
↓
Shared VPC attachment④ Shared VPC：
Endpoint ENI
10.0.10.50⑤ Endpoint：
PrivateLink
↓
AWS SSM以下の項目は、プロセス全体を通して必須ではありません。
Internet Gateway
NAT Gateway
Public IPこれはPrivateLinkの最も重要な意義の一つです。PrivateLinkの目的は、IGW、NAT、またはパブリックIPアドレスを必要とせずに、プライベートネットワーク経由でAWSサービスにアクセスできるようにすることです。
19. 複数のエンドポイントをどのように処理すればよいですか？
次のようなものが必要だとしましょう。
SSM
EC2 Messages
SSM Messages
KMS
CloudWatch
CloudWatch Logs
Secrets Manager
ECR API
ECR DKR
STSCentral VPC：
Network VPC
├─ vpce-ssm
├─ vpce-ssmmessages
├─ vpce-ec2messages
├─ vpce-kms
├─ vpce-monitoring
├─ vpce-logs
├─ vpce-secretsmanager
├─ vpce-ecr-api
├─ vpce-ecr-dkr
└─ vpce-stsRoute53：
ssm.ap-northeast-1.amazonaws.com
→ SSM Endpoint
ssmmessages.ap-northeast-1.amazonaws.com
→ SSM Messages Endpoint
ec2messages.ap-northeast-1.amazonaws.com
→ EC2 Messages Endpoint
kms.ap-northeast-1.amazonaws.com
→ KMS Endpoint
logs.ap-northeast-1.amazonaws.com
→ Logs Endpoint
secretsmanager.ap-northeast-1.amazonaws.com
→ Secrets Manager Endpoint次にPHZは同時に以下を関連付けます。
VPC-A
VPC-B
VPC-C
VPC-D
...AWSサービスの中には、ECRのDocker/OCIエンドポイントなど、独自のDNS構造を持つものがあります。また、一部のサービスではワイルドカードエイリアスが必要になる場合があるため、すべてのエンドポイントが単一のシンプルなレコードのみを持つとは限らないことをAWSは指摘しています。
20. それらが異なるAWSアカウントの場合はどうなりますか？
例えば：
Network Account
111111111111
App Account A
222222222222
App Account B
333333333333建築様式は全く問題ない。
推薦する：
AWS Organizations
Network Account
├─ TGW
├─ Shared VPC
├─ Interface Endpoints
└─ Route53 PHZ
↓ AWS RAM
App Account A
└─ VPC-A
App Account B
└─ VPC-BTGWには以下の方法でアクセスできます。
AWS Resource Access Manager共有。
プライベートホストゾーンにおけるアカウント間の関連付けは、もう少し複雑です。
21. クロスアカウントPHZ関連付け
例えば：
Network Account:
PHZ Z123456
App Account:
VPC vpc-abcdefネットワークアカウントを最初に取得する:
aws route53 create-vpc-association-authorization \
--hosted-zone-id Z123456 \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdef次にアプリアカウント：
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id Z123456 \
--vpc VPCRegion=ap-northeast-1,VPCId=vpc-abcdefAWSにおけるアカウント間プライベートホストゾーンの公式プロセスは以下のとおりです。
PHZ Owner
↓
CreateVPCAssociationAuthorization
VPC Owner
↓
AssociateVPCWithHostedZoneさらに、このアカウント間操作はRoute 53コンソールのみに頼って完全に完了することはできず、CLI/API/SDKが必要です。
22. 方法2：VPCピアリング
VPCが2つか3つしかない場合は、必ずしもTGWは必要ありません。
例えば：
Central VPC
Endpoint VPC
10.0.0.0/16
/ \
/ \
Peering Peering
/ \
VPC-A VPC-B
10.10/16 10.20/16構成：
VPC-A ↔ Central VPC
VPC-B ↔ Central VPCそれから：
VPC-A：
10.0.0.0/16
→ pcx-aaaCentral：
10.10.0.0/16
→ pcx-aaa
10.20.0.0/16
→ pcx-bbbEndpoint SG：
443
10.10.0.0/16
443
10.20.0.0/16DNSはまだ:
PHZ
↓
Endpoint Alias
↓
associate VPC-A
associate VPC-B23.ピアリングの最大の欠点
それ：
推移的ルーティングはサポートされていません。
AWSは公式声明でこの点を明確にしている。
例えば：
VPC-A
│
peering
│
Central
│
peering
│
VPC-Bこれは以下の結論を導き出す根拠にはならない。
A → Central → Bあり得る。
したがって、もし：
2 VPC
3 VPC覗き見はとても快適です。
もし：
20 VPC
50 VPC
100 VPC維持していくのはますます困難になるだろう。
したがって、一般的に言えば次のようになります。
小規模: VPCピアリング 大規模: トランジットゲートウェイ24. 方法3：エンドポイントDNSを直接使用する
また、特にテストに適した非常にシンプルな方法もあります。
エンドポイントを作成すると、AWS は次のようなものを生成します。
vpce-0123456789abcdef-xxxx.ssm.ap-northeast-1.vpce.amazonaws.comAWS は、インターフェースエンドポイント用にリージョンおよびゾーンの DNS 名を作成します。
したがって、VPC-Aネットワークが共有VPCに到達できる限り、直接以下のことが可能です。
aws ssm describe-instance-information \
--endpoint-url \
https://vpce-xxxx.ssm.ap-northeast-1.vpce.amazonaws.comこうすれば、自分でやる必要すらありません。
ssm.ap-northeast-1.amazonaws.comPrivate Hosted Zone。
アドバンテージ
すごく簡単。
こんな方に最適です：
ルーティングの検証、SGの検証、TGWの検証、エンドポイントの検証欠点
アプリケーションの設定を変更する必要があります。
オリジナル：
AWS SDK
↓
ssm.ap-northeast-1.amazonaws.comこれで次のようになります。
AWS SDK
↓
vpce-xxx....多くのアプリケーションは、このように変更するのが都合が悪い。
したがって、生産環境は一般的に次のようになります。
PHZ + Aliasほとんど。
25. 集中型エンドポイントの最大の利点
①エンドポイントを大幅に削減
予測：
20 VPC
15 Interface Endpoints
2 AZDistributed：
20 × 15 × 2
=
600 Endpoint AZ instances中央集権化：
15 × 2
=
30その差は非常に大きい。
26. 利点 ②: コストを大幅に削減できる可能性があります。
インターフェースエンドポイントを受信しました:
Endpoint/AZ/hour
+
Data Processing / GBAWS PrivateLinkでは、AZごとの時間料金とデータ処理料金が発生します。最初の1 PBに対するデータ処理の基準料金は約1.60円/GBで、時間料金はリージョンによって異なります。
Distributed：
VPC × Service × AZ × endpoint-hourCentral：
Service × AZ × endpoint-hour
+
TGWVPCの数が増えるほど、エンドポイントの数の差はより顕著になります。
27. しかし、TGWは無料ではありません。
ここに掲載されている多くのアーキテクチャ図は、意図的にこの点を無視している。
Transit Gatewayが受信した情報：
添付ファイル時間単価 + データ処理/GBAWSは公式には、接続時間とTGWを通過するデータ量に基づいて課金します。
したがって、実際に計算すべきなのは以下のとおりです。
VPCエンドポイントごと
コスト = VPC の数 × エンドポイントの数 × AZ の数 × エンドポイントの1時間あたりの料金 + PrivateLink データCentralized
コスト = エンドポイント数 × AZ数 × エンドポイント時間当たり + TGW接続時間当たり + TGWデータ処理 + PrivateLinkデータ処理 + 可能性のあるクロスAZデータそれで：
企業が既にTGW（タウンシップゲートウェイ）を所有している場合、セントラルエンドポイントは通常非常に魅力的な選択肢となります。
しかし、もし：
VPCは2つしかなく、エンドポイントは3つしかなく、TGWはありません。エンドポイントのコスト削減を目的としてTGWを構築することは、費用対効果が高いとは限らない。
28. 集中型システムの最大の欠点：爆発範囲
これは非常に重要な問題です。
結果は以下の通り：
VPC-A → Endpoint-A
VPC-B → Endpoint-B
VPC-C → Endpoint-CエンドポイントAに問題があります。
問題があるのはAだけだ。中央集権化：
A ─┐
B ─┼→ Central Endpoint
C ─┘中央エンドポイント、共有VPCルーティング、DNS、またはTGWの設定ミス：
A
B
C
D
E
...二人とも停職処分になるかもしれない。
それで：
経費削減とコスト管理の代償は、共有インフラへの影響範囲の拡大である。
AWSはまた、中央エンドポイントを使用すると、ポリシーや障害の影響範囲が拡大する可能性があることを具体的に指摘しています。
29. エンドポイントポリシーもより複雑になるだろう。
Distributed：
開発用VPCエンドポイント → 開発権限 本番用VPCエンドポイント → 本番権限 セキュリティ用VPCエンドポイント → セキュリティ権限管理が非常に簡単です。
中央集権化：
開発・本番・テスト環境におけるセキュリティ監視のためのKMSエンドポイント...すべて共有されています。
Endpoint Policy：
Principal
Resource
Action
Conditions事態はますます複雑化するだろう。
AWSもこれに関して特別な注意喚起を行っています。
中央集権化は、最小権限のエンドポイントポリシーの管理を困難にし、単一のエンドポイントポリシーの影響範囲を拡大させる。また、エンドポイントポリシー文書自体にもサイズ制限がある。
30. セキュリティ上の分離も問題です。
例えば：
Production VPC
Development VPCすべての使用:
Central S3 Interface Endpointそれでも：
IAM
Bucket Policy
Endpoint Policy
SG権限の制御は引き続き可能ですが、物理的境界とネットワーク境界はもはや完全に独立しているとは言えません。
したがって、特に厳しい環境においては：
PCI金融製品セキュリティツール考えられるデザイン：
Prod Endpoint VPC
NonProd Endpoint VPC会社全体ではなく：
エンドポイントVPC31．推奨される企業構造
会社全体で1人しかいないというわけではなく、むしろ：
AWS Services
│
┌─────────────┴──────────────┐
│ │
Prod Endpoint VPC NonProd Endpoint VPC
│ │
TGW TGW
┌────┼────┐ ┌────┼────┐
│ │ │ │ │ │
Prod Prod Prod Dev Test Sandbox
VPC1 VPC2 VPC3平：
Security
Production
NonProduction共有エンドポイントVPCは別途作成してください。
こうすれば、両方を考慮に入れることができます。
コスト管理、セキュリティ、隔離、爆発範囲32. もう一つ非常に実際的な問題：DNSの競合。
例えば、VPC-Aには既に独自のVPC-Aが存在していました。
SSM Endpoint
Private DNS = Enabledそして再び関連付けます。
ssm.ap-northeast-1.amazonaws.comここは中央PHZです。
これはDNSネームスペースの競合を引き起こす可能性があります。
したがって、移住は一般的に次のようになるべきである。
① 中央エンドポイントを作成する ② 中央pHZを作成する ③ エンドポイント固有のDNSをテストする ④ スポークVPCを関連付ける ⑤ DNSを確認する ⑥ スポークVPC自身のエンドポイントを削除する ⑦ サービスを検証する ⑧ 次のVPCに移行するそれらを一度にすべて削除するのではなく。
33. 地域をまたいだ運用は可能ですが、過剰な使用は推奨されません。
例えば：
Tokyo VPC
ap-northeast-1
Osaka VPC
ap-northeast-3理論上は：
Tokyo VPC
↓
TGW
↓
TGW Peering
↓
Osaka
↓
Central EndpointAWS は、以下の方法でリージョンをまたがる集中型エンドポイント アーキテクチャも提供しています。
TGW Peering
+
Private Hosted Zones成し遂げる。
ただし、一般的には以下のことが推奨されます。
Tokyo Endpoint VPC
↓
Tokyo VPCs
Osaka Endpoint VPC
↓
Osaka VPCsつまり、
1つのリージョンに、1つの中央エンドポイントVPC。
それで：
低遅延、シンプルなネットワーク、優れた災害対策、地域間トラフィックコストの削減34．4つの選択肢の直接比較
| プロジェクト | VPCエンドポイントごと | Peering Central | TGW Central | S3 Gateway |
|---|---|---|---|---|
| エンドポイント番号 | たくさんの | 少し | 少し | VPCごと |
| PrivateLinkの料金 | 高い | 低い | 低い | 無料 |
| TGWコスト | なし | なし | 持っている | なし |
| DNS管理 | 単純 | 中くらい | 中くらい | とても簡単です。 |
| ネットワークの複雑性 | 最低 | 中くらい | 中くらい | 最低 |
| 大規模VPC | ❌ | ❌ | ✅ | ✅ |
| 分離 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Blast Radius | 小さい | 真ん中 | 大きい | 小さい |
| 複数アカウント | できる | できる | 非常に適切 | それぞれが作成 |
| Transitive Routing | N/A | ❌ | ✅ | N/A |
| 推奨されるVPCの数 | 1～少量 | 少量 | 中型と大型 | どれでも |
35．大規模環境に適した設計
会社が以下の条件を満たしていると仮定します。
VPC 30個、AWSアカウント 5個、東京リージョン以下のように立証できる。
Network Account
│
├─ Transit Gateway
│
├─ Endpoint VPC
│ │
│ ├─ SSM
│ ├─ SSM Messages
│ ├─ EC2 Messages
│ ├─ ECR API
│ ├─ ECR DKR
│ ├─ STS
│ ├─ KMS
│ ├─ Secrets Manager
│ ├─ CloudWatch
│ ├─ CloudWatch Logs
│ ├─ SNS
│ └─ SQS
│
└─ Route53 Private Hosted Zonesそれから：
Account A
├─ VPC1 ─┐
├─ VPC2 ─┤
└─ VPC3 ─┤
│
Account B│
├─ VPC4 ─┤
├─ VPC5 ─┤
└─ VPC6 ─┤
▼
TGW
│
▼
Endpoint VPC
│
▼
AWS PrivateLinkしかし：
S3 Gateway Endpoint
DynamoDB Gateway Endpoint依然として推奨される事項：
各VPCごとに個別に作成されます。無料であること、そしてゲートウェイエンドポイント自体はTGW/ピアリングを介して他のVPCから使用できないためです。
36. 全体のアーキテクチャは4つの層として記憶できます。
実際、今後問題解決に取り組む際には、以下の4つのレイヤーだけを覚えておけばよいのです。
┌─────────────────┐
│ DNS │
│ Route53 PHZ │
└────────┬────────┘
│
▼
Endpoint Private IP
│
┌────────┴────────┐
│ Routing │
│ TGW/Peering │
└────────┬────────┘
│
┌────────▼────────┐
│ Security │
│ Endpoint SG/NACL│
└────────┬────────┘
│
┌────────▼────────┐
│ IAM Policy │
│ Endpoint Policy │
│ Service Policy │
└─────────────────┘アクセスできない場合は、以下の手順に従ってください。
① DNS
② Route
③ Security Group/NACL
④ IAM / Endpoint Policy調査を行えば、たいてい問題は見つかるものだ。
最も印象的な一文
VPCエンドポイント自体は、RAMを介して「複数のVPCと共有される」ものではありません。
インターフェースエンドポイントの中央集権的な性質は以下のとおりです。
Central VPC
↓
Interface Endpoint ENI
↑
TGW / VPC Peering
↑
Other VPCs再び合格しました：
Route53 Private Hosted ZoneすべてのVPCにおいて：
ssm.ap-northeast-1.amazonaws.comすべて分析の結果、以下のことが判明しました。
Central VPC Endpointこれで全工程が完了します。 Shared/Centralized VPC Endpoint。
そして S3/DynamoDBゲートウェイエンドポイントではこの操作を行わないでください。各VPCごとに独自のエンドポイントを構築してください。無料であることに加え、AWSはTGWやピアリングなど、相手側からの使用を明確に禁止しているからです。