REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する

コントロールプレーンはリソースの設定に使用し、データプレーンはサービスを提供します。通常、データプレーンの可用性設計目標はコントロールプレーンよりも高く、複雑さは低くなっています。回復力に影響する可能性があるイベントに対して復旧または軽減対策を実装するときは、コントロールプレーンを使用すると、アーキテクチャの全体的な回復力が下がる可能性があります。例えば、Amazon Route 53 データプレーンを利用して、ヘルスチェックに基づいて DNS クエリを確実にルーティングできますが、Route 53 ルーティングポリシーの更新にはコントロールプレーンを使用するため、これを復旧には利用しないでください。

Route 53 データプレーンは、DNS クエリに応答し、ヘルスチェックを実行し、評価します。グローバルに分散され、 100% の可用性サービスレベルアグリーメント (SLA) として設計されています。 Route 53 のリソースを作成、更新、削除する Route 53 管理 API およびコンソールは、コントロールプレーンで実行します。コントロールプレーンは、DNS の管理に必要な強力な一貫性と耐久性を重視するように設計されています。これを達成するために、コントロールプレーンは単一のリージョン、US East (N. Virginia) に配置されています。どちらのシステムも非常に高い信頼性で構築されていますが、コントロールプレーンは SLA には含まれません。まれに、データプレーンの回復力設計によって可用性を維持できるときでも、コントロールプレーンでは維持でない場合があります。ディザスタリカバリおよびフェイルオーバーメカニズムについては、データプレーンの機能を使用して、可能な限り最善の信頼性を提供してください。

データプレーン、コントロールプレーン、および AWS が高可用性目標を満たすためにサービスを構築する方法の詳細については、 アベイラビリティーゾーンを使用した静的安定性 ペーパーと Amazon Builders' Library を参照してください。

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

実装のガイダンス

リソース

関連するドキュメント:

関連する例: