AWS による優れた設計のフレームワーク2016

年 11 月© 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved

注意

本書は情報提供のみを目的としています。本書の発⾏時点における AWS の現
⾏製品と慣⾏を表したものであり、それらは予告なく変更されることがあります。お客様は本書の情報、および AWS 製品またはサービスの利⽤について、独自の評価に基づき判断する責任を負います。いずれの AWS 製品またはサービスも、明示または黙示を問わずいかなる保証も伴うことなく、「現状のまま」提供されます。本書のいかなる内容も、AWS、その関係者、サプライヤ、またはライセンサーからの保証、表明、契約的責任、条件や確約を意味するものではありません。お客様に対する AWS の責任は AWS 契約によって規定されています。また、本文書は、AWS とお客様との間の契約に属するものではな
く、また、当該契約が本文書によって修正されることもありません。.

目次

はじめに
AWS による優れた設計のフレームワークの定義
一般的な設計の原則
AWS による優れた設計のフレームワークの 5 本柱
セキュリティの柱
信頼性の柱
パフォーマンス効率の柱
コストの最適化の柱
運用性の柱
まとめ
寄稿者
ドキュメント履歴
付録: Well-Architected の質問、回答、ベストプラクティス
セキュリティの柱
信頼性の柱
パフォーマンスの柱
コストの最適化の柱
運用性の柱

1
2
3
5
5
17
24
36
45
54
54
55
56
56
65
72
79
86

要約

本書では AWS による優れた設計のフレームワークについて説明しています。
お客様はクラウドベースのアーキテクチャを評価および改善し、設計上の決定
がビジネスに及ぼす影響をより良く理解できるようになります。ここでは、
AWS による優れた設計のフレームワークの柱とされる 5 つの概念領域における一般的な設計の原則と、特定のベストプラクティスおよびガイダンスを紹介します。

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

はじめにアマゾン ウェブ サービス (AWS) では、クラウドで信頼性、セキュリティ、効率、コスト効果が⾼いシステムを設計し運⽤するために、アーキテクチャのベストプラクティスについてお客様に学習していただくことが重要だと考えます。この一環として、AWS でシステムを構築する際の選択肢の⻑所と短所の理
解に役⽴つように、AWS による優れた設計のフレームワークを開発しました。
システムを上手に構築することで、ビジネスが成功する可能性が飛躍的に増加すると確信しています。
ソリューションアーキテクトは、多様なビジネス業界およびユースケース
におけるソリューションの設計において⻑年の経験を持ち、何千という AWSのお客様のアーキテクチャの設計および検証のお手伝いをしてきました。この経験から、クラウドにおけるシステム設計のベストプラクティスおよび核となる戦略を⾒つけ出しました。

AWSによる優れた設計のフレームワークには、特定のアーキテクチャがクラウドのベストプラクティスにうまく合致しているかどうかを理解するための基本的な質問が記載されています。このフレームワークは、現代のクラウドベースのシステムに期待する品質を評価するための一貫したアプローチと、その品質を達成するために必要な対応を提供します。AWS は進化し続け、お客様との共同作業で学ぶことも尽きないため、優れた設計の定義も改良され続け
ます。

AWS

本書は技術責任者 (CTO)、設計者、開発者、オペレーションチームメンバーな
どの技術担当者を対象としています。本書を読むことで、クラウドアーキテク
チャを設計し運用する際の AWS のベストプラクティスおよび取るべき戦略が理解できます。本書では、実装の詳細またはアーキテクチャパターンは扱いません。しかし、この情報に関する適切なリソースへの参照が含まれています。
1ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
AWS による優れた設計のフレームワークの定義の専門家は、⽇々、お客様がクラウドのベストプラクティスの利点を活かせるようなシステムを構築できるようにお手伝いしています。設計が進化する
につれて発生するアーキテクチャとのトレードオフをお客様とともに考えてきました。ライブ環境にシステムをデプロイするたびに、システムがどの程度うまく機能するか、トレードオフの影響はどうかが判ります。
このように学んできたことをベースに、AWS による優れた設計のフレームワー
クは作成されました。これは、アーキテクチャが AWS ベストプラクティスにどの程度合致しているかを評価できる質問集です。
AWS による優れた設計のフレームワークは、セキュリティ、信頼性、
パフォーマンス効率、コスト最適化、運⽤性という 5 本の柱を基本としています。それぞれは以下のように定義されます。
AWS

柱名
セキュリティ

説明
リスクの評価と軽減戦略を通して、ビジネス価値を提供しな
がら、情報、システム、資産を保護する能⼒です。
インフラストラクチャまたはサービスの障害から復旧した
信頼性
り、必要に応じて動的にコンピューティングリソースを獲得したり、設定ミスや一時的なネットワークの問題などによる障害を軽減したりといったシステムの能⼒です。
パフォーマンス効率 システムの要求に合わせてコンピューティングリソースを効
率的に使⽤し、需要の変化や技術の進歩に合わせてこの効率を維持する能⼒です。
不要なコストや最適でないリソースを回避または排除する能コストの最適化⼒です。
ビジネスの価値をもたらし、サポートプロセスと手順の継続運用性的な向上を実現するために、システムを実⾏およびモニタリ
ングする能⼒です。
2ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ソリューションを設計する際にビジネスコンテキストに基づいて柱の間でト
レードオフを⾏うことになり、こうしたビジネス上の決定がエンジニアリングの優先付けにつながります。開発環境では信頼性を犠牲にすることでコストを削減するという最適化を⾏う場合や、ミッションクリティカルなソリューショ
ンでは、信頼性を最適化するためにコストをかける場合などがあります。E コ
マースソリューションでは、パフォーマンスが収益と顧客の購入優先順位に影響を与える可能性があります。セキュリティと運用性は、通常、他の柱とトレードオフされることはありません。
一般的な設計の原則による優れた設計のフレームワークは、クラウドにおける適切な設計を可能にする一般的な設計の原則を提供します。

AWS

必要キャパシティーの推測が不要に: 必要なインフラストラクチャキャパ
シティーを予測する必要がなくなります。システムのデプロイに先⽴ってキャパシティを決定すると、高価なアイドルリソースが発生したり、キャパシティが制限されることによりパフォーマンスに影響したりします。クラウドコンピューティングにはこのような問題はありません。必要な分のみキャパシティーを使用し、自動的にスケールアップまたはス
ケールダウンできます。
• 本稼働スケールでシステムをテストする: クラウドでは、本稼働スケー
ルのテスト環境を作成してテストを完了したら、リソースを破棄することができます。⽀払いはテスト環境を実⾏しているときのみ発⽣するため、オンプレミスでテストを実施する場合と比べて僅かなコストで、本番環境をシミュレートできます。
•

3

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

⾃動化によってアーキテクチャ上の実験を容易にする : 自動化によって、システムを低コストで作成およびレプリケートでき、手動作業の手間がかかりません。⾃動化に対する変更を追跡し、影響を監査して、必要な場合は以前のパラメーターに戻すことができます。
• 発展するアーキテクチャが可能に: 従来の環境では、アーキテクチャ上の決定は、しばしば静的な 1 回限りのイベントとして実装され、その運用期間中にシステムのいくつかの主要なバーションが実装されます。
ビジネスとそのコンテキストは変化し続けているのに、当初の決定に縛られ、システムがビジネスの需要の変化に対応できない場合があります。クラウドでは、自動化とオンデマンドなテスト機能によって、設計変更によって⽣じる影響のリスクを低減できます。これによって、シス
テムが何度でも進化でき、新しいイノベーションをビジネスに活用する
ことを、標準的なプラクティスとして実施できるようになります。
• データ駆動型アーキテクチャ: クラウドでは、選択したアーキテクチャ
がワークロードの動作に与える影響についてのデータを収集することができます。これにより、ワークロードの改善について事実に基づいた意
思決定を⾏うことができます。クラウドインフラストラクチャはコード化できるので、そのデータを使⽤してアーキテクチャを⾒直し、継続的に改善していくことができます。
• ゲームデーを通じた向上: 定期的にゲームデーを開催し、実稼働環境でのイベントをシミュレートすることで、アーキテクチャとプロセスがどのように実⾏されるのかをテストします。これは、改善可能な箇所を把握したり、イベントに対応する体験を組織的に育成するのに役⽴ちま
す。
•

4

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

AWS による優れた設計のフレームワークの 5 本柱ソフトウェアシステムの作成はビルの建築に似ています。基礎がしっかりしていなければ、ビルの健全性や機能を損なう構造の問題が発生することがあります。技術ソリューションを設計する場合、セキュリティ、信頼性、パフォーマ
ンス効率、コスト最適化、運用性の 5 本の柱を疎かにすると、意図したとおりに要件に従って稼働するシステムの構築が難しくなるでしょう。これらの柱をアーキテクチャに組み込むことで、安定した効率的なシステムを作成することができます。こうすることで、要求される機能など設計の他の要素に集中できます。
このセクションでは、5 本柱のそれぞれについて、定義、ベストプラクティ
ス、質問、考慮点、および関連する AWS の主要サービスを説明します。
セキュリティの柱

セキュリティの柱には、リスクの評価と軽減戦略を通して、ビジネス価値を提供しながら、情報、システム、アセットを保護する能⼒が含まれます。
設計の原則

クラウドでは、システムセキュリティを強化する役に⽴つ数多くの原則があり
ます。

5

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

すべてのレイヤーでセキュリティを適用: インフラストラクチャのエッジ
でセキュリティアプライアンス (例: ファイアウォール) を実⾏するだけではなく、ファイアウォールや他のセキュリティ制御をすべてのリソース(例: 各仮想サーバー、ロードバランサー、ネットワークサブネット) でも使用します。
• トレーサビリティを有効化: 環境に対する全てのアクションと変更を記録
し監査します。
• 最小権限の原則の導入: AWS リソースとのそれぞれのやり取りに適切な認可が与えられていることを確認し、リソース対する強⼒な論理的アク
セスコントロールを実装します。
• お客様システムの保護にフォーカス: AWS 責任共有モデルにもとづき、
安全なインフラストラクチャやサービスを AWS が提供します。お客様
は、その上で稼働するお客様のアプリケーション、データ、オペレー
ティングシステムの保護に集中できます。
• セキュリティのベストプラクティスを自動化する: ソフトウェアベース
のセキュリティメカニズムによって、安全に、より迅速かつコスト効率
よくスケールすることができます。パッチが適用されセキュリティ強化
された仮想サーバーのイメージを作成して保存し、そのイメージを自動的にお客様が起動する各新規サーバーに使用します。リビジョン管理を通して、テンプレートで定義・管理された信頼ゾーンアーキテクチャ全体を作成します。ルーチンおよび異常なセキュリティイベントへの対応を自動化します。
•

6ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
定義

クラウドでのセキュリティには、次の 5 つのベストプラクティスの領域があります。
アイデンティティ管理とアクセス管理
2. 発⾒的統制
3. インフラストラクチャの保護
4. データ保護
5. インシデントへの対応
1.

システムを構築する前に、セキュリティに影響を及ぼす基礎的なプラクティス
が適切に導⼊される必要があります。誰が何を実⾏できるのかをコントロールする必要があります。さらに、セキュリティインシデントを特定し、システムとサービスを保護して、データ保護によりデータの機密性と整合性を維持する必要があります。それには、セキュリティインシデントに対応する明確に定義された実績のあるプロセスが必要となります。これらのツールや技術は、経済的損失の防⽌や、法令上の義務の遵守などの目的をサポートするために重要です。
責任共有モデルを使用して、クラウドを使用する企業がセキュリティおよびコンプライアンスの目的を達成できます。AWS がクラウドサービスをサポートするインフラストラクチャを物理的に保護するため、AWS のお客様は、サービスを使用してお客様の目的を達成することに集中できます。また、AWS クラウドでは、セキュリティデータへのアクセス機能が強化され、セキュリティイ
ベントへの応答方法が自動化できます。

AWS

7

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
ベストプラクティス

アイデンティティ管理とアクセス管理
アイデンティティ管理とアクセス管理は情報セキュリティプログラムの主要部分です。権限を持つユーザーおよび認証されたユーザーのみが、意図した方法
でのみ、確実にリソースにアクセスできるようにします。たとえば、プリンシ
パル (ユーザー、グループ、サービス、アカウントでアクションを実⾏するロール) を定義し、これらのプリンシパルに合わせてポリシーを構築し、強⼒な認証情報管理を導⼊します。これらの権限管理の構成要素は、認証と許可の主要な概念です。
では、権限管理は主に AWS Identity and Access Management (IAM) サー
ビスでサポートされており、AWS のサービスやリソースへのユーザーのアクセスを制御することができます。アクセス権限をユーザー、グループ、ロール、
リソースに割り当てるポリシーは細かく適用できます。複雑さのレベル、パス
ワード再利⽤の禁⽌、多要素認証 (MFA) の使⽤など、強⼒なパスワードポリ
シーを要求することもできます。また、既存のディレクトリサービスでフェデ
レーションを使用できます。AWS にアクセスするシステムを必要とするワーク
ロードでは、IAM がインスタンスプロファイル、ID フェデレーション、一時的な認証情報を通じて安全なアクセスを実現します。

AWS

次の質問はセキュリティのための権限管理の考慮事項に関するものです (セキュリティに関するすべての質問、回答、およびベストプラクティスの一覧については、付録を参照してください)。

8ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ルートアカウントの認証情報へのアクセスと使用をどのように保護していますか。
SEC 2. AWS マネジメントコンソールと API へのユーザーによるア
クセスを制御するために、システムユーザーのロールと責任をどのように定義していますか。
SEC 3. AWS リソースへの自動化されたアクセスをどのように制限していますか (アプリケーション、スクリプト、サードパーティーのツールやサービスなど)。
SEC 1. AWS

ルートアカウント認証情報を保護し続けることは非常に重要です。このため、
AWS では MFA をルートアカウントに設定し、MFA 付きの認証情報を物理的に安全な場所に保管することをお勧めします。 IAM サービスでは、その他の(ルートではない) ユーザーアクセス権限を作成して管理し、またリソースへのアクセスレベルを確⽴できます。
発⾒的統制
発⾒的統制は潜在的なセキュリティインシデントの識別に使⽤できます。発⾒的統制は管理フレームワークに不可⽋の部分であり、品質プロセス、法律上の準拠義務、脅威の識別や対応に利⽤されます。発⾒的統制には、さまざまな種
類があります。たとえば、資産およびその詳細属性を目録化して、より効果的に意思決定 (およびライフサイクル統制) を促進し、オペレーションの基礎を確⽴します。あるいは、情報システムに関連するコントロールを精査する内部監査を使用し、実態がポリシーおよび要件に一致しているか、定義した条件に基づいたアラート通知の自動化が正しく設定されているかを確認できます。これらの統制は重要なリアクティブファクターであり、企業が変則的なアクティビ
ティの範囲を識別して理解するのに役⽴ちます。
9ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

