社内勉強会向けのAWS White Belt資料をベースに作成した資料

1. Well-Architected
フレームワークについて
２０１９年４月９日

2. Well-Architected フレームワークとは？
• AWSを利用したシステム構築のベストプラクティス集
• ５本の柱（運用の優秀性、セキュリティ、信頼性、パフォーマ
ンス効率、コスト最適化）に分類して解説
• ５本の柱は、ビジネスのコンテキストに基づいてトレードオフ
の関係にあるので、この部分を利用者は決定する必要がある
• フレームワークの内容は、サービスの追加や機能追加により、
毎年更新される

3. Well-Architectedフレームワークの構成
• 各セクションの構成は、以下の通りです。
• 設計原則
• 設計時に気を付けるべき観点、項目
• ベストプラクティス
• 各柱のベストプラクティスが質問形式で記載
• 具体的な実装例については、柱ごとに作成されたホワイトペーパーや該当するサービス
のドキュメントを参照する
ホワイトペーパー
（運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化）
ベストプラクティス
設計原則
サービスごとのドキュメント
Well-Architected
フレームワークの範囲

4. Well-Architectedフレームワークの構成
• それぞれの柱における設計の原則を記述しています。
原則は、以下の一般的な設計の原則を各柱に適用した内容です。
• 必要なキャパシティーを勘に頼らない
• 本番規模でシステムをテストする
• 自動化によってアーキテクチャ上の実験を容易にする
• 発展的なアーキテクチャを受け入れる
• データ計測に基づいてアーキテクチャを決定する
• 本番で想定されるトラブルをあらかじめテストし、対策する

5. …でも、全部やると大変
• 入門編として、特に利用開始時におさえておきたい項目を抜粋
して説明します
• どれを抜粋するかは、2018年3月1日の「Day 1 with Amazon
Web Services - AWSご利用開始時に最低限おさえておきたい
10のこと」という「AWS White Belt Online Seminar」の資料
をベースにしています
• ただし、今回取り上げなかった項目についても、さまざまなリ
スクを回避し、コストを効率化する項目なので、ぜひ本編を一
度参照するようにしてください

6. 今回取り上げる項目
• セキュリティ
• ５項目
• コスト最適化
• ３項目
• 信頼性
• ２項目

7. セキュリティ
• セキュリティの質問（抜粋）
セキュリティ 1: ワークロードの認証情報をどのように管理していますか？
セキュリティ 2: AWSサービスへの人為的なアクセスをどのように制御していますか？
セキュリティ 3: AWSサービスへのプログラムによるアクセスをどのように制御していますか？
セキュリティ 4: ワークロードのセキュリティイベントをどのように検知していますか？
セキュリティ 5: ネットワークをどのように保護していますか？

8. セキュリティ 1: ワークロードの認証情報
をどのように管理していますか？
• AWSのアカウント
• AWSルートアカウント
• すべてのAWSサービスとリソースへの完全なアクセス権限を保持
• 十分な強度のパスワードだけでなく、MFA（多要素認証）で保護し、通常は利用
しない運用をすること
• IAMユーザ
• AWSリソースへのアクセスを安全に制御するためのサービス
• ユーザ／認証情報管理
• アクセス権限管理
• AWSリソースへの安全なアクセス

9. セキュリティ 2: AWSサービスへの人為的な
アクセスをどのように制御していますか？
• IAMユーザとIAMグループ
IAMユーザ • AWS操作用のユーザ
• マネージメントコンソールへのサインイン、APIはたはCLIの使用時に利用
する
• 名前、マネジメントコンソールにサインインするためのパスワード、API
はたはCLIで使用できるアクセスキーで構成
• AWSサービスへのアクセス権限をJSON形式で記述する
IAMグループ • IAMユーザをまとめるグループ
• AWSサービスへのアクセス権限をJSON形式で記述する

10. セキュリティ 2: AWSサービスへの人為的な
アクセスをどのように制御していますか？
• 最小権限の原則
• IAMユーザとIAMグループを利用する
• 最小限のアクセス権限から開始し、必要に応じて追加のアクセス権を付与す
る
【ダメな例】
{
"Version": "2012-10-17“,
“Statement”: [{
“Effect”: “Allow”,
“Action”: “s3:*”,
“Resource”:
[“arn:aws:s3:::*”]
}]
}

11. セキュリティ 3: AWSサービスへのプログラムによ
るアクセスをどのように制御していますか？
• IAMロールを利用して、認証情報を埋め込まない
• EC2のようなAWSサービスに対して、AWS操作権限を不要するには、
２つ方法がある
• プログラムにアクセスキー情報を埋め込む
• IAMロールを付与する
プログラム
プログラム
IAMユーザ利用 IAMロール利用
SDK/CLI
認証情報の管理
ローテーション
の管理が必要
IAMロール
メタデータ
認証情報はSecurity
Token Serviceで生成し自
動的にローテーションが
行われる

12. セキュリティ 4: ワークロードのセキュリテ
ィイベントをどのように検知していますか？
• AWS CloudTrailによる操作ログの取得をする
• AWSユーザのAPI操作などのアクションをログ取得保存するサービス
• セキュリティインシデント発生時の分析に活用
• CloudTrailのログをCloudWatch Logsに転送し管理することも可能
• その他のログも有効化する
• ELB
• S3バケット
• CloudFront
• API Gateway
• VPC Flow Logs

