# 基盤
**Topics**
+ [REL 1.Service Quotas と制約はどのように管理しますか?](rel-01.md)
+ [REL 2.ネットワークトポロジをどのように計画しますか?](rel-02.md)
# REL 1.Service Quotas と制約はどのように管理しますか?
クラウドベースのワークロードアーキテクチャには、Service Quotas (サービスの制限とも呼ばれます) というものがあります。このようなクォータは、誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使用から保護することを目的として 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 サービスクォータと制約を認識する
デフォルトのクォータに注意して、ワークロードアーキテクチャに対するクォータ引き上げリクエストを管理しましょう。ディスクやネットワークなど、どのクラウドリソースの制約が潜在的に大きな影響を与えるかを知っておきましょう。
**期待される成果:** 主要メトリクスのモニタリング、インフラストラクチャのレビュー、自動修復手順に適切なガイドラインを設けて、サービスの機能低下や停止につながるサービスのクォーターや制約に達していないことを検証することで、AWS アカウントのサービスの機能低下や停止を防止できます。
**一般的なアンチパターン:**
+ 使用しているサービスのハードまたはソフト上のクォータや制限を理解せずにワークロードをデプロイする。
+ 必要なクォータの分析と再設定、またはサポートへの事前連絡をせずに、代替ワークロードをデプロイする。
+ クラウドサービスには制限がなく、料金、制限、回数、数量を気にせずにサービスを使用できると考えている。
+ クォータは自動的に増加すると考えている。
+ クォータリクエストのプロセスやスケジュールを知らない。
+ クラウドサービスのデフォルトのクォータが、リージョン間で比較する各サービスで同一だと考えている。
+ サービスの制約は破ることが可能で、システムによりリソースの制約を超えて自動スケールまたは制限の増加が追加されると考えている。
+ リソースの使用率にストレスをかけるためにピーク時トラフィックでアプリケーションをテストしていない。
+ 必要なリソースサイズを分析せずにリソースをプロビジョニングする。
+ 実際に必要な分または予想されるピークを遥かに超えるリソースタイプを選択することでキャパシティを過剰プロビジョニングする。
+ 新規顧客イベントや新技術のデプロイに先駆けて、新しいレベルのトラフィックのキャパシティ要件を評価していない。
**このベストプラクティスを活用するメリット:** サービスクォータとリソースの制約をモニタリングおよび自動管理すると、エラーを予防できます。ベストプラクティスに従っていないと、顧客のサービスにおけるトラフィックパターンの変化により、停止または機能低下が起こる可能性があります。これらの値をすべてのリージョンとすべてのアカウントでモニタリングし管理することで、有害なイベントや計画外のイベントにおける、アプリケーションの回復力が向上します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
Service Quotas は、250 を超える 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 のレート制限など、一部のサービス上の制限は、Amazon API Gateway 内で使用量プランを変更することで設定できます。それぞれのサービス上の構成として設定される一部の制限には、プロビジョンド IOPS、割り当てられた Amazon RDS ストレージ、Amazon EBS ボリューム割り当てなどがあります。Amazon Elastic Compute Cloud には、インスタンス、Amazon Elastic Block Store、および Elastic IP アドレスの制限を管理するのに役立つ独自のサービスの制限ダッシュボードがあります。サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例が発生した場合は、サポート に連絡し、緩和策の有無についてお問い合わせください。
サービスクォータはその性質上、リージョン固有である場合も、グローバルである場合もあります。クォータに達している AWS サービスを使用すると、通常の使用で予想どおりに動作しないことや、サービスの停止や機能低下を招くことがあります。例えば、あるサービスクォータではリージョンで使用する DL Amazon EC2 数を制限しており、Auto Scaling グループ (ASG) を使用したトラフィックスケーリングイベント中にその制限に達する可能性があります。
各アカウントのサービスクォータについて、使用量を定期的に評価し、そのアカウントにおける適切なサービス制限を判断する必要があります。このようなサービスクォータは、意図せず必要以上のリソースをプロビジョニングすることを防止する運用上のガードレールとして存在しています。また、API オペレーションにおけるリクエスト率を制限し、不正使用からサービスを保護する役目も持っています。
サービスの制約は、サービスクォータとは異なります。サービスの制約は、リソースタイプごとに決まっている特定のリソースの制限を表します。ストレージキャパシティ (例: gp2 のサイズ制限は 1 GB～16 TB) だったりディスクスループット (10,0000 iops) だったりします。制限に達する可能性のある使用量について、リソースタイプの制約を監督し定期的に評価することが不可欠です。予期せず制約に達した場合、アカウントのアプリケーションまたはサービスが機能低下または停止する恐れがあります。
サービスクォータがアプリケーションのパフォーマンスに影響を及ぼし、ニーズに合わせて調整できないような事例がある場合は、サポート に連絡し、緩和策の有無についてお問い合わせください。修正されたクォータの調整について詳しくは、[REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する](rel_manage_service_limits_aware_fixed_limits.md) を参照してください。
Service Quotas をモニタリングおよび管理できる AWS のサービスやツールが多数用意されています。これらのサービスやツールは、クォータレベルの自動または手動チェックの提供に活用するものです。
+ AWS Trusted Advisor は、いくつかのサービスの一部の側面に対する利用状況とクォータを表示する、サービスクォータチェックを提供しています。クォータに迫っているサービスの特定に役立ちます。
+ AWS マネジメントコンソールでは、サービスのクォータ値の表示、管理、新しいクォータのリクエスト、クォータリクエストのステータスのモニタリング、クォータの履歴の表示を行う手段を提供しています。
+ AWS CLI および CDK は、サービスクォータのレベルと使用量を自動で管理およびモニタリングする、プログラムによる手段を提供します。
**実装手順**
Service Quotas の場合:
+ [AWS Service Quotas をレビューします。 ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ 既存のサービスクォータを把握し、使用されているサービス (IAM Access Analyzer など) を判断します。サービスクォータで制御されている AWS のサービスは約 250 あります。次に、各アカウントとリージョンで使用されている可能性のある特定のサービスクォータ名を判断します。リージョンごとに約 3,000 のサービスクォータ名があります。
+ このクォータ分析を AWS Config で強化して、AWS アカウントで使用されているすべての [AWS リソース](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)を見つけます。
+ [AWS CloudFormation データ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)を使用して、使用されている AWS リソースを判断します。AWS マネジメントコンソールまたは [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html) AWS CLI コマンドを使用して作成されたリソースを見つけます。テンプレート自体にデプロイされるように設定されたリソースも確認できます。
+ デプロイコードを見て、ワークロードに必要なすべてのサービスを決定します。
+ 適用されるサービスクォータを決定します。Trusted Advisor および Service Quotas を使用してプログラムでアクセスできる情報を使用します。
+ サービスクォータが制限に近づいたか達した場合にアラートを発して知らせる自動モニタリング手段を作成します ([REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する](rel_manage_service_limits_limits_considered.md) および [REL01-BP04 クォータをモニタリングおよび管理する](rel_manage_service_limits_monitor_manage_limits.md) を参照)。
+ 同一アカウント内のあるリージョンでサービスクォータが変更されたが他のリージョンでは変更されていない場合を確認する、自動またはプログラムによる手段を作成します ([REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する](rel_manage_service_limits_limits_considered.md) および [REL01-BP04 クォータをモニタリングおよび管理する](rel_manage_service_limits_monitor_manage_limits.md) を参照)。
+ アプリケーションログやメトリクスのスキャンを自動化して、クォータまたはサービス制約のエラーが発生しているか判断します。エラーが発生している場合は、モニタリングシステムにアラートを送信します。
+ 特定のサービスでクォータの引き上げが必要であると判断された場合に、クォータで必要な変更を計算するエンジニアリング手順を作成します ([REL01-BP05 クォータ管理を自動化する](rel_manage_service_limits_automated_monitor_limits.md) を参照)。
+ サービスクォータの変更をリクエストするプロビジョニングおよび承認ワークフローを作成します。これには、リクエストが拒否または一部承認された場合の例外ワークフローを含めます。
+ 本稼働環境またはロード済み環境にロールアウトする前に、新しい AWS サービスをプロビジョニングして使用するにあたって、サービスクォータをレビューするエンジニアリング手段を作成します (例: ロードテストアカウント)。
サービス制約の場合:
+ 読み取りがリソースの制約に近づいているリソースについてアラートを発報するモニタリングおよびメトリクス手段を作成します。必要に応じて CloudWatch を活用して、メトリクスまたはログをモニタリングします。
+ 制約のある各リソースについて、アプリケーションまたはシステムにとって有意なアラートのしきい値を設定します。
+ 制約が使用量に近い場合、リソースタイプを変更するワークフローまたはインフラストラクチャ管理手順を作成します。このワークフローには、ベストプラクティスとして負荷テストを含め、新しいタイプが新しい制約のある適切なリソースタイプであることを検証します。
+ 既存の手順やプロセスを使用して、特定したリソースを推奨の新しいリソースタイプに移行します。
## リソース
**関連するベストプラクティス:**
+ [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)
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
**関連するドキュメント:**
+ [AWS Well Architected フレームワークの信頼性の柱: 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [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)
+ [クォータの引き上げのリクエスト方法](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Service Quotas ユーザーガイド](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS のクォータモニター](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)(AWS の障害分離境界)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)(冗長性を備えた可用性)
+ [ データのための AWS](https://aws.amazon.com/data/)
+ [継続的インテグレーションとは](https://aws.amazon.com/devops/continuous-integration/)
+ [継続的デリバリーとは](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN パートナー: 設定管理を支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)(AWS のテナント別アカウント SaaS 環境でアカウントのライフサイクルを管理する)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)(ワークロードの API スロットリングの管理とモニタリング)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)(AWS Organizations で AWS Trusted Advisor の推奨事項を大規模に表示する)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)(AWS Control Tower でサービス制限の緩和とエンタープライズサポートを自動化する)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)(Service Quotas を使用して AWS のサービスのクォータを表示および管理する)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)(AWS IAM のクォータのデモ)
**関連ツール:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する
複数のアカウントまたはリージョンをご利用の場合は、本番ワークロードを実行するすべての環境で適切なクォータをリクエストしてください。
**期待される成果:** 複数のアカウントまたはリージョンにまたがる設定、またはゾーン、リージョン、アカウントのフェイルオーバーを使用したレジリエンス設計になっている設定において、サービスクォータの枯渇によってサービスやアプリケーションが影響を受けないようにします。
**一般的なアンチパターン:**
+ 1 つの分離リージョンでのリソース使用量の増加を許可するが、他のリージョンではキャパシティーを維持するメカニズムがない。
+ 分離リージョン内のすべてのクォータを手動で設定する。
+ 主要ではないリージョンの能力が低下している際に、将来のクォータの必要性について、回復力のあるアーキテクチャ (アクティブやパッシブなど) の影響を考慮していない。
+ ワークロードが実行されているすべてのリージョンやアカウントにおいて、クォータを定期的に評価し、必要な変更を行っていない。
+ 複数のリージョンやアカウントにまたがって緩和をリクエストする際に、[クォータリクエストテンプレート](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html)を活用していない。
+ クォータの緩和は、コンピューティング予約リクエストのように、コストに影響があるという誤った考えのもと、サービスクォータを更新していない。
**このベストプラクティスを活用するメリット:** リージョンでのサービスが利用不可になった際に、セカンダリリージョンやアカウントで現在の負荷を処理できることを検証します。これにより、リージョンを利用できない場合に発生するエラー数や機能低下のレベルを削減できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
サービスクォータの追跡はアカウントごとに行います。特に明記されていない限り、各クォータは AWS リージョン 固有です。テストと開発が妨げられないように、本番環境に加えて、該当するすべての非本番環境でもクォータを管理します。高レベルの回復性を維持するには、サービスクォータを継続的に評価する必要があります (自動または手動で)。
*アクティブ/アクティブ*、*アクティブ/パッシブ - ホット*、*アクティブ/パッシブ - コールド*、*アクティブ/パッシブ - パイロットライト*の各アプローチを使用した設計の実装により、複数のリージョンにまたがるワークロードが増えると、すべてのリージョンおよびアカウントのクォータレベルを把握することが不可欠になってきます。サービスクォータが正しく設定されている場合、過去のトラフィックパターンが常に適した指標になるとは限りません。
同じくらい重要なのが、サービスクォータ名の制限が各リージョンで常に同じとは限らないことです。あるリージョンでは値が 5 であり、別のリージョンでは値が 10 であることもありえます。負荷時の一貫した回復力を提要するために、このようなクォータの管理は、すべての同じサービス、アカウント、リージョンを網羅する必要があります。
異なるリージョン (アクティブリージョンまたはパッシブリージョン) 間の全てのサービスクォータの差異を調整し、これらの差異を継続的に調整するプロセスを作成します。パッシブリージョンのフェイルオーバーのテスト計画は、ピーク時のアクティブキャパシティまでスケールすることはめったにありません。つまり、ゲームデーや机上演習では、リージョン間のサービスクォータの差異を見つけられない場合があり、したがって適切な制限を維持できない場合があります。
*サービスクォータのドリフト*とは、特定の名前のクォータにおけるサービスクォータの制限が、すべてのリージョンではなく、1 つのリージョンで変更される状況であり、追跡と評価が非常に重要になります。トラフィックを伴う、またはトラフィックを伴う可能性があるリージョンでのクォータの変更を、考慮する必要があります。
+ サービスの要件、レイテンシー、およびディザスタリカバリ (DR) 要件に基づいて、関連するアカウントとリージョンを選択します。
+ 関連するすべてのアカウント、リージョン、アベイラビリティーゾーン全体のサービスクォータを特定します。制限の対象範囲はアカウントとリージョンです。これらの値を比較して差異を把握する必要があります。
**実装手順**
+ 使用量のリスクレベルを超えている可能性がある Service Quotas の値をレビューします。AWS Trusted Advisor は 80% および 90% のしきい値で違反を警告します。
+ パッシブリージョンのサービスクォータの値をレビューします (アクティブ/パッシブ設計の場合)。プライマリリージョンで障害があった場合に、負荷が正常にセカンダリリージョンで実行されることを検証します。
+ サービスクォータのドリフトが同一アカウント内のリージョン間で発生し、それに伴って制限が変更された場合の評価を自動化します。
+ お客様の組織単位 (OU) がサポートされている方法で構成されている場合、サービスクォータテンプレートを更新して、クォータの変更を反映し、複数のリージョンやアカウントに適用する必要があります。
+ テンプレートを作成して、リージョンをクォータの変更に関連付けます。
+ 既存のすべてのサービスクォータテンプレートをレビューして、変更が必要かどうかを確認します (リージョン、制限、アカウント)。
## リソース
**関連するベストプラクティス:**
+ [REL01-BP01 サービスクォータと制約を認識する](rel_manage_service_limits_aware_quotas_and_constraints.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)
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
**関連するドキュメント:**
+ [AWS Well Architected フレームワークの信頼性の柱: 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [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)
+ [クォータの引き上げのリクエスト方法](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Service Quotas ユーザーガイド](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS のクォータモニター](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)(AWS の障害分離境界)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)(冗長性を備えた可用性)
+ [ データのための AWS](https://aws.amazon.com/data/)
+ [継続的インテグレーションとは](https://aws.amazon.com/devops/continuous-integration/)
+ [継続的デリバリーとは](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN パートナー: 設定管理を支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)(AWS のテナント別アカウント SaaS 環境でアカウントのライフサイクルを管理する)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)(ワークロードの API スロットリングの管理とモニタリング)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)(AWS Organizations で AWS Trusted Advisor の推奨事項を大規模に表示する)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)(AWS Control Tower でサービス制限の緩和とエンタープライズサポートを自動化する)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)(Service Quotas を使用して AWS のサービスのクォータを表示および管理する)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)(AWS IAM のクォータのデモ)
**関連サービス:**
+ [ Amazon CodeGuru Reviewer ](https://aws.amazon.com/codeguru/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP03 アーキテクチャを通じて、固定サービスクォータと制約に対応する
サービスクォータ、サービスの制約、物理リソースの制限には変更できないものもあることに注意します。このような制限が信頼性に影響を及ぼさないように、アプリケーションとサービスのアーキテクチャを設計します。
例えば、ネットワーク帯域幅、サーバーレス関数呼び出しのペイロードサイズ、API Gateway のスロットルバーストレート、データベースへの同時ユーザー接続数などは変更できません。
**期待される成果:** アプリケーションやサービスは、通常のトラフィック状況および高トラフィック状況で期待されるとおりに動作します。アプリケーションやサービスは、リソースの固定制約またはサービスクォータの制限内で機能するように設計されています。
**一般的なアンチパターン:**
+ 単一のサービスリソースを使用する設計を選択し、スケーリング時に障害が発生する原因となる設計上の制約があることを認識していない。
+ テスト中にサービスの固定クォータに到達してしまう非現実的なベンチマークを採用している。(例: バースト制限を利用しながら長時間テストを実行する)
+ 固定サービスクォータを超えてもスケーリングしたり変更したりできない設計を選択する。(例: 256KB のペイロードサイズの SQS)
+ 高トラフィックイベント中に危険にさらされる可能性があるサービスクォータのしきい値をモニタリングしたり警告したりするために、オブザーバビリティが設計および実装されていない。
**このベストプラクティスを活用するメリット:** 予測されるあらゆるサービス負荷レベルで、アプリケーションが中断や低下することなく実行されることを確認できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
ソフトサービスクォータ、つまりより高い容量ユニットに置き換えられるリソースとは異なり、AWS サービスの固定クォータは変更できません。つまり、アプリケーションの設計で使用する場合、このようなタイプのすべての AWS サービスの容量のハード制限を評価する必要があります。
ハード制限は Service Quotas コンソールに表示されます。列に `ADJUSTABLE = No`と表示されていれば、そのサービスにはハード制限があります。ハード制限は、一部のリソース設定ページにも表示されます。例えば、Lambda には調整できない特定のハード制限があります。
例としては、Lambda 関数で実行する Python アプリケーションを設計する場合、Lambda が 15 分以上実行される可能性があるかを判断するためにアプリケーションを評価する必要があります。コードがこのサービスクォータ制限を超過して実行される可能性がある場合は、代替テクノロジーや設計を検討する必要があります。本番環境へのデプロイ後にこの制限に達すると、修正されるまでアプリケーションの機能が低下し、中断することになります。ソフトクォータとは異なり、このような制限は、重大度 1 の緊急事態が発生した場合でも、変更できません。
アプリケーションがテスト環境にデプロイされたら、ハード制限に到達できるかどうかを確認する戦略を行使する必要があります。ストレステスト、負荷テスト、カオステストは、導入テスト計画の一環とする必要があります。
**実装手順**
+ 使用できる AWS サービスの完全なリストをアプリケーションの設計段階で確認します。
+ これらすべてのサービスについて、ソフトクォータ制限とハードクォータ制限を確認します。すべての制限が Service Quotas コンソールに表示されているとは限りません。サービスによっては、[このような制限について、別の場所で説明されています](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)。
+ アプリケーションを設計する際は、ビジネス上の成果、ユースケース、依存するシステム、可用性目標、ディザスタリカバリオブジェクトなど、ワークロードのビジネスとテクノロジーの推進要因を確認します。ビジネスとテクノロジーの推進要因に従って、ワークロードに適した分散システムを特定するプロセスを進めます。
+ リージョン全体とアカウント全体にわたるサービス負荷を分析します。ハード制限の多くは、サービスのリージョンに基づいていますが、アカウントに基づく制限もあります。
+ ゾーン障害時とリージョン障害時のリソース使用状況について、回復力あるアーキテクチャを分析します。「アクティブ/アクティブ」、「アクティブ/パッシブ – ホット」、「アクティブ/パッシブ – コールド」、「アクティブ/パッシブ – パイロットライト」のアプローチを使用するマルチリージョン設計を進めると、このような障害ケースはより高い使用状況につながり、ハード制限に達するユースケースを生み出す可能性が出てきます。
## リソース
**関連するベストプラクティス:**
+ [REL01-BP01 サービスクォータと制約を認識する](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 アカウントおよびリージョンをまたいでサービスクォータを管理する](rel_manage_service_limits_limits_considered.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)
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
**関連するドキュメント:**
+ [AWS Well Architected フレームワークの信頼性の柱: 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [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)
+ [クォータの引き上げのリクエスト方法](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Service Quotas ユーザーガイド](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS のクォータモニター](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)(AWS の障害分離境界)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)(冗長性を備えた可用性)
+ [ データのための AWS](https://aws.amazon.com/data/)
+ [継続的インテグレーションとは](https://aws.amazon.com/devops/continuous-integration/)
+ [継続的デリバリーとは](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN パートナー: 設定管理を支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)(AWS のテナント別アカウント SaaS 環境でアカウントのライフサイクルを管理する)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)(ワークロードの API スロットリングの管理とモニタリング)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)(AWS Organizations で AWS Trusted Advisor の推奨事項を大規模に表示する)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)(AWS Control Tower でサービス制限の緩和とエンタープライズサポートを自動化する)
+ [Actions, Resources, and Condition Keys for Service Quotas Services](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html) (AWS サービスのアクション、リソース、および条件キー)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)(Service Quotas を使用して AWS のサービスのクォータを表示および管理する)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)(AWS IAM のクォータのデモ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: ループをクローズして柔軟に対応: サイズを問わず、システムを制御する方法)
**関連ツール:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP04 クォータをモニタリングおよび管理する
予想される使用量を評価し、クォータを必要に応じて引き上げて、使用量を予定通り増やせるようにします。
**期待される成果:** 管理およびモニタリングするアクティブで自動化されたシステムが導入されます。このような運用ソリューションを採用すると、使用量がクォータのしきい値に近づいているかどうかを確認することができます。クォータの変更が要請されると、これらは積極的に修正されます。
**一般的なアンチパターン:**
+ サービスクォータのしきい値をチェックするようにモニタリングを設定していない。
+ ハード制限の値は変更できないにもかかわらず、モニタリングを設定していない。
+ ソフトクォータの変更を要請して確保するのに必要な時間は即時または短期間であると想定している。
+ サービスクォータに近づいた際のアラームは設定していても、アラートの対応方法に関するプロセスがない。
+ AWS Service Quotas でサポートされているサービスのアラームのみを設定し、その他の AWS サービスのモニタリングを行っていない。
+ 「アクティブ/アクティブ」、「アクティブ/パッシブ – ホット」、「アクティブ/パッシブ – コールド」、「アクティブ/パッシブ – パイロットライト」のアプローチなど、複数リージョンの回復力ある設計のクォータ管理を考慮していない。
+ リージョン間のクォータの違いを評価していない。
+ 特定のクォータ引き上げ要請について、すべてのリージョンのニーズを評価していない。
+ [マルチリージョンクォータ管理向けのテンプレート](https://docs.aws.amazon.com/servicequotas/latest/userguide/organization-templates.html)を活用していない。
**このベストプラクティスを活用するメリット:** AWS Service Quotas を自動的に追跡し、これらのクォータに対する使用状況をモニタリングすることで、クォータ制限に近づいていることを確認できます。このモニタリングデータを使用して、クォータの枯渇による低下を制限することもできます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
サポートされているサービスについては、評価してアラートまたはアラームを送信できるさまざまなサービスを設定することで、クォータをモニタリングできます。これにより、使用状況のモニタリングがサポートされ、クォータに近づいていることのアラートが送信されます。このアラームは、AWS Config、Lambda 関数、Amazon CloudWatch、または AWS Trusted Advisor からトリガーできます。また、CloudWatch Logs のメトリクスフィルターを使用して、ログのパターンを検索して抽出し、使用量がクォータのしきい値に近づいているかどうかを判断することもできます。
**実装手順**
モニタリング:
+ 現在のリソース消費 (バケットやインスタンスなど) を把握します。Amazon EC2 `DescribeInstances` などの API オペレーションを使用して、現在のリソース消費の情報を収集します。
+ 以下を使用して、サービスに不可欠で適用できる現在のクォータをキャプチャします。
+ AWS Service Quotas
+ AWS Trusted Advisor
+ AWS ドキュメントを
+ AWS サービス固有のページ
+ AWS Command Line Interface (AWS CLI)
+ AWS Cloud Development Kit (AWS CDK)
+ AWS Service Quotas を使用します。これは、250 を超える AWS のサービスのクォータを一元的に管理するのに役立つ AWS のサービスです。
+ さまざまなしきい値で現在のサービス制限をモニタリングするには、Trusted Advisor サービス制限を使用します。
+ リージョンの使用状況の増加をチェックするには、サービスクォータ履歴 (コンソールまたは AWS CLI) を使用します。
+ 各リージョンと各アカウントのサービスクォータの変化を比較して、必要に応じて同等性を確立します。
管理:
+ 自動化: AWS Config カスタムルールを設定し、リージョン間でサービスクォータをスキャンして、違いを比較します。
+ 自動化: リージョン全体にわたるサービスクォータをスキャンするスケジュールされた Lambda 関数を設定して、違いを比較します。
+ 手動: リージョン全体にわたるサービスクォータをスキャンするために、AWS CLI、API、または AWS コンソールを介してサービスクォータをスキャンして、違いを比較します。違いについてのレポートを作成します。
+ リージョン間でクォータの違いが確認された場合は、必要に応じてクォータの変更を要請します。
+ すべての変更の結果を確認します。
## リソース
**関連するベストプラクティス:**
+ [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-BP05 クォータ管理を自動化する](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する](rel_manage_service_limits_suff_buffer_limits.md)
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
**関連するドキュメント:**
+ [AWS Well Architected フレームワークの信頼性の柱: 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [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)
+ [クォータの引き上げのリクエスト方法](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Service Quotas ユーザーガイド](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS のクォータモニター](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)(AWS の障害分離境界)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)(冗長性を備えた可用性)
+ [ データのための AWS](https://aws.amazon.com/data/)
+ [継続的インテグレーションとは](https://aws.amazon.com/devops/continuous-integration/)
+ [継続的デリバリーとは](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN パートナー: 設定管理を支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)(AWS のテナント別アカウント SaaS 環境でアカウントのライフサイクルを管理する)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)(ワークロードの API スロットリングの管理とモニタリング)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)(AWS Organizations で AWS Trusted Advisor の推奨事項を大規模に表示する)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)(AWS Control Tower でサービス制限の緩和とエンタープライズサポートを自動化する)
+ [Actions, Resources, and Condition Keys for Service Quotas Services](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html) (AWS サービスのアクション、リソース、および条件キー)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)(Service Quotas を使用して AWS のサービスのクォータを表示および管理する)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)(AWS IAM のクォータのデモ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: ループをクローズして柔軟に対応: サイズを問わず、システムを制御する方法)
**関連ツール:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL01-BP05 クォータ管理を自動化する
しきい値に近づいたときに警告するツールを実装します。AWS Service Quotas API を使用すると、クォータの引き上げリクエストを自動化できます。
お使いの Configuration Management Database (CMDB) またはチケット発行システムを Service Quotas と統合すると、クォータの引き上げリクエストと現在のクォータに関する情報のトラッキングを自動化できます。AWS SDK のほかに、Service Quotas も AWS Command Line Interface (AWS CLI) を使用した自動化を提供しています。
**一般的なアンチパターン:**
+ スプレッドシートでクォータと使用状況を追跡する。
+ 毎日、毎週、または毎月の使用状況に関するレポートを実行し、使用量とクォータを比較する。
**このベストプラクティスを活用するメリット:** AWS のサービスクォータの自動追跡と、そのクォータに対する使用量のモニタリングにより、クォータに近づいていることを確認できます。必要に応じてクォータの引き上げをリクエストできるように、オートメーションを設定できます。使用量の傾向が反対の方向にある場合は、(認証情報が漏えいした場合の) リスクの低下とコスト削減のメリットを実現するために、クォータの削減を検討することをお勧めします。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 自動モニタリングをセットアップする しきい値に近づいたときにアラートを発行するため、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 サポート に問い合わせるトリガーをセットアップします。
+ 変更イベントを手動でトリガーします。
+ ゲームデーを実行して、クォータ引き上げの変更プロセスをテストします。
## リソース
**関連するドキュメント:**
+ [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 フェイルオーバーに対応するために、現在のクォータと最大使用量の間に十分なギャップがあることを確認する
リソースに障害が発生するか、アクセスできない場合、リソースが正常に終了されるまで、クォータにカウントされることがあります。障害が発生したリソースまたはアクセスできないリソースと、代替のリソースの合計リソース数がクォータ内に収まることを確認します。このギャップを算出する際は、ネットワーク障害、アベイラビリティーゾーンの不具合、またはリージョン規模の不具合などのユースケースを考慮する必要があります。
**期待される成果:** 現在のサービスのしきい値を使用して、規模を問わず、リソースやリソースへのアクセスで障害に対応できます。リソースプランニングでは、ゾーン障害、ネットワーク障害、さらにはリージョン規模の不具合が考慮されています。
**一般的なアンチパターン:**
+ フェイルオーバーシナリオを考慮せずに、現在のニーズに基づいてサービスクォータを設定する。
+ ピーク時のサービスクォータの計算時に静的安定性の原則を考慮しない。
+ 各リージョンに求められる合計クォータを計算する際に、アクセスできないリソースの可能性を考慮しない。
+ AWS サービス障害分離境界と、予測される異常な使用パターンを考慮していないサービスがある。
**このベストプラクティスを活用するメリット:** サービス中断イベントがアプリケーションの可用性に影響を与えるような場合、クラウドを使用すると、このようなイベントを軽減または復旧するための戦略を実装できます。そのような戦略には、多くの場合、障害が発生したリソース、またはアクセスできないリソースに置き換わる追加リソースの作成が含まれます。このようなフェイルオーバーの状況に対応し、サービス制限の枯渇による追加の低下を発生させないようなクォータ戦略を策定します。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
クォータ制限を評価する際は、何らかの劣化が原因で発生する可能性のあるフェイルオーバーのケースを検討します。以下のタイプのフェイルオーバーのケースを検討する必要があります。
+ 中断したり、アクセスできない VPC。
+ アクセスできないサブネット。
+ 多くのリソースへのアクセスに影響を及ぼすレベルまで低下したアベイラビリティーゾーン。
+ まざまなネットワークルートまたは受信ポイントと送信ポイントがブロックされたり、変更されたりしている。
+ 多くのリソースへのアクセスに影響を及ぼすレベルまで低下したリージョン。
+ 複数のリソースがあるが、すべてのリソースがリージョンやアベイラビリティーゾーンの不具合の影響を受けているわけではない。
上記のリストのような障害は、フェイルオーバーイベントを開始するトリガーになる可能性があります。ビジネスへの影響は大きく異なる可能性があり、フェイルオーバーの決定は状況や顧客ごとに異なります。ただし、アプリケーションまたはサービスのフェイルオーバーという運用上の決定を下す場合、イベントが発生する前に、フェイルオーバーのロケーションでのリソースのキャパシティプランニングと、それに関連するクォータについて対処する必要があります。
発生する可能性がある通常のピーク時よりも高いピークを考慮に入れて、各サービスのクォータを確認します。このようなピークは、ネットワークまたはアクセス許可のために到達でき、まだアクティブなリソースに関連している可能性があります。終了していないアクティブなリソースは、サービスクォータ制限に対して引き続きカウントされます。
**実装手順**
+ フェイルオーバーまたはアクセスできなくなった場合に対応するため、サービスクォータと最大使用量の間に十分なギャップがあることを確認します。
+ デプロイのパターン、可用性の要件、消費の増加を考慮して、サービスクォータを決定します。
+ 必要に応じてクォータの引き上げをリクエストします。クォータの引き上げリクエストの実行に必要な時間を計画します。
+ 信頼性の要件 (「9 の数」としても知られる) を決定します。
+ 障害シナリオ (コンポーネント、アベイラビリティーゾーン、リージョンの損失など) を確立します。
+ デプロイ手法 (例えば、Canary、ブルー/グリーン、レッド/ブラック、ローリングなど) を確立します。
+ 現在の制限に適切なバッファ (例えば、15%) を含めます。
+ 必要に応じて、静的安定性 (ゾーンおよびリージョン) の計算を含めます。
+ 消費の増加を計画します (例えば、消費の傾向をモニタリングする)。
+ 最も重要なワークロードへの静的安定性の影響を考慮します。すべてのリージョンとアベイラビリティーゾーンで静的に安定性のあるシステムに相当するリソースを評価します。
+ オンデマンドキャパシティ予約を使用して、フェイルオーバーが発生する前に容量をスケジュールすることを検討します。これは、フェイルオーバー発生時、最も重要なビジネススケジュール中に、適切な量および種類のリソースを取得するうえで予測できるリスクの軽減に役立つ戦略です。
## リソース
**関連するベストプラクティス:**
+ [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)
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP05 カオスエンジニアリングを使用して回復力をテストする](rel_testing_resiliency_failure_injection_resiliency.md)
**関連するドキュメント:**
+ [AWS Well Architected フレームワークの信頼性の柱: 可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [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)
+ [クォータの引き上げのリクエスト方法](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
+ [サービスエンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)
+ [Service Quotas ユーザーガイド](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [AWS のクォータモニター](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [AWS Fault Isolation Boundaries ](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)(AWS の障害分離境界)
+ [ Availability with redundancy ](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)(冗長性を備えた可用性)
+ [ データのための AWS](https://aws.amazon.com/data/)
+ [継続的インテグレーションとは](https://aws.amazon.com/devops/continuous-integration/)
+ [継続的デリバリーとは](https://aws.amazon.com/devops/continuous-delivery/)
+ [APN パートナー: 設定管理を支援できるパートナー](https://partners.amazonaws.com/search/partners?keyword=Configuration+Management&ref=wellarchitected)
+ [ Managing the account lifecycle in account-per-tenant SaaS environments on AWS](https://aws.amazon.com/blogs/mt/managing-the-account-lifecycle-in-account-per-tenant-saas-environments-on-aws/)(AWS のテナント別アカウント SaaS 環境でアカウントのライフサイクルを管理する)
+ [ Managing and monitoring API throttling in your workloads ](https://aws.amazon.com/blogs/mt/managing-monitoring-api-throttling-in-workloads/)(ワークロードの API スロットリングの管理とモニタリング)
+ [ View AWS Trusted Advisor recommendations at scale with AWS Organizations](https://aws.amazon.com/blogs/mt/organizational-view-for-trusted-advisor/)(AWS Organizations で AWS Trusted Advisor の推奨事項を大規模に表示する)
+ [ Automating Service Limit Increases and Enterprise Support with AWS Control Tower](https://aws.amazon.com/blogs/mt/automating-service-limit-increases-enterprise-support-aws-control-tower/)(AWS Control Tower でサービス制限の緩和とエンタープライズサポートを自動化する)
+ [Actions, Resources, and Condition Keys for Service Quotas Services](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html) (AWS サービスのアクション、リソース、および条件キー)
**関連動画:**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
+ [ View and Manage Quotas for AWS Services Using Service Quotas ](https://www.youtube.com/watch?v=ZTwfIIf35Wc)(Service Quotas を使用して AWS のサービスのクォータを表示および管理する)
+ [AWS IAM Quotas Demo ](https://www.youtube.com/watch?v=srJ4jr6M9YQ)(AWS IAM のクォータのデモ)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)(AWS re:Invent 2018: ループをクローズして柔軟に対応: サイズを問わず、システムを制御する方法)
**関連ツール:**
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
+ [ Amazon DevOps Guru ](https://aws.amazon.com/devops-guru/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [AWS CDK ](https://aws.amazon.com/cdk/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Marketplace](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
# REL 2.ネットワークトポロジをどのように計画しますか?
多くの場合、ワークロードは複数の環境に存在します。このような環境には、複数のクラウド環境 (パブリックにアクセス可能なクラウド環境とプライベートの両方) と既存のデータセンターインフラストラクチャなどがあります。計画する際は、システム内およびシステム間の接続、パブリック 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 ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を使用する
ワークロードのパブリックエンドポイントに高可用性ネットワーク接続を構築すると、接続の喪失によるダウンタイムを低減し、ワークロードの可用性と SLA を向上できます。これを実現するには、可用性の高い DNS、コンテンツ配信ネットワーク、API ゲートウェイ、負荷分散、またはリバースプロキシを使用します。
**期待される成果:** パブリックエンドポイントの高可用性ネットワーク接続を計画、構築、運用化することが重要です。接続が失われたためにワークロードにアクセスできなくなった場合、ワークロードが実行中で利用可能であっても、顧客はシステムがダウンしていると見なします。ワークロードのパブリックエンドポイントに対する可用性と回復力に優れたネットワーク接続と、ワークロード自体の回復力のあるアーキテクチャを組み合わせることで、可能な限り最高レベルの可用性とサービスレベルを顧客に提供できます。
AWS Global Accelerator、Amazon CloudFront、Amazon API Gateway、AWS Lambda 関数 URL、AWS AppSync API、Elastic Load Balancing (ELB) はすべて、高可用性のパブリックエンドポイントを提供します。Amazon Route 53 は、ドメイン名解決のための高可用性 DNS サービスを提供し、パブリックエンドポイントアドレスを解決できることを確認できます。
また、ロードバランシングとプロキシ処理のために、AWS Marketplace のソフトウェアアプライアンスを評価することもできます。
**一般的なアンチパターン:**
+ 高可用性に向けて DNS とネットワーク接続を計画せず、高可用性ワークロードを設計する。
+ 個別のインスタンスまたはコンテナでパブリックインターネットアドレスを使用し、DNS 経由でそれらのアドレスへの接続を管理する。
+ サービスの検索に、ドメイン名ではなく、IP アドレスを使用する。
+ パブリックエンドポイントへの接続が失われるシナリオをテストしていない。
+ ネットワークスループットのニーズと分散パターンを分析していない。
+ ワークロードのパブリックエンドポイントへのインターネットにおけるネットワーク接続が中断される可能性を考慮したシナリオをテストおよび計画していない。
+ 大規模な地理的領域にコンテンツ (ウェブページ、静的アセット、またはメディアファイル) を提供し、コンテンツ配信ネットワークを使用しない。
+ 分散サービス拒否 (DDoS) 攻撃に備えた計画をしていない。DDoS 攻撃は、正当なトラフィックを遮断し、ユーザーの可用性を低下させるリスクがあります。
**このベストプラクティスを活用するメリット:** 可用性と回復力に優れたネットワーク接続を設計することで、ユーザーはワークロードにアクセスして利用できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
パブリックエンドポイントへの高可用性ネットワーク接続を構築する際の中核となるのが、トラフィックのルーティングです。トラフィックがエンドポイントに到達できることを確認するには、ドメイン名を DNS が対応する IP アドレスに解決することができる必要があります。ドメインの DNS レコードを管理するには、Amazon Route 53 などの高可用性かつスケーラブルな[ドメインネームシステム (DNS)](https://aws.amazon.com/route53/what-is-dns/) を使用します。Amazon Route 53 が提供するヘルスチェックも利用できます。ヘルスチェックは、アプリケーションが到達可能かつ利用可能で、機能していることを確認します。ヘルスチェックは、ウェブページや特定の URL を要求するなどのユーザーの動作を模倣するように設定できます。障害が発生した場合、Amazon Route 53 は DNS 解決リクエストに応答し、トラフィックを正常なエンドポイントのみに転送します。Amazon Route 53 が提供する位置情報 DNS およびレイテンシーベースルーティング機能の使用を検討することもできます。
ワークロード自体の可用性が高いことを確認するには、Elastic Load Balancing (ELB) を使用します。Amazon Route 53 は、トラフィックを ELB にターゲットとするために使用できます。ELB は、このトラフィックを、ターゲットのコンピューティングインスタンスに分散します。サーバーレスソリューションには、Amazon API Gateway と AWS Lambda を組み合わせて使用できます。また、複数の AWS リージョン でワークロードを実行することもできます。[マルチサイトのアクティブ/アクティブパターン](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)を使用すると、ワークロードは複数のリージョンからのトラフィックを処理できます。マルチサイトのアクティブ/パッシブパターンの場合、ワークロードはアクティブリージョンからのトラフィックを処理し、データはセカンダリリージョンにレプリケートされ、プライマリリージョンで障害が発生した場合にアクティブになります。その後、Route 53 のヘルスチェックを使用して、プライマリリージョンの任意のエンドポイントからセカンダリリージョンのエンドポイントへの DNS フェイルオーバーを制御して、ワークロードが到達可能であり、ユーザーが利用できることを確認することができます。
Amazon CloudFront は、世界中のエッジロケーションのネットワークを使用してリクエストを処理することにより、低レイテンシーかつ高データ転送速度でコンテンツを配信する、シンプルな API を提供します。コンテンツ配信ネットワークは、ユーザーの所在地に近いロケーションにあるか、近いロケーションでキャッシュされているコンテンツを提供することで、顧客にサービスを提供します。これにより、コンテンツの負荷がサーバーから CloudFront の[エッジロケーション](https://aws.amazon.com/products/networking/edge-networking/)へと移動するため、アプリケーションの可用性も向上します。エッジロケーションとリージョンのエッジキャッシュは、視聴者の近くにコンテンツのキャッシュコピーを保持するため、ワークロードの取得が迅速化し、到達可能性と可用性が向上します。
ユーザーが地理的に分散しているワークロードの場合、AWS Global Accelerator を使用すると、アプリケーションの可用性とパフォーマンスを向上できます。AWS Global Accelerator は、1 つまたは複数の AWS リージョン でホストされているアプリケーションへの固定エントリポイントとして機能するエニーキャスト静的 IP アドレスを提供します。これにより、トラフィックがユーザーにできるだけ近い AWS グローバルネットワークに入ることができ、ワークロードの到達可能性と可用性が向上します。AWS Global Accelerator を使用すると、TCP、HTTP、および HTTPS ヘルスチェックを使用して、アプリケーションエンドポイントの健全性もモニタリングできます。エンドポイントの正常性または設定に変更が生じると、正常なエンドポイントへのユーザートラフィックのリダイレクトがトリガーされ、最高のパフォーマンスと可用性がユーザーに提供されます。さらに、AWS Global Accelerator は障害を分離するように設計されており、独立したネットワークゾーンによって提供される 2 つの静的 IPv4 アドレスを使用して、アプリケーションの可用性を向上します。
DDoS 攻撃からの保護として、AWS は、AWS Shield Standard を提供しています。Shield Standard は自動的に有効にされており、SYN/UDP フラッド攻撃やリフレクション攻撃などの一般的なインフラストラクチャ (レイヤー 3 および 4) 攻撃から保護し、AWS 上のアプリケーションの高可用性をサポートします。より高度で大規模な攻撃 (UDP フラッド攻撃など)、State-Exhaustion 攻撃 (TCP SYN フラッドなど) に対する追加の保護、および Amazon Elastic Compute Cloud (Amazon EC2)、Elastic Load Balancing (ELB)、Amazon CloudFront、AWS Global Accelerator、Route 53 上で実行されるアプリケーションの保護には、AWS Shield Advanced の使用を検討できます。HTTP POST や GET フラッド攻撃などのアプリケーションレイヤー攻撃からの保護には、AWS WAF を使用します。AWS WAF を使用すると、IP アドレス、HTTP ヘッダー、HTTP ボディ、URI 文字列、SQL インジェクション、クロスサイトスクリプティング条件を使用して、リクエストをブロックするか許可するかを決定できます。
**実装手順**
1. 高可用性の DNS の設定: Amazon Route 53 は、高可用性かつスケーラブルな[ドメインネームシステム (DNS)](https://aws.amazon.com/route53/what-is-dns/) ウェブサービスです。Route 53 は、AWS またはオンプレミスで実行されるインターネットアプリケーションにユーザーリクエストを接続します。詳細については、「[DNS サービスとしての Amazon Route 53 の設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html)」を参照してください。
1. ヘルスチェックの設定: Route 53 を使用する場合、正常なターゲットのみが解決可能であることを確認します。[Route 53 ヘルスチェックの作成と DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html)から始めます。ヘルスチェックを設定する際には、以下を考慮することが重要です。
1. [Amazon Route 53 でヘルスチェックの正常性を判断する方法](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html)
1. [ヘルスチェックの作成、更新、削除](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html)
1. [ヘルスチェックステータスのモニタリングと通知の受信](https://docs.aws.amazon.com/)
1. [Amazon Route 53 DNS のベストプラクティス](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html)
1. [DNS サービスをエンドポイントに接続します。](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html)
1. Elastic Load Balancing をトラフィックのターゲットとして使用する場合、Amazon Route 53 を使用してロードバランサーのリージョンエンドポイントを指す[エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を作成します。エイリアスレコードの作成中に、[Evaluate Target Health (ターゲットの正常性の評価)] オプションを [Yes (あり)] に設定します。
1. サーバーレスワークロードまたはプライベート API については、API Gateway を使用する場合、[Route 53 を使用してトラフィックを API Gateway にルーティング](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html)します。
1. コンテンツ配信ネットワークを決定します。
1. ユーザーに近いエッジロケーションを使用してコンテンツを配信するには、[CloudFront がコンテンツを配信する方法](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/HowCloudFrontWorks.html)を理解することから始めます。
1. [簡単な CloudFront ディストリビューション](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html)の使用から始めます。これにより、CloudFront は、コンテンツの配信元と、コンテンツ配信の追跡および管理方法に関する詳細を認識できます。CloudFront のディストリビューションを設定する際には、以下の側面を理解して、考慮することが重要です。
1. [CloudFront エッジロケーションでのキャッシュの仕組み](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio-explained.html)
1. [CloudFront キャッシュから直接提供されるリクエストの比率 (キャッシュヒット率) の向上](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cache-hit-ratio.html)
1. [Amazon CloudFront Origin Shield の使用](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html)
1. [CloudFront オリジンフェイルオーバーによる高可用性の最適化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html)
1. アプリケーションレイヤー保護の設定: AWS WAF は、可用性低下、セキュリティの侵害、リソースの過剰消費といった、一般的なウェブのエクスプロイトやボットから保護します。詳細を理解するには、「[AWS WAF の仕組み](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html)」を確認し、アプリケーションレイヤーの HTTP POST および GET フラッド攻撃からの保護を実装する準備が整ったら、「[AWS WAF の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html)」を確認してください。AWS WAF は CloudFront と組み合わせて使用することもできます。ドキュメントについては、「[AWS WAF と Amazon CloudFront の機能との連携](https://docs.aws.amazon.com/waf/latest/developerguide/cloudfront-features.html)」を参照してください。
1. 追加の DDoS 保護の設定: デフォルトでは、すべての AWS のお客様が追加料金なしで、ウェブサイトやアプリケーションをターゲットする一般的で最も頻繁に発生するネットワーク層およびトランスポート層の DDoS 攻撃に対する AWS Shield Standard を使用した保護を受けています。Amazon EC2、Elastic Load Balancing、Amazon CloudFront、AWS Global Accelerator、Amazon Route 53 で実行されているインターネット接続アプリケーションの保護を強化するには、[AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) を検討し、「[DDoS に対する回復力が高いアーキテクチャの例](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-resiliency.html)」を確認してください。ワークロードとパブリックエンドポイントを DDoS 攻撃から保護するには、「[AWS Shield Advanced の開始方法](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-ddos.html)」を確認してください。
## リソース
**関連するベストプラクティス:**
+ [REL10-BP01 複数の場所にワークロードをデプロイする](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 マルチロケーションデプロイ用の適切な場所の選択](rel_fault_isolation_select_location.md)
+ [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP06 イベントが可用性に影響する場合に通知を送信する](rel_withstand_component_failures_notifications_sent_system.md)
**関連するドキュメント:**
+ [APN パートナー: ネットワークの計画を支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace for Network Infrastructure](https://aws.amazon.com/marketplace/b/2649366011) (ネットワークインフラストラクチャ向け AWS Marketplace)
+ [What Is AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) (AWS Global Accelerator とは)
+ [Amazon CloudFront とは何ですか?](https://docs.aws.amazon.com/Amazon/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)
+ [ Network Connectivity capability - Establishing Your Cloud Foundations ](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/network-connectivity-capability.html)(ネットワーク接続機能 - クラウド基盤の確立)
+ [Amazon API Gateway とは何ですか?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
+ [AWS WAF、AWS Shield、AWS Firewall Manager とは](https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html)
+ [ What is Amazon Route 53 Application Recovery Controller? ](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) (Amazon Route 53 Application Recovery Controller とは)
+ [Amazon Route 53 ヘルスチェックの作成と DNS フェイルオーバーの設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/dns-failover.html)
**関連動画:**
+ [AWS re:Invent 2022 - Improve performance and availability with AWS Global Accelerator](https://www.youtube.com/watch?v=s5sjsdDC0Lg)(AWS re:Invent 2022 - AWS Global Accelerator を使用してパフォーマンスと可用性を向上する)
+ [AWS re:Invent 2020: Global traffic management with Amazon Route 53 ](https://www.youtube.com/watch?v=E33dA6n9O7I)(AWS re:Invent 2020: Amazon Route 53 を使用したグローバルトラフィック管理)
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications ](https://www.youtube.com/watch?v=mwUV5skJJ0s)(AWS re:Invent 2022 - 高可用性のマルチ AZ アプリケーションの運用)
+ [AWS re:Invent 2022 - Dive deep on AWS networking infrastructure ](https://www.youtube.com/watch?v=HJNR_dX8g8c)(AWS re:Invent 2022 - AWS ネットワークインフラストラクチャの詳細)
+ [AWS re:Invent 2022 - Building resilient networks ](https://www.youtube.com/watch?v=u-qamiNgH7Q)(AWS re:Invent 2022 - 回復力のあるネットワークの構築)
**関連する例:**
+ [ Disaster Recovery with Amazon Route 53 Application Recovery Controller (ARC) ](https://catalog.us-east-1.prod.workshops.aws/workshops/4d9ab448-5083-4db7-bee8-85b58cd53158/en-US/) (Amazon Route 53 Application Recovery Controller (ARC) を使用したディザスタリカバリ)
+ [ Reliability Workshops ](https://wellarchitectedlabs.com/reliability/)(信頼性ワークショップ)
+ [AWS Global Accelerator ワークショップ](https://catalog.us-east-1.prod.workshops.aws/workshops/effb1517-b193-4c59-8da5-ce2abdb0b656/en-US)
# REL02-BP02 クラウド環境とオンプレミス環境のプライベートネットワーク間の冗長接続をプロビジョニングする
個別にデプロイされたプライベートネットワーク間で複数の 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 つの環境間で依存するサービスが確実に通信できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 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)
## リソース
**関連するドキュメント:**
+ [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 サブネットの割り当てを確実に行う
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 アドレスの数を不正確に見積もる。
+ 多数の高トラフィックロードバランサーを同じサブネットにデプロイする。
**このベストプラクティスを確立するメリット:** これにより、ワークロードの増大に対応し、スケールアップ時に可用性を引き続き提供できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 拡張、コンプライアンス、他のネットワークとの統合に対応できるようにネットワークを計画します。適切に計画しないと、拡張の見積もりが甘くなったり、規制コンプライアンスが変わったり、取得やプライベートネットワーク接続の設定が難しくなったりする場合があります。
+ サービス要件、レイテンシー、規制、およびディザスタリカバリ (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 に追加することはできます。ただし、この場合、アドレス範囲が断片化される可能性があります。
## リソース
**関連するドキュメント:**
+ [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 多対多メッシュよりもハブアンドスポークトポロジを優先する
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/2023-10-03/framework/images/without-transit-gateway.png)
![\[AWS Transit Gateway を使用した場合の図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2023-10-03/framework/images/with-transit-gateway.png)
**一般的なアンチパターン:**
+ VPC ピア接続を使用して 3 つ以上の VPC を接続する。
+ 各 VPC に対して複数の BGP セッションを確立し、複数の AWS リージョン における仮想プライベートクラウド (VPC) にまたがる接続を確立する。
**このベストプラクティスを確立するメリット:** ネットワークの数が増えるにつれて、このようなメッシュ接続の複雑さは受容できないものになります。AWS Transit Gateway は、維持しやすいハブアンドスポークモデルを提供し、複数のネットワーク間でトラフィックをルーティングできるようにします。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 多対多メッシュよりもハブアンドスポークトポロジを優先します。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)
## リソース
**関連するドキュメント:**
+ [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 アドレス範囲を指定する
各 VPC の IP アドレス範囲が、ピア接続時または VPN 経由での接続時に重複しないようにする必要があります。同様に、VPC とオンプレミス環境の間、または使用する他のクラウドプロバイダーとの IP アドレスの競合を回避する必要があります。また、必要に応じてプライベート IP アドレス範囲を割り当てる方法を用意する必要もあります。
これには、IP アドレス管理 (IPAM) システムが役立ちます。複数の IPAM は AWS Marketplace から入手できます。
**一般的なアンチパターン:**
+ オンプレミスまたは社内ネットワークにあるのと同じ IP 範囲を VPC で使用する。
+ ワークロードのデプロイに使用されている VPC の IP 範囲を追跡しない。
**このベストプラクティスを確立するメリット:** ネットワークを積極的に計画することで、相互接続されたネットワークで同じ IP アドレスが複数出現しないようにできます。これにより、異なるアプリケーションを使用しているワークロードの一部でルーティングの問題が発生するのを防ぐことができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 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) アプライアンスを使用できます。
## リソース
**関連するドキュメント:**
+ [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)