type
status
date
slug
summary
tags
category
icon
password
理論
1. AWS PrivateLink
AWS PrivateLinkは、AWSサービスまたはサードパーティのアプリケーションに対してインターネットを経由せず、安全にプライベートネットワーク経由で接続するためのサービスです。
- インターフェイスVPCエンドポイント: 特定のAWSサービスやエンドポイントサービス（サードパーティのアプリケーションなど）に接続するために使用される。
- 主な特徴:
- インターネットを経由せず、AWSネットワーク内で通信。
- エンドポイントにセキュリティグループを適用可能で、アクセス制御が柔軟。
- サービス提供者と消費者が別々のVPCに存在する場合でも利用可能。
AWS PrivateLinkの通信特性
- 単方向通信:
- AWS PrivateLinkでは、インターフェイスVPCエンドポイントを通じて、サービスの消費者（Client側）がサービスプロバイダー（Provider側）にアクセスする仕組みです。
- 消費者側（エンドポイントが存在するVPC）からプロバイダー側（サービスが提供されるVPC）へのリクエストは可能ですが、その逆方向の通信はサポートされていません。
- 消費者とプロバイダーの分離:
- 消費者側はプロバイダーのVPCに関する情報（例: IPアドレス範囲やVPC ID）を知る必要がありません。
- プロバイダーも消費者のVPCに直接アクセスすることはできず、完全に分離されています。
- 双方向の通信が必要な場合の代替案:
- AWS PrivateLinkではデータやリクエストを送信する方向が限定されるため、双方向通信が必要な場合には別の方法を検討する必要があります。例:
- VPCピアリング: 双方向の通信が可能。
- AWS Transit Gateway: より複雑な接続環境を管理可能。
単方向通信のメリット
- セキュリティの向上:
- 通信の方向を明確に制限することで、不要なアクセスや潜在的な脅威を防ぐ。
- ネットワーク分離:
- サービス提供者と消費者が分離されているため、接続先の詳細情報を隠すことが可能。
まとめ
AWS PrivateLinkは「クライアント（消費者）がサーバー（プロバイダー）にリクエストを送る」という単方向通信が基本です。双方向通信が必要な場合は、VPCピアリングや別のサービスを利用する方が適しています。
2. AWS Site-to-Site VPN
AWS Site-to-Site VPNは、オンプレミス環境や他のAWS環境との間で安全なVPN接続を確立するサービスです。
- 主な特徴:
- 暗号化されたトンネルで通信。
- インターネットを経由するため、完全なプライベート接続ではない。
- ネットワークACLやセキュリティグループでアクセスを制御可能。
3. VPCピアリング
VPCピアリングは、異なるAWSアカウントまたは同一アカウント内の2つのVPC間で安全なネットワーク接続を確立する方法です。
- 主な特徴:
- 双方向でアクセス可能な接続を構築。
- プライベートIPアドレスを使用して通信。
- ルートテーブルの設定が必要で、アクセス範囲の制御が難しい場合もある。
4. アクセス制御と最小権限の原則
- セキュリティグループ: 特定のVPCリソースに対するアクセスを許可または拒否するルールを設定。細かい制御が可能。
- ネットワークACL: サブネットレベルでのアクセス制御。セキュリティグループより粗い制御。
- 最小権限の原則: 必要最低限の権限のみを付与し、不要なアクセスを防ぐ。
関連するAWSサービスのユースケース比較
サービス | 特徴 | 使用例 |
AWS PrivateLink | 完全にプライベートな接続を提供。インターネットを経由せず、セキュリティが高い。 | サードパーティのSaaSアプリケーションやAWSサービスへのアクセス。 |
Site-to-Site VPN | 暗号化された接続だが、インターネットを経由するため完全なプライベート通信ではない。 | オンプレミス環境とAWS間の接続。 |
VPCピアリング | 双方向のプライベート接続。設定が簡単だが、大規模な接続管理には向かない。 | 同じAWSアカウントまたは異なるアカウントのVPC間通信。 |
実践
Privatelinkとは、
「VPC間のPrivate通信を許可する設定および構成」を指しています。VPC Peeringとの違いは、「特定の通信のみを許可できる」点です。それでは、構築を進めましょう。
構成図
ステップ 1：VPC構築
下記のVPCを構築します。
リソース・サービス | 設定・要点 |
VPC（privatelink-A-vpc） | サービス利用側のVPC |
ㅤ | - Availability Zone-A/C に Public/Private サブネットを作成 |
ㅤ | - NATゲートウェイを1つ作成 |
VPC（privatelink-B-vpc） | サービス提供側のVPC |
ㅤ | - Availability Zone-A/C に Public/Private サブネットを作成 |
ㅤ | - NATゲートウェイを1つ作成 |
この表を参考に構築を進めてください。
ステップ 2：EC2構築
下記のEC2を構築します。
リソース・サービス | 設定・要点 |
Security Group (EC2-A-sg) | サービス利用側EC2（EC2-A）のSG。インバウンドルールは後ほど設定します。 |
Security Group (EC2-B-sg) | サービス提供側EC2（EC2-B）のSG。インバウンドルールは後ほど設定します。 |
IAMロール (SSM-role) | EC2にSSM接続をするためのIAMロール。AmazonSSMManagedInstanceCoreポリシーをアタッチします。 |
EC2 (EC2-A) | サービス利用側のEC2。- 作成したSGとIAM Roleをアタッチ。- VPC-A AZ-aのPrivate Subnetに配置します。 |
EC2 (EC2-B) | サービス提供側のEC2。- 作成したSGとIAM Roleをアタッチ。- VPC-B AZ-cのPrivate Subnetに配置します。 |
EC2-B ユーザーデータ | #!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
touch /var/www/html/index.html
echo "Hello AWS!" | tee -a /var/www/html/index.html |
ステップ 3：NLB構築
下記のEC2を構築します。
リソース・サービス | 設定・要点 |
Security Group (NLB-B-sg) | NLB（NLB-B）のSG。インバウンドルールは後ほど設定します。 |
Target Group (NLB-B-tg) | NLBからEC2に接続するためのTG。
- プロトコル: TCP:80
- ヘルスチェックパス: /index.html
- ターゲット: EC2（EC2-B） |
Network Load Balancer (NLB-B) | PrivateLinkとしてサービスを提供するためのNLB。
- 内部向けNLBとして構築。
- privatelink-B-vpc のAvailability Zone-A/Cにマッピング。
- 上記のSGをアタッチ。
- TCP:80番のリスナーに上記TGをアタッチ。 |
この表を参考に構築を進めてください。
ステップ 4：NLBからEC2への接続許可
リソース・サービス | 設定・要点 |
Security Group（EC2-B-sg） | HTTP（TCP: 80）に対し、
NLBのSG（NLB-B-sg）の通信を許可します。 |
エンドポイントとエンドポイントサービスの違い
- エンドポイント: インターネットを経由せず、VPCからS3などにアクセスするための接続口。
- エンドポイントサービス: 自分のVPCで構築したNLB（ネットワークロードバランサー）を使って、他のVPCから自分のサービスに接続できるようにする機能。
まとめ
- エンドポイントはAWSのサービスに接続するための入口。接続したい側、消費者が構築
- エンドポイントサービスは、他のVPCに自分のサービスを提供するための仕組みです。提供者が構築
ステップ 5：提供者側の設定
下記のエンドポイントサービスを作成します。
リソース・サービス | 設定・要点 |
VPC Endpoint Service（privatelink-B-vpces） | Privatelinkを構成するサービスです。
サービス提供側VPCに構築したNLB（NLB-B）をアタッチします。
サポートされいているIPアドレスタイプにはIPv4を設定します。 |
ステップ 6：利用者側の設定
下記のエンドポイントを作成します。
リソース・サービス | 設定・要点 |
Security Group（privatelink-A-vpce-sg） | VPC EndpointのSGです。
HTTP（TCP: 80）に対し、EC2のSG（EC2-A-sg）の通信を許可します。 |
VPC Endpoint（privatelink-A-vpce） | Privatelinkの入り口となるサービスです。
サービス利用VPCに構築されたEC2と同一のサブネットに配置します。
・ タイプ：NLB と GWLB を使用するエンドポイントサービスサービス名には控えておいたサービス名を入力し、サービスの検証を押下します。
・サブネット：ap-northeast-1aのPrivateSubnetのIDを選択します。
・セキュリティグループ：privatelink-A-vpce-sg |
ステップ 7：提供者側の承諾
リソース・サービス | 設定・要点 |
VPC Endpoint Service（privatelink-B-vpces） | エンドポイント接続タブにて作成したエンドポイントがPending acceptanceとなっているので、アクション → エンドポイント接続リクエストの承諾を選択します。 |
ステップ 8：ネットワーク到達性の確認
VPC Reachability Analyzer を利用してネットワークの到達性を確認します。以下の手順で進めてください。
- VPC Reachability Analyzerの起動
AWSマネジメントコンソールの検索バーから「VPC Reachability Analyzer」を検索してアクセス。
- 料金注意
実行1回につき 0.10USD が請求されます。検証のため2回失敗を試みる場合、料金が気になる方は実施前に内容を確認してください。
- 設定手順
- 「パスの作成」を選択。
- 分析対象の送信元・送信先を設定し、分析を実行。
- 分析結果
- 到達性を確認可能。
- Elastic Network Interface（ENI） や Security Group（SG） の通過状況が詳細に表示され、トラブルシューティングに役立ちます。
- 期待結果
- 実際の結果
- 原因の確認
リソース・サービス | 設定・要点 |
パスの作成と分析（EC2A-B） | 到達性の設定をします。
・ 送信元タイプ：instances
・送信元：EC2-A （id）
・送信先タイプ：instances
・送信先：EC2-B （id）プロトコル：TCP |
EC2間接続の確認結果
EC2-AとEC2-B間で接続が可能になるはずが
「到達不可能」 と表示されました。
詳細を確認すると、次のエラーが発生：
「セキュリティグループの ingress ルールが適用されていない」など
VPC Reachability Analyzerを参照しながら、SGを修正していきます
NLBPrivateLinkの通信セキュリティの解除
デフォルトの設定では、NLBに設定されているSGがPrivateLinkの通信に適用されます。 PrivateLinkの通信セキュリティはエンドポイントのSGで制御しているため、この関連付けを解除します。
リソース・サービス | 設定・要点 |
NLB（NLB-B） | セキュリティタブより編集ボタンを押下します。PrivateLink トラフィックにインバウンドルールを適用する のチェックを外します。 |
（再度）ネットワーク到達性を確認する
設定が完了したので、再度、到達性の検証をします。 2回目以降は通信先を設定する必要は無く、先ほど作成したパス（EC2A-B）を選択し、
パスの分析ボタン → 確認ボタンを押下します。しかし、またもや「到達不可能」と出てしまいました！
詳細を見てみると、
ロードバランサー loadbalancer/net/NLB-B/xxx のリスナーは、いずれも適用されません。というエラーの様です。 その原因は、クロスゾーン負荷分散を有効化する
この接続が失敗した理由は、EC2-A/Bがそれぞれ別のAZに配置されていたためです。 デフォルトの設定では同一のAZ内で通信を行うため、AZ間で通信できるようにするためには、 NLBの設定から「クロスゾーン負荷分散」機能を有効化する必要があります。
NLBがAZをまたいだルーティングを可能にするために、クロスゾーン負荷分散の設定を行います。
リソース・サービス | 設定・要点 |
NLB（NLB-B） | NLBを選択し アクション → ロードバランサーの属性を編集を選択します。ロードバランサーのターゲット選択ポリシー項目でクロスゾーン負荷分散を有効にするを選択します。 |
設定編集画面より、NLB以降でAZ間に通信ができるイメージ画像に変わります。
（再々度）ネットワーク到達性を確認する
今度こそ、設定不足が無いかチェックしながら、再々確認します。
「到達可能」となりました！
実際に接続してみる
サービス利用側EC2（EC2-A）からサービス提供EC2（EC2-B）のWebページが閲覧できることを確認します。
EC2-Aのアクセス先は、作成したエンドポイントとなるので、アクセス先DNS名を取得します。
リソース・サービス | 設定・要点 |
VPC Endpoint（privatelink-A-vpce） | 消費者側のエンドポイントのDNS名を取得します。 詳細タブより、DNS名を控えておきます。合わせて、サブネットタブより、IPv4アドレスを控えておきます。 |
EC2-AにSSMでログインし、以下のコマンドを用いてWebページへアクセスします。
最後に
今回のHTTP:80を使用したWebサーバの設定は、独自のサービスやプロトコルに置き換えることで、AWSネットワーク間で安全な通信を実現できます。また、VPC Reachability Analyzerを活用すれば、インスタンス以外も送信元/先に設定可能で、送信ヘッダーの制御を含め柔軟なテストケースを作成できます。
一問道場
質問 #12
ある企業がサードパーティのソフトウェア・アズ・ア・サービス（SaaS）アプリケーションを利用したいと考えています。このSaaSアプリケーションは、いくつかのAPI呼び出しを通じて利用され、AWS上のVPC内で動作しています。企業は、自社のVPC内からこのSaaSアプリケーションを利用します。
要件
- インターネットを経由しないプライベート接続を使用すること。
- 企業VPC内のリソースが外部からアクセスされないこと。
- すべてのアクセス許可は最小権限の原則に従うこと。
選択肢
A.
- AWS PrivateLinkインターフェイスVPCエンドポイントを作成する。
- このエンドポイントをサードパーティのSaaSアプリケーションが提供するエンドポイントサービスに接続する。
- セキュリティグループを作成してエンドポイントへのアクセスを制限し、このセキュリティグループをエンドポイントに関連付ける。
B.
- サードパーティのSaaSアプリケーションと企業のVPCの間にAWS Site-to-Site VPN接続を作成する。
- ネットワークACLを設定してVPNトンネル間のアクセスを制限する。
C.
- サードパーティのSaaSアプリケーションと企業のVPCの間にVPCピアリング接続を作成する。
- ルートテーブルを更新して、ピアリング接続に必要なルートを追加する。
D.
- AWS PrivateLinkエンドポイントサービスを作成する。
- サードパーティのSaaSプロバイダーに、このエンドポイントサービス用のインターフェイスVPCエンドポイントを作成するよう依頼する。
- このエンドポイントサービスへのアクセス許可を特定のサードパーティSaaSプロバイダーのアカウントに付与する。
どのソリューションがこの要件を満たすでしょうか？
解説
問題の要件
- プライベート接続の利用: インターネットを経由しない通信が必要。
- 企業VPC外からのアクセス禁止: サードパーティのSaaSアプリケーションへの通信のみを許可。
- 最小権限の原則: 必要最低限のアクセス許可を設定すること。
各選択肢の評価
選択肢 A: AWS PrivateLink を使用
AWS PrivateLinkインターフェイスVPCエンドポイントを作成し、サードパーティSaaSアプリケーションのエンドポイントサービスに接続する。セキュリティグループを作成し、アクセスを制限する。
- 要件適合性:
- プライベート接続: AWS PrivateLinkはAWSネットワークを利用するため、インターネットを経由しない。
- 企業VPC外からのアクセス禁止: 接続はエンドポイント経由で行われ、企業VPC外からの直接アクセスは不可能。
- 最小権限: セキュリティグループを使用してアクセスを限定できる。
- 評価: 要件をすべて満たしており、最適な解決策。
✅ 適切
選択肢 B: AWS Site-to-Site VPN
サードパーティのSaaSアプリケーションと企業VPC間でSite-to-Site VPN接続を作成し、ネットワークACLでアクセスを制限する。
- 要件適合性:
- プライベート接続: VPNはインターネットを経由するため、完全なプライベート接続にはならない。
- 企業VPC外からのアクセス禁止: VPN接続自体が双方向通信を可能にするため、外部リソースが企業VPCにアクセスできる可能性がある。
- 最小権限: ネットワークACLで制限可能だが、完全に分離された構成ではない。
- 評価: インターネット非経由の要件を満たさず不適切。
❌ 不適切
選択肢 C: VPC Peering
サードパーティのSaaSアプリケーションと企業VPCの間にVPCピアリング接続を作成し、ルートテーブルを更新する。
- 要件適合性:
- プライベート接続: VPC PeeringはAWSネットワーク内で通信するため、インターネットを経由しない。
- 企業VPC外からのアクセス禁止: VPC Peeringは双方向通信が可能であるため、サードパーティが企業VPCにアクセスできてしまう。
- 最小権限: 双方向通信のため、不要なアクセスリスクが増加。
- 評価: 双方向通信が可能であるため要件に適合しない。
❌ 不適切
選択肢 D: 消費者がエンドポイントサービスを作成
- 要件適合性:
- プライベート接続: AWS PrivateLinkはプライベート接続を提供。
- 企業VPC外からのアクセス禁止: エンドポイントサービスは企業側で提供されるため、構成が要件と逆になる。
- 最小権限: 消費者側がサービスを提供する形になるため、管理負担が増加。
企業側でAWS PrivateLinkエンドポイントサービスを作成し、サードパーティにエンドポイントを設定させる。
- 評価: 構成が要件に沿っておらず不適切。
❌ 不適切
結論
最適な解決策は 選択肢 A: AWS PrivateLink を使用することです。このソリューションは以下の理由で要件を満たします。
- インターネットを経由せず、AWSのプライベートネットワーク内で通信する。
- エンドポイントを介した接続のみを許可し、企業VPC外からのアクセスを遮断。
- セキュリティグループを活用して最小権限を適用可能。
答え: A
- 作者:みなみ
- 链接:https://tangly1024.com/資格勉強/15bd7ae8-88e2-8053-9e2d-e61e178bee49
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
.png?table=block&id=021326af-6a29-487e-ac2f-560985ab23b3&t=021326af-6a29-487e-ac2f-560985ab23b3&width=800&cache=v2)
