セクション 01 · タスク 1.1 · SAP-C02-010
AWSサービスへのプライベート接続
VPCエンドポイント / ゲートウェイエンドポイント / インターフェイスエンドポイント / AWS PrivateLink / エンドポイントポリシー / プライベートサービス統合
このページのゴール
AWSサービスやプライベートサービスへインターネットを通さず接続するとき、接続対象・接続元・コスト・セキュリティ境界から正しいVPCエンドポイント方式を選べることをゴールにします。
1. SAP-C02公式範囲との対応
SAP-C02 タスク 1.1では、サービス統合のためにサービスエンドポイントを利用する設計判断が対象です。VPCエンドポイントは種類一覧を暗記するのではなく、何へ・どこから・どの境界で接続するかから方式を選びます。
2. プライベート接続の判断軸
プライベート接続が必要
│
▼
何へ接続?
│
├─ S3 / DynamoDB
│ ↓
│ ゲートウェイエンドポイントをまず評価
│
├─ PrivateLink対応AWSサービス
│ ↓
│ インターフェイスエンドポイント
│
└─ 別VPC / アカウントのプライベートサービス
↓
AWS PrivateLink
↓
どこから利用?
VPC / オンプレミス
↓
ネットワーク制御
→ セキュリティグループ
認可制御
→ エンドポイントポリシー + IAM等
↓
コスト / HA / DNS3. VPCエンドポイント
VPCエンドポイントを利用すると、対応するAWSサービスやプライベートサービスへ、インターネットゲートウェイやNAT ゲートウェイに依存せずプライベートに接続できます。
ただしVPCエンドポイントは1種類ではなく、接続対象と方式によって責任が異なります。
4. 現在のVPCエンドポイント種類
現在はインターフェイス / ゲートウェイ / ゲートウェイロードバランサー / リソース / サービスネットワークなど複数のVPCエンドポイントがあります。ただしSAP-C02では中心テーマに従い、ゲートウェイエンドポイント / インターフェイスエンドポイント / AWS PrivateLink / エンドポイントポリシー / プライベートサービス統合へ集中します。
ゲートウェイエンドポイントだけはAWS PrivateLinkを利用しない点も区別します。
5. ゲートウェイエンドポイント
基本構造
ゲートウェイ VPCエンドポイントは、Amazon S3とAmazon DynamoDBへプライベートに接続するためのエンドポイントです。選択したVPC ルートテーブルへAWS マネージドプレフィックスリスト宛のルートが追加されます。
プライベートサブネット
│
▼
ルートテーブル
宛先: AWS マネージドプレフィックスリスト
対象: ゲートウェイエンドポイント
│
▼
S3 / DynamoDBエンドポイントENIは作られず、エンドポイント自体の追加料金もありません。
ルートテーブルで利用範囲を決める
ゲートウェイエンドポイントを作成しただけでVPC内すべてのサブネットが自動的に利用するわけではありません。どのルートテーブルへエンドポイントルートを関連付けたかで利用範囲が決まります。
セキュリティグループをエンドポイントへ付ける方式ではなく、必要に応じてエンドポイントポリシーやワークロード側のネットワーク / IAM制御を組み合わせます。
6. インターフェイスエンドポイント
基本構造
インターフェイス VPCエンドポイントはAWS PrivateLinkを利用します。選択したサブネットへエンドポイントENIを作成し、そのプライベート IPを通じて対応AWSサービスやエンドポイントサービスへ接続します。
アプリケーション
│
▼
エンドポイントENI
│ PrivateLink
▼
AWSサービス / エンドポイントサービスエンドポイントENIにはセキュリティグループを関連付け、ネットワーク到達性を制御します。
可用性とコスト
本番システムで複数AZから利用するなら、必要なAZごとにサブネットを選択してエンドポイントENIを配置します。インターフェイスエンドポイントはエンドポイント利用時間とデータ処理に料金が発生し、サブネットのIPアドレスも消費します。
したがって「プライベートだからインターフェイスエンドポイントを各VPC・各AZへ無条件に配置する」ではなく、可用性・分離・コストを合わせて判断します。
プライベート DNS
インターフェイスエンドポイントでプライベート DNSを有効にすると、対応AWSサービスの通常のDNS名をエンドポイントENIのプライベート IPへ解決できます。
アプリケーション
secretsmanager.region.amazonaws.com
│ DNS
▼
インターフェイスエンドポイントのプライベートIPこれによりアプリケーションへ専用エンドポイント URLを大量に埋め込む設計を避けられます。
7. ゲートウェイ / インターフェイスを要件で選ぶ
| 要件 | 有力な方式 |
|---|---|
| VPC → S3 / DynamoDB、低コスト | ゲートウェイエンドポイント |
| VPC → PrivateLink対応AWSサービス | インターフェイスエンドポイント |
| オンプレミス → S3をプライベート接続 | インターフェイスエンドポイントを評価 |
| 別アカウントへ内部サービスだけ公開 | AWS PrivateLink |
8. S3 ハイブリッドではゲートウェイとインターフェイスを使い分ける
Amazon S3はゲートウェイエンドポイントとインターフェイスエンドポイントの両方を利用できます。VPC内ワークロードとオンプレミスの両方からS3へプライベート接続したい場合は、通信元によって使い分ける構成を評価します。
VPCワークロード
│
▼
ゲートウェイエンドポイント
│
▼
Amazon S3
オンプレミス
│ DNSクエリ
▼
Route 53 Resolverインバウンドエンドポイント
│
▼
S3インターフェイスエンドポイント
│
▼
Amazon S3S3 インターフェイスエンドポイントでプライベート DNSをインバウンド Resolver エンドポイントからのクエリに対してのみ有効化すると、オンプレミスからはインターフェイスエンドポイントを使い、VPC内からはゲートウェイエンドポイントを使う構成にできます。
| 通信元 | 主な経路 | 設計上の意味 |
|---|---|---|
| VPC | ゲートウェイエンドポイント | インターフェイスエンドポイントの処理料金を避けやすい |
| オンプレミス | Resolver インバウンド + インターフェイスエンドポイント | ゲートウェイエンドポイントでは利用できないオンプレミス接続を実現 |
この設定を利用するにはS3 ゲートウェイエンドポイントも必要です。単にプライベート DNSを有効にするとVPC内トラフィックまでインターフェイスエンドポイントへ向かうため、ハイブリッド DNSとエンドポイントコストを一体で設計することが重要です。
9. エンドポイントポリシー
エンドポイントポリシーは、そのVPCエンドポイントを経由してどのプリンシパルがどのサービスリソースへ何を実行できるかを制御するための認可レイヤーです。
重要なのは、エンドポイントポリシーがIAM ポリシーやリソースポリシーを置き換えないことです。
ネットワーク到達性
→ セキュリティグループ / ルート
エンドポイント経由のAPI制御
→ エンドポイントポリシー
プリンシパルの権限
→ IAM ポリシー
リソース側の制御
→ リソースポリシー10. AWS PrivateLinkによるプライベートサービス統合
PrivateLink
AWS PrivateLinkは、VPC全体を相互ルーティングするのではなく、特定サービスへのプライベートアクセスを提供します。
利用側 VPC
インターフェイスエンドポイント
│
▼
AWS PrivateLink
│
▼
提供側エンドポイントサービス
│
▼
プライベートアプリケーションVPC CIDRが重複していても、VPC全体の相互ルーティングを必要としないサービス単位の公開なら有力です。
エンドポイントサービス
提供側がアプリケーションやAPIをPrivateLinkで公開する一般的な構成では、Network Load Balancerをエンドポイントサービスへ関連付け、利用側はインターフェイスエンドポイントから接続します。一方、ゲートウェイロードバランサーを利用する仮想アプライアンスサービスでは、利用側はゲートウェイロードバランサー エンドポイントから接続します。
提供側では利用を許可するプリンシパルや接続承認の要否を制御できます。
11. PrivateLinkとVPC全体接続を混同しない
| 要件 | 有力な方式 |
|---|---|
| サービス / APIだけ公開 | AWS PrivateLink |
| VPC間で広い相互ルーティングが必要 | VPC ピアリング / AWS Transit Gateway等 |
「プライベート接続」という言葉だけで方式を決めず、通信範囲がサービス単位なのかネットワーク単位なのかを決定打にします。
12. 現行仕様の補足
現在のAWS PrivateLinkにはリソースエンドポイント、サービスネットワークエンドポイント、ゲートウェイロードバランサー エンドポイント、対応サービスでのクロスリージョン PrivateLinkなどもあります。
特に、エンドポイントサービス + NLB/GWLBとリソースエンドポイントは別モデルです。リソースエンドポイントでは対応リソースへロードバランサーなしで直接接続できるため、「PrivateLink = 必ずNLB」は現在は正しくありません。
ただしこれらは基本設計を置き換えて主講義にはしません。
13. エンドポイントだけでインターネット向け通信が消えるわけではない
アプリケーションがS3やSecrets Managerだけでなく、外部SaaSやOS パッケージ リポジトリへも通信するなら、その宛先への外向き通信は別途必要です。
VPCエンドポイントを作成
≠
任意のインターネット宛先までプライベート化14. インターフェイスエンドポイントの中央集約
多数VPCで同じAWSサービス用インターフェイスエンドポイントを利用すると、各VPC・各AZへの分散配置は料金・ENI・IP・運用対象を増やします。共有VPCへ集約する設計も評価できます。
一方で中央化するとDNS、ルーティング、エンドポイントポリシー、障害影響範囲が共有されます。コスト最小化だけで中央化を決めないことが重要です。
15. ハイブリッド DNSとの組み合わせ
オンプレミスや別VPCからインターフェイスエンドポイントを通常のAWSサービス DNS名で利用する場合、DNS設計が重要です。Amazon Route 53 VPC Resolverのインバウンドエンドポイントなどを組み合わせ、利用者がインターフェイスエンドポイントのプライベート IPへ名前解決できるようにします。
16. 混同ポイント
- S3 / DynamoDBだから必ずインターフェイス:VPC内だけならゲートウェイエンドポイントをまず評価。
- インターフェイスエンドポイントはルートテーブルへサービスプレフィックスを追加:ゲートウェイエンドポイントとの混同。
- セキュリティグループとエンドポイントポリシーは同じ:ネットワークとAPI認可で責任が違う。
- エンドポイントポリシーが許可ならIAM 拒否を無視:できない。
- オンプレミス → S3でゲートウェイエンドポイント:ハイブリッドアクセスではインターフェイスエンドポイントを評価。
- PrivateLink = VPC全体のルーティング:基本はサービス単位。
- PrivateLink = 必ずNLB:エンドポイントサービスとリソースエンドポイントを区別。
17. SAP-C02判断フローとまとめ
判断フロー
AWS / プライベートサービスへプライベート接続が必要
│
▼
何へ接続?
│
├─ S3 / DynamoDB
│ ↓
│ ゲートウェイエンドポイントを評価
│
├─ PrivateLink対応AWSサービス
│ ↓
│ インターフェイスエンドポイント
│
└─ プライベートサービス
↓
AWS PrivateLink
↓
どこから利用?
VPC / オンプレミス
↓
DNSは?
プライベート DNS / Resolver
↓
ネットワーク制御
→ セキュリティグループ / ルート
API 認可
→ エンドポイントポリシー + IAM等
↓
HA / コスト / 集約範囲を確認まとめ
VPC → S3 / DynamoDB
→ ゲートウェイエンドポイントをまず評価
VPC → PrivateLink対応AWSサービス
→ インターフェイスエンドポイント
オンプレミス → S3 プライベート アクセス
→ インターフェイスエンドポイント + ハイブリッド DNSを評価
独自サービスを別アカウントへ公開
→ AWS PrivateLink
ネットワーク到達性
→ セキュリティグループ / ルート
API認可
→ エンドポイントポリシー + IAM等
多数VPC
→ 分散配置と中央集約をコスト / 分離 / 影響範囲で比較最重要ポイント:「プライベートにしたい」だけでインターフェイスエンドポイントを選ばず、接続対象・接続元・通信範囲・DNS・認可・コストから方式を選びます。
主要AWS公式資料
理解確認
このページの内容を16問で確認します。
理解確認16問へ →