PrivateLinkが求められる背景と「インターネットに出さない」の定義
インターネットに出さない設計は、ただNATやIGWを外すだけでは完成しません。
SAA-C03の文脈でも、セキュアなアクセス経路を設計する中で「どの経路がインターネットを経由しないか」を説明できることが前提として扱われやすいです。
「インターネットに出さない」を分解して考える
現場でよくある誤解は、「プライベートサブネットに置いた＝外に出ない」です。実際には、次の2点を分けて整理すると一気にクリアになります。
- 経路：通信がIGW/NAT/パブリックIP経由で外部インターネットに出ないこと
- 名前解決：アクセス先が“公開エンドポイント”ではなく“VPC内のプライベートIP”に解決されること
PrivateLinkやVPCエンドポイントは、ここをセットで満たすための仕組みです。AWS自身も、PrivateLinkによってIGWやNATなどを使わずにサービスへプライベート接続できる点を明確に説明しています。
NATを使わないと何が嬉しいのか
NATゲートウェイは便利ですが、セキュリティ境界としては「外向き通信ができる」状態を作ります。監査や統制の観点では、最小権限だけでなく「最小経路」も求められる場面があります。加えて、NATには時間課金とデータ処理課金があり、構成や通信量によってはコストが膨らみます。
ここで重要なのは「NATが悪」ではなく、必要な通信だけを必要な経路で通すという設計思想です。PrivateLinkは、その選択肢を強くしてくれます。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
PrivateLinkとVPCエンドポイントの全体像
PrivateLinkは、VPC内のリソースから“プライベートに”サービスへ到達するための仕組みです。
まずは「VPCエンドポイント」という器の中で、何がPrivateLinkで何が違うのかを整理します。
VPCエンドポイントは大きく2種類
SAA-C03で混乱しやすいポイントですが、VPCエンドポイントには代表的に次の2系統があります。
- ゲートウェイ型エンドポイント
ルートテーブルに“ゲートウェイ”として登録して使うタイプ。代表は Amazon S3 と Amazon DynamoDB。 - インターフェイス型エンドポイント
サブネット内にENIが作られ、プライベートIPで到達するタイプ。多くのAWSサービスがこちら。
そして、このインターフェイス型が AWS PrivateLinkで提供される接続です。
「PrivateLink＝インターフェイス型」と覚えるより、**“ENIが生えるエンドポイントはPrivateLinkで動く”**とイメージすると、構成図が頭に残ります。
Private DNSが効くと何が変わる
インターフェイス型エンドポイントを作ると、リージョナルDNS名・ゾーンDNS名が用意されます。さらに Private DNSを有効にすると、通常はパブリックに解決されるAWSサービスの名前が、VPC内ではエンドポイントのプライベートIPに解決されます。
ここが「経路だけでなく、名前解決も閉域化する」の核心です。
VPC Endpoint Serviceという提供側の概念
PrivateLinkは「使う側」だけでなく「提供する側」も設計できます。
別アカウントやSaaSに対して、NLBやGWLBの背後にあるサービスをPrivateLinkで公開し、利用者側はインターフェイス型エンドポイントで接続します。
SAA-C03では細部の手順暗記よりも、「なぜNLBが前段に来るのか」「公開と言ってもインターネット公開ではないのか」を言語化できることが、混乱を減らします。
代表的な設計パターン
ここからは「結局どう組むのか」を、よくある要件別に組み立てます。
試験でも実務でも、正解は一つではないので、判断軸を明確にするのがコツです。
AWSサービスへ閉域で接続する基本形
“インターネットに出さない”の王道は、必要なAWSサービスに対してVPCエンドポイントを作ることです。インターフェイス型エンドポイントは多くのAWSサービスに対応しており、PrivateLinkでプライベートに到達できます。
例として、閉域VPCを作るなら次の発想が実務的です。
- 監視・ログ：CloudWatch系に出すなら対応エンドポイントを用意
- 運用管理：Systems Manager系を使うなら対応エンドポイントを用意
- コンテナ運用：ECRを使うなら必要なエンドポイントを揃える
- 認証・暗号：KMSやSTSなど、呼び出しが多い基盤系を見落とさない
ここはサービス名の丸暗記より、ワークロードが何を呼ぶか（SDKが裏で叩く先）から逆算するのが安全です。
S3とDynamoDBはまずゲートウェイ型で考える
S3とDynamoDBは、ゲートウェイ型エンドポイントが代表的です。ルートテーブルに紐づくため、サブネット設計とセットで考えられます。
ただしS3はインターフェイス型も選べます。S3のインターフェイス型は、ゲートウェイ型を“拡張”する位置づけで、プライベートIP経由のルーティングや、オンプレ・別リージョンなど条件によって効いてきます。
つまり「S3＝ゲートウェイ型で終わり」と決めつけるより、到達元の範囲まで含めて判断します。
マルチVPCでエンドポイントを中央集約したい
大規模になると「各VPCに全部作るのは面倒・コストが気になる」という話になります。ここで出てくるのが 中央集約型のプライベートエンドポイントという考え方です。
ただし、インターフェイス型のPrivate DNSは“そのVPC内に閉じた仕組み”として動くため、中央VPCに作ったエンドポイントのDNS解決を、スポークVPCへそのまま配るのはうまくいかないケースがあります。AWSのホワイトペーパーでも、この制約を前提に設計を組み立てています。
この場合の設計の方向性は、ざっくり次のどちらかです。
- 各スポークVPCに必要最小限のエンドポイントを持たせる（シンプルで事故が少ない）
- Route 53のプライベートホストゾーン設計を含めて、名前解決を再設計する（難易度は上がるが統制は効く）
SAA-C03向けには、まず前者の「シンプルに各VPC」が理解しやすく、設計理由も説明しやすいです。
別アカウントやSaaSへ閉域接続したい
「社内共通APIを別アカウントに置いた」「SaaSを閉域で使いたい」など、VPC外のサービスへプライベートに繋ぐ場合に、PrivateLinkが強い選択肢になります。
提供側はNLBまたはGWLBを前段に置いてエンドポイントサービスを作り、利用側はそのサービス名を指定してインターフェイス型エンドポイントを作成します。
重要なのは、ここで言う“公開”は「インターネット公開」とは別物だという点です。アクセス許可や接続受け入れの運用まで含めて、閉域のまま共有できます。
セキュリティと運用の勘所
PrivateLinkは便利ですが、設計の失敗原因はだいたい「DNS」「許可の置き場所」「可用性」のどれかです。
ここを押さえると、試験でも実務でも事故が減ります。
制御点はどこにあるか
インターフェイス型エンドポイントはENIとして存在するので、セキュリティグループで到達制御ができます。ここがゲートウェイ型と大きく違うポイントです（ゲートウェイ型はルートとポリシー寄りの発想になります）。
さらに、エンドポイントサービスを提供する場合は、接続要求を自動承認にするか、許可したプリンシパルだけにするか、といった運用設計が重要です。AWSも、承認フローや公開範囲の設定に注意点があることを明記しています。
DNSでハマる典型パターン
- Private DNSを有効にしたら、意図しない名前解決になって別経路が死んだ
- 中央VPCのエンドポイントをスポークVPCから使おうとして名前が引けない
- Private APIや特定サービスのDNS要件と衝突した
API GatewayのPrivate APIなどは、Private DNSの扱いでアクセス性が変わるため、Route 53の設計とセットで整理する必要があります。
「とりあえず有効化」は避け、どの名前がどこに解決されるかを図で説明できる状態にしてから切り替えるのが安全です。
可用性はサブネットとAZで作る
インターフェイス型はサブネットにENIが作られるので、複数AZにまたがって配置するのが基本です。提供側のエンドポイントサービスも、可用性を意識した作り方が整理されています。
試験対策としても、「単一AZで良い」より「障害を前提に複数AZ」が説明できる方が、設計問題で迷いにくいです。
コストとトラブルシュート
最後に、コストと“動かない時の見方”をまとめます。
ここまで理解していると、選択問題での消去法がかなり楽になります。
PrivateLinkの料金感とNATとの比較軸
インターフェイス型エンドポイントは、一般に 時間課金＋データ処理課金が発生します。
一方、NATゲートウェイも時間課金とデータ処理課金があり、AZ数や通信量で効き方が変わります。
比較のコツは、次の2段階です。
- 要件で必要か：外部インターネットへ出る必要があるか（OSアップデート、外部API、外部リポジトリなど）
- 閉域で足りるなら、どこまでエンドポイントで置き換えるか：S3/DynamoDB、運用系、監視系、認証系
「PrivateLinkは高い／NATは高い」と一言で決めず、通信先の種類と通信量とAZ設計で見積もるのが現実的です。
うまく繋がらない時のチェックリスト
- インターフェイス型
- エンドポイントのセキュリティグループのインバウンドが許可されているか
- サブネットのNACLで落ちていないか
- Private DNSの設定が期待通りか（名前がどこに解決されるか）
- ゲートウェイ型
- ルートテーブルにエンドポイントルートがあるか
- エンドポイントポリシーで拒否していないか
- エンドポイントサービス利用
- 提供側が接続要求を承認しているか
- 許可プリンシパルの範囲が適切か
このあたりは、暗記というより「どこに制御点があるか」を把握していると自然に追えるようになります。
学習を体系化したい人向けの教材の一例
PrivateLinkは単体でも理解できますが、SAA-C03全体では「VPC」「ルーティング」「DNS」「セキュリティ」「コスト最適化」が絡みます。なので、点ではなく線で学べる教材があると復習が楽です。
Udemyには、SAA-C03向けにVPC設計や接続方式をハンズオン込みで整理してくれる講座が複数あります。演習で「NATあり構成」と「VPCエンドポイント構成」を作り比べると、設計意図が言葉にしやすくなります（講座選びでは、VPCとネットワークの章が厚いものを選ぶのが無難です）。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
PrivateLinkは、「プライベートサブネットに置く」だけでは達成できない“インターネットに出さない”を、経路と名前解決の両面から成立させる仕組みです。
設計では、まずVPCエンドポイントの2種類（ゲートウェイ型とインターフェイス型）を押さえ、S3/DynamoDBはゲートウェイ型を基本にしつつ、要件次第でS3のインターフェイス型まで視野を広げるのが実務的です。
マルチVPCでは、Private DNSの制約が絡んで難易度が上がるため、中央集約にこだわるより「各VPCに必要最小限のエンドポイント」を置く設計が説明しやすく、事故も減らせます。
そして最後は、セキュリティの制御点（SG、承認フロー、ポリシー）と、NATとのコスト比較軸（要件と通信先と通信量）をセットで整理すると、SAA-C03でも実務でも判断がブレにくくなります。
