どーも！shihopowerです！
SAP/SAAの勉強をしていると、こんな状況になりませんか？
リーダーエンドポイント、クラスターエンドポイント、エッジ最適化エンドポイント、プライベートエンドポイント… 〇〇エンドポイントって多すぎん？？🤯
わたしもそうでした！「エンドポイント」って言葉自体はわかるけど、AWSだといろんなサービスでいろんな種類が出てきて混乱しますよね。
そこで今回は、試験でよく出る Aurora・API Gateway・VPCエンドポイント の3つに絞って、それぞれのエンドポイントの種類と使い分けを整理してみました！
目次
1. そもそも「エンドポイント」って何？
エンドポイントとは、サービスやリソースへの接続口となるURL・アドレスのことです。
各サービスのドキュメントを読み込んでいくと、「接続元」「接続先」「用途・目的」という要素が共通して登場することに気づきました。そこでわたしなりの覚え方として、「どこから」「どこへ」「どんな目的で」接続するかを軸に整理してみました！これが「〇〇エンドポイントって何が違うの？」という混乱を解くカギになると思います😊
大きく分けると以下の3サービスで登場します。
| サービス | 何のエンドポイントか |
|---|---|
| Aurora | データベースへの接続先 |
| API Gateway | APIの公開口 |
| VPCエンドポイント | VPC内からAWSサービスへのプライベート接続口 |
それぞれ見ていきましょう！
2. Auroraのエンドポイント
Auroraは単一のDBインスタンスではなく、クラスター構成になっています。プライマリ・レプリカ・特定インスタンスなど、接続先の役割に応じてエンドポイントが分かれています。
① クラスターエンドポイント（Cluster Endpoint）
→ 読み書き両方を処理するメインエンドポイント
- プライマリインスタンスに接続する
- INSERT・UPDATE・DELETE・DDL など書き込み操作はここ
- アプリケーション開発・テスト時のメイン接続先
例）mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com
② リーダーエンドポイント（Reader Endpoint）
→ 読み取り専用・複数レプリカへ自動で負荷分散
- Auroraレプリカ（最大15台）に自動でバランシング
- SELECT など読み取り専用のワークロード向け
- 重要ポイント！ Lambda + Aurora の構成で「読み取りが多い」→ リーダーエンドポイントを使う
例）mydb.cluster-ro-xxxx.ap-northeast-1.rds.amazonaws.com
③ インスタンスエンドポイント（Instance Endpoint）
→ 特定の1台に直接つなぐ（診断・チューニング用）
- 特定のDBインスタンスを名指しで接続する
- 本番運用ではなく、障害調査やパフォーマンスチューニング時に使う
- フェイルオーバー時に自動で切り替わらないので注意⚠️
④ カスタムエンドポイント（Custom Endpoint）
→ 指定したインスタンスグループにルーティング
- 「重い分析クエリは高スペックなレプリカだけに向ける」といった柔軟な制御が可能
- インスタンスのスペックや設定が混在するクラスターで有効
【まとめ表】Auroraエンドポイントの使い分け
| エンドポイント | どこから | どこへ | どんな目的で |
|---|---|---|---|
| クラスター | アプリケーション | プライマリインスタンス | 読み書き（通常の業務処理） |
| リーダー | アプリケーション | 全レプリカ（自動分散） | 読み取り専用・負荷分散 |
| インスタンス | 管理者・開発者 | 特定の1台 | 診断・チューニング |
| カスタム | アプリケーション | 任意のインスタンスグループ | 用途別の柔軟なルーティング |
💡 重要ポイント
「Lambda関数がAurora MySQLをクエリするだけ」→ リーダーエンドポイント！
クラスターエンドポイントはプライマリ（書き込み）なので読み取り専用ワークロードには非効率です。
3. API Gatewayのエンドポイント
API Gatewayでは、APIクライアントがどこにいるかによって最適なエンドポイントタイプが異なります。
① エッジ最適化エンドポイント（Edge-Optimized）
→ 世界中に分散したユーザー向け・デフォルト設定
- リクエストを最寄りの CloudFront POP（Points of Presence） 経由でルーティング
- クライアントが地理的に分散している場合に有効
- API Gateway REST APIのデフォルトタイプ
イメージ：世界中のユーザー → CloudFront POP → API Gateway
② リージョナルエンドポイント（Regional）
→ 同一リージョン内のクライアント向け
- CloudFrontを経由せず、同じリージョン内で直接通信
- EC2インスタンスや同一リージョンのサービスからAPI呼び出す場合に接続オーバーヘッドを削減
- 自前のCloudFrontディストリビューションと組み合わせることも可能
イメージ：同一リージョンのEC2・Lambda → API Gateway（直接）
③ プライベートエンドポイント（Private）
→ VPC内部からのみアクセス可能・インターネット非公開
- VPC内に作成したインターフェイスVPCエンドポイント（ENI）経由でのみ到達できる
- インターネットに公開したくない社内向けAPIや、マイクロサービス間通信に最適
- AWS PrivateLinkを使用し、トラフィックはAWSネットワーク内に留まる
イメージ：VPC内のリソース → VPCエンドポイント（ENI） → API Gateway
【まとめ表】API Gatewayエンドポイントの使い分け
| エンドポイント | どこから | どこへ | どんな目的で |
|---|---|---|---|
| エッジ最適化 | 世界中に分散したクライアント | CloudFront POP 経由で API Gateway | レイテンシーを抑えてグローバルに公開 |
| リージョナル | 同一リージョン内のクライアント | API Gateway（直接） | 接続オーバーヘッドを削減してAPI呼び出し |
| プライベート | VPC内部のリソースのみ | VPCエンドポイント（ENI）経由で API Gateway | インターネット非公開のAPI呼び出し |
💡 重要ポイント
「ユーザーがアプリのデプロイリージョン近くに集中している」→ リージョナルエンドポイント！
エッジ最適化に変えてもパフォーマンスは改善しません（むしろ不要なCloudFrontを経由するだけ）。
4. VPCエンドポイント
VPCエンドポイントは、VPC内のリソースがインターネットを経由せずにAWSサービスへ接続するための仕組みです。種類によって対象サービスや仕組みが異なります。
① インターフェイスエンドポイント（Interface）
→ 多くのAWSサービスへのプライベート接続（AWS PrivateLink使用）
- VPCサブネット内に ENI（Elastic Network Interface） が作成される
- SQS・SNS・CloudWatch・Secrets Manager など多数のサービスに対応
- DNS解決によってトラフィックをプライベートIPへルーティング
- 有料（時間課金＋データ転送料）
イメージ：EC2/Lambda → ENI（プライベートIP） → AWSサービス（インターネット不使用）
② ゲートウェイエンドポイント（Gateway）
→ S3・DynamoDB専用・無料！
- Amazon S3 と DynamoDB のみに対応
- ルートテーブルにルートを追加する形で動作（ENIは作成されない）
- AWS PrivateLinkを使用しない
- 追加料金なし ← 重要ポイント！
イメージ：EC2 → ルートテーブル → ゲートウェイエンドポイント → S3/DynamoDB
③ Gateway Load Balancerエンドポイント
→ ファイアウォール・侵入検知システムなどのセキュリティアプライアンス経由
- 別VPCに展開されたセキュリティアプライアンス群にトラフィックを通す
- ルートテーブルで経由させる構成
- セキュリティ要件が厳しい構成で登場する
④ リソースエンドポイント（Resource）
→ 別VPCのリソース（DB・EC2など）に直接アクセス
- ロードバランサー不要で別VPCのリソースへ直接接続
- RAM（Resource Access Manager）でリソースを共有してから利用
⑤ サービスネットワークエンドポイント（Service Network）
→ 複数サービスへ1つのエンドポイントでまとめてアクセス
- サービスネットワークに紐づいた複数リソース・サービスへ一括でプライベートアクセス
【まとめ表】VPCエンドポイントの使い分け
| エンドポイント | どこから | どこへ | どんな目的で |
|---|---|---|---|
| インターフェイス | VPC内のリソース | SQS・SNS・CloudWatch 等（ENI経由） | 多くのAWSサービスへプライベートに接続 |
| ゲートウェイ | VPC内のリソース | S3・DynamoDB（ルートテーブル経由） | 無料でS3・DynamoDBへプライベートに接続 |
| Gateway Load Balancer | VPC内のリソース | セキュリティアプライアンス（別VPC） | ファイアウォール等を経由してトラフィックを検査 |
| リソース | VPC内のリソース | 別VPCのDB・EC2等 | 別VPCのリソースへ直接プライベートアクセス |
| サービスネットワーク | VPC内のリソース | サービスネットワーク上の複数サービス | 1つのエンドポイントで複数サービスにまとめてアクセス |
💡 重要ポイント
「VPCからS3へインターネットを経由せずアクセスしたい・コストを抑えたい」→ ゲートウェイエンドポイント（無料）！
インターフェイスエンドポイントでもS3に接続できますが、ゲートウェイエンドポイントのほうがシンプルで安価です。
5. 全体まとめ
横断比較表
| 分類 | エンドポイント | どこから | どこへ | どんな目的で |
|---|---|---|---|---|
| Aurora | クラスター | アプリケーション | プライマリインスタンス | 読み書き・通常の業務処理 |
| リーダー | アプリケーション | 全レプリカ（自動分散） | 読み取り専用・負荷分散 | |
| インスタンス | 管理者・開発者 | 特定の1台 | 診断・チューニング | |
| カスタム | アプリケーション | 任意のインスタンスグループ | 用途別の柔軟なルーティング | |
| API Gateway | エッジ最適化 | 世界中に分散したクライアント | CloudFront POP 経由で API Gateway | グローバルに低レイテンシーで公開 |
| リージョナル | 同一リージョン内のクライアント | API Gateway（直接） | 同一リージョン向けに効率よくAPI公開 | |
| プライベート | VPC内部のリソースのみ | ENI 経由で API Gateway | インターネット非公開のAPI呼び出し | |
| VPC | インターフェイス | VPC内のリソース | SQS・SNS 等（ENI経由） | 多くのAWSサービスへプライベート接続 |
| ゲートウェイ | VPC内のリソース | S3・DynamoDB（ルートテーブル経由） | 無料でS3・DynamoDBへプライベート接続 | |
| Gateway Load Balancer | VPC内のリソース | セキュリティアプライアンス（別VPC） | ファイアウォール等を経由してトラフィック検査 |
重要ポイントまとめ
- Lambda + Aurora で読み取りのみ → リーダーエンドポイント ＋ RDS Proxy
- ユーザーが同一リージョン集中 → API Gateway はリージョナルエンドポイント
- VPCからS3・DynamoDB にコスト最小で接続 → ゲートウェイエンドポイント（無料）
- 社内向けAPIをインターネット非公開にしたい → API Gateway プライベートエンドポイント
- エッジ最適化はグローバル分散ユーザー向け → 同一リージョンでは効果なし
おわりに
「〇〇エンドポイント」って最初は全部一緒に見えるんですが、各サービスのドキュメントを読み込んでいくうちに、わたしなりの整理として 「どこから」「どこへ」「どんな目的で」接続するか という軸で考えるとスッキリすることに気づきました！
試験中に迷ったときは、まずその軸で考えてみてください✍️
この記事が少しでも役に立てたら嬉しいです！引き続きSAP/SAA対策の記事を書いていくのでよろしくです〜！
参考：AWS公式ドキュメント