では、ログ、イベント、モニタリングの処理によって、監査や⾃動分析、アラームを実現し、発⾒的統制を実装することができます。AWS CloudTrail ロ
グ、AWS API 呼び出し、および Amazon CloudWatch はアラームを伴うメトリ
クスのモニタリングを提供し、AWS Config は設定履歴を提供します。サービ
スレベルログも使用可能です。たとえば、Amazon Simple Storage Service (S3)を使用してアクセスリクエストのログを作成できます。最後に、 Amazon
Glacier はボールトロック機能を提供しているため、ミッションクリティカルなデータを、監査可能な⻑期保持期間をサポートするように設計されたコンプラ
イアンス統制を保って保持できます。

AWS

次の質問は、セキュリティのための発⾒的統制の考慮事項に関するものです。
SEC 4.

ログをどのように取得して分析していますか。

セキュリティやフォレンジックに関連する理由のため、また規制および法令の要件のため、優れた設計においてはログ管理が重要です。潜在的なセキュリ
ティインシデントを特定できるように、ログを分析してそれに対応することが重要です。AWS には、お客様がデータ保持ライフサイクルを定義したり、デー
タを保管、アーカイブ、場合によっては削除する場所を定義したりすること
で、ログ管理をより簡単に実装できる機能があります。この機能により、予測可能で信頼できるデータ操作を、よりシンプルに高いコスト効果で⾏うことができます。

10ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

インフラストラクチャの保護
イ ン フ ラ ス ト ラ ク チ ャ の 保 護 に は 、 多 層 に 渡 る 防 御 や Multi-Factor
Authentication などのコントロール方法が含まれ、ベストプラクティスや、業界
あるいは法令上の義務を満たす必要があります。クラウドでもオンプレミスでも、オペレーションの実⾏を成功させるには、これらの⼿段を使⽤することが非常に重要です。
AWS では、AWS ネイティブの技術を使用するか、AWS Marketplace で入手できるパートナー製品およびサービスを使用して、ステートフルおよびステート
レスなパケットインスペクションを実装できます。また、 Amazon Virtual
Private Cloud (VPC) を使用してプライベートで安全でスケラーラブルな環境を作成 し、ゲートウェイ、ルーティングテーブル、パブリックサブネット、およびプライベートサブネットを含むトポロジを定義できます。
次の質問は、セキュリティのためのインフラストラクチャ保護の考慮事項に関するものです。
ネットワークおよびホストレベルの境界保護をどのように実施していますか。
SEC 6. AWS サービスレベルセキュリティ機能をどのように活用していますか。
SEC 7. Amazon EC2 インスタンス上のオペレーティングシステムの整合性はどのように保護していますか。
SEC 5.

11ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

多層防御はどのタイプの環境にもお勧めです。インフラストラクチャの保護に関しては、多くの概念や対応⽅法が、オンプレミスでもクラウドでも有効です。境界保護の徹底、送受信のモニタリング、広範囲のログ記録、モニタリン
グおよびアラートはすべて、効果的な情報セキュリティ計画に不可⽋です。
前述の「設計の原則」セクションで説明したとおり、AWS のお客様は EC2 イ
ンスタンスの設定をカスタマイズまたはハードニングして、この設定をAmazon Machine Image (AMI) に配置できます。その後、Auto Scaling によるトリガーでも手動起動でも、この AMI で起動するすべての新規仮想サーバー(インスタンス) では、ハードニングされた設定が適用されます。
データ保護
システムを構築する前に、セキュリティに影響を及ぼす基礎的なプラクティス
が適切に導⼊される必要があります。たとえば、データ分類は、企業のデータを重要度に基づいてカテゴリー分けする⽅法です。また、暗号化は、認証されていないアクセスでは解読できないようにデータを変換することでデータを保護します。これらのツールや技術は、経済的損失の防⽌や、法令上の義務の遵守などの目的をサポートするために重要です。
AWS

では、次のようなプラクティスでデータの保護が実⾏されます。

のお客様は、お客様のデータに対する完全な統制を保持します。
• AWS ではデータの暗号化や定期的なキーローテーションを含むキーの管理がより簡単になります。これらは AWS によってネイティブに自動化することも、お客様が保守することもできます。
• ファイルアクセスや変更などの重要な内容を含む詳細なログ記録を使⽤
できます。
•

12

AWS

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

は、非常に⾼い弾⼒性を持つようにストレージシステムを設計しました。たとえば、Amazon Simple Storage Service (S3) はほぼ完全な耐久性を求めた設計になっています。(たとえば、Amazon S3 を使用して 10,000のオブジェクトを保存する場合、平均で、10,000,000 年間に 1 つのオブジェクトを消失する可能性しかありません)。
• バージョニングは、より⼤容量データのライフサイクル管理処理の⼀部であり、意図しない上書きや削除、その他の障害に対してデータを保護することができます。
• AWS ではリージョン間のデータの移動は実⾏しません。1 つのリージョンに置かれたコンテンツは、お客様が明示的に機能を有効にするか、その機能を提供するサービスを利⽤しないかぎり、そのリージョンに残り続けます。
次の質問は、データセキュリティの考慮事項に関するものです。
AWS•

データをどのように分類していますか。
SEC 9. 保管時のデータをどのように暗号化、保護していますか。
SEC 10. キーと認証情報をどのように管理していますか。
SEC 11. 伝送中のデータをどのように暗号化、保護していますか。
SEC 8.

では、保管時および伝送時のデータの暗号化用に複数の手段を用意しています。これらの機能を製品とサービスに組み込み、データの暗号化を容易にします。たとえば、サーバー側の暗号化 (SSE) を Amazon S3 に実装し、暗号化されたフォームでのデータ保存をより簡単にします。また、HTTPS 全体の暗号

AWS

13

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

化および復号化処理 (一般には SSL ターミネーション と呼ばれます) を Elastic
Load Balancing で実⾏するように調整することもできます。
インシデントへの対応
非常に成熟した予防的統制と発⾒的統制が⾏われているとしても、企業は、セキュリティインシデントの潜在的な影響に対応し、それを軽減するためのプロセスを導入する必要があります。ワークロードのアーキテクチャは、お客様のチームがインシデント発⽣時に、システムを分離したり、影響の拡⼤を抑えた
り、オペレーションを通常の状態に復旧させたりして、効果的に対処できるかどうかに大きな影響を与えます。セキュリティインシデントが発生する前にツールを導入してアクセスし、定期的にインシデント対応を実施することで、調査と復旧をタイムリーに⾏えるようにアーキテクチャを更新できるようにな
ります。
AWS

す。

では、次のようなプラクティスで効果的なインシデント対応が実⾏されま

ファイルアクセスや変更などの重要な内容を含む詳細なログ記録を使⽤できます。
• イベントは⾃動的に処理され、AWS API を使用して自動的に Runbook
を実⾏するスクリプトをトリガーすることができます。
• AWS CloudFormation を使用して、プレプロビジョニングツールと「クリーンルーム」を実現できます。これにより、安全で分離された環境でフォレンジックを実施できます。

•

次の質問は、インシデント対応の考慮事項に関するものです。

14

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

どのようにして適切なインシデント対応が取れることを確認できますか。
SEC 12.

チームに対して迅速にアクセスを許可し、インスタンスの隔離と、フォレンジックのためのデータと状態の取得を⾃動化する⽅法を確⽴します。

InfoSec

関連する AWS サービス

セ キ ュ リ テ ィ に 不 可 ⽋ な AWS サ ー ビ ス は AWS Identity and Access
Management (IAM) です。AWS のサービスやリソースへのユーザーのアクセスを安全に管理できます。以下のサービスと機能は、セキュリティの 4 つの領域をサポートします。
により、AWS サービスおよびリ
ソースへのアクセスを安全にコントロールすることができます。多要素認証(MFA) は、ユーザー名およびパスワードに加え、拡張された保護レイヤーを追加します。
Identity and Access Management: IAM

発⾒的統制: AWS CloudTrail は AWS API コールを記録します。AWS Config は
AWS リソースおよび設定の詳細なインベントリーを提供し、 Amazon
CloudWatch は AWS リソースのサービスをモニタリングします。
インフラストラクチャの保護: Amazon Virtual Private Cloud (VPC) では、AWS
クラウド上にプライベートで隔離されたネットワークをプロビジョニングすることができ、仮想ネットワーク内に AWS リソースを起動することができ
ます。
15

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

データ保護 : Elastic Load Balancing 、 Amazon Elastic Block Store (EBS) 、
Amazon Simple Storage Service (S3) 、および Amazon Relational Database
Service (RDS) などのサービスには、伝送中や保管中のデータを保護する暗号化機能があります。AWS Key Management Service (KMS) では、データの暗号化に使⽤する暗号キーの作成や制御を簡単に⾏うことができます。
インシデント対応: IAM を使⽤して、インシデント対応チームに適切な許可を付与する必要があります。Amazon CloudFormation を使⽤して、調査を実⾏するための信頼できる環境を構築することができます。
リソース

セキュリティに関連するベストプラクティスの詳細については、以下のリソー
スを参照してください。
ドキュメント & ブログ
セキュリティセンター• AWS コンプライアンス• AWS セキュリティブログ•

AWS

ホワイトペーパー• AWS セキュリティの概要• AWS セキュリティのベストプラクティス• AWS リスクおよびコンプライアンス
動画

クラウドのセキュリティ• 責任共有モデルの概要
•

16

AWS

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
信頼性の柱

信頼性の柱には、インフラストラクチャまたはサービスの障害からの復旧、必要に応じた動的なコンピューティングリソースの獲得、設定ミスや一時的なネットワークの問題などによる障害軽減などのシステムの能⼒が含まれています。
設計の原則

クラウドでは、信頼性を⾼める役に⽴つ数多くの原則があります。
復旧⼿順のテスト: オンプレミス環境では、テストはたいてい特定のシナリオによってシステムが機能することを証明するために⾏われます。
復旧戦略を検証するためにテストが使⽤されることはあまりありません。クラウドでは、システム障害の発⽣過程をテストし、復旧⼿順を検証できます。⾃動化により、異なる障害をシミュレートしたり以前に障害が発生したシナリオを再作成したりできます。これらによって障害経路が洗い出され、実際に障害が発⽣する前にテストし修正することで、テストしていないコンポーネント障害のリスクを軽減できます。
• 障害から⾃動的に復旧する : システムの主要なパフォーマンスインジ
ケーター (KPI) をモニタリングすることで、しきい値を超過した場合に⾃動処理をトリガーできます。それにより⾃動的に障害を通知および追跡し、障害を回避または修正する復旧プロセスを⾃動化できます。より⾼度な⾃動化を使⽤して、障害が発⽣する前にそれを予測し修正することも可能です。

•

17

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

⽔平⽅向にスケールして集約システム能⼒を強化する: 1 つの大きなリ
ソースを複数の小さなリソースに置換して、1 つの障害がシステム全体に及ぼす影響を軽減します。複数のより小さなリソースに要求を分散させて、障害の共通点を共有しないようにします。
• キャパシティーの推測が不要に: オンプレミスシステムで発生する障害の一般的な原因はリソースの飽和です。システムに対する要求がそのシステムの能⼒を超えたときに発⽣します (よくサービス妨害攻撃の目標になります)。クラウドでは、需要とシステム使⽤率を監視し、需要を満たすために最適なレベルを維持するためのリソースの追加や削除を自動化することができます。
• ⾃動化における変更管理: インフラストラクチャの変更を⾃動化により実⾏する必要があります。管理する必要のある変更は⾃動化の変更です。
•

定義

クラウドで高い信頼性を実現するには、次の 3 つのベストプラクティスの領域があります。
基礎
2. 変更管理3. 障害管理1.

信頼性を確保するには、システムによく計画された基礎があり適切な箇所をモ
ニタリングし、また要望や要件に応じた変更を⾏う仕組みが必要です。障害を検出し⾃動的に⾃⼰修復するようにシステムを設計する必要があります。

18

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
ベストプラクティス

基礎
システムを構築する前に、信頼性に影響を及ぼす基礎的な要件が適切に導⼊される必要があります。たとえば、データセンターには十分なネットワーク帯域幅が必要です。これらの要件は時として放置されがちです (それぞれのプロ
ジェクトスコープ外のため)。これらを放置すると、信頼性の高いシステムを構築する際に重大な影響を与える可能性があります。オンプレミス環境では、依存関係の影響によりこれらの要件を満たすには⻑い時間を必要とします。そのため計画の初期に組み込まれる必要があります。
では、ほとんどの基礎要件は組み込み済みであるか、必要に応じて利⽤できます。クラウドは基本的に制限がないように設計されています。そのため、十分なネットワーキングおよびコンピューティングキャパシティの要件を満たすのは AWS の責任であり、お客様はオンデマンドでストレージデバイスのサイズなどのリソースサイズおよび割り当てを⾃由に変更できます。

AWS

次の質問は、信頼性のための基本的な考慮事項に関するものです。
REL 1.

か。

アカウントの AWS サービス制限はどのように管理しています

REL 2. AWS

か。

19

ページ

でのネットワークトポロジをどのように計画していますアマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

は、お客様がリソースを意図せずよけいにプロビジョニングしてしまう事故を防止するため、サービス制限 (チームが要求できる各リソースの数の上限)を設定しています。これらの制限をモニタリングしビジネスのニーズに合わせて変更するために、適切なガバナンスおよびプロセスを設ける必要があります。クラウドを取り入れるにあたって、既存のオンプレミスリソースとの統合(ハイブリッドアプローチ) を計画しなければならない場合があります。ハイブ
リッドモデルにより、時間をかけて段階的にオールインのクラウド利⽤に移⾏することができます。そのため、AWS とオンプレミスのリソースがネットワー
クトポロジとして相互作用する方法を考えて設計することが重要です。

AWS

変更管理
変更がシステムに及ぼす影響を把握すれば事前に計画を⽴てることができます。モニタリングによって容量の問題や SLA 未達を引き起こす傾向をすばやく⾒つけることができます。旧来の環境では、変更制御のプロセスは⼿動である
ことが多く、変更を⾏う担当者や変更実施時期を効果的に制御するには、監査を受けながら注意深く調整しなければなりません。
を使用することで、システムの挙動をモニタリングし KPI の変化への対応を自動化できます。たとえば、システムのユーザーが増えた場合にサーバーを追加するなどです。誰にシステムを変更する権限を持たせるかを制御し、これらの変更の履歴を監査できます。