13. セキュリティ 5: ネットワークをどのよう
に保護していますか？
• アクセス設定を必要最低限に設定
• ネットワークレイヤ…ネットワークACL
• VPCのサブネット単位で設定するステートレスなファイアウォール
• ベースラインとなるポリシーを設定する際に用いる
• 各リソース（EC2、RDSなど）…セキュリティグループ
• インスタンス（グループ）単位に設定するステートフルなファイアウォール
• サーバの機能や用途に応じたルール設定に適している

14. コスト最適化
• コスト最適化の質問（抜粋）
コスト最適化 2:
コスト目標を達成するためにインスタンスタイプとサイズをどのように選択していますか？
コスト最適化 7: AWS 使用量をどのように管理していますか？
コスト最適化 3: コスト削減のために料金モデルをどのように選択していますか？

15. コスト最適化 2:
コスト目標を達成するためにインスタンスタイプとサイ
ズをどのように選択していますか？
• AWS CloudWatchでリソース利用情報を把握する
• AWS上で稼働するシステム監視サービス
• システム全体のリソース使用率、アプリケーションパフォーマンスを把握
• あらかじめ設定した閾値を超過したら、メール通知、AutoScalingなどのアク
ションを実行することも可能
• CloudWath LogsでOS上やアプリケーションログの取得も可能
Amazon CloudWatch
AWS Auto Scaling
Amazon Simple
Notification Service
Amazon EC2
Amazon Simple Storage
Service (S3)
CPU使用率/ディスクIO
/ネットワーク使用率
[カスタムメトリクス]
メモリ使用率/ディスク使用率

16. コスト最適化 2:
コスト目標を達成するためにインスタンスタイプとサイ
ズをどのように選択していますか？
• 利用状況に応じた適切なインスタンスタイプなどを選択
• 使用率が安定している場合
• 使用率が低い／高い場合、インスタンスファミリーやタイプの見直し
• 使用率が適切な場合、リザーブドインスタンスの購入を検討
• 使用率が一定でない場合
• 時刻ごとの台数増減、AutoScaling活用を検討
• バッファベース（Amazon SQSやAmazon Kinesisを活用した）の処理も検討

17. コスト最適化 7: AWS 使用量をどのよう
に管理していますか？
• IAMユーザへの請求情報へのアクセス有効化
• コストエクスプローラの有効化
• 請求アラームの活用
• 利用状況を監視し、閾値を超過したら通知することが可能
• 設定した閾値を超過した場合、Simple Notification Serviceにて、Eメ
ールやHTTP／HTTPSなどで通知可能

18. コスト最適化 3: コスト削減のために料金
モデルをどのように選択していますか？
• 購入オプションの活用
• AWSには、さまざまな購入オプションがあり、ニーズにあった最も費
用対効果の高い購入オプションを選択する。
オンデマンド
インスタンス
（デフォルト）
初期費用なし、コミットな
しの従量課金
• ピークなど増減するWeb/Appサーバ
• 一時利用のキャンペーンサイト
• 昼にしか利用しない開発サーバ
• EC2
• Elastic MapReduce
• RDS
• ElastiCache
• RedShift
リザーブド
インスタンス
（オプション）
長期（1年or3年）の長期利
用コミットによる割引料金
の適用
• 常時稼働しているサーバ
• DB、キャッシュサーバ
• 必要最低限のWeb/Appサーバ
• EC2
• RDS
• ElastiCache
• RedShift
スポット
インスタンス
（オプション）
AWS余剰リソースをより
安価に利用可能
• 分散処理のタスクノード、クローラ
• メディアプロセッシング
• EC2
• Elastic MapReduce

19. 信頼性
• 信頼性の質問（抜粋）
信頼性 6: データをどのようにバックアップしていますか？
信頼性 7: システムがコンポーネントのエラーに耐えるようにどのように設計していますか？

20. 信頼性 6: データをどのようにバックアッ
プしていますか？
• AWS各サービスのバックアップ機能を活用する
• EC2のAMI
• EC2のマシンイメージを作成
• Amazon EBSのスナップショット
• EBSのスナップショットを取得
• 作成時はデータ整合性を保つため、静止点を設けて実行
• RDSの自動バックアップ機能
• 1日1回のスナップショット取得と、スナップショット取得から5分前までのトラ
ンザクションログを取得し、Point-in-Timeリカバリを実現
• 最長35日まで設定可能
• トラブル発生時を想定した復旧テストで手順を確認しておく

21. 信頼性 7: システムがコンポーネントのエラーに耐
えるようにどのように設計していますか？
• RDSのMultiAZデプロイメント
• 同期レプリケーション（冗長化）と自動フェイルオーバを実現
• データ冗長化と可用性向上を実現

22. 信頼性 7: システムがコンポーネントのエラーに耐
えるようにどのように設計していますか？
• ELB（Elastic Load Balancing）の活用
• AutoScalingの活用、各種セキュリティサービスの観点からも活用
• EC2-AutoScalingの活用
• 最小台数を設定し、インスタンス異常時にも起動している台数を維持

23. 信頼性 7: システムがコンポーネントのエラーに耐
えるようにどのように設計していますか？
• EC2-AutoRecovery
• インスタンスの異常を検知し、復旧する仕組み
• CloudWatchアラームの「Recover this Instance」を活用
Amazon EC2 Amazon CloudWatch
Alarm
CloudWatchでモニタリングし、
設定されたアラームによりアクシ
ョンを実行させる
インスタンスの停止、削除、
再起動、復元