Well Architected Tool 使い方セミナー（コスト最適化編）
•
1 j'aime•1,815 vues
Well Architected Tool 使い方セミナー（コスト最適化編）
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Well Architected Tool 使い方セミナー（コスト最適化編）
Similaire à Well Architected Tool 使い方セミナー（コスト最適化編） (20)
Plus de Nobuhiro Nakayama
Plus de Nobuhiro Nakayama (20)
Well Architected Tool 使い方セミナー（コスト最適化編）
- 3. 3はじめに この資料は、 「Well-Architected Tool の使い方セミナー」後半パートの資料です 前半ではWell-Architected Framework自体の概要を解説しています。 Well-Architected Frameworkについては以下の資料をご確認ください。 AWS Black Belt Online Seminar 2018 AWS Well-Architected Framework https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar- 2018-aws-wellarchitected-framework
- 4. 4目次 ✓ Well-Architected Toolの使い方 ✓ コスト最適化に関する質問事項と改善方法 ✓ まとめ
- 6. 6 これまでのレビュー
- 7. 7
- 8. 8 と思っていたら
- 9. 9
- 10. 10Well-Architected Tool re:Invent 2018で新サービスとして発表！ • Well-Architected Frameworkに基づくレビューをセルフサービスで実施でき るツール • 現時点（2019年1月24日）では英語のみ
- 11. 11作業の流れ 1. マネージメントコンソールへのログイン 2. ワークロードの定義 3. レビュー 4. マイルストーンの保存 5. （以降、改善とレビューを継続）
- 12. 12マネージメントコンソールへのログイン 以下のURLにアクセスします https://console.aws.amazon.com/wellarchitected/ 事前にIAM User / Role に権限を付与してください { "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "wellarchitected:*" ], "Resource": "*" } ] }
- 13. 13 • バージニア北部、オハイオ、オレゴン、北アイルランドリージョンで利用できます • 東京リージョンのワークロードを評価できます（評価にあたりW-A Toolはリソースにアクセスしません）
- 14. 14ワークロードの定義 Name ワークロード（システム）名称 Description ワークロードの概要 Industry type 業種 Industry 細業種 Regions リージョン Environment 本番／非本番 Account IDs – optional AWSアカウントID
- 15. 15ワークロードの定義
- 16. 16レビュー
- 17. 17レビュー “Question does not apply to this workload” ワークロードに適用できない質問をスキップ するときにチェック 例）「AWSサービスへのプログラムによるア クセスをどのように制御していますか？」→ プログラムによる制御をしていない “Notes - optional” 補足事項を記載 例）「RPO/RTOに関する要求レベルが低いた め、単一障害点の排除は付与」のように、ベ ストプラスティスに沿う必要が無い理由など を記載
- 21. 21レビュー
- 24. 24現在のWell-Architected Tool 以下のリソース／機能をマネージメントコンソールで提供 • チェックリスト • チェックリストの回答結果の保存 • 改善案の提示 • 各種リソース（W-A Frameworkの解説ページや公式ドキュメント）へのリンク
- 26. 26日本語化について 現時点でW-A Tool日本語化の予定などは公開されておりません 「AWS クラウドサービス活用資料集」で質問を日本語化した資料が公開 AWS クラウドサービス活用資料集 https://aws.amazon.com/jp/aws-jp-introduction/ AWS Well-Architected Framework ヒアリングシート（日本語版） https://d1.awsstatic.com/webinars/jp/pdf/services/images/Well- Architected_2018Nov.c682850f634e788de4c112f0b782a8520bf35ac5.xlsx 日本語のホワイトペーパーはまだ最新化されていません（2018年6月版） https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well- Architected_Framework_2018_JA_final.pdf 最新の英語版は2018年11月版
- 31. 311．使用量をどのように管理していますか？ 社内のルールに基づいて、ポリシーを設定している (リソース使用ルールやコスト目標など) AWSアカウントは、組織やプロジェクトに対応した構成にしている グループとロールはポリシーに基づいた構成にしている (開発、テスト、本番など) 組織のポリシーと定義されたグループおよびロールに基づいたコストコントロー ルを実装している (IAMによる特定リソースやリージョンへのアクセス禁止制御など) プロジェクトのライフサイクルを追跡している (不要なリソースや支払いが無いかなどの確認)
- 33. 33マルチアカウント戦略 1つの組織で目的に応じて複数のAWSアカウントを利用するアプローチ メリット コストの分離（後述するタグだけでは厳密な識別が難しい場合がある） 権限の分離 デメリット ネットワークの複雑性 AWS Multiple Account Security Strategy https://aws.amazon.com/jp/answers/account-management/aws-multi-account-security-strategy/
- 34. 34マルチアカウントの実装例 AWS Landing Zone • 各アカウントで必要になる機能（ログやセキュリティ対策など）を共有アカウ ントに分離／実装 • アカウントの発行を仕組み化 • シングルサインオン • 最低限必要なセキュリティ／通知設定をアカウント発行時点で自動設定 AWS Answers | AWS Landing Zone https://aws.amazon.com/jp/answers/aws-landing-zone/
- 35. 35マルチアカウントの実装例 [REPEAT 1] Architecting Security & Governance across your AWS Landing Zone (SEC303-R1) - AWS re:Invent 2018 https://www.slideshare.net/AmazonWebServices/repeat-1-architecting-security-governance-across-your-aws-landing-zone-sec303r1-aws-reinvent-2018/59
- 36. 36Landing Zoneのマネージドサービス化 AWS re:Invent 2018 - Keynote with Andy Jassy https://www.youtube.com/watch?v=ZOIkOnW640A
- 37. 37IAM Policy IAM User / Role に対して付与する権限を定義 • Effect（許可／拒否） • Action（どの操作） • Resource（どのリソース） • Condition（条件）
- 38. 38IAM Policy 例：特定のインスタンスタイプのみ起動可能（EC2） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*", "Condition": { "StringEquals": { "ec2:InstanceType": “t3.small" } } } ] }
- 39. 39IAM Policy 例：特定のリージョン以外での操作は不可 { "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1" ] } } }] }
- 40. 402．AWS使用量とコストをどのようにモニタリングしていますか？ AWSのコストと使用量レポートで詳細を確認している 組織と使用量の紐づけを行っている 組織ごとのメトリクスを確認している タグ付け可能なリソースに組織や作業属性に基づいて定義したタグ付けをしてい る AWS Cost ExplorerとAWS Budgetsを設定している 目標コストと使用状況についての分析を実施している コストをダッシュボードなどで積極的に監視している 使用状況またはビジネスの成果に応じて、コストを各チームに分配している (Athenaで分析することも出来る)
- 42. 42AWS Cost and Usage Report 詳細な料金情報をCSV形式でS3に出力 • 時間別／日別での出力 • コスト配分タグを利用可能 • 1つのAWSアカウント内部で利用目的や組織を識別したい場合には設定する必要がある • S3をハブにして Athena / QuickSight / RedShift と連携（後述）
- 43. 43コスト配分タグ コストの分析を目的として付与したタグをレポートに出力することが可 能 • 例：ワークロード（システム）名、オーナー など • レポートにタグがないと必要な切り口での分析ができない Using Cost Allocation Tags https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
- 44. 44【参考情報】タグの利用目的 以下の目的でタグを利用することが多い Technical Tags システムの名称やアプリケーションのバージョン など Tags for Automation バックアップの要否や監視対象かどうかの識別 など Business Tags コストを負担する部門名やプロダクトオーナー名 など Security Tags データの機密性 など AWS Answers | AWS Tagging Strategies https://aws.amazon.com/jp/answers/account-management/aws-tagging-strategies/
- 47. 47Cost Optimization Monitor (AWS Answers) Kibanaによるダッシュボードを容易に構築 Cost Optimization Monitor https://aws.amazon.com/jp/answers/account-management/cost-optimization-monitor/
- 48. 48Athena / QuickSightによるダッシュボード Query and Visualize AWS Cost and Usage Data Using Amazon Athena and Amazon QuickSight https://aws.amazon.com/jp/blogs/big-data/query-and-visualize-aws-cost-and-usage-data- using-amazon-athena-and-amazon-quicksight/
- 49. 493．不要なリソースをどのように削除していますか？ ライフサイクルを意識したリソース追跡をしている (タグ付けを利用して、リソースとワークロードの紐づけを把握している) 孤立した不要なリソースを特定し、リソース停止を検討するプロセスがある なにかイベントがあった際(定期監査時や気づいたときなど)に手動で削除してい る 利用率が低い、重要度の低いなどの不要なリソースを安全に自動的に停止する仕 組みになっている (AutoScalingやスクリプトなど)
- 50. 50CloudWatch Events スケジュールもしくはイベントドリブンで何らかの処理を実行できる スケジュールの例 EC2インスタンスを毎日22時に停止 検証／開発環境などは夜間の稼働は不要（である場合が多い）なので停止する イベントドリブンの例 EC2インスタンスが新たに作成されたらメールで通知 計画されていない作成であれば、CloudTrail や Config で原因を調査する
- 52. 52AutoScaling リソースの利用率（CPUUtilizationなど）に基づいてEC2インスタン スを増減させる機能 AWS Black Belt Online Seminar 2017 Auto Scaling https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-auto-scaling/25
- 53. 534．AWSサービス選択の際にコストをどのように評価していますか？ コストの組織要件を定義している (他の柱とのトレードオフのバランスなど) ワークロード内のすべてのコンポーネントをコスト削減の対象にしている 各コンポーネントについて徹底的な分析をする (マネージドサービスの削減できる運用コストや管理コストも考慮する) コスト全体最適のためにコンポーネントを選択している (マネージドサービス利用、ライセンス費用の考慮) 定期的にコスト最適化の評価をしている (ワークロードの変化や、新サービスの活用)
- 54. 54要件定義 コスト以外の非機能要件、定義してますか？ • 非機能要求グレードでは以下の分類で要件を定義 • 可用性 • 性能／拡張性 • 運用／保守性 • 移行性 • セキュリティ • システム環境・エコロジー • 要件を「どの程度」のレベルまで満たすか定義可能 → 一般的なフレームワークを有効に活用
- 55. 55要件定義（トレードオフの例） 可用性 < コストの場合 RDSインスタンスをSingle-AZで運用する Single-AZであってもある程度のRPO/RTOは担保できる “Amazon RDS Under the Hood: シングル AZ インスタンスのリカバリ” https://aws.amazon.com/jp/blogs/news/amazon-rds-under-the-hood-single-az-instance- recovery/ 移行性 > コストの場合 EC2インスタンスでDBサーバーを構築／移行 オンプレミスからRDSへ移行するための検証に時間を割けない EC2であれば機能上の制約がない（検証／動作確認が容易）
- 56. 56例：マネージドサービスによる運用コストの削減 Amazon RDS • リレーショナルデータベース • バックアップ／リカバリー、バッチ適用が容易に • 様々なデータベースエンジンを選択可能（商用／OSS） AWS Transfer for SFTP • S3と連携するSFTP(Secure File Transfer Service)サービス • ストレージとしてS3を利用するため、拡張性が高い
- 57. 57Commercial LicenseのDBエンジンからの移行 Database Migration Service • データベースの移行サービス • 同種のデータベースだけでなく、異なるデータベース間の移行もサポート • 継続的レプリケーションをサポート Schema Conversion Tool • 異なるデータベース間でデータを移行する前にスキーマの変換を行うことが可 能
- 58. 58Commercial LicenseのDBエンジンからの移行 例：OracleからPostgreSQLへの移行ベストプラクティス • Best practices for migrating an Oracle database to Amazon RDS PostgreSQL or Amazon Aurora PostgreSQL: Migration process and infrastructure considerations https://aws.amazon.com/blogs/database/best-practices-for- migrating-an-oracle-database-to-amazon-rds-postgresql-or- amazon-aurora-postgresql-migration-process-and- infrastructure-considerations/
- 59. 595．コスト目標を達成するためにインスタンスタイプとサイズを どのように選択していますか？ コストモデリングを実行する (ワークロード内の各コンポーネントのコスト比率やコストの変化など) 以前のワークロードの計測や特性に基づいてリソースタイプとサイズを選択して いる パフォーマンスメトリクスに基づいたサイジングを実施している
- 60. 60 「推測するな 計測せよ」
- 62. 62ワークロードの監視 エージェントによるEC2インスタンスの詳細な監視も可能 • CloudWatch Agent • 各種メトリックの監視 • cpu_*, disk_*, diskio_*, mem_*, net_*, netstat_*, processes_*, swap_* • 各種プラグインの利用も可能 • procstat, StatsD, collectd • CloudWatch Logs Agent • ログの監視 • メトリックフィルタによる通知 • インサイトによるログの分析 • 「Amazon CloudWatch Logs Insightsでログの高速な分析が可能になりました #reinvent」 https://dev.classmethod.jp/cloud/aws/amazon-cloudwatch-logs-insights/
- 63. 63Trusted Advisor AWSアカウントの状態を自動で評価するサービス 利用率が低い／利用されていないリソースの特定などが可能 20180711 AWS Black Belt Online Seminar AWS Trusted Advisor https://www.slideshare.net/AmazonWebServicesJapan/20180711-aws-black-belt-online-seminar-aws-trusted-advisor
- 64. 646．コスト削減のために料金モデルをどのように選択していますか？ 購入オプション活用に向けた分析をしている (Cost ExplorerのRI推奨機能など) スポットインスタンス(スポットフリートやスポットブロックを含む)を活用して いる すべてのコンポーネントに購入オプション(オンデマンド、リザーブ、スポットイ ンスタンス)を検討している リージョン毎の料金の差を考慮している
- 65. 65様々な購入オプション 1. オンデマンドインスタンス 2. リザーブドインスタンス 3. スポットインスタンス
- 66. 66On-demand Instance 利用量／時間に応じた課金、前払いなしの課金体系 • インスタンスの稼働時間 • 保存しているデータ量 • API Call数 • データ転送量 • ユーザー数 • 他・・・
- 67. 67Reserved Instance (RI) 年または3年の利用コミットによる料金割引 • EC2、RDS、Redshift、Elasticache、Elasticsearch Serviceで利用可能 • m5.xlarge(Linux)のEC2インスタンスを3年間利用する場合の料金例 • オンデマンド • $0.248 / h × 24h × 365d × 3y = $6,517.44 • リザーブドインスタンス（3年／全額前払い／スタンダード） • $2,861.00 → オンデマンドと比較して約56％の割引 Amazon EC2 リザーブドインスタンス料金表 https://aws.amazon.com/jp/ec2/pricing/reserved-instances/pricing/
- 68. 68Spot Instance AWS上の余ったリソースを格安で提供 • 現在の価格を上回る価格で入札するとインスタンスが起動 • 現在の価格が入札価格を上回るとインスタンスが削除
- 69. 69Spot Instance
- 71. 71Spot Instance 「Amazon EC2 スポットでスポットインスタンスの停止と開始が可能 に」（2017年9月） https://aws.amazon.com/about-aws/whats-new/2017/09/amazon-ec2- spot-can-now-stop-and-start-your-spot-instances/ → 利用しているサービスのアップデートを把握しておくことが重要
- 73. 73スポットフリート 指定した条件（価格、インスタンス／vCPU）に基づいてインスタンス を利用 • 配分戦略に応じて複数のスポットプールを利用し、インスタンスを起動 • Lowest Price / Diversified を選択 • 詳細は以下の資料をご確認ください • AWS Black Belt Online Seminar 2016 Amazon EC2 Spot Instances （スポットインスタンス） https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online- seminar-2016-amazon-ec2-spot-instances
- 75. 75リージョン間の価格差 m5.xlargeのEC2インスタンス（Linux）の場合 • 東京リージョン • $ 0.248/時間 • オレゴンリージョン • $ 0.192/時間 → 約23％安い！ Amazon EC2 料金表（オンデマンド料金） https://aws.amazon.com/jp/ec2/pricing/on-demand/
- 76. 76料金の試算 購入オプションを変更した場合の料金を試算 SIMPLE MONTHLY CALCULATOR https://calculator.s3.amazonaws.com/index.html?lng=ja_JP# AWS Pricing Calculator https://calculator.aws/#/
- 77. 777．データ転送料金についてどのように計画していますか？ データ転送量についてのモデリングを実行する (ビジネス計画に基づくデータ転送量の変化など) データ転送量を最適化するアーキテクチャになっている (アプリケーション設計, WAN最適化, Multi-AZ, リージョン選択等) データ転送量を削減するためのサービスを活用する (CloudFront、ElastiCache、Direct Connectなど)
- 79. 79試算例 S3のWebサイトホスティング（デジタルコンテンツの配信） • ストレージ料金 • 10MB/Content × 約100,000 Contentと仮定 • $0.025 × 1024GB = $25.5 • リクエスト料金 • 10,000,000 GETと仮定 • $0.00037/k × 10,000k = $3.7 • データ転送料金 • 10MB × 10,000,000 GET = 100TB • $0.114/GB × 10TB + $0.089/GB × 30TB + $0.086/GB × 60TB = $9185.28 • 合計：$9214.48 Amazon S3 の料金 https://aws.amazon.com/jp/s3/pricing/
- 80. 80どうすれば費用を削減できるか？ データ転送量が費用の大半を占める • コンテンツのサイズを減らす（技術的なアプローチ） • 圧縮など • リクエストを減らす（技術的なアプローチ） • クライアントサイドキャッシュなど • CloudFrontのリザーブドキャパシティーを利用（ビジネス的なアプローチ） • 10TB以上の利用をコミットすれば、ディスカウント可能 → モデリングを通して、何がコストに効くのかを把握
- 81. 81ミドルウェアでできるデータ転送量の削減 （例）Webサーバーの場合 • 圧縮転送を有効にする（nginxの場合） • Module ngx_http_gzip_module http://nginx.org/en/docs/http/ngx_http_gzip_module.html • クライアントサイドキャッシュの有効化 • 14.9 Cache-Control https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 → 従来のノウハウも活用できる
- 84. 84Direct ConnectとVPN接続の比較 （例）月間のデータ転送量が100GBの場合 • DirectConnect（1Gbpsのポート × 2） • ポート料金：$0.285/h × 2ポート × 24h × 30d = $410.4 • データ転送（送信）：$0.0410/GB × 100GB = $4.1 • 合計：$414.5 • VPN接続（接続を冗長化） • 接続時間： $0.048/h × 2接続 × 24h × 30d = $69.12 • データ転送（送信）： $0.114/GB × 100GB = $11.4 • 合計：$80.52 AWS Direct Connect の料金 https://aws.amazon.com/jp/directconnect/pricing/ Amazon VPC の料金 https://aws.amazon.com/jp/vpc/pricing/
- 85. 85Direct ConnectとVPN接続の比較 （例）月間のデータ転送量が10TBの場合 • DirectConnect（1Gbpsのポート × 2） • ポート料金：$0.285/h × 2ポート × 24h × 30d = $410.4 • データ転送（送信）：$0.0410/GB × 10000GB = $410 • 合計：$820.4 • VPN接続（接続を冗長化） • 接続時間： $0.048/h × 2接続 × 24h × 30d = $69.12 • データ転送（送信）： $0.114/GB × 10000GB = $1140 • 合計：$1,209.12 → 利用量によってコスト効率の高い方法が変わり得る （サイト間接続については、アクセス回線の費用も含めて比較検討をお願いします。） AWS Direct Connect の料金 https://aws.amazon.com/jp/directconnect/pricing/ Amazon VPC の料金 https://aws.amazon.com/jp/vpc/pricing/
- 86. 868．リソースの供給と顧客の需要をどのように一致させていますか？ ワークロード需要の分析を実施している (季節的な変動など様々な要因) リソースを需要に応じて手動で追加削除している 需要ベースで対応している (変化する要求に対応するためにAuto Scalingを利用)
- 88. 88様々なスケーリング 手動 • インスタンスタイプの変更（スケールアップ／ダウン） • EC2インスタンスをELBに登録／登録解除 • AutoScaling Desired Countを手動で変更 自動 • AutoScalingによる自動スケーリング （スケジュール／リソースベース）
- 89. 89インスタンスタイプの変更 インスタンスタイプ変更 • ターゲットグループからインスタ ンスを削除 （ELBからのルーティングを停止） • インスタンスを停止 • インスタンスタイプを変更／起動 • インスタンスをターゲットグルー プに追加
- 90. 90手動でのインスタンスの追加 ELB配下のEC2インスタンスを 手動で操作 （追加する場合） • インスタンスを作成 • register-targetsでターゲットグ ループにインスタンスを追加
- 92. 92AutoScaling Groupの手動運用 AutoScaling GroupのDesired Countを手動で操作 • インスタンス数がDesired Countの 数に収束
- 93. 93AutoScaling Groupの自動運用 スケジュールに基づくスケーリ ング • 毎週土曜のAM9:00にスケールアッ プ • 毎週土曜のPM1:00にスケールダウ ン
- 94. 94AutoScaling Groupの自動運用 CloudWatchメトリクスの値に 応じてDesired Countを増減 • スケールアウト • CPU利用率が60％を超えたらインスタン スをXつ追加 • スケールイン • CPU利用率が30％を下回ったらインスタ ンスをYつ削除
- 95. 95The Twelve-Factor App I. コードベース バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係 依存関係を明示的に宣言し分離する III. 設定 設定を環境変数に格納する IV. バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロセスと して実行する VII. ポートバインディング ポートバインディングを通してサービスを公開する VIII. 並行性 プロセスモデルによってスケールアウトする IX. 廃棄容易性 高速な起動とグレースフルシャットダウンで堅牢性を最大化する X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログ ログをイベントストリームとして扱う XII. 管理プロセス 管理タスクを1回限りのプロセスとして実行する Twelve-Factor App https://12factor.net/ja/
- 96. 969．新しいAWSサービスをどのように評価していますか？ コスト最適化を担当するチームがある コスト最適化のルールがある (AWS利用料の10%を超えるサービスは四半期ごと、10%未満は1年毎に見直す など) 計画されておらず、必要そうであれば都度検討する 定期的にコスト関するレビューをして、分析している 定期的にAWSのソリューションアーキテクトやAPNパートナーとのミーティング を実施したり、ブログをチェックするなどコスト削減に役立ちそうな新機能の適 用を検討している
- 99. 99情報収集（有償） 公式トレーニング https://aws.amazon.com/jp/training/ オンライン学習サービス 例）A CLOUD GURU https://acloud.guru/ プロフェッショナルサービス AWS プロフェッショナルサービス https://aws.amazon.com/jp/professional-services/
- 100. 100インスタンスタイプの世代による価格差 汎用インスタンス（Linux/東京）の場合 • m3.xlarge：$0.385/時間 • m4.xlarge：$0.258/時間 • m5.xlarge：$0.248/時間 → 新しい情報のキャッチアップが重要 Amazon EC2 料金表（オンデマンド料金） https://aws.amazon.com/jp/ec2/pricing/on-demand/ 旧世代のインスタンス https://aws.amazon.com/jp/ec2/previous-generation/
- 101. 101M5などのNITROインスタンスへの移行について 第5世代のインスタンスタイプは新しいハイパーバイザーを利用してい るため、移行には注意が必要 • Windows • 最新世代のインスタンスタイプへの移行 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/migrating-latest- types.html • Linux • NITRO世代(C5、M5)へのEC2インスタンスタイプ変更を試してみた(Amazon Linux編) #reinvent https://dev.classmethod.jp/cloud/aws/change-type-to-m5-nitro-generation/
- 102. 102新サービスの評価 最近提供されはじめたマネージドサービス • Amazon FSx • Amazon DocumentDB (MongoDB 互換) • AWS Transfer for SFTP • Amazon Managed Blockchain • Amazon Connect • Amazon Managed Streaming for Kafka • Amazon Personalize / Forecast / Textract (Preview) • （他、多数）
- 103. 103 まとめ
- 104. 104Well-Architected Frameworkは「考え方」 唯一の正解があるわけではない • 全てのベストプラクティスに対応する必要はない （無理は禁物） • 優先順位は利用者のビジネス環境やステークホルダーの要求に寄って異なる （要件や優先順位を明確に） 「組織で」「継続的に」レビューすることが重要 • 全てのステークホルダーとレビューを実施 • AWSがアップデートするように、AWSで構築したシステムもアップデート
- 107. 107