AWS

次の質問は、変更管理に関連する信頼性のための考慮事項に関するものです。

20

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 3.

システムは需要の変化にどのように対応できますか。

REL 4. AWS
REL 5.

リソースをどのようにモニタリングしていますか。

変更をどのように実⾏していますか。

需要の変更に対応してリソースを⾃動的に追加および削除するようにシステムを設計すると、信頼性が向上するだけでなく、ビジネスの成功が重荷ではなくなります。適切にモニタリングしていれば、KPI が予想した水準を逸脱した場合、チームは⾃動的にアラートを受信します。環境に対する変更を自動的に記録することで、それを監査し信頼性に影響を与えるアクションをすばやく識別できます。変更管理を統制することで、必要とされる信頼性を達成するためのルールを強化できます。
障害管理
合理的な複雑性を持つシステムでは、障害は発⽣するものです。このような障害を感知し、対応し、再発を防止する方法には、誰しも関心を持っています。
では、モニタリングデータに対応するために自動化を活用できます。
たとえば、特定のメトリックスがしきい値を超えたとき、自動化されたアクションをトリガーして問題を修正できます。また、本番環境の一部である、障害が発生したリソースを診断して修正するのではなく、新しいものに置換して、障害が発生したリソースを本番環境外で分析できます。クラウドでは低価格で⼀時的なバージョンとしてシステム全体を⽴ち上げることができるため、自動化されたテストを使⽤して復旧プロセス全体を検証できます。

AWS

次の質問は、障害管理に関する信頼性のための考慮事項に関するものです。
21

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 6.

データをどのようにバックアップしていますか。

REL 7.

システムはコンポーネントの障害にどのように対応します

REL 8.

弾⼒性をどのようにテストしていますか。

REL 9.

災害対策についてどのように計画していますか。

か。

論理エラーおよび物理エラーの両⽅から確実に復旧するように、定期的にデータをバックアップし、バックアップファイルをテストしてください。障害管理の要は、障害から復旧までの⾃動化されたシステムのテストを頻繁に実⾏することです (定期スケジュールに加えて、⼤規模なシステム変更後にも実⾏されるのが理想です)。システムの弾⼒性 (特に障害テストシナリオ内で) を評価して、目標復旧時間 (RTO) および目標復旧時点 (RPO) などの KPI を能動的にト
ラッキングしてください。KPI をトラッキングすることで、単一障害点を識別し修正する⼿がかりになります。目標は、システム復旧プロセスを徹底的にテストし、問題が解決できない局⾯においても、すべてのデータが復旧可能で顧客へのサービスを継続できる確信を持ち続けることです。復旧プロセスは通常の本番稼働プロセスと同様に習熟されていなければなりません。
関連する AWS サービス

信頼性を確実にする要となる AWS サービスは、実⾏中のメトリックスをモニタリングする Amazon CloudWatch です。信頼性の 3 つの領域をサポートする
その他のサービスと機能は、次のとおりです。

22

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

基礎: AWS Identity and Access Management (IAM) により、お客様のユーザーの AWS サービスおよびリソースへのアクセスを安全にコントロールすることができます。Amazon VPC を使用すると、AWS クラウドの隔離されたプライ
ベートなセクションをプロビジョニングし、仮想ネットワークで AWS リソー
スを起動することが可能になります。
変更管理: AWS CloudTrail は、アカウントの AWS API コールを記録し、アカウント保持者に監査用のログファイルを送信します。AWS Config は AWS リソー
スのおよび設定の詳細インベントリーを提供し、継続して設定の変更を記録します。
障害管理: AWS CloudFormation では AWS リソース作成用にテンプレートを提供して、整然とした予測可能な方法でプロビジョニングできます。
リソース

信頼性に関連するベストプラクティスの詳細については、以下のリソースを参照してください。
ビデオおよびアナリストレポート• 障害の受け入れ: 障害の意図的な生成とサービスの信頼性• クラウドでの可用性と信頼性のベンチマーク
ドキュメントおよびブログ• サービスの制限• サービス上限についてのブログ

23

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ホワイトペーパー• AWS を用いたバックアップアーカイブおよびリカバリのアプローチ• 大規模環境での AWS インフラストラクチャの管理• AWS 災害対策
• AWS Amazon VPC のネットワーク接続オプション
サポート• AWS プレミアムサポート

AWS•

Trusted Advisor

パフォーマンス効率の柱

パフォーマンス効率の柱は、コンピューティングリソースを要求に合わせて効率的に使⽤し、需要の変化や技術の進化に合わせてその効率を維持すること
です。
設計の原則

クラウドでは、パフォーマンス効率を達成するいくつかの原則があります。
•

24

先端技術の一般化: 技術の知識や複雑性をクラウドベンダーの領域に押しやることで、実装が難しかった技術の利⽤がより簡単になります。
IT チームに新技術のホストおよび実⾏⽅法を学習してもらうよりも、
単純にサービスとして使用してもらうことができます。たとえば、
NoSQL データベース、メディア変換、機械学習はどれも専門知識を必要とする技術ですが、この専門知識は技術コミュニティに広く⾏き渡っているわけではありません。クラウドでは、これらの技術はチームが使用できるサービスとなり、リソースのプロビジョニングや管理よりも製品開発に注⼒できます。

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

グローバル化を即座に達成: わずか数クリックで、世界中の複数のリージョンにシステムを簡単にデプロイします。これにより、最小限のコストで、より低いレイテンシーとより良いエクスペリエンスを顧客に提供できます。
• サーバーレスアーキテクチャの使用: クラウドでは、サーバーレスアー
キテクチャにより、従来のコンピューティング活動を実⾏するサーバーを稼働させ維持する必要がなくなります。たとえば、ストレージサービ
スは静的ウェブサイトとして動作でき、ウェブサーバーの必要がなくな
ります。イベントサービスならお客様のプログラムコードをホストできます。サーバーを管理するオペレーション上の負担がなくなるだけでな
く、トランザクションコストが低くなります。なぜなら、これらのマ
ネージドサービスは、クラウドのスケールで実⾏されるからです。
• 実験の頻度の増加 : 仮想化された自動化可能なリソースを使用して、異なったタイプのインスタンス、ストレージ、設定を使⽤した⽐較テス
トを簡単に実⾏できます。
• 適合したテクノロジーアプローチ: 実現させようとしていることに最も適したテクノロジーアプローチを使用します。たとえば、データベース
またはストレージアプローチを選択する際にデータアクセスパターンを検討します。
•

25ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
定義

クラウドでのパフォーマンス効率には、次の 4 つのベストプラクティスの領域があります。
選択 (コンピューティング、ストレージ、データベース、ネットワーク)
2. 確認
3. モニタリング
4. トレードオフ
1.

データ駆動型アプローチを採用して、高パフォーマンスのアーキテクチャを選択します。ハイレベルな設計からリソースタイプの選択と設定まで、アーキテ
クチャのあらゆる側⾯についてデータを収集します。定期的に選択内容を⾒直すことで、AWS プラットフォームを継続的に発展させるというメリットが得られます。モニタリングにより、期待するパフォーマンスからの逸脱を認識して、それに対するアクションをとることができます。最後に、圧縮またはキャッシュなどを使用するか、整合性要件を緩和することで、アーキテクチャのトレードオフを通じてパフォーマンスを向上させることができます。
ベストプラクティス

選択
特定のシステムに向けた適切なソリューションは、抱えているワークロードの種類によって異なり、多くの場合、複数のアプローチを組み合わせたものになります。優れた設計のシステムでは、複数のソリューションを使用し、さまざまな機能を有効にしてパフォーマンスを向上させます。

26

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

では、リソースは仮想化され、さまざまなタイプおよび設定で利⽤できます。これにより、ニーズに忠実に⼀致するアプローチを⾒つけることがより簡単になるとともに、オンプレミスのインフラストラクチャでは簡単に実現できないストレージの選択肢も得られます。たとえば、Amazon DynamoDB などのマネージド型サービスは、どのような規模でも、数ミリ秒台のレイテンシーの
フルマネージド型 NoSQL データベースを提供します。

AWS

次の質問例は、選択の考慮事項に関するものです。
PERF 1.

最良の実⾏アーキテクチャをどのように選択していますか。

アーキテクチャのパターンと実装を選択するときは、最適なソリューションに
データ駆動型のアプローチを使用します。AWS ソリューションアーキテクト、AWS リファレンスアーキテクチャ、および AWS パートナーは経験や実績に基づくアーキテクチャの選択に役⽴ちますが、アーキテクチャの最適化にはベン
チマークまたはロードテストから取得したデータが必要です。
アーキテクチャは、さまざまなアーキテクチャアプローチ (イベント駆動型、
ETL、パイプラインなど) を組み合わせる可能性が高くなります。アーキテク
チャの実装では、アーキテクチャのパフォーマンスの最適化に特有の AWS
サービスが使用されます。以下のセクションでは、考慮すべき 4 つの主要なリ
ソースタイプ (コンピューティング、ストレージ、データベース、およびネットワーク) を⾒ていきます。

27

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

コンピューティング
特定のシステムに向けた適切なコンピューティングソリューションはアプリ
ケーション設計、使⽤パターン、構成設定によって異なります。アーキテク
チャでは、パフォーマンスを向上させるために、さまざまなコンポーネントに対して異なるコンピューティングソリューションを使⽤し、異なる機能を有効にします。システムに対して適切でないコンピューティングソリューションや機能を選択すると、パフォーマンス効率が低下する可能性があります。
では、コンピューティングはインスタンス、コンテナ、関数という 3 つの形式で利⽤できます。

AWS

インスタンスは仮想化されたサーバーであるため、ボタンクリックまたは API コールで機能を変更できます。クラウド上でのリソースの決定が変更できないものではなくなったため、異なるサーバータイプで実験できます。AWS では、これらの仮想サーバーインスタンスは異なるファミリーおよびサイズで使用でき、ソリッドステートドライブ (SSD) やグラ
フィック処理ユニット (GPU) を含む幅広い機能を提供します。
• コンテナは、アプリケーションとそのリソースを分離したプロセスの依存関係を実⾏できるオペレーティングシステム仮想化の⽅法です。
• 関数は実⾏するコードから実⾏環境を抽象化します。たとえば、 AWS
Lambda ではインスタンスを実⾏せずにコードを実⾏できます。
次の質問例は、コンピューティングの考慮事項に関するものです。
•

PERF 2.

すか。

28

ページ

コンピューティングソリューションをどのように選択していまアマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

コンピューティングの使用を設計するときは、需要の変化に応じてパフォーマンスを維持するのに十分なキャパシティを確保するために利⽤できる伸縮⾃在
性のメカニズムを利⽤する必要があります。
ストレージ
特定のシステムの最適なストレージソリューションは、アクセス方法の種類(ブロック、ファイル、またはオブジェクト)、アクセスのパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフ
ライン、アーカイブ)、更新頻度 (WORM、動的)、および可用性と耐久性の制約によって異なります。優れた設計のシステムでは、複数のストレージソ
リューションを使用し、さまざまな機能を有効にしてパフォーマンスを向上させます。
では、ストレージは仮想化され、さまざまなタイプで利⽤できます。
これにより、データ保管方法をニーズに一層忠実に一致させることがより簡単になるとともに、オンプレミスのインフラストラクチャでは簡単に実現できないストレージの選択肢も得られます。たとえば、Amazon S3 は、イレブンナイ
ン (99.999999999%) の堅牢性を実現するよう設計されています。また、マグ
ネティックハードドライブ (HDD) の使用をソリッドステートドライブ (SSD)に変更することも、仮想ドライブを 1 つのインスタンスから別のインスタンスに数秒で簡単に移動することもできます。

AWS

次の質問例は、パフォーマンス効率を向上させるためのストレージの考慮事項
に関するものです。
PERF 3.

29

ページ

ストレージソリューションをどのように選択していますか。

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ストレージソリューションを選択する際には、アクセスパターンと一致することを確認して、必要なパフォーマンスを達成することが不可⽋です。
データベース
特定のシステムに最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、拡張性、およびクエリ機能についての要件によって異なります。多くのシステムでは、パフォーマンスを向上させるために、さまざまなサブシステムに対して異なるデータベースソリューションを使⽤し、異なる機能を有効化しています。システムに対して適切でないデータ
ベースソリューションや機能を選択すると、パフォーマンス効率が低下する可能性があります。
では、Amazon Relational Database Service (RDS) が、完全マネージド型
リレーショナルデータベースサービスを提供します。Amazon RDS を使用すれば、データベースのコンピューティングリソースやストレージリソースをスケールすることができ、多くの場合、ダウンタイムは発生しません。Amazon
DynamoDB は、どのような規模でも、数ミリ秒台に抑えらえれたレイテンシーを提供する、フルマネージド型 NoSQL データベースです。Amazon Redshift
は、パフォーマンスまたはキャパシティーのニーズが変わったときにノードの数やタイプを変更することができる、マネージド型でペタバイトスケールのデータウェアハウスです。

AWS

次の質問例は、パフォーマンス効率を向上させるためのデータベースの考慮事項に関するものです。
PERF 4.

30

ページ

データベースソリューションをどのように選択していますか。

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ワークロードのデータベース手法 (RDBMS、NoSQL など) はパフォーマンス効率に⼤きな影響を与えますが、これはデータ駆動型のアプローチを通じてではなく、組織のデフォルトに従って選択されることがしばしばある領域です。
ストレージと同様に、ワークロードのアクセスパターンを検討し、他の非デー
タベースソリューションが問題をより効率的に解決できるかどうかを検討することも重要です (検索エンジンやデータウェアハウスの使⽤など)。
ネットワーク
特定のシステムに最適なネットワークソリューションは、レイテンシー、
スループット要件などによって異なります。ユーザーやオンプレミスリソースなどの物理的な制約によりロケーションの選択が決まりますが、エッジの手法
やリソースの配置を使用して制約を相殺することができます。
では、ネットワーキングは仮想化され、さまざまなタイプおよび設定で利用できます。これにより、ネットワーキングの方法をニーズにさらに近づける
ことが容易になります。AWS はネットワークトラフィックを最適化するための製品機能 (非常に⾼度なネットワークインスタンスタイプ、Amazon EBS 最適
化 イ ン ス タ ン ス 、 Amazon S3 Transfer Acceleration 、 Dynamic Amazon
CloudFront など) を提供します。AWS はネットワーク距離またはジッターを低減するためのネットワーク機能 (Amazon Route53 レイテンシールーティング、
Amazon VPC エンドポイント、AWS Direct Connect など) も提供します。

AWS

次の質問例は、パフォーマンス効率を向上させるためのストレージの考慮事項
に関するものです。
PERF 5.

