AWS Black Belt Tech Webinar 2016 (旧マイスターシリーズ) AWS Well Architected Program

1. AWS Well Architected Program
AWS Black Belt Tech Webinar 2016
Yasuhiro Araki
Sr. Manager, Solutions Architect, Amazon Web Service Japan

2. AWS Well-Architected Framework
• アプリケーションが良い設計(Well-Architected)になっているかを確認
し、改善するためのフレームワーク
• 4つの軸によってチェックを行い、不足している箇所があれば欠点に対
処する方法を発見することができる
– セキュリティ
– 信頼性
– パフォーマンス効率
– コストの最適化
http://aws.typepad.com/aws_japan/2015/10/are-you-well-architected.html

3. AWS Well-Architected Frameworkとは？
• AWS Well-Architected Frameworkは、お客様が
AWSクラウド内に、セキュアで、信頼性に富み、コス
ト最適化されたアプリケーションを構築し運用管理す
る助けとなる大局的なガイドとベストプラクティスを
提供することを狙いとしています。

4. AWS Well-Architected Framework
• クラウドアーキテクチャのベストプラクティスへの
理解を深める
• 忘れられがちな基礎となる領域を再確認
• アーキテクチャを評価する一貫したアプローチ
• 以下の要素から構成されます:
• 柱
• 設計の原則
• 確認事項

5. 優れたアーキテクチャの四本柱
セキュリティ 信頼性 性能効率 コスト最適化

6. 「Well Architected」＝「正しい構築」の柱
信頼性: 障害から復旧し、増加する需要を処理でき、サービス中断を防止
するよう対象システムを構築してください。
セキュリティ: AWSクラウド内でデータや資産を保護するための
ベストプラクティスを活用してください。
パフォーマンス: 対象システムを構成するリソースが効率的に
パフォーマンスを実現するよう構築してください。
コスト最適化: コストを理解し、コントロールし、対象システムの
所期の目的を達しながらもコストを削減してください。

7. 「Well Architected」＝「正しい構築」の柱

8. 設計の原則
• AWSによる優れた設計のフレームワークでは、
クラウドにおける適切な設計を可能にする設計
の原則を明確にしました:
• 一般的な設計の原則
• 柱ごとの設計の原則

9. 一般的な設計の原則
必要な容量の判断を勘に頼らない
本番のスケールでテストする
アーキテクチャ変更のリスクを下げる
アーキテクチャの実験を容易にするために自動化を取り入れる
革新的なアーキテクチャを取り入れる

10. セキュリティ
• ビジネスにおける価値を生み出しながら、リス
クアセスメントと防御戦略により、情報、シス
テム、資産を守る能力。
• データ保護
• 権限管理
• インフラの保護
• 検知

11. 設計の原則
全ての層にセキュリティ
トレーサビリティを実現
セキュリティ事象に自動的に対応
あなたのシステムのセキュリティにフォーカス
セキュリティのベストプラクティスを自動化

12. セキュリティにおいて重要なサービス
Areas Key Services
データ保護
権限管理
インフラ保護
検知
Elastic Load
Balancing Amazon EBS Amazon S3 Amazon RDS
AWS Key
Management
Service
MFA tokenIAM
Amazon VPC
AWS
CloudTrail
AWS Config CloudWatch
IAM

13. • 保管時のデータをどのように暗号化、保護して
いますか
• 伝送中のデータをどのように暗号化、保護して
いますか
データセキュリティの考慮事項

14. セキュリティのための権限管理の考慮事項
• AWSルートアカウントの認証情報へのアクセスと
使用をどのように保護していますか
• AWSマネジメントコンソールとAPIへの人間による
アクセスを制御するために、システムユーザーの
ロールと責任をどのように定義していますか
• AWSリソースへの自動化されたアクセス（アプリ
ケーション、スクリプト、サードパーティツールま
たはサービスからのアクセス等）をどのように制御
していますか
• キーと認証情報をどのように管理していますか

15. インフラストラクチャ保護の考慮事項
• ネットワークおよびホストレベルの境界保護を
どのように実施していますか
• AWSサービスレベルの保護をどのように実施し
ていますか
• EC2上のOS整合性はどのように保護しています
か

16. セキュリティ発見のための考慮事項
• AWSログをどのようにキャプチャして分析して
いますか

17. 信頼性
• 需要に応じて動的に計算資源を取得したり、構
成の問題や通信経路の切断による停止を防ぐこ
とで、インフラやサービスの障害から回復する
能力。
• 基盤
• 変更管理
• 障害管理

18. 設計の原則
回復手順をテストする
障害からの回復を自動化する
システムの可用性を向上させるために水平スケーリング
容量の判断を勘に頼らない

19. 信頼性における重要なサービス
Areas Key Services
基盤
変更管理
障害管理
IAM Amazon VPC
AWS CloudTrail AWS Config
AWS
CloudFormation
CloudWatch

20. • アカウントのAWSサービス制御はどのようにモ
ニタリングしていますか
• AWSでのネットワークトポロジをどのように計
画していますか
• 技術的な問題に対応するためのエスカレーショ
ンパスがありますか
信頼性のための基礎的な考慮事項

21. • システムは需要の変更にどのように対応します
か
• AWSリソースをどのようにモニタリングしてい
ますか
• 変更管理をどのように実行していますか
信頼性のための変更に関する考慮事項

22. • データをどのようにバックアップしていますか
• システムはコンポーネントの障害にどのように
対応しますか
• 復旧についてどのように計画していますか
信頼性のための障害管理の考慮事項

23. 性能効率
• システムの要求に応え、需要が変動しテクノロジー
が進化しても効率を保ち続けるように計算資源を利
用する能力。
• コンピューティング
• ストレージ
• データベース
• 容量と処理時間のトレードオフ

24. 設計の原則
最先端の技術を開放する
即座にグローバル化
サーバーレス・アーキテクチャ
もっと頻繁に実験・挑戦

25. 性能効率に重要なサービス
Areas Key Services
コンピューティング
ストレージ
データベース
処理時間と容量のトレー
ドオフ
Amazon EBS Amazon S3
Amazon RDS
Auto Scaling
Amazon
Glacier
CloudFron
t
DynamoDB
CloudWatch

26. • システムに対して適切なインスタンスタイプを選択
するには、どのようにすればよいでしょうか
• 新しいインスタンスタイプや機能が開始される中で
最適なインスタンスタイプを使い続けるには、どの
ようにすればよいでしょうか
• 起動後のインスタンスが予期通り実行されるように
するには、インスタンスをどのようにモニタリング
したらよいでしょうか
• インスタンスの数量を需要に一致させるには、どう
すればよいでしょうか
パフォーマンス効率に関するコンピュートの考慮事項

27. • システムの最適なストレージソリューションを選択する
には、どのようにすればよいでしょうか
• 新しいストレージソリューションや機能が開始される中
で最適なストレージソリューションを使い続けるには、
どのようにすればよいでしょうか
• ストレージソリューションが予期通り実行されるように
するには、ソリューションをどのようにモニタリングし
たらよいでしょうか
• ストレージソリューションのキャパシティーとスルー
プットを需要に一致させるには、どうすればよいでしょ
うか
パフォーマンス効率に関するストレージの考慮事項

28. • システムの最適なデータベースソリューションを選
択するには、どのようにすればよいでしょうか
• 新しいデータベースソリューションや機能が開始さ
れる中で最適なデータベースソリューションを使い
続けるには、どのようにすればよいでしょうか
• パフォーマンスを予期通りにするには、データベー
スをどのようにモニタリングしたらよいでしょうか
• データベースのキャパシティーとスループットを需
要に一致させるには、どうすればよいでしょうか
パフォーマンス効率に関するデータベースの考慮事項

29. • システムの最適なキャッシュソリューションを選択
するには、どのようにすればよいでしょうか
• 新しいソリューションや機能が開始される中で最適
なキャッシュソリューションを使い続けるには、ど
のようにすればよいでしょうか
• パフォーマンスを予期通りにするには、キャッシュ
ソリューションをどのようにモニタリングしたらよ
いでしょうか
• キャッシュのキャパシティーとスループットを需要
に一致させるには、どうすればよいでしょうか
パフォーマンス効率に関するキャッシュの考慮事項

30. コスト最適化
• 不要なコストや最適ではない資源を予防し排除
する能力。
• 需要と供給の一致
• コスト効果の高い資源
• 費用の認知
• 最適化の継続

31. 設計の原則
費用賦課における透明性
所有コストを低減させるためにマネージドサービスを使用
資本投資を止め、運用コストに
規模の経済の恩恵を受ける
データセンター運用への投資を止める

32. コスト最適化に重要なサービス
Areas Key Services
需要と供給の一致
コスト効果の高いリソース
支出を認知する
継続して最適化
CloudWatch
Auto Scaling
Amazon SNS
Reserved Instances AWS Trusted
Advisor
AWS Trusted
Advisor
AWS Blog & What’s New
Cost Allocation Tags

33. • キャパシティが一致しているが、必要量を大幅
に超えていないことを確認するにはどうすれば
よいでしょうか
• AWSサービスの使用量を最適化するにはどうす
ればよいでしょうか
コスト最適化のための需要と供給の一致のための
考慮事項

34. • コスト目標を達成するために適切なリソースタ
イプを選択しましたか
• コスト目標を達成するために適切な料金モデル
を選択しましたか
• ROIを高めるために使用できるマネージドサー
ビスはありますか
コスト最適化のためのコスト効率の高いリソース選択
のための考慮事項

35. • AWSのコストを管理するためにどのようなアク
セス制御と手順を実行していますか
• 使用状況と支出をどのようにモニタリングして
いますか
• 必要なくなったリソースをどのように廃棄して
いますか。または一時的に必要ないリソースを
どのように停止していますか
• アーキテクチャを設計するときに、データ転送
料金についてどのように考えていますか
コスト最適化のための費用の認識

36. • 新しいサービスの採用をどのように管理または
検討していますか
コスト最適化のためのコストの再評価

37. まとめ
• AWS Well-Architected Frameworkは、アプリケーションが良い設計
(Well-Architected)になっているかを確認し、改善することができる
• 4つの軸によってチェックを行い、不足している箇所があれば欠点に対
処する方法を発見することができる
– セキュリティ
– 信頼性
– パフォーマンス効率
– コストの最適化
http://aws.typepad.com/aws_japan/2015/10/are-you-well-architected.html