

# 基盤
<a name="a-foundations"></a>

**Topics**
+ [REL 1 サービスクォータと制約はどのように管理しますか?](w2aac19b9b5b5.md)
+ [REL 2 ネットワークトポロジをどのように計画しますか?](w2aac19b9b5b7.md)

# REL 1 サービスクォータと制約はどのように管理しますか?
<a name="w2aac19b9b5b5"></a>

クラウドベースのワークロードアーキテクチャには、サービスクォータ (サービスの制限とも呼ばれます) というものがあります。このようなクォータは、誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使用から保護することを目的として API 操作のリクエスト頻度を制限するために存在します。リソースにも制約があります。たとえば、光ファイバーケーブルのビットレートや、物理ディスクの記憶容量などです。 

**Topics**
+ [REL01-BP01 サービスクォータと制約を認識する](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 クォータをモニタリングおよび管理する](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 クォータ管理を自動化する](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する](rel_manage_service_limits_suff_buffer_limits.md)

# REL01-BP01 サービスクォータと制約を認識する
<a name="rel_manage_service_limits_aware_quotas_and_constraints"></a>

 あなたは、ワークロードアーキテクチャに対するデフォルトのクォータとクォータ引き上げリクエストを認識しています。さらに、ディスクやネットワークなど、どのリソースの制約が潜在的に大きな影響を与えるかを知っておきましょう。 

 Service Quotas は、100 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。クォータ値の検索に加えて、Service Quotas コンソールから、または AWS SDK 経由でクォータ増加をリクエスト、追跡することもできます。AWS Trusted Advisor には、あるサービスの一部の要素に関する使用状況とクォータを表示するサービスクォータチェックが用意されています。サービスごとのデフォルトのサービスクォータは、それぞれのサービスごとの AWS ドキュメントにも記載されています。例えば、次を参照してください。 [Amazon VPC クォータ](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)。スロットルされた API のレート制限は、API Gateway 内で使用量プランを変更することで設定できます。それぞれのサービス上の構成として設定される他の制限には、プロビジョンド IOPS、割り当てられた RDS ストレージ、EBS ボリューム割り当てなどがあります。Amazon Elastic Compute Cloud (Amazon EC2) には、インスタンス、Amazon Elastic Block Store (Amazon EBS)、および Elastic IP アドレスの制限を管理するのに役立つ独自のサービスの制限ダッシュボードがあります。サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例が発生した場合は、AWS サポート に連絡し、緩和策の有無についてお問い合わせください。 

 **一般的なアンチパターン:** 
+  使用される AWS のサービスに対するサービスクォータを考慮に入れることなく、ワークロードをデプロイする。 
+  AWS のサービスの設計上の制約を調査、対応することなく、ワークロードを設計する。 
+  必要なクォータを設定することなく、また AWS サポート に事前に連絡することなく、既知の既存のワークロードを置き換えるような、使用量の多いワークロードを導入すること。 
+  ワークロードへのトラフィックを促進するイベントを計画したが、必要なクォータを設定せず、事前に AWS サポート に連絡しない。 

 **このベストプラクティスを確立するメリット:** サービスクォータ、API スロットリング制限、および設計制約を認識することで、ワークロードの設計、実装、およびオペレーションでこれらを考慮することができます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  公開されているドキュメントと Service Quotas で AWS のサービスクォータを確認します 
  +  [AWS Service Quotas (旧称は「Liimits (制限)」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  デプロイコードを見て、ワークロードに必要なすべてのサービスを決定します。
+  AWS Config を使用して、AWS アカウント で使用するすべての AWS リソースを検索します。
  +  [AWS Config によってサポートされている AWS リソースタイプとリソース関係](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html) 
+  AWS CloudFormation を使用して、使用する AWS リソースを決めることもできます。AWS マネジメントコンソール で、または list-stack-resources CLI コマンドで作成されたリソースを確認します。テンプレート自体にデプロイされるように設定されたリソースも確認できます。
  +  [AWS マネジメントコンソール での AWS CloudFormation スタックデータとリソースの表示](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html) 
  +  [AWS CLI for CloudFormation: list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) 
+  適用されるサービスクォータを決定します。Trusted Advisor および Service Quotas を通じて、プログラムでアクセスできる情報を使用します。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「Liimits (制限)」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する
<a name="rel_manage_service_limits_limits_considered"></a>

 複数の AWS アカウント または AWS リージョン をご利用の場合は、必ず本番ワークロードを実行するすべての環境で適切なクォータをリクエストしてください。 

 サービスクォータの追跡はアカウントごとに行います。特に明記されていない限り、各クォータは AWS リージョン 固有です。テストと開発が妨げられないように、本番環境に加えて、該当するすべての非本番環境でもクォータを管理します。 

 **一般的なアンチパターン:** 
+  1 つの分離ゾーンでのリソース使用率の増加を許可し、他のゾーンにはキャパシティーを維持するメカニズムがない。 
+  分離ゾーン内のすべてのクォータを手動で設定する。 
+  デプロイが失われた場合に別のリージョンからのトラフィック増加に対応できるように、リージョン別に分離されたデプロイが適切なサイズとなっていない。 

 **このベストプラクティスを活用するメリット:** 分離ゾーンが使用できない場合に現在の負荷を処理できることを確認することで、フェイルオーバー中に発生するエラーの数を減らすことができ、顧客にサービス拒否を発生させないようにします。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  サービスの要件、レイテンシー、およびディザスタリカバリ (DR) 要件に基づいて、関連するアカウントとリージョンを選択します。
+  関連するすべてのアカウント、リージョン、アベイラビリティーゾーン全体のサービスクォータを特定します。制限の対象範囲はアカウントとリージョンです。 
+  [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する
<a name="rel_manage_service_limits_aware_fixed_limits"></a>

 サービスクォータと物理リソースには変更できないものもあることに注意し、これらが信頼性に影響を及ぼさないように設計します。 

 例としては、ネットワーク帯域幅、AWS Lambda ペイロードサイズ、API Gateway のスロットルバーストレート、Amazon Redshift クラスターへの同時ユーザー接続などがあります。 

 **一般的なアンチパターン:** 
+  バースト制限を利用しながらベンチマークをごく短期間実行するが、継続する期間にわたってそのキャパシティーでサービスが実行されることが予想される。 
+  ユーザーまたは顧客ごとに 1 つのサービスリソースを使用する設計を選択するが、この設計の制約 (スケーリング時にこの設計の失敗を引き起こすもの) があることを認識していない。 

 **このベストプラクティスを活用するメリット:** AWS のサービスの固定クォータと、接続の制約、IP アドレスの制約、サードパーティーのサービスの制約など、ワークロードの他の部分の制約を追跡することで、クォータに対する傾向を検出し、クォータを超える前にそのクォータに対応できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  固定されたサービスクォータと制約のほか、これらに関するアーキテクトを把握します。 
  +  [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスのチェック (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP04 クォータをモニタリングおよび管理する
<a name="rel_manage_service_limits_monitor_manage_limits"></a>

 予想される使用量を評価し、クォータを必要に応じて引き上げて、使用量を予定通り増やせるようにします。 

 サポートされているサービスの場合、CloudWatch アラームを設定して使用量をモニタリングし、クォータのしきい値に近づいていることのアラームを受けることで、クォータを管理できます。このアラームは、Service Quotas または Trusted Advisor からトリガーできます。CloudWatch Logs のメトリクスフィルターを使用して、ログのパターンを検索および抽出し、使用量がクォータのしきい値に近づいているかどうかを判断することもできます。 

 **一般的なアンチパターン:** 
+  Service Quotas に近づいている場合のアラートを設定するが、アラートへの対応方法に関するプロセスがない。 
+  Service Quotas でサポートされているサービスのアラームのみを設定し、他のサービスのモニタリングを行わない。 

 **このベストプラクティスを活用するメリット:** AWS のサービスクォータの自動追跡と、それらのクォータに対する使用率のモニタリングにより、クォータの限界に近づいていることを確認できます。また、このモニタリングデータを使用して、コストを節約するためにクォータを下げるタイミングを評価することもできます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  AWS で予想される使用量を評価し、リージョンごとのサービスクォータを適切に増やして、計画的な使用量の増加を可能にします。 
  +  現在のリソース消費 (バケットやインスタンスなど) を把握します。現在のリソース消費を収集するには、Amazon EC2 DescribeInstances API などのサービス API オペレーションを使用します。
  +  現在のクォータを把握する AWS Service Quotas、AWS Trusted Advisor、AWS のドキュメントを使用します。
    +  AWS Service Quotas を使用します。これは、100 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。
    +  Trusted Advisor のサービスの制限を使用して、現在のサービスの制限を決定します。 
    +  サポートされている場合は、サービス API オペレーションを使用して、現在のサービスクォータを決定します。
    +  リクエストしたクォータの増加とそれらのステータスを記録する クォータの増加が承認された後、クォータの変更を反映するように記録を更新します。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [サービスの制限に関する AWS Trusted Advisor ベストプラクティスのチェック](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html) 
+  [AWS Answers の AWS Limit Monitor](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
+  [Amazon CloudWatch を使用して Service Quotas をモニタリングする](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP05 クォータ管理を自動化する
<a name="rel_manage_service_limits_automated_monitor_limits"></a>

 しきい値に近づいたときに警告するツールを実装します。AWS Service Quotas API を使用すると、クォータの引き上げリクエストを自動化できます。 

 お使いの Configuration Management Database (CMDB) またはチケット発行システムを Service Quotas と統合すると、クォータの引き上げリクエストと現在のクォータに関する情報のトラッキングを自動化できます。AWS SDK のほかに、Service Quotas も AWS Command Line Interface (AWS CLI) を使用した自動化を提供しています。 

 **一般的なアンチパターン:** 
+  スプレッドシートでクォータと使用状況を追跡する。 
+  毎日、毎週、または毎月の使用状況に関するレポートを実行し、使用量とクォータを比較する。 

 **このベストプラクティスを活用するメリット:** AWS のサービスクォータの自動追跡と、そのクォータに対する使用量のモニタリングにより、クォータに近づいていることを確認できます。必要に応じてクォータの引き上げをリクエストできるように、オートメーションを設定できます。使用量の傾向が反対の方向にある場合は、(認証情報が漏えいした場合の) リスクの低下とコスト削減のメリットを実現するために、クォータの削減を検討することをお勧めします。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  自動モニタリングをセットアップする しきい値に近づいたときにアラートを発行するため、SDK を使用するツールを実装します。 
  +  Service Quotas を使用し、AWS Limit Monitor や AWS Marketplace からのサービスなど、自動クォータモニタリングソリューションでサービスを補強します。
    +  [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 
    +  [AWS でのクォータモニタリング - AWS ソリューション](https://aws.amazon.com/answers/account-management/limit-monitor/) 
  +  Amazon SNS および AWS Service Quotas API を使用して、クォータしきい値に基づいてトリガーされるレスポンスをセットアップします。
  +  自動化をテストします。
    +  制限のしきい値を設定します。
    +  AWS Config、デプロイパイプライン、Amazon EventBridge、またはサードパーティーからの変更イベントと統合します。
    +  応答をテストするために、人為的に低いクォータしきい値を設定します。
    +  通知に対して適切なアクションを取り、必要に応じて AWS サポート に問い合わせるトリガーをセットアップします。
    +  変更イベントを手動でトリガーします。
    +  ゲームデーを実行して、クォータ引き上げの変更プロセスをテストします。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: 設定管理を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management) 
+  [AWS Marketplace: 制限の追跡に役立つ CMDB 製品](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスのチェック (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [AWS でのクォータモニタリング - AWS ソリューション](https://aws.amazon.com/answers/account-management/limit-monitor/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [Service Quotas とは何ですか?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
<a name="rel_manage_service_limits_suff_buffer_limits"></a>

 リソースに障害が発生したときには、リソースが正常に終了されるまで、クォータにカウントされることがあります。エラーが生じたリソースが停止されるまで、エラーが生じたすべてのリソースと代替リソースの合計リソース数がクォータ内に収まるようにします。この開きを計算するときは、アベイラビリティーゾーンの不具合を考慮する必要があります。 

 **一般的なアンチパターン:** 
+  フェイルオーバーシナリオを考慮せずに、現在のニーズに基づいてサービスクォータを設定する。 

 **このベストプラクティスを活用するメリット:** イベントが可用性に影響する恐れがあるとき、クラウドでは、これらのイベントを緩和またはイベントから復旧するための戦略を実装できます。そのような戦略には、多くの場合、障害が発生したリソースに置き換わる追加リソースの作成が含まれます。クォータ戦略は、これらの追加リソースに対応する必要があります。 

 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  フェイルオーバーに対応するため、サービスクォータと最大使用量の間に十分なギャップがあることを確認します。 
  +  デプロイのパターン、可用性の要件、消費の増加を考慮して、サービスクォータを決定します。
  +  必要に応じてクォータの引き上げをリクエストします。クォータの引き上げリクエストの実行に必要な時間を計画します。
    +  信頼性の要件 (「9 の数」としても知られる) を決定します。 
    +  障害シナリオ (コンポーネント、アベイラビリティーゾーン、リージョンの損失など) を確立します。
    +  デプロイ手法 (例えば、Canary、ブルー/グリーン、レッド/ブラック、ローリングなど) を確立します。
    +  現在の制限に適切なバッファ (例えば、15%) を含めます。 
    +  消費の増加を計画します (例えば、消費の傾向をモニタリングする)。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: CMDB products that help track limits](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB) 
+  [AWS Service Quotas (旧称は「サービスの制限」)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 
+  [AWS Trusted Advisor ベストプラクティスチェックリスト (「サービスの制限」セクションを参照)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/) 
+  [Amazon EC2 サービスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 
+  [「What Is Service Quotas?」](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) 

 **関連動画:** 
+  [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo) 

# REL 2 ネットワークトポロジをどのように計画しますか?
<a name="w2aac19b9b5b7"></a>

多くの場合、ワークロードは複数の環境に存在します。このような環境には、複数のクラウド環境 (パブリックにアクセス可能なクラウド環境とプライベートの両方) と既存のデータセンターインフラストラクチャなどがあります。計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する必要があります。

**Topics**
+ [REL02-BP01 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 多対多メッシュよりもハブアンドスポークトポロジを優先する](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 接続されているすべてのプライベートアドレス空間において、重複しないプライベート IP アドレス範囲を指定する](rel_planning_network_topology_non_overlap_ip.md)

# REL02-BP01 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する
<a name="rel_planning_network_topology_ha_conn_users"></a>

 これらのエンドポイントとそれらへのルーティングは、可用性が高い必要があります。これを実現するには、可用性の高い DNS、コンテンツ配信ネットワーク (CDN)、API Gateway、ロードバランシング、またはリバースプロキシを使用します。 

 Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway、Elastic Load Balancing (ELB) はすべて、高可用性パブリックエンドポイントを提供します。また、ロードバランシングとプロキシ処理を行うために、AWS Marketplace のソフトウェアアプライアンスを評価することもできます。 

 ワークロードで提供されるサービスの消費者は、エンドユーザーであろうと他のサービスのユーザーであろうと、これらのサービスエンドポイントでリクエストを行います。高可用性のエンドポイントを提供できるように、いくつかの AWS リソースが利用できます。 

 Elastic Load Balancing は、アベイラビリティーゾーン間のロードバランシングを提供し、レイヤー 4 (TCP) またはレイヤー 7 (http/https) のルーティングを実施し、AWS WAF と統合します。また、AWS Auto Scaling との統合により、自己回復型のインフラストラクチャを構築し、トラフィックの増加を吸収しながら、トラフィックが減少したときにリソースを解放することができます。 

 Amazon Route 53 は、スケーラブルで可用性の高いドメインネームシステム (DNS) サービスであり、Amazon EC2 インスタンス、Elastic Load Balancing ロードバランサー、Amazon S3 バケットなど、AWS で実行するインフラストラクチャとユーザーリクエストを接続します。これはユーザーを AWS の外部のインフラストラクチャにルーティングするためにも使用できます。 

 AWS Global Accelerator は、AWS グローバルネットワーク上で最適なエンドポイントにトラフィックを誘導するために使用できるネットワークレイヤーサービスです。 

 分散型サービス拒否 (DDoS) 攻撃は、正当なトラフィックをシャットアウトして、ユーザーの可用性の低下を招きかねません。AWS Shield は、ワークロードにおける AWS サービスエンドポイントに対して、追加コストなしでこれらの攻撃に対する自動保護を提供します。これらの機能は、APN Partners や AWS Marketplace の仮想アプライアンスを使って、ニーズに合わせて拡張することができます。 

 **一般的なアンチパターン:** 
+  インスタンスまたはコンテナでパブリックインターネットアドレスを使用し、DNS 経由でそれらのアドレスへの接続を管理する。 
+  サービスの検索のために、ドメイン名ではなく、インターネットプロトコルアドレスを使用する。 
+  大規模な地理的領域にコンテンツ (ウェブページ、静的アセット、メディアファイル) を提供し、コンテンツ配信ネットワークを使用しない。 

 **このベストプラクティスを確立するメリット:** ワークロードに可用性の高いサービスを実装することで、ユーザーがワークロードを利用できるようになることがわかります。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードのユーザーのために高可用性接続を確保する Amazon Route 53、AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway、Elastic Load Balancing (ELB) はすべて、高可用性パブリックエンドポイントを提供します。また、ロードバランシングとプロキシ処理を行うために、AWS Marketplace のソフトウェアアプライアンスを評価することもできます。 
+  ユーザーへの高可用性接続を確保します。 
+  高可用性 DNS を使用して、アプリケーションエンドポイントのドメイン名を管理していることを確認します。 
  +  ユーザーがインターネット経由でアプリケーションにアクセスする場合は、サービス API オペレーションを使用して、インターネットゲートウェイの正しい使用状況を確認します。また、アプリケーションエンドポイントをホストするサブネットのルートテーブルのエントリが正しいことを確認します。
    +  [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html) 
    +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
+  アプリケーションの前に高可用性リバースプロキシまたはロードバランサーを使用していることを確認します。 
  +  ユーザーがオンプレミス環境を通じてアプリケーションにアクセスする場合は、AWS とオンプレミス環境の間の接続が高可用性であることを確認します。
  +  Route 53 を使用してドメイン名を管理します。
    +  [Amazon Route 53 とは?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
  +  要件を満たすサードパーティーの DNS プロバイダーを使用します。
  +  Elastic Load Balancing を使用します。
    +  [Elastic Load Balancing とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
  +  要件を満たす AWS Marketplace アプライアンスを使用します。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [Direct Connect Resiliency Toolkit を使用して開始する](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [AWS Global Accelerator とは?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [「Amazon CloudFront とは」](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html) 
+  [Amazon Route 53 とは?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 
+  [Elastic Load Balancing とは?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) 
+  [Direct Connect ゲートウェイの操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP02 クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする
<a name="rel_planning_network_topology_ha_conn_private_networks"></a>

 個別にデプロイされたプライベートネットワーク間で複数の AWS Direct Connect 接続または VPN トンネルを使用します。高可用性のために複数の Direct Connect ロケーションを使用します。複数の AWS リージョン を使用している場合は、少なくとも 2 つのリージョンで冗長性を確保してください。VPN を終端する AWS Marketplace アプライアンスを評価したい場合があります。AWS Marketplace アプライアンスを使用する場合は、さまざまなアベイラビリティーゾーンで高可用性を実現するために冗長インスタンスをデプロイします。 

 AWS Direct Connect は、オンプレミス環境から AWS への専用ネットワーク接続を簡単に確立できるようにするクラウドサービスです。Direct Connect ゲートウェイを使用すると、オンプレミスのデータセンターを複数の AWS リージョン にまたがる複数の AWS VPC に接続できます。 

 この冗長性は、接続の回復力に影響を与える可能性のある障害に対処します。 
+  トポロジにおける障害に対する弾力性を高めるにはどうすればよいでしょうか? 
+  間違った設定を行い、接続が停止したらどうなりますか? 
+  トラフィックとサービス利用量が予想外に増加した場合に対応できますか? 
+  分散型サービス拒否 (DDoS) 攻撃の影響を緩和できますか? 

 VPC をVPN 経由でオンプレミスのデータセンターに接続するときは、ベンダーとそのアプライアンスを実行する際に必要となるインスタンスサイズを選択する際に、弾力性と必要とする帯域幅の要件を考慮する必要があります。使用するVPN アプライアンスがその実装において十分な弾力性がない場合、2 つ目のアプライアンスを通じて冗長接続を設定する必要があります。すべてのシナリオにおいて、許容可能な復旧時間を定義し、その要件を満たすかどうかをテストする必要があります。 

 Direct Connect 接続を使用して VPC をデータセンターに接続することにし、この接続を高可用性にする必要がある場合は、各データセンターから冗長化した Direct Connect 接続を使用します。冗長接続では、最初の接続とは異なる場所から 2 番目の Direct Connect 接続を使用する必要があります。複数のデータセンターがある場合は、接続が異なる場所で終端するようにしてください。このセットアップに役立てるため [Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) を使用します。 

 Site-to-Site VPN を使用してインターネット経由で VPN にフェイルオーバーする場合、VPN トンネルごとに最大 1.25 Gbps のスループットはサポートしますが、同じ VGW 上で終端する AWS マネージド VPN トンネルが複数ある場合、アウトバウンドトラフィック用の Equal Cost Multi Path (ECMP) はサポートしないということを理解しておくことが重要です。フェイルオーバー中に 1 Gbps 未満の速度を許容できないのであれば、Direct Connect 接続のバックアップとして AWS マネージド VPN を使用することはお勧めしません。 

 VPC エンドポイントを使用して、VPC を、パブリックインターネットを経由せずに、サポートされている AWS のサービスおよび AWS PrivateLink が提供する VPC エンドポイントサービスにプライベートに接続することもできます。エンドポイントは仮想デバイスです。これは、水平にスケーリングされ、冗長性と可用性に優れた VPC コンポーネントです。仮想デバイスにより、ネットワークトラフィックに可用性のリスクや帯域幅の制約を課すことなく、VPC 内のインスタンスとサービス間の通信が可能になります。 

 **一般的なアンチパターン:** 
+  オンサイトネットワークと AWS の間に接続プロバイダを 1 つだけ持つ。 
+  AWS Direct Connect 接続の接続機能を消費するが、接続は 1 つのみである。 
+  VPN 接続用のパスは 1 つだけである。 

 **このベストプラクティスを活用するメリット:** クラウド環境と企業/オンプレミス環境の間に冗長接続を実装することで、2 つの環境間で依存するサービスが確実に通信できるようになります。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  AWS とオンプレミス環境との間に高可用性接続を確保します。個別にデプロイされたプライベートネットワーク間で複数の AWS Direct Connect 接続または VPN トンネルを使用します。高可用性のために複数の Direct Connect ロケーションを使用します。複数の AWS リージョン を使用している場合は、少なくとも 2 つのリージョンで冗長性を確保してください。VPN を終端する AWS Marketplace アプライアンスを評価したい場合があります。AWS Marketplace アプライアンスを使用する場合は、さまざまなアベイラビリティーゾーンで高可用性を実現するために冗長インスタンスをデプロイします。 
  +  オンプレミス環境への冗長接続を確保する可用性ニーズを達成するには、複数の AWS リージョン への冗長接続が必要な場合があります。
    +  [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
    +  [冗長な Site-to-Site VPN 接続を使用してフェイルオーバーを提供する](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
      +  サービス API オペレーションを使用して Direct Connect 回線の適切な使用方法を明確にします。
        +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
        +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
        +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
        +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
        +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
        +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
        +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
      +  Direct Connect 接続が 1 つだけあるか、1 つもない場合は、仮想プライベートゲートウェイへの冗長 VPN トンネルを設定します。
        +  [AWS Site-to-Site VPN とは?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
  +  現在の接続をキャプチャします (例えば、Direct Connect、仮想プライベートゲートウェイ、AWS Marketplace アプライアンス)。
    +  サービス API オペレーションを使用して、Direct Connect 接続の設定をクエリします。
      +  [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html) 
      +  [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html) 
      +  [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html) 
      +  [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll) 
      +  [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html) 
      +  [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html) 
      +  [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html) 
    +  サービス API オペレーションを使用して、ルートテーブルが使用している仮想プライベートゲートウェイを収集します。
      +  [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html) 
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 
    +  サービス API オペレーションを使用してルートテーブルが使用している AWS Marketplace アプリケーションを収集します。
      +  [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/) 
+  [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud 接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [冗長な Site-to-Site VPN 接続を使用してフェイルオーバーを提供する](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html) 
+  [Direct Connect Resiliency Toolkit を使用して開始する](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) 
+  [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
+  [AWS Site-to-Site VPN とは?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html) 
+  [Direct Connect ゲートウェイの操作](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う
<a name="rel_planning_network_topology_ip_subnet_allocation"></a>

 Amazon VPC IP アドレスの範囲は、将来の拡張や アベイラビリティゾーンをまたがるサブネットへの IP アドレスの割り当てを考慮し て、ワークロードの要件に対応するのに十分な大きさでなければなりません。これには、ロードバランサー、EC2 インスタンス、コンテナーベースのアプリケーションが含まれます。 

 ネットワークトポロジの計画は、IP アドレス空間の定義から始めます。プライベート IP アドレス範囲 (RFC 1918 ガイドラインに準拠) は、VPC ごとに割り当てる必要があります。このプロセスの一環として、次の要件を満たすようにします。 
+  リージョンごとに複数の VPC 用の IP アドレス空間を割り当てる。 
+  VPC 内で、複数のアベイラビリティーゾーンにまたがる複数のサブネット用の空間を割り当てます。 
+  将来の拡張のために、常に未使用の CIDR ブロック空間を VPC 内に残しておきます。 
+  機械学習用のスポットフリート、Amazon EMR クラスター、Amazon Redshift クラスターなど、使用する可能性のある EC2 インスタンスの一時的なフリートのニーズを満たす IP アドレス空間があることを確認します。 
+  各サブネット CIDR ブロックの最初の 4 つの IP アドレスと最後の IP アドレスはリザーブドのため、お客様はご使用いただけません。 
+  大きな VPC CIDR ブロックのデプロイを計画する必要があります。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。サブネット IPv4 CIDR は変更できませんが、IPv6 CIDR は変更できます。最大規模の VPC (/16) をデプロイする場合、65,000 を超える IP アドレスが割り当てられることになります。ベース 10.x.x.x IP アドレス空間だけで、そのような VPC を 255 個プロビジョニングできます。したがって、VPC の管理を容易にするためには、小さすぎて失敗するよりも、大きすぎて失敗するほうが良いでしょう。 

 **一般的なアンチパターン:** 
+  小さな VPC を作成する。 
+  小さなサブネットを作成するため、増大に伴ってサブネットを設定に追加する必要がある。 
+  Elastic Load Balancing が使用できる IP アドレスの数を不正確に見積もる。 
+  多数の高トラフィックロードバランサーを同じサブネットにデプロイする。 

 **このベストプラクティスを確立するメリット:** これにより、ワークロードの増大に対応し、スケールアップ時に可用性を引き続き提供できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  拡張、コンプライアンス、他のネットワークとの統合に対応できるようにネットワークを計画します。適切に計画しないと、拡張の見積もりが甘くなったり、規制コンプライアンスが変わったり、取得やプライベートネットワーク接続の設定が難しくなったりする場合があります。 
  +  サービス要件、レイテンシー、規制、およびディザスタリカバリ (DR) 要件に基づいて、関連する AWS アカウント とリージョンを選択します。
  +  リージョン別 VPC デプロイのニーズを明確にします。
  +  VPC のサイズを明確にします。
    +  マルチ VPC 接続をデプロイするかどうかを判断します。
      +  [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 
      +  [単一リージョンの複数 VPC 接続](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
    +  規制要件のためネットワークの分離が必要かどうかを判断します。 
    +  VPC を可能な限り大きくします。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。ただし、この場合、アドレス範囲が断片化される可能性があります。
    +  VPC を可能な限り大きくします。VPC に割り当てられた最初の VPC CIDR ブロックは変更または削除することはできませんが、重複していない CIDR ブロックを VPC に追加することはできます。ただし、この場合、アドレス範囲が断片化される可能性があります。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [単一リージョンの複数 VPC 接続](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/) 
+  [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP04 多対多メッシュよりもハブアンドスポークトポロジを優先する
<a name="rel_planning_network_topology_prefer_hub_and_spoke"></a>

 3 つ以上のネットワークアドレス空間 (VPC およびオンプレミスネットワークなど) が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。 

 そのようなネットワークが 2 つしかない場合は、それらを互いに接続するだけで済みますが、ネットワークの数が増えるにつれて、そのようなメッシュ接続の複雑さは維持できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。 

![\[AWS Transit Gateway を使用していない場合の図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)


![\[AWS Transit Gateway を使用した場合の図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)


 **一般的なアンチパターン:** 
+  VPC ピア接続を使用して 3 つ以上の VPC を接続する。 
+  各 VPC に対して複数の BGP セッションを確立し、複数の AWS リージョン における仮想プライベートクラウド (VPC) にまたがる接続を確立する。 

 **このベストプラクティスを確立するメリット:** ネットワークの数が増えるにつれて、このようなメッシュ接続の複雑さは受容できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  多対多メッシュよりもハブアンドスポークトポロジを優先します。3 つ以上のネットワークアドレス空間 (VPC およびオンプレミスネットワークなど) が VPC ピア接続、AWS Direct Connect、または VPN 経由で接続されている場合は、AWS Transit Gateway が提供するようなハブアンドスポークモデルを使用します。 
  +  そのような 2 つのネットワークのみについては、それらを互いに接続するだけで済みますが、ネットワークの数が増えるにつれて、そのようなメッシュ接続の複雑さは受容できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。
    +  [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [VPC Endpoints and VPC Endpoint Services (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) 
+  [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [Transit Gateway とは?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) 

# REL02-BP05 接続されているすべてのプライベートアドレス空間において、重複しないプライベート IP アドレス範囲を指定する
<a name="rel_planning_network_topology_non_overlap_ip"></a>

 各 VPC の IP アドレス範囲が、ピア接続時または VPN 経由での接続時に重複しないようにする必要があります。同様に、VPC とオンプレミス環境の間、または使用する他のクラウドプロバイダーとの IP アドレスの競合を回避する必要があります。また、必要に応じてプライベート IP アドレス範囲を割り当てる方法を用意する必要もあります。 

 これには、IP アドレス管理 (IPAM) システムが役立ちます。複数の IPAM は AWS Marketplace から入手できます。 

 **一般的なアンチパターン:** 
+  オンプレミスまたは社内ネットワークにあるのと同じ IP 範囲を VPC で使用する。 
+  ワークロードのデプロイに使用されている VPC の IP 範囲を追跡しない。 

 **このベストプラクティスを確立するメリット:** ネットワークを積極的に計画することで、相互接続されたネットワークで同じ IP アドレスが複数出現しないようにできます。これにより、異なるアプリケーションを使用しているワークロードの一部でルーティングの問題が発生するのを防ぐことができます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  CIDR の使用をモニタリングし、管理します。AWS での予想される使用量を評価して、CIDR の範囲を既存の VPC に追加し、計画的な使用量の増加を可能にする VPC を作成します。 
  +  現在の CIDR 消費量 (VPC、サブネットなど) を把握します。 
    +  サービス API オペレーションを使用して、現在の CIDR 消費量を収集します。
  +  現在のサブネットの使用量を把握します。
    +  サービス API オペレーションを使用して、各リージョンの VPC ごとにサブネットを収集します。
      +  [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html) 
    +  現在の使用量を記録します。
    +  重複している IP 範囲を作成したかどうか確認します。
    +  予備容量を計算します。
    +  重複している IP 範囲を特定します。重複する範囲に接続する必要がある場合は、新しいアドレス範囲に移行するか、AWS Marketplace の Network and Port Translation (NAT) アプライアンスを使用できます。

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network) 
+  [ネットワークインフラストラクチャ向け AWS Marketplace](https://aws.amazon.com/marketplace/b/2649366011) 
+  [Amazon Virtual Private Cloud の接続オプションホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) 
+  [Multiple data center HA network connectivity](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/) 
+  [「Amazon VPC とは?」](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) 
+  [IPAM とは](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303) (高度な VPC 設計と Amazon VPC の新機能)](https://youtu.be/fnxXNZdf6ew) 
+  [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1) (多くの VPC に対応した AWS Transit Gateway のリファレンスアーキテクチャ)](https://youtu.be/9Nikqn_02Oc) 