31

ページ

ネットワークソリューションをどのように選択していますか。

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ネットワークソリューションを選択するときは、ロケーションを考慮する必要があります。AWS を使⽤すると、距離を縮めるために使⽤する場所の近くにリソースを配置することができます。リージョン、プレースメントグループ、
エッジロケーションを利⽤することで、パフォーマンスを⼤幅に向上させることができます。
確認
ソリューションの設計には、選択できる一定のセットのオプションがあります。しかし、時間がたつと、アーキテクチャのパフォーマンスを向上させる可能性のある新しいテクノロジとアプローチが利⽤可能になります。
を使用することで、お客様のニーズに基づいた継続的なイノベーションを活用できます。新しいリージョン、エッジロケーション、サービス、機能を定期的にリリースします。これらのいずれも、お客様のアーキテクチャーのパフォーマンス効率を積極的に向上させる可能性があります。

AWS

次の質問例は、パフォーマンス効率を向上させるための確認に関するものです。
新しいリソースタイプや機能の提供が開始される中で、どのようにして最適なリソースタイプを使い続けていることを担保していますか。
PERF 6.

アーキテクチャのパフォーマンスが制限されている場所を理解することで、その制約を緩和できるリリースを検討することができます。
モニタリングアーキテクチャを実装したら、パフォーマンスを監視して、顧客が認識する前に問題を修正する必要があります。しきい値を超過した場合にアラームを送信
32

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

させるには、モニタリングメトリックを使用する必要があります。アラーム
は、パフォーマンスの悪いコンポーネントを回避するための自動化されたアクションをトリガーすることができます。
は AWS を使用して通知アラームを監視および送信し、自動化を使用して Amazon Kinesis、Amazon Simple Queue Service (SQS)、および
AWS Lambda を介してアクションをトリガーすることでパフォーマンスの問題を回避することができます。

Amazon CloudWatch

次の質問例は、パフォーマンス効率を向上させるためのモニタリングに関するものです。
起動後のリソースが期待どおりの性能を出すように、リソースをどのようにモニタリングしていますか。
PERF 7.

あまりにも多くの誤検出がないか、データを処理しきれなくなっていないかを確認することは、効果的なモニタリングソリューションを実現する上で重要です。自動トリガーは人為的なミスを防ぎ、問題を修正する時間を短縮することができます。本番環境でシミュレーションを⾏う「ゲームデー」を計画して、モニタリングソリューションをテストし、問題を正しく認識できるようにします。
トレードオフソリューションを構築するときに、トレードオフを考慮することで、最適なアプローチを選択できます。状況に応じて、整合性、耐久性、スペースと時間、およびレイテンシーをトレードして、より高いパフォーマンスを実現できます。
33ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

を使用すれば、即座にグローバル化を達成し、世界各地の複数の場所でリソースをデプロイして、エンドユーザーに近づけることができます。また、読み取り専用レプリカをデータベースシステムなどの情報ストアに動的に追加し、プライマリデータベース上の負荷を減らすこともできます。AWS は、イン
メモリデータストアまたはキャッシュを提供する Amazon ElastiCache や、静的コンテンツのコピーをエンドユーザーの近くにキャッシュする Amazon
CloudFront などのキャッシュソリューションも提供しています。

AWS

次の質問例は、パフォーマンス効率を向上させるための容量と時間のトレード
オフに関するものです。
パフォーマンスを向上させるためにトレードオフをどのように使用しますか。
PERF 8.

トレードオフにより、アーキテクチャの複雑さが増すことがあります。また、どのくらいの利点があるか確認するためロードテストが必要になることがあります。
関連する AWS サービス

パフォーマンス効率を⾼めるための主要な AWS サービスは、 Amazon
CloudWatch です。これはリソースやシステムをモニタリングし、パフォーマ
ンス全体および運用健全性を可視化します。以下のサービスは、パフォーマン
ス効率の領域において重要です。
選択:
34

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

コンピューティング: Auto Scaling は、需要を満たし応答性を維持するために十分なインスタンスを確保するための鍵となります。
ストレージ: Amazon EBS は、ユースケースにあわせて最適化するための広範囲なストレージオプション (SSD やプロビジョニングされた 1 秒あたりの⼊⼒/出⼒オペレーション数 (PIOPS) など) を提供します。Amazon S3 はサーバーレスのコンテンツ配信機能を提供し、Amazon S3 Transfer Acceleration によって⻑距離間でファイルを⾼速、簡単、安全に転送できます。
データベース: Amazon RDS は、ユースケースにあわせて最適化できる広範囲なデータベース機能 (プロビジョンド IOPS やリードレプリカなど) を提供します。Amazon DynamoDB は、どのような規模でも、数ミリ秒台に抑えらえれたレイテンシーを提供します。
ネットワーク: Amazon Route 53 はレイテンシーに基づくルーティングを提供します。Amazon VPC エンドポイントと Direct Connect を使用すると、ネットワークの距離やジッターを低減できます。
確認: AWS ブログと AWS ウェブサイトの「最新情報」セクションは、新機能や新しいサービスについて学習するためのリソースです。
モニタリング: Amazon CloudWatch は、既存の監視ソリューションと統合でき、AWS Lambda でアクションをトリガーするために使用できるメトリック
ス、アラーム、および通知を提供します。
トレードオフ: Amazon ElastiCache、Amazon CloudFront、AWS Snowball によりパフォーマンスを改善できます。Amazon RDS のリードレプリカにより、読み込み負荷の高いワークロードを拡大することができます。

35

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
リソース

パフォーマンス効率に関連するベストプラクティスの詳細については、以下のリソースを参照してください。
動画•

Performance Channel•

AWS

におけるパフォーマンスベンチマーキング
ドキュメント• Amazon S3 パフォーマンスの最適化• Amazon EBS ボリュームのパフォーマンス
コストの最適化の柱

コストの最適化の柱には、ライフサイクル全体にわたるシステムの改善と継続的な改善のプロセスが含まれます。最初の概念実証の初期設計からプロダク
ションワークロードの実⾏中の操作まで、このホワイトペーパーのプラクティ
スを採用することで、ビジネス上の成果を達成しコストを最小限に抑えるコス
ト意識の⾼いシステムを構築して運⽤することができ、投資収益率を最⼤化で
きます。
設計の原則

クラウド上では、コストの最適化を達成できる数多くの原則に従うことができます。
• 消費モデルの採用 : 詳細な予測を使用するのではなく、消費するコン
ピューティングリソースに対してのみ⽀払いを⾏い、ビジネス要件に応じて使⽤量を増減します。たとえば、開発環境とテスト環境は、通常、
36ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

週中 1 日 8 時間しか使用されません。使用しないときはこれらのリソースを停止して最大 75% のコストを節約できます (40 時間対 168 時間)。
• 大幅なスケールメリット: クラウドコンピューティングを使用すると、自社環境よりも低い変動コストを実現できます。AWS には高いスケール
メリットがあるためです。数十万単位のユーザーの使用が AWS クラウドに集約されるため、従量課⾦制の料⾦も低くなります。
• データセンターの運⽤への投資が不要に : サーバーのラッキング、ス
タック、電源供給といった手間のかかる作業は AWS が⾏うため、お客様は IT インフラストラクチャではなく自社の顧客やビジネスプロジェク
トに集中することができます。
• 投資の分析と要因の把握: クラウドを使⽤すると、システムの使⽤量とコストを正確に特定することが容易になり、IT コストを個々のビジネスオーナーに明確に帰属させることができます。これは投資効果 (ROI) を測定する助けとなり、リソースを最適化して、コストを削減化するための機会をシステムオーナーに与えることになります。
• マネージドサービスを使用して所有コストを減らす: クラウド上では、マネージドサービスは E メールの送信といったタスクを⾏うサーバーの保守や、データベースの管理のような運⽤⾯の負荷を取り除きます。さらに、マネージドサービスはクラウドスケールで実⾏されるため、トランザクションまたはサービスあたりのコストが低くなります。
定義

クラウド上でのコストの最適化には、次の 4 つのベストプラクティスの領域があります。
1. コスト効果が高いリソース
2. 供給と需要の一致
37

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

費用の把握
4. 継続した最適化
3.

他の柱と同様に、考慮すべきトレードオフがあります。たとえば、最適化した
いのは市場投⼊時間ですか、またはコストですか。場合によっては、先⾏コストの最適化に投資するのではなく、市場投入時間、新機能の提供、または単純に期日の順守といった、スピードの最適化が最善であることもあります。設計
上の決定は、経験的データを使⽤せずにあわてて⾏われる場合があります。コ
スト最適化したデプロイのベンチマークに時間を費やすよりも、「念のため」に過度な補償を⾏いたくなるためです。これにより、過度にプロビジョニング
しすぎ、最適化されていないデプロイがしばしば生まれます。以下のセクショ
ンでは、デプロイの初期コストの最適化および継続的なコストの最適化についての技術的および戦略的なガイダンスを⽰します。
ベストプラクティス

コスト効果が高いリソース
システムに対して適切なインスタンスとリソースを使⽤することが、コスト削減の鍵となります。たとえば、⼩規模なサーバーでレポートを作成する処理に5 時間かかるところ、コストが 2 倍の大規模なサーバーでは、これを 1 時間で実⾏できるとします。どちらのジョブでも結果は同じですが、⼩規模なサーバーでは時間とともにより多くのコストが発生します。
優れた設計のシステムでは、最もコスト効率の⾼いリソースが使⽤され、それにより大きなコスト効果が得られます。また、コストを削減するために、マネージドサービスを使用することもできます。たとえば、E メール配信のために複数のメールサーバーを維持する代わりに、メッセージごとに課⾦するサービスを使用することができます。
38ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

は柔軟でコスト効率が⾼いさまざまな料⾦オプションを提供し、ニーズに最も合った方法で Amazon EC2 インスタンスを利⽤できるようにします。オン
デマンドインスタンスは、最低契約⾦なしに、時間単位で、コンピューティン
グ性能に対して料⾦をお⽀払いいただくものです。リザーブドインスタンス(RI) では、キャパシティーを予約し、オンデマンド料⾦の最⼤ 75 パーセントを節約できます。スポットインスタンスでは、使用されていない Amazon EC2
キャパシティーを、⼤幅な割引で価格を指定して利⽤することができます。ス
ポットインスタンスは、HPC やビッグデータのように、サーバー群の中の個々のサーバーが、動的に追加/削除されるような状況での利⽤に適しています。

AWS

次の質問例は、コスト最適化のために、コスト効率の⾼いリソースを選択する
方法に関するものです。
ソリューションに AWS サービスを選択する際のコストを検討していますか。
COST 1.

COST 2.

コスト目標を達成するためにリソースのサイズを決定しまし

COST 3.

コスト目標を達成するために適切な料⾦モデルを選択してい

たか。

ますか。

などのツールを使用して定期的に AWS の使⽤量を確認することで、使⽤率をアクティブにモニタリングし、それに応じてデプロイを調整できます。

AWS Trusted Advisor

39

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

供給と需要の一致
供給と需要を最適に一致させることで、システムのコストは最少となりますが、プロビジョニングの時間と個別のリソースの障害を考慮して、十分な供給の余⼒を確保しておく必要もあります。需要は固定または可変の場合があるた
め、管理が⼤きなコストとならないようにメトリックスと⾃動化が必要になります。
では、需要に合わせて自動的にリソースをプロビジョニングできます。
Auto Scaling 、需要、バッファ、時間ベースの手法により、必要に応じてリソースを追加または削除できます。需要の変動を予想できる場合、より費用を節約し、リソースをシステムのニーズに一致させることができます。
AWS

次の質問例は、コスト最適化のための供給と需要の⼀致に関するものです。
キャパシティーが必要量を満たしているが⼤幅に超えていな
いことをどのように実現していますか。
COST 4.

需要と供給とを一致させるように設計するときは、新しいリソースをプロビ
ジョニングするのに使用されるパターンや時間のパターンについて積極的に考える必要があります。
費用の把握
クラウドで柔軟性と俊敏性が高まることにより、イノベーションと速いペースの開発およびデプロイが容易になります。ハードウェア仕様の確認、価格⾒積りの交渉、発注書の管理、配送のスケジュール、リソースのデプロイなど、オンプレ
ミスインフラストラクチャのプロビジョニングに関連する手動のプロセスと時間
40ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワークが排除されます。ただし、使いやすさと事実上無制限のオンデマンドキャパシ
ティーでは、支出に関する新しい考え方が必要になる場合があります。
多くのビジネスは、さまざまなチームによって実⾏される複数のシステムで構成されています。それぞれのビジネスオーナーまたは製品オーナーにリソースのコストを割り当てるようにすると、リソースを効率的に利⽤するようになり、無駄を低減できます。正確なコストを特定することで、実際に利益率の⾼い製品を把握することができ、予算の配分先についてより多くの情報に基づいた決定ができるようになります。
次の質問例は、コストの最適化のための費⽤の把握に関するものです。
アーキテクチャを設計するときに、データ転送料⾦について考慮しましたか。
COST 5.

COST 6.

使用状況と支出をどのようにモニタリングしていますか。

必要なくなったリソースは廃棄していますか。または、一時的に必要ないリソースを停止していますか。
COST 7.

の使⽤状況を管理するためにどのような管理と⼿順を実⾏していますか。
COST 8. AWS

コスト配分タグを使用して、AWS コストをカテゴライズおよび追跡できます。
使用している AWS リソース (たとえば Amazon EC2 インスタンスや Amazon S3バケット) にタグを適⽤すると、使⽤量とコストをタグごとに集計したコスト
配分レポートが生成されます。自社のカテゴリ (たとえばコストセンター、シ41

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ステム名、所有者) を表すタグを適用すると、複数のサービスにわたってコストを分類することができます。
タグ付けされたリソースとエンティティライフサイクル追跡 (従業員、プロジェクト) を結合することで、ビジネス上の価値を生み出しておらず、削除する必要のある孤⽴したリソースやプロジェクトを確認できます。予測される費用超過を通知する請求アラートを設定できます。また、AWS 簡易⾒積りツール
によりデータ転送コストを計算することもできます。
継続した最適化
AWS が新しいサービスや機能を公開するときに、既存のアーキテクチャ上の決定を⾒直し、それらが引き続き最もコスト効果が⾼いことを確認するのがベス
トプラクティスです。要件が変わったら、必要なくなったリソースとサービス全体またはシステムを積極的に廃棄します。
のマネージドサービスにより、しばしばソリューションを大幅に最適化できるため、利⽤可能になった新しいマネージドサービスについて確認することをお勧めします。たとえば、 Amazon RDS データベースの実⾏は、Amazon
EC2 で独自のデータベースを実⾏するよりも安価になる場合があります。

AWS

次の質問例は、コスト最適化のためのコストの再評価に関するものです。
COST 9.

すか。

42

ページ

新しいサービスの採⽤をどのように管理または検討していま

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

デプロイされたシステムを定期的に確認することで、新しい AWS サービスを利用してコストを下げることがしばしば可能になります。また、より新しいサー
ビスが費⽤を節約するためにどのように役⽴つかを評価します。たとえば、Aurora 用の AWS RDS を使用すると、リレーショナルデータベースのコストを削減できます。
関連する AWS サービス

コストの最適化をサポートする主な AWS 機能はコスト配分タグで、システムのコストを理解するうえで役⽴ちます。以下のサービスと機能は、コスト最適化の 4 つの領域に関して重要です。
コスト効果が高いリソース: リザーブドインスタンスと前払いのキャパシティ
を使用してコストを削減できます。AWS Trusted Advisor を使用してお客様のAWS 環境を検査し、コスト削減の機会を⾒つけることができます。
供給と需要の一致: Auto Scaling では、費用の超過を抑えて、需要に合わせてリソースを追加または削除できます。
費用の把握 : Amazon CloudWatch アラームと Amazon Simple Notification
Service (SNS) では、予算額を超えた場合や、予算額を超える⾒通しの場合に警告を通知することができます。
継続した最適化: AWS ブログと AWS ウェブサイトの「最新情報」セクション
は、新機能や新しいサービスについて学習するためのリソースです。 AWS
Trusted Advisor は AWS 環境を検査し、使用されていないリソースやアイドル状態のリソースを排除したり、リザーブドインスタンス容量をコミットしたりすることで、コスト削減の可能性を⾒つけます。
43ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

リソース

コストの最適化に関連する AWS ベストプラクティスの詳細については、以下の参考資料を参照してください。
動画
•

AWS

でのコスト最適化

ドキュメント• AWS クラウドエコノミクスセンター
ツール

総所有コスト (TCO) 計算ツール• AWS 詳細な請求レポート• AWS 簡易⾒積りツール• AWS コストエクスプローラー
•

44

AWS

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
運用性の柱

運用の柱には、本番環境のワークロード管理に利⽤される運⽤⼿法と⼿順が含まれます。これには、どのように計画された変更を実⾏するのかや予期しない
運用イベントへの応答が含まれます。変更の実⾏や応答は自動化されている必要があります。高い運用性のためのすべてのプロセスと手順は文書化して、テ
ストし、定期的に確認する必要があります。
設計の原則

クラウド上では、高い運用性を実現するいくつかの原則があります。
コードによるオペレーションの実⾏: 共通の反復プロセスまたは⼿順がある場合は、⾃動化を使⽤します。たとえば、構成管理、変更、およびイベントへの応答を自動化することを検討してください。
• オペレーションプロセスをビジネス目標に合わせる: ビジネス目標を達成する上で高い運用性を示すメトリックスを収集します。ゴールはメト
リックのノイズ信号を低減することであり、運用上のモニタリングと応答は、ビジネスクリティカルなニーズをサポートすることを目標としています。不要なメトリックスを収集することで、モニタリングと応答が複雑になるため、予期しない運用イベントへの効果的な対応が妨げられます。
• 定期的に、⼩規模で、増分変更を加える: ワークロードは、コンポーネントを定期的に更新できるように設計する必要があります。変更は、⼤規模バッチではなく、⼩さな増分で⾏う必要があり、オペレーションに影響を与えずにロールバックできる必要があります。メンテナンスや依

•

45

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

存するサービスコンポーネントの交換のための停止時間なしに、これらの変更を実装できるように、オペレーション⼿順を整えます。
• 予期しないイベントの応答のためのテスト: ワークロードは、コンポー
ネントの障害や他の予期しないイベントについてテストする必要があります。運用イベントに応答する⼿順をテストして理解することが重要であり、運用イベントが発生したときにその手順に従うようにしてください。ゲームデーを設定して、シミュレートされた運用イベントや失敗したインジェクションに対する応答をテストできます。
• 運用イベントと障害から学ぶ: すべてのタイプの運用イベントと障害がキャプチャされ、確認され、その後改善のために使用されるように、プロセスを定める必要があります。定期的な機能別のオペレーション確認によって、プロセスの改善がもたらされ、高い運用性が実現されるはずです。
• オペレーション手順を最新に保つ: プロセスと手順ガイドは、環境とオ
ペレーションの進展に適応されている必要があります。これには、通常のオペレーションランブック (標準的なオペレーション手順) のほか、プ
レイブック (予期しない運用イベントまたはプロダクションの障害に対する応答プラン) の更新も含まれます。間違いの繰り返しを防ぐために、オペレーションのガイダンスと学習をチーム間で共有する必要があります。この情報についての wiki または社内のサポート技術情報の使用を検討してください。評価すべき情報には、オペレーションメトリック
ス、予期しない異常、失敗したデプロイ、システム障害、および障害に対する効果的でない、または不適切な応答が含まれます。環境とオペ
レーションが進化するにつれて、システムとアーキテクチャの文書化も⾃動化を使⽤し、キャプチャして更新する必要があります。
46ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
定義

クラウド上で高い運用性を実現するには、次の 3 つのベストプラクティスの領域があります。
準備
2. 運用
3. 応答

1.

⾼い運⽤性を実現するには、準備が不可⽋です。ワークロードを設計する際のベストプラクティスに従うことで、多くの運用上の問題を回避することができます。また、実働環境ではなく設計フェーズで実装する方がコストがかかりません。オペレーションプロセスと手順は、徹底的に計画して、テストし、確認する必要があります。ワークロードは、⾃動化された管理可能な⽅法で進化して、変更される必要があります。変更は、継続的なオペレーションに影響を与えることなく、⼩規模に、頻繁に、増分で⾏う必要があります。オペレーショ
ンチームは、運用イベントや障害に対応する準備ができていなければなりま
せん。
ベストプラクティス

準備
高い運用性を実現するには、効果的な準備が必要です。運用チェックリストにより、本番運用のためのワークロードの準備ができていることを確認でき、十分な準備なしに意図せず実稼働に入ってしまうことを防止できます。ワーク
ロードには、オペレーションチームが通常の⽇常的なタスクを実⾏できるように (ランブック)、また予期しない運用イベントに対応できるように (プレイブック) 参照するためのオペレーションガイダンスが必要です。プレイブック
47

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワークには、応答プラン、エスカレーションパス、ステークホルダー通知が含まれている必要があります。運営上の変化を促すビジネスサイクルイベント (マーケティングイベント、フラッシュセールなど) の定期的な確認も実⾏する必要があります。ギャップや課題を特定し、潜在的なリスクを軽減できるように、すべてのランブックとプレイブックをテストする必要があります。失敗を追跡し、失敗から学ぶ仕組みが整備されているべきです。環境、アーキテクチャ、
およびそれらのリソースの設定パラメータは、追跡およびトラブルシューティ
ングのためにコンポーネントを容易に識別できる仕⽅で⽂書化する必要があります。設定の変更も追跡可能で⾃動化されている必要があります。
には、運用準備をサポートするために使用できる複数の方法、サービス、機能があり、また通常の日常運用と予期しない運用イベントに備える能⼒があります。運⽤の準備には、依然として⼿作業の⾊々な仕事や⾒落としを確実に防ぐためにピアレビューが含まれるかもしれません。AWS CloudFormation な
どの AWS サービスを使用して、実稼働環境にデプロイするときに必要なすべてのリソースが含まれていること、および環境設定がテストされたベストプラ
クティスに基づいていることを確認でき、ヒューマンエラーを減らせます。
Auto Scaling またはその他の自動スケーリングメカニズムを実装することで、ビジネス関連のイベントが運用上のニーズに影響する場合に、ワークロードが自動的に応答するようになります。 AWS Config ルール機能を備えた AWS
Config のようなサービスは、AWS ワークロードや環境での変更を⾃動的に追跡して対応するためのメカニズムを作成します。運用中や対応中の必要なときにワークロードのすべてのリソースを簡単に識別できるように、タグ付けなどの機能を使用することも重要です。

AWS

次の質問は、高い運用性に関する準備のための考慮事項に関するものです。

48

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

クラウドオペレーションのどのベストプラクティスを使用しているかOPS 1.

OPS 2.

ワークロードの設定管理はどのように⾏っているか

手順が変わった場合、ドキュメントが古いものにならないようにしてください。また、それがすべてを網羅していることを確認してください。アプリケー
ション設計、環境設定、リソース設定、対応プラン、および軽減プランがなけ
れば、ドキュメントは完全とは⾔えません。ドキュメントが定期的に更新されてテストされなければ、予期しない運用イベントが発⽣した時に役に⽴ちません。運用前にワークロードを確認しないと、検出されない問題が発生した場合に運用に影響が出ます。運用イベントが発生した時にリソースが文書化されていない場合、正しいリソースを特定し対応方法を決定することはより困難になります。
運用
運⽤は標準化され、⽇常的に管理可能なものである必要があります。⾃動化、
⼩規模で頻繁な変更、定期的な品質保証テスト、変更を追跡、監査、ロール
バック、および確認するための定義されたメカニズムに重点を置くべきです。
変更は、⼤規模なものや頻度が低いものであってはならず、スケジュールされたダウンタイムや⼿動での実⾏も不要であるべきです。ワークロードの主要な運用指標に基づく幅広いログとメトリクスを収集して確認し、継続的な運用を確実にする必要があります。
AWS では、継続的な統合/継続的デプロイメント (CI / CD) パイプライン (ソース
コードリポジトリ、ビルドシステム、デプロイメントおよびテスト自動化など)を設定できます。⼿動であれ⾃動であれ、リリース管理プロセスはテストされ、49ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

⼩さい差分変更と追跡されたバージョンに基づいていなければなりません。運⽤
上の問題を引き起こすことなく、運⽤上の問題を引き起こす変更を元に戻すことができます。変更の品質保証には、Blue/Green、Canary、A/B テストなどのリスク低減戦略が含まれている必要があります。運用チェックリストは、本番環境のワークロードが準備できていることを評価するために使用する必要があります。
⼀元管理されたモニタリングおよびアラート⽤にログを集計します。アラートが通知やエスカレーションなどの自動応答をトリガーするようにします。また、障害だけでなく、異常も監視するよう設計します。
次の質問は、高い運用性のためにワークロードをどのように運用するかに関するものです。
変更の影響を最⼩限に抑えながら、ワークロードをどのように進化させるかOPS 4. ワークロードが想定通りに動作していることを確認するために、どのように監視するか
OPS 3.

ルーチンオペレーションや計画外のイベントへの応答を自動化する必要があります。デプロイメント、リリース管理、変更、およびロールバックのための⼿動プロセスは避ける必要があります。リリースは頻度の低い大規模バッチであってはなりません。⼤規模な変更ではロールバックがより困難になり、ロー
ルバックプランを作成できないか、障害の影響を緩和できないため、オペレー
ションの持続性が損なわれます。モニタリングをビジネスニーズに合わせることで、ビジネスの継続性を維持する上で効果的な応答にすることができます。
手動による応答で場当たり的かつ一元化されていない監視は、予期しないイベ
ントでのオペレーションにより大きな影響を与えます。
50ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

応答
予期せぬ運用イベントへの応答は自動化されるべきです。これはアラートのためだけでなく、緩和、修復、ロールバック、復旧にも役⽴ちます。アラートはタイムリーである必要があり、また応答が運用イベントの影響を緩和するのに十分でない場合、エスカレーションを呼び出す必要があります。失敗したデプ
ロイメントを自動的にロールバックするには、品質保証のメカニズムを整えておく必要があります。応答は、ステークホルダー、エスカレーションプロセス
および手順を含む事前定義されたプレイブックに従う必要があります。エスカ
レーションパスを定義し、機能的および階層的エスカレーション機能の両方を含める必要があります。階層的エスカレーションは自動化され、エスカレート
された優先度はステークホルダーへの通知をもたらすべきです。
には、予期せぬ運用イベントや自動化された応答に応じて、適切なアラー
トと通知の両⽅を確実に⾏うためのメカニズムがいくつかあります。ワーク
ロードを⼀元的に監視し、主要な運⽤指標に関連するすべての利⽤可能なログとメトリクスに基づいて、効果的なアラートと通知を作成するためのツールも必要です。これには、サービスやコンポーネントの障害だけでなく、範囲外の異常に関するアラートや通知も含まれます。応答は、依存する AWS 環境とサービス、およびワークロードのアプリケーションの状態に対して有効にする必要があります。根本原因の分析 (RCA) は、運用イベントの後に実⾏し、アー
キテクチャと対応プランの両方を改善するために使用します。

AWS

次の質問は、高い運用性のためのイベントへの対応に関するものです。

51

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
OPS 5.

計画外の運用イベントにどのように対応するか

計画外の運用イベントに対応する場合、エスカレーションはどのように管理されるかOPS 6.

対応プランが場当たり的に⾏われ、定義されていない場合、結果は予測不可能であり、しばしばイベントに悪影響を与えます。期限切れのプレイブックに基づいた対応、または問題が発生しプレイブックにアクセスできない場合も、予測できない結果が生じます。もしプロセスがイベントを確認するのにふさわしくなく、そのため将来の運用イベントがより防止が困難になる場合は、同じようなインパ
クトがあります。
関連する AWS サービス

高い運用性を実現するために使用できる主なサービスが 2 つあります。AWS
CloudFormation を使用すれば、ベストプラクティスに基づいてテンプレートを作成し、リソースを整然とした予測可能な方法でプロビジョニングできます。Amazon CloudWatch は、メトリクスの監視、ログの収集、アラートの生成、および応答のトリガーに使用できます。高い運用性の 3 つのエリアをサポートするその他のサービスと機能は、次のとおりです。
準備: AWS Config は AWS リソースおよび設定の詳細インベントリーを提供
し、継続して設定の変更を記録します。AWS Service Catalog は、ベストプラク
ティスに合わせて標準化されたサービス提供を作成するのに役⽴ちます。ワー
クロードを、Auto Scaling や Amazon SQS などのサービスを利⽤した⾃動化を⾏うように設計すれば、予期しない運用イベントが発生した場合でも継続的な運用を確実にできます。
52ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

運用: AWS ワークロードへのコードの変更を管理し⾃動化するために、AWS
CodeCommit、AWS CodeDeploy、および AWS CodePipeline を使用できます。
オペレーションの変更を⾃動化するためには、AWS SDK またはサードパー
ティライブラリを使用します。AWS 環境に対して加えられた変更を監査し、追跡するには AWS CloudTrail を使用できます。
応答: Amazon CloudWatch サービスの機能を利⽤して、効果的かつ⾃動化された応答を実現できます。Amazon CloudWatch アラームを使用してアラートと通知のしきい値を設定でき、Amazon CloudWatch イベントは通知と自動化された応答をトリガーできます。
リソース高い運用性に関連するベストプラクティスの詳細については、以下のリソースを参照してください。
動画

での DevOps• AWS re:Invent 2015 - インフラストラクチャのスケーリング操作• AWS Summit 2016 - DevOps、AWS における継続的統合とデプロイメント•

AWS re:Invent 2015 – Amazon

ドキュメントおよびブログ• AWS と DevOps• 継続的な統合とは• 継続的な配信とは• AWS DevOps ブログ

53

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ホワイトペーパー• AWS クラウド導入フレームワーク - 運用の視点• AWS の DevOps 入門• AWS 運用チェックリスト
サポート• AWS クラウドオペレーションレビュー• AWS プレミアムサポートAWS•

AWS Trusted Advisor

まとめによる優れた設計のフレームワークは、クラウド上の信頼性、セキュリ
ティ、効率、コスト効果が⾼いシステムを設計および運⽤するための 5 つの柱についてアーキテクチャのベストプラクティスを提供します。このフレームワー
クには、既存のアーキテクチャまたは提案されたアーキテクチャを確認するための質問と、それぞれの柱についての AWS ベストプラクティスが用意されています。アーキテクチャでフレームワークを使⽤すると、安定した効率的なシステムを構築することができ、より機能的な要件に注目することができます。

AWS

寄稿者

本書の執筆に当たり、次の人物および組織が寄稿しました。
•、

Philip Fitzsimons Well-Architected

サービス

シニアマネージャー、アマゾン ウェブ、シニアプロダクトマネージャー、アマゾン ウェブ サービス•

Erin Rifkin

54

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク、プリンシパルセキュリティソリューションアーキテクト、ア
マゾン ウェブ サービス
• Scott Paddock、セキュリティソリューションアーキテクト、アマゾン ウェ
ブ サービス• John Steele、シニアテクニカルアカウントマネージャー、アマゾン ウェブ
サービス• Callum Hughes、ソリューションアーキテクト、アマゾン ウェブ サービス•

Max Ramsay

ドキュメント履歴2015

年 11 月 20 日: 最新の Amazon CloudWatch ログ情報で付録を更新しました。

年 11 月 20 日: フレームワークを更新しました。卓越したオペレーションの柱を含め、他の柱を改訂、更新して重複を削減しました。また、数千のお客様とともにレビューを⾏った結果から学んだこと組み込みました。

2016

55

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

付録: Well-Architected の質問、回答、ベス
トプラクティス

この付録には、ベストプラクティスを含む Well-Architected に関する質問と回答の完全な⼀覧が、柱ごとに整理されて含まれています。
セキュリティの柱
アイデンティティ管理とアクセス管理

ルートアカウントの認証情報へのアクセスと使用をどのように保護していますか。

SEC 1. AWS

ルートアカウントの認証情報は、他のオペレーティングシステムのルート
またはローカル管理者と似ており、非常に注意して使⽤する必要があります。
最新のベストプラクティスでは、AWS Identity and Access Management (IAM)
ユーザーを作成し、それらのユーザーを管理者グループに関連付けて、IAM
ユーザーを使ってアカウントを管理します。AWS のルートアカウントは、API
キーを保持せず、強⼒なパスワードがあり、ハードウェアの多要素認証 (MFA)
デバイスと関連付けられている必要があります。これにより、ルートアイデン
ティティの使用を AWS マネジメントコンソール経由のみに強制し、アプリ
ケーションプログラミングインターフェイス (API) コールにルートアカウントの使用を許可しません。注意：一部のリセラーやリージョンでは、AWS ルート
アカウントのクレデンシャルの配布やサポートは⾏われません。

AWS

56

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
ルートの MFA および最低限の使用 AWS ルートアカウントの認証情報は、必要最小限の作業にのみ使用されている。
• ルートを使用しない•

マネジメントコンソールと API へのユーザーによるアクセスを制御するために、システムユーザーのロールと責任をどのように定義していますか。

SEC 2. AWS

お客様にとって最新のベストプラクティスは、ユーザーグループを作成してシ
ステムユーザーの定義されたロールと責任を分離することです。ユーザーグ
ル ー プ は 複 数 の 異 な る 技 術 で 定 義 で き ま す 。 Identity and Access
Management (IAM) グループ、クロスアカウントアクセス用の IAM ロール、Security Assertion Markup Language (SAML) 統合によるウェブ認証 (例: Active
Directory でのロール定義)、または SAML や AWS Security Token Service (STS)により統合されるサードパーティーソリューションの使用 (Okta 、 Ping
Identity、別のカスタムテクニック) などです。共有アカウントは使用しないことを強くお勧めします。
ベストプラクティス:
従業員のライフサイクルが管理されている 従業員のライフサイクルポリ
シーが定義、実施されている。
• 最小限の権限 ユーザー、グループ、およびロールが明確に定義され、ビジネス要件を達成するために必要な最小の権限のみが付与されている。

•

57

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

リソースへの自動化されたアクセスをどのように制限していますか(アプリケーション、スクリプト、サードパーティーのツールやサービスなど)。
SEC 3. AWS

ユーザーグループは人について作成されるため、システムによるアクセスも同様の方法で定義する必要があります。Amazon EC2 インスタンスの場合、これらのグループは EC2 用の IAM ロールと呼ばれます。最新のベストプラクティ
スは、EC2 用の IAM ロールと AWS SDK または CLI を使用することです。これらには、EC2 認証情報のための IAM ロールを取得する機能が組み込まれています。従来、ユーザーの認証情報は EC2 インスタンス内に設定されていました
が、スクリプトやソースコードへの認証情報のハードコーディングはお勧めできません。
ベストプラクティス:
自動化されたアクセスに使用される静的認証情報 これらが安全に保管されている。
• 自動化されたアクセス用の動的認証 インスタンスプロファイルまたはAmazon STS を使⽤して管理する。

•

58

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
発⾒的統制
SEC 4.

ログをどのように取得して分析していますか。

ログの取得は、パフォーマンスからセキュリティインシデントまですべてを調査するために重要です。最新のベストプラクティスは、ビジネスニーズに基づ
いて、ログを定期的にソースから直接ログ処理システム (CloudWatch Logs、Splunk、Papertrail など) に移動するか、後で処理するために Amazon S3 バケッ
トに保存することです。ログの一般的なソースには、AWS API およびユーザー
関連ログ (AWS CloudTrail など) 、AWS サービス固有のログ (Amazon S3、Amazon CloudFront など)、オペレーティングシステム生成ログ、およびサード
パーティー製アプリケーション固有のログがあります。Amazon CloudWatch ロ
グを使用して、Amazon EC2 インスタンス、AWS CloudTrail、およびその他のリソースをモニタリング、保存、アクセスすることができます。
ベストプラクティス:
アクティビティが Amazon CloudWatch ログ、イベント、VPC フ
ローログ、ELB ログ、S3 バケットログなどを適切にモニタリングしている。
• AWS Cloud Trail が有効化されている• オペレーティングシステムまたはアプリケーションのログをモニタリン
グしている
•

59

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
インフラストラクチャの保護
SEC 5.

すか。

ネットワークおよびホストレベルの境界保護をどのように実施していま

オンプレミスデータセンターで、DMZ 手法ではファイアウォールを使用して異なるシステムを信頼済みゾーンと信頼されていないゾーンに分離します。
AWS で、ステートフルなファイアウォールとステートレスのファイアウォールの両方が使用されます。ステートフルなファイアウォールはセキュリティグ
ループと呼ばれ、ステートレスなファイアウォールは、Amazon Virtual Private
Cloud (VPC) のサブネットを保護するネットワークアクセスコントロールリス
ト (ACL) と呼ばれます。最新のベストプラクティスは、VPC でシステムを実⾏し、セキュリティグループでロールベースのセキュリティ (ウェブ層、アプリ
ケーション層など) を定義して、ネットワーク ACL で場所ベースのセキュリ
ティ (アベイラビリティーゾーンごとに 1 つのサブネットでの Elastic Load
Balancing 層、アベイラビリティーゾーンごとに別のサブネットでのウェブ層など) を定義することです。
ベストプラクティス:
でネットワークトラフィックが制御されている たとえば、ファイ
アウォール、セキュリティグループ、NACLS、踏み台ホストなどを使用する。
• 境界でネットワークトラフィックが制御されている たとえば、 AWS
WAF 、ホストベースのファイアウォール、セキュリティグループ、
NACLS などを使用する。
•

60

VPC

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
SEC 6. AWS

サービスレベルセキュリティ機能をどのように活用していますか。

のサービスで追加のセキュリティ機能が提供されている場合があります(Amazon S3 バケットポリシー、 Amazon SQS 、 Amazon DynamoDB 、 KMS
キーポリシーなど)。

AWS

ベストプラクティス:•

追加機能の適切な使⽤インスタンス上のオペレーティングシステムの整合性はどのように保護していますか。
SEC 7. Amazon EC2

別の従来の制御として、オペレーティングシステムの整合性の保護があります。これは、従来のホストベースの手法 (OSSEC 、 Tripwire 、 Trend Micro
Deep Security など) を使用して Amazon EC2 で簡単に⾏うことができます。
ベストプラクティス:
ファイルの整合性 EC2 インスタンス用にファイル整合性のコントロールが使用されている。
• EC2 侵入検出 EC2 インスタンス用にホストベースの侵入検出コントロールが使用されている。
• AWS Marketplace またはパートナーソリューションAWS Marketplace または APN パートナーからのソリューション。
• 設定管理ツール カスタム Amazon Machine Image (AMI) またはデフォル
トでセキュリティ保護される設定管理ツール (Puppet または Chef など)を使用している。

•

61

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
データ保護
SEC 8.

データをどのように分類していますか。

データを分類することで、レベルや重要度に基づいて構造化されたデータをカテゴリ分けできます。これには、使用できるデータ型、データの場所、アクセ
スレベル、データの保護 (たとえば暗号化かアクセス制御か) も含まれます。
ベストプラクティス:
データ分類スキーマの使用• すべてのデータを機密として扱う•

SEC 9.

保管時のデータをどのように暗号化、保護していますか。

伝統的なセキュリティ統制では、保管時のデータを暗号化します。AWS は、クライアント側 (SDK サポート、オペレーティングシステムサポート、Windows
Bitlocker、dm-crypt、Trend Micro SafeNet など) およびサーバー側 (Amazon
S3 など ) の両方を使用してこれをサポートしています。サーバー側の暗号化(SSE) や Amazon Elastic Block Store 暗号化ボリュームなどを使用することもできます。
ベストプラクティス:
不要 保管時のデータ暗号化は不要• 保存時の暗号化
•

62

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
SEC 10.

キーと認証情報をどのように管理していますか。

キーは、秘密情報であるため保護される必要があり、適切なローテーションポ
リシーを定義して管理する必要があります。ベストプラクティスは、これらの秘密情報を管理スクリプトやアプリケーションにハードコーディングしないことです。しかし、これはしばしば⾏われています。
ベストプラクティス:を使用する。
• AWS サービスのコントロール 保管時のデータを、AWS サービス固有の統制 (Amazon S3 SSE 、 Amazon EBS 暗号化ボリューム、 Amazon
Relational Database Service (RDS) Transparent Data Encryption (TDE) など) を使用して暗号化できる。
• クライアント側を使用 保管時のデータを、クライアント側の手法を使用
して暗号化する。
• AWS Marketplace またはパートナーソリューションAWS Marketplace または APN パートナーからのソリューション。
(SafeNet、TrendMicro など)。
•

AWS CloudHSM AWS CloudHSM

SEC 11.

伝送中のデータをどのように暗号化、保護していますか。

暗号化を使用することによって、伝送中のデータを保護するのがベストプラク
ティスです。AWS は、サービス API に対する暗号化エンドポイントの使用をサポートします。さらに、お客様は Amazon EC2 インスタンス内でさまざまな技術を使用できます。
63ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:• 必須でない 伝送中のデータは暗号化を要求されない。
• 暗号化された通信 通信には TLS またはそれと同等のものが適切に使⽤されている。
インシデントへの対応

インシデント対応が適切であることをどのように確認しますか。
セキュリティインシデントが発生する前にツールを導入してアクセスし、定期的にインシデント対応を実施することで、調査と復旧をタイムリーに⾏えるよ
うにアーキテクチャを更新できるようになります。
ベストプラクティス:
SEC 12.

事前にプロビジョニングされたアクセス 情報セキュリティに正しいアクセス権限がある、またはすばやくアクセスできる手段がある。インシデントに対して適切に対応できるように、事前にプロビジョニングされている必要があります。
• 事前にデプロイされたツール インシデントに対して適切に対応できるよ
うに、情報セキュリティで AWS に正しいツールが事前にデプロイされている• 本稼働以外でのゲームデー 本稼働環境以外でインシデント対応シミュ
レーションが定期的に実⾏され、そこで学んだ教訓がアーキテクチャや運用に生かされている。
• 本稼働でのゲームデー 本稼働環境でインシデント対応シミュレーション
が定期的に実⾏され、そこで学んだ教訓がアーキテクチャや運⽤に⽣かされている。
•

64ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
信頼性の柱
基礎
REL 1.

アカウントの AWS サービス制限はどのように管理していますか。

アカウントは、新しいユーザーが誤って必要以上のリソースをプロビジョ
ニングしないように、デフォルトのサービス制限でプロビジョニングされます。AWS のお客様は AWS サービスに関するニーズを評価し、使用している各リージョンについて制限の適切な変更をリクエストする必要があります。

AWS

ベストプラクティス:
制限のモニタリングと管理 AWS の使⽤量の可能性について評価し、リージョンの制限を適切に引き上げ、使⽤量の計画的な成⻑を可能にしている。
• 自動化されたモニタリングのセットアップ SDK などのツールを実装して、しきい値に近づいたときに警告を発する。
• サービスの固定の上限に注意 変更できないサービスの上限に注意し、それらを考慮した設計を⾏っている。
• フェイルオーバーに対応するために、サービスの上限とお客様の最大使
⽤量の間に⼗分な余裕を持たせてある• サービスの上限が、関連するすべてのアカウントとリージョンを含めて考慮されている•65ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 2. AWS

でのネットワークトポロジをどのように計画していますか。

アプリケーションは、EC2 Classic、VPC、デフォルト VPC の中のひとつ、または複数の環境で実⾏することができます。システム接続性、Elastic IP/パブリック IP アドレスの管理、VPC/プライベート アドレスの管理、名前解決などのネットワークの考慮点は、クラウドのリソースを利⽤する上で基礎となるものです。よく計画され、文書化されたデプロイは、重複や競合のリスクを減らすために必要不可⽋です。
ベストプラクティス:
データセンター内の接続性の考慮は不要• AWS とオンプレミス環境 (ある場合) 間の可用性の高い接続 複数の DX
接続、複数の VPN トンネル、AWS Marketplace アプライアンスの適切な利⽤。
• 負荷の高いユーザーのための可用性の高い接続 可用性の高い負荷分散またはプロキシ、DNS ベースのソリューション、AWS Marketplace アプラ
イアンス等の利⽤。
• 重複のないプライベート IP アドレス範囲 仮想プライベートクラウドのIP アドレス範囲とサブネットが互いに重複せず、他のクラウド環境やオンプレミス環境とも重複しない。
• IP サブネットの割り当て 個別の Amazon VPC の IP アドレス範囲は、将来の拡張やアベイラビリティーゾーン間でのサブネットに対する IP アド
レス割り当てを考慮し、アプリケーションの要件を満たすために十分な大きさがある。
•

66ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
変更管理

システムは需要の変化にどのように対応できますか。
スケーラブルなシステムは、いつの時点でも最新の需要に合わせて、リソースを自動的に追加、削除する伸縮性を備えています。
ベストプラクティス:• 自動スケーリング Amazon S3 、 Amazon CloudFront 、 Auto Scaling 、
Amazon DynamoDB 、 AWS Elastic Beanstalk など、自動スケーラブル
サービスを使用する。
• ロードがテスト済み ロードテスト手法を採用し、規模の拡大や縮小がア
プリケーションの要件に合うかどうか測定する。
REL 3.

リソースをどのようにモニタリングしていますか。
ログとメトリクスは、アプリケーションの健全性についての洞察を得るための強⼒なツールです。ログとメトリックスをモニタリングし、しきい値を超える
か重要なイベントが発生したときに通知を送信するようシステムを設定できます。低パフォーマンスのしきい値を超えるか、障害が発生した場合、システムが⾃動的に⾃⼰修復するか、それに応じてスケールするよう構築されていることが理想的です。
ベストプラクティス:• モニタリング Amazon CloudWatch またはサードパーティー製ツールでアプリケーションをモニタリングする。
• 通知 重要なイベントが発生した場合に通知を受け取るように計画します。
• 自動応答 自動化を使用して、障害が検出されたときに、失敗したコン
ポーネントを置き換えるなどのアクションを実⾏します。

REL 4. AWS

67

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 5.

変更をどのように実⾏していますか。

環境に対する変更を制御していないと、変更による影響を予測することが難しくなります。プロビジョニングされた AWS リソースとアプリケーションの変更制御は、アプリケーションと運⽤環境で既知のソフトウェアが実⾏されており、予測できる方法でパッチを適用または置換できることを確認するために必要です。
ベストプラクティス:•

自動化 デプロイおよびパッチ適用を自動化する。

障害管理
REL 6.

データをどのようにバックアップしていますか。

データ、アプリケーション、および運用環境 (アプリケーションで設定された
オペレーティングシステムと定義される) をバックアップし、平均修復時間(MTTR) および目標復旧時点 (RPO) の要件を満たします。
ベストプラクティス:
自動バックアップ AWS の機能、AWS Marketplace ソリューション、またはサードパーティー製ソフトウェアを使用してバックアップを自動化します。
• 定期的な復旧テスト 復旧テストを通じて、バックアップの実装が RTO
および RPO を満たすことを確認する。
•

68

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 7.

システムはコンポーネントの障害にどのように対応しますか。

アプリケーションが、⾼可⽤性と短い平均修復時間 (MTTR) を満たす、暗黙または明⽰の要件がありますか。そのような要件がある場合は、弾⼒性を持つようアプリケーションを設計し、機能停止に対処できるようにアプリケーションを配置します。より高いレベルの可用性を達成するため、アプリケーション
は、複数の物理的なロケーションに分散して配置される必要があります。弾⼒性を持つように個別の Layer (ウェブサーバー、データベースなど) を構築します。これにはイベントの重要な中断と障害のモニタリング、⾃⼰修復、および通知が含まれます。
ベストプラクティス:
マルチ AZ/リージョン 複数のアベイラビリティーゾーン/リージョンにまたがってアプリケーション負荷を分散する ( 例 : DNS 、 ELB 、
Application Load Balancer、API Gateway)。
• 疎結合依存関係 たとえば、キューシステム、ストリーミングシステム、
ワークフロー、ロードバランサーなどを使用する。
• グレースフルデグレデーション コンポーネントの依存関係に異常がある
場合、コンポーネントそのものは異常とはレポートされない。機能が低下した状態でリクエストの処理を続⾏できます。
• ⾃動修復 ⾃動的に障害を検出し、復旧対応を実⾏する。システムの状態を継続してモニタリングし、重要なイベントについて通知を受け取るよ
うに計画します。
•

69

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
REL 8.

弾⼒性をどのようにテストしていますか。

弾⼒性をテストすると、本稼働でのみ表⾯化する潜伏バグを⾒つけることがあります。定期的にゲームデーで手順を実践することで、組織で手順をスムーズに実⾏できるようになります。
ベストプラクティス:
プレイブック 障害シナリオのプレイブックが用意されている。
• 障害の生成 定期的に障害をテストして (Chaos Monkey を使用するなど)、障害経路の詳細を把握している。
• ゲームデーのスケジュール• 根本原因の分析 (RCA) 重要なイベントに基づいてシステム障害のレビューを⾏い、アーキテクチャを評価する。
•

REL 9.

災害対策についてどのように計画していますか。

データ復旧 (DR) は、バックアップからデータを復元する際に不可⽋です。このデータに対して、RTO および RPO の目標と一致するように目標、リソー
ス、場所、および機能が定義され、実⾏される必要があります。
ベストプラクティス:
目標の定義 RTO および RPO を定義します。
• 災害対策 DR 戦略を確⽴します。
•

70

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

構成情報の乖離 Amazon Machine Images (AMI) およびシステム設定状態
が、DR サイト/リージョンで最新であることを確認している。
• DR のテストと確認 DR サイトへのフェイルオーバーを定期的にテストして、RTO と RPO が満たされていることを確認している。
• ⾃動復旧の実装 AWS またはサードパーティー製ツール (またはその両方) を使⽤してシステム復旧を⾃動化します。
•

71

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
パフォーマンスの柱
選択
PERF 1.

最良の実⾏アーキテクチャをどのように選択していますか。

特定のシステムに向けた適切なソリューションは、ワークロードの種類によって異なり、複数の⼿法を組み合わせたものになります。優れた設計のシステム
では、複数のソリューションを使用し、さまざまな機能を有効にしてパフォー
マンスを向上させます。
ベストプラクティス:
ベンチマーク AWS で既知のワークロードのロードテストを⾏い、それを使⽤して最適な選択を⾏っている。
• ロードテスト さまざまなリソースタイプとサイズを使用して AWS でシステムの最新バージョンをデプロイし、モニタリングを使用してパ
フォーマンスメトリクスをキャプチャしてから、パフォーマンス/コス
トの計算に基づいて選択を⾏っている。

•

PERF 2.

コンピューティングソリューションをどのように選択しましたか。

特定のシステムに向けた適切なコンピューティングソリューションはアプリ
ケーション設計、使⽤パターン、構成設定によって異なります。アーキテク
チャでは、パフォーマンスを向上させるために、さまざまなコンポーネントに対して異なるコンピューティングソリューションを使⽤し、異なる機能を有効にします。システムに対して適切でないコンピューティングソリューションや機能を選択すると、パフォーマンス効率が低下する可能性があります。
72

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
オプションの検討 最良のパフォーマンスを達成するために、インスタ
ンス、コンテナ、関数の使⽤⽅法について異なるオプションを検討している。
• インスタンス設定のオプション インスタンスを使用している場合、ファ
ミリー、インスタンスサイズ、機能 (GPU、I/O、バースト可能) などの設定オプションを検討している。
• コンテナ設定のオプション コンテナを使用している場合、コンテナのメ
モリー、CPU、テナンシー設定などの設定オプションを検討している。
• 関数設定のオプション 関数を使用している場合、メモリ、ランタイム、
ステートなどの設定オプションを検討している。
• 伸縮性 弾⼒性を使⽤して (Auto Scaling、Amazon EC2 Container Service(ECS)、AWS Lambda)、需要の変化に対応している。
•

PERF 3.

ストレージソリューションをどのように選択していますか。

特定のシステムの最適なストレージソリューションは、アクセス方法の種類(ブロック、ファイル、またはオブジェクト)、アクセスのパターン (ランダムまたはシーケンシャル)、必要なスループット、アクセス頻度 (オンライン、オフ
ライン、アーカイブ)、更新頻度 (WORM、動的)、および可用性と耐久性の制約によって異なります。優れた設計のシステムでは、複数のストレージソ
リューションを使用し、さまざまな機能を有効にしてパフォーマンスを向上さ
せます。

73

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
特性の検討 使用する必要があるサービス (Amazon S3、Amazon EBS、
Amazon Elastic File System (EFS)、EC2 インスタンスストア) を選択す
るために必要な別の特性 (共有可能、ファイルサイズ、キャッシュサイ
ズ、アクセスパターン、レイテンシー、スループット、データの永続性など) を検討している。
• 設定オプションの検討 PIOPS、SSD、マグネティック、および Amazon
S3 Transfer Acceleration などの設定オプションを検討している。
• アクセスパターンの検討 アクセスパターン ( ストライピング、キー分
散、パーティショニングなど) に基づいてストレージシステムの使用方
法を最適化している。

•

PERF 4.

データベースソリューションをどのように選択していますか。

特定のシステムに最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、拡張性、およびクエリ機能についての要件によって異なります。多くのシステムでは、パフォーマンスを向上させるために、さまざまなサブシステムに対して異なるデータベースソリューションを使⽤し、異なる機能を有効化しています。システムに対して適切でないデータ
ベースソリューションや機能を選択すると、パフォーマンス効率が低下する可能性があります。

74ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
特性の検討 最もパフォーマンスのよいデータベースの使用アプローチ(リレーショナル、No-SQL 、ウェアハウス、インメモリ) を選択できる
ように、別の特性 (可用性、整合性、分断耐性、レイテンシー、耐久性、拡張性、クエリ機能など) を検討している。
• 設定オプションの検討 ストレージの最適化、データベースレベルの設定、メモリ、キャッシュなどの設定オプションを検討している。
• アクセスパターンの検討 アクセスパターン (インデックス、キー分散、
パーティション、水平スケーリングなど) に基づいてデータベースシス
テムの使用方法を最適化している。
• 他のアプローチの検討 検索インデックス、データウェアハウス、ビッグデータなどのクエリ可能データの提供で他のアプローチを検討した。
•

PERF 5.

ネットワーキングソリューションをどのように設定していますか。

特定のシステムに最適なネットワークソリューションは、レイテンシー、ス
ループット要件などによって異なります。ユーザーやオンプレミスリソースな
どの物理的な制約は、エッジの⼿法やリソースの配置を使⽤してオフセットすることができる場所のオプションを実⾏します。
ベストプラクティス:•

75

場所の検討ネットワークレイテンシーを低減するために場所のオプショ
ン (リージョン、アベイラビリティーゾーン、プレイスメントグルー
プ、エッジなど) を検討する。

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

製品機能の検討 ネットワークトラフィックを最適化するために製品の機能 (EC2 インスタンスネットワーク性能、超高ネットワークインスタン
スタイプ、 Amazon EBS 最適化インスタンス、 Amazon S3 Transfer
Acceleration、Dynamic Amazon CloudFront など) を検討する。
• ネットワーキング機能の検討 ネットワーク距離またはジッターを低減するために、ネットワーキング機能 (Amazon Route 53 レイテンシールー
ティング、Amazon VPC エンドポイント、AWS Direct Connect など) を検討する。
• 適切な NACLS ネットワークスループットを維持するために、最低限のセットの NACLS を使用する。
• 暗号化のオフロードの検討 暗号化停止 (TLS) をオフロードするために、負荷分散の使用を検討する。
• プロトコルの検討 ネットワークパフォーマンスを最適化するために必要なプロトコルについて検討する。
•

確認

新しいリソースタイプや機能の提供が開始される中で、どのようにして最適なリソースタイプを使い続けていることを担保していますか。
PERF 6.

ソリューションの設計には、選択できる一定のセットのオプションがあります。しかし、時間がたつと、アーキテクチャのパフォーマンスを向上させる可能性のある新しいテクノロジとアプローチが利⽤可能になります。

76

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:•

レビュー 新しいリソースタイプおよびサイズをレビューするプロセスがある。パフォーマンステストを再実⾏して、パフォーマンス効果に向上が⾒られるかどうかを評価します。

モニタリング

起動後のリソースが期待どおりの性能を出すように、リソースをどのようにモニタリングしていますか。
PERF 7.

内部または外部 (またはその両方) の要因により、時間とともにシステムパ
フォーマンスが低下する場合があります。システムのパフォーマンスをモニタリングすることで、パフォーマンスの低下を検知し、内部または外部の要因(オペレーティングシステムまたはアプリケーションのロードなど) を修正することができます。
ベストプラクティス:
モニタリング Amazon CloudWatch、サードパーティー製、またはカス
タムのモニタリングツールを使用してパフォーマンスをモニタリングする。
• アラームベースの通知 メトリクスが安全な境界を超えた場合に、モニタ
リングシステムから自動的なアラートを受信する。
• トリガーベースのアクション 自動化されたアクションで問題を修正またはエスカレーションするアラームを設定する。
•

77

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
トレードオフPERF 8.

ますか。

パフォーマンスを向上させるためにトレードオフをどのように使用しソリューションを構築するときに、積極的にトレードオフを考慮することで、最適なアプローチを選択できます。整合性、耐久性、容量を、時間およびレイ
テンシーと引き換えにすることで、より高いパフォーマンスを達成できることがよくあります。
ベストプラクティス:
サービスの検討 Amazon ElastiCache 、 Amazon CloudFront 、 AWS
Snowball など、パフォーマンスを向上させるサービスを使用する。
• パターンの検討 キャッシング、リードレプリカ、シャーディング、圧縮、バッファリングなど、パフォーマンスを向上させるパターンを使用
する。

•

78

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
コストの最適化の柱
コスト効果が高いリソース
COST 1.

ますか。

ソリューションに AWS サービスを選択する際のコストを検討してい、Amazon EBS、Amazon S3 などは AWS のサービスの基本的な「ビルディングブロック」です。Amazon RDS や Amazon DynamoDB などのマ
ネージドサービスは、「ハイレベル」の AWS サービスです。適切な構成要素
およびマネージドサービスを選択することで、コストに対してアーキテクチャ
を最適化できます。たとえば、これらのマネージドサービスを使用すると、管理オーバーヘッドまたは運⽤オーバーヘッドの⼤部分を減らすか排除することができ、アプリケーションやビジネス関連のアクティビティに労⼒を向けることができます。
Amazon EC2

ベストプラクティス:
コスト削減サービスの選択 サービスを分析して、コスト削減に使用できるサービスを確認する。
• ライセンス費用の最適化• サーバーレスおよびコンテナベースの手法を使用した最適化 AWS
Lambda 、 Amazon S3 ウェブサイト、 Amazon DynamoDB 、および
Amazon ECS を使用したコストの削減。
• 適切なストレージソリューションを使⽤した最適化 使用パターンに基づいたもっともコスト効果の高いストレージソリューションを使用する
•

79

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

コールドストレージ、 Amazon S3 Standard-Infrequent
Access、Amazon Glacier など)。
• 適切なデータベースを使⽤した最適化 該当する場合は、 Amazon
Relational Database Service (RDS) (Postgres 、 MySQL 、 SQL Server 、
Oracle Server) または Amazon DynamoDB (またはその他のキーと値のス
トア、NoSQL 代替策) を使用する。
• その他のアプリケーションレベルのサービスを使用した最適化 該当する場 合 は 、 Amazon Simple Queue Service (SQS) 、 Amazon Simple
Notification Service (SNS)、Amazon Simple Email Service (SES) を使用する。
(Amazon EBSCOST 2.

コスト目標を達成するためにリソースのサイズを決定しましたか。

タスクに対して適切な AWS リソースサイズを選択していることを確認しま
す。AWS では、ベンチマーク評価の使用によって、選択したタイプがそのワークロードに対して最適化されていることを確認します。
ベストプラクティス:•

80

メトリクス駆動型のリソースサイズ設定 パフォーマンスメトリクスを活用して正しいサイズ/タイプを選択し、コストを最適化する。Amazon
EC2 、 Amazon DynamoDB 、 Amazon EBS ( プロビジョンド IOPS) 、
Amazon RDS、Amazon EMR、ネットワーキングなどのようなサービスのスループット、サイジング、ストレージについて適切にプロビジョニ
ングを⾏います。

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
COST 3.

コスト目標を達成するために適切な料⾦モデルを選択していますか。

ワークロードで費⽤を最⼩化するために最適な料⾦モデルを使⽤します。デプ
ロイを最適化すると、すべてオンデマンドインスタンス、オンデマンドとリ
ザーブドインスタンスの組み合わせとするか、可能な場合はスポットインスタ
ンスを含めることもできます。
ベストプラクティス:
キャパシティーの予約および取引のコミット 定期的に使⽤料を分析し、それに応じてリザーブドインスタンスを購入する (Amazon EC2 、Amazon DynamoDB、Amazon S3、Amazon CloudFront など)。
• スポット 選択ワークロード (バッチ、EMR など) 向けのスポットインス
タンス (スポットブロック、フリートなど) を使用する。
• リージョンコストの検討 リージョンの選択でコストを考慮する。
•

供給と需要の一致

キャパシティーが必要量を満たしているが⼤幅に超えていないことをどのように実現していますか。
COST 4.

料⾦とパフォーマンスの点でバランスが取れたアーキテクチャを構築するには、⽀払ったすべてのものが使⽤されるようにし、著しく使⽤率が低いインス
タンスを避けます。いずれかの⽅向に偏った使⽤率のメトリックスは、運⽤コ
スト (過度の使⽤率によるパフォーマンスの低下) または無駄な AWS 支出 (オーバープロビジョニングによる) によるビジネスへの悪影響につながります。
ベストプラクティス:
81ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

デマンドベースの手法 Auto Scaling を使用して変化する需要に対応する。
• バッファベースの手法 作業をバッファして (Amazon Kinesis or Amazon
Simple Queue Service (SQS) を使用するなど ) 、処理に⼗分なキャパシ
ティーができるまで作業を保留する。
• 時間ベースの手法 時間ベースの⼿法の例としては、Follow The Sun、週末に開発およびテストインスタンスをオフにする、四半期または年間スケジュールに従う (ブラックフライデーなど) など。
•

費用の把握
COST 5.

したか。

アーキテクチャを設計するときに、データ転送料⾦について考慮しま

データ転送料⾦をモニタリングし、それらのコストの一部を軽減できるようなアーキテクチャの決定を⾏います。たとえば、コンテンツプロバイダーがエンドユーザーに対して Amazon S3 バケットから直接コンテンツを提供している場
合、コンテンツを Amazon CloudFront コンテンツ配信ネットワーク (CDN) にプッシュすれば、大幅なコスト削減が可能になる可能性があります。小規模でも効果的なアーキテクチャ変更によって、運⽤コストを⼤幅に削減できる場合があることを覚えておいてください。
ベストプラクティス:
最適化 データ転送を最適化するよう設計する (アプリケーション設計、
WAN アクセラレーション、マルチ AZ、リージョン選択など)。
• CDN 該当する場合、CDN を使用する。

•

82

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク•

AWS Direct Connect
Connect

COST 6.

を使用する。

状況を分析し、該当する場合は AWS Direct

使用状況と支出をどのようにモニタリングしていますか。

コストをモニタリング、管理、適切に割り当てるためのポリシーと⼿順を確⽴します。AWS 提供のツールを活用して、だれが何をどのぐらいのコストで使用しているのかを明らかにします。これにより、ビジネスニーズとチームのオペ
レーションについてより深く理解することができます。
ベストプラクティス:
すべてのリソースにタグ付け タグ付け可能なリソースすべてにタグ付けして、請求の変化をインフラストラクチャと使⽤量の変更に関連付けられるようにする。
• 請求およびコスト管理レポートツールの活⽤ 詳細な請求レポートまたは
コストエクスプローラーをロードし、解釈できるための標準プロセスがある。該当する場合は Amazon CloudWatch またはサードパーティープ
ロバイダー (例:Cloudability、CloudCheckr、CloudHealth) を使用して定期的に使⽤量と費⽤をモニタリングします。
• 通知 費⽤が明確に定義された限度を超える場合に、チームの主要メンバーに通知する。
• 財務駆動型のチャージバック/ショーバック方法 これを使用して、インス
タンスとリソースをコストセンターに割り当てる (タグ付けの使用など)。
•

83

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

必要なくなったリソースは廃棄していますか。または、一時的に必要ないリソースを停止していますか。
COST 7.

プロジェクトの開始から終了まで変更管理とリソース管理を実装し、適切な場合は必要なプロセス変更または機能強化を識別できるようにします。AWS サ
ポートと協⼒して、お客様のワークロードに合わせてプロジェクトを最適化す
る方法を提案します。たとえば、どのような場合に Auto Scaling 、 AWS
OpsWorks、AWS Data Pipeline、その他異なる Amazon EC2 プロビジョニング
手法を使用するべきかについてや、Trusted Advisor のコスト最適化の提案のレビューなどです。
ベストプラクティス:
自動化 重要でないリソースや不要なリソース、または使⽤率が低いリ
ソースを確認して廃棄する際に、リソースの削除を適切に処理するようシステムを設計する。
• 定義されたプロセス 既に使われていないリソースを確認して廃棄するプ
ロセスがある。
•

COST 8. AWS

いますか。

の使⽤状況を管理するためにどのような管理と⼿順を実⾏して目標の達成のために適切なコストとなるようなポリシーとメカニズムを確⽴します。タグ付けと IAM コントロールを通じてチェックとバランスの手法を使用
すると、浪費することなくイノベーションが可能になります。

84

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
グループとロールの確⽴ (例: 開発/テスト/本稼働) ガバナンスメカニズ
ムを使用して、各々のグループのインスタンスとリソースをスピンアッ
プできるのが誰かを管理する。(これは AWS サービスまたはサードパー
ティーのソリューションに適用されます)。
• プロジェクトライフサイクルの追跡 プロジェクト、チーム、および環境のライフサイクルを追跡、測定、監査して、不要なリソースの使⽤と⽀払いを避ける。
•

継続した最適化
COST 9.

新しいサービスの採⽤をどのように管理または検討していますか。

が新しいサービスや機能を公開するときに、既存のアーキテクチャ上の決定を⾒直し、それらが引き続き最もコスト効果が⾼いことを確認するのがベス
トプラクティスです。

AWS

ベストプラクティス:
コスト最適化関数の確⽴• レビュー 新しいサービス、リソースタイプおよびサイズをレビューする
プロセスがある。パフォーマンステストを再実⾏して、コスト削減が⾒られるかどうかを評価します。
•

85

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク
運用性の柱
準備
OPS 1.

クラウドオペレーションのどのベストプラクティスを使用しているか

高い運用性を実現するには、効果的な準備が必要です。オペレーションチェッ
クリストを使用すると、ワークロードが本稼働オペレーションの準備ができていることを確認できます。チェックリストを使用すると、十分な準備ができな
いまま意図せず本稼働に昇格させてしまうことがなくなります。
ベストプラクティス:
オペレーションチェックリスト ワークロードの運用準備ができているかどうかを評価するために使用するオペレーションチェックリストを作成する。
• 事前計画 ビジネスに実体的な影響を与える機会とリスク (評価、財務など) に備えてイベント (マーケティングキャンペーン、フラッシュセールなど) の事前計画を⽴てる。
• セキュリティチェックリスト ワークロードを安全に運用する準備ができているかの評価に使用できるセキュリティチェックリストを作成する(ゼロデイ、DDoS、キー漏えいなど)。
•

OPS 2.

ワークロードの設定管理はどのように⾏っているか

環境、アーキテクチャ、およびそれらのリソースの設定パラメータは、追跡およびトラブルシューティングのためにコンポーネントを容易に識別できる仕⽅で⽂書化する必要があります。設定の変更も追跡可能で⾃動化されている必要があります。
86ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
リソース追跡 ワークロード内のリソースとその機能を識別する⽅法を計画する (メタデータ、タグ付けの使用など)。
• ドキュメント作成 アーキテクチャのドキュメントを作成する (コードとしてのインフラストラクチャ、CMDB、ダイアグラム、リリースノートなど)。
• 運⽤知識の習得 継続的に運⽤知識を習得している (wiki、ナレッジベー
ス、チケットなど)。
• イミュータブルインフラストラクチャ イミュータブルインフラストラク
チャを確⽴し、パッチではなく再デプロイできるようにする。
• 変更⼿順の⾃動化 変更⼿順を⾃動化する。
• 設定管理データベース (CMDB) CMDB のすべての変更を追跡する。
•

運用
OPS 3.

せるか

変更の影響を最⼩限に抑えながら、ワークロードをどのように進化さ

⾃動化、⼩規模の頻繁な変更、定期的な品質管理テスト、および変更の追跡、監査、ロールバック、レビューについて定義されたメカニズムに注⼒する必要があります。

87ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ベストプラクティス:
デプロイメントパイプライン CI/CD パイプラインを適切に配置する(ソースコードリポジトリ、ビルドシステム、デプロイメントとテストの自動化など)。
• リリース管理プロセス リリース管理プロセスを確⽴する (マニュアルまたは自動化など)。
• ⼩規模の増分変更 システムコンポーネントの小規模なバージョンアップ
をリリースできるようにする。
• 復元可能な変更 オペレーションに問題が出る場合は変更を元に戻せるよ
うに準備しておく (ロールバックや機能切り替えなど)。
• リスク軽減戦略 Blue/Green、 Canary、A/B テストなどのリスク軽減戦
略を使⽤する。

•

ワークロードが想定通りに動作していることを確認するために、どのように監視するかOPS 4.

内部または外部 (またはその両方) の要因により、時間とともにシステムが機能低下する場合があります。システムの動作をモニタリングすることで、この低下の要因を確認し、修正することができます。
ベストプラクティス:•

88

モニタリング Amazon CloudWatch、サードパーティー製、またはカスタ
ムのモニタリングツールを使用してパフォーマンスをモニタリングする。

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

ログの集約 複数のソースからログを集約する (アプリケーションログ、AWS サービス固有のログ、VPC フローログ、CloudTrail など)。
• アラームベースの通知 メトリクスが安全な境界を超えた場合に、モニタ
リングシステムから自動的なアラートを受信する。
• トリガーベースのアクション アラームによって自動化されたアクションが起動し、問題を修正またはエスカレーションする。
•

対応
OPS 5.

計画外の運用イベントにどのように対応するか予期しない運用イベントへの応答を自動化しておきます。これにはアラートだ
けでなく、緩和、修復、ロールバック、復旧も含みます。
ベストプラクティス:
プレイブック 従うべきプレイブック (オンコールプロセス、ワークフ
ローチェーン、エスカレーションプロセスなど) があり、定期的に更新されている。
• RCA プロセス 問題を解決、記録、修正でき、今後の再発を防ぐ RCA プ
ロセスがある。
• 自動化された対応 自動化された対応を通じて、計画にない運用イベントに手順正しく対応する (Auto Scaling、Support API など)。
•

89

ページ

アマゾン ウェブ サービス — AWS による優れた設計のフレームワーク

計画外の運用イベントに対応する場合、エスカレーションはどのように管理されますか。

OPS 6.

計画外の運用イベントへの対応は、ステークホルダー、エスカレーションプロ
セスおよび手順を含む事前定義されたプレイブックに従う必要があります。エスカレーションパスを定義し、機能的および階層的エスカレーション機能の両方を含めます。階層的エスカレーションは自動化され、エスカレートされた優
先度でステークホルダーに通知されるべきです。
ベストプラクティス:
適切なドキュメントとプロビジョン 必要なステークホルダーとシステムを適切に配置し、エスカレーションが発⽣した場合にアラートを受信できるようにします。
• キューベースのアプローチを使用した機能的なエスカレーション 優先
度、深刻度、取り込みメカニズムに基づいた適切に機能するチームのキュー間でエスカレーションします。
• 階層的エスカレーション デマンド型または時間ベースの手法を使用します。インシデントの深刻度、スケール、または解決/リカバリーまでの時間が増加すると、優先度が上がります。
• 外部エスカレーションパス 外部サポート、AWS サポート、AWS パート
ナー、およびサードパーティーのサポート参加をエスカレーションパスに含める。
• 階層的優先度のエスカレーションが⾃動化されている デマンドまたは時間のしきい値を超えると、優先度が⾃動的にエスカレーションします。

•

90ページ