AWSご利用開始時に最低限おさえておきたい10のこと · 以前から「漠然と100%活用できてない。なんとかしないと…」とは思っていた。

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾンウェブサービスジャパン株式会社

Well-Architected Lead 髙山博史2018/04/03

【AWS White Belt Online Seminar】

AWSご利用開始時に最低限おさえておきたい10のこと

White BeltOnline Seminar


内容についての注意点

• 本資料では2018年04月03日時点のサービス内容および価格についてご説明しています。最新の情報は

AWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください

• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違が

あった場合、AWS公式ウェブサイトの価格を優先とさせていただきます

• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税

をご請求させていただきます

AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at

http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information

that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

http://aws.amazon.com/


本日のセミナーの目的

これからAWSを使う方、最近AWSを使い始めた方が…

AWS利用開始時(DAY1)に最低限おさえておきたい設定などを理解する

AWS活用のベストプラクティス(の一部)を理解する

(ベストプラクティスに則った設計・構築・運用とすることで)

お客様ビジネス成功の可能性が向上

すでにご利用されている方の見直しにも最適

その際に…

最終的には…


本日の流れ

AWS Well-Architected Framework(W-A)の…• 全体像(概要)を理解する• 活用方法を理解する

AWS利用開始時に最低限おさえておきたいこと• セキュリティ(5項目)• コスト最適化 (3項目)• 信頼性 (2項目)

まとめ


AWS Well-Architected Framework(W-A)とは?





・AWSのソリューションアーキテクト(SA)と

お客様が数多くの経験で作り上げたもの

・AWSとお客様と共に、

W-Aも常に進化し続ける

システム設計・運用の”大局的な”考え方とベストプラクティス集



設計原則と(質問と回答形式)のベストプラクティス集

コストの

最適化

セキュリティ信頼性パフォーマンス

効率

運用性

あくまでも設計”原則“なので、実装の詳細やアーキテクチャパターンは扱っていない



設計原則と(質問と回答形式)のベストプラクティス集

コストの

最適化

セキュリティ信頼性パフォーマンス

効率

運用性

実際の開発者だけでなく、ユーザ企業にもおさえておきたい内容


AWS Well-Architected Frameworkの構成要素

ホワイトペーパー、チェックリストで構成

①メインとなるW-Aホワイトペーパーと、柱ごと5つの詳細版ホワイトペーパー

②「ベストプラクティスに則っているか」のチェックリスト(確認質問集)

①AWS Well-Architected Framework ホワイトペーパーコストの最適化

詳細版WP

セキュリティ

詳細版WP

信頼性

詳細版WP

パフォーマンス

効率詳細版WP

運用性

詳細版WP

②チェック

リスト


AWS W-Aホワイトペーパーの概要紹介

ホワイトペーパーの構成

• クラウドでの設計(大)原則と、

5つの柱ごとの「質問と回答形式でのベストプラクティス」が記載されています

設計(大)原則• 必要な容量の判断を勘に頼らない

• 本番のスケールでテストする

• アーキテクチャの実験を容易にするために自動化を取り入れる

• 発展的なアーキテクチャを取り入れる

• データドリブンでのアーキテクチャ変更

• 本番で想定される事態をあらかじめテストする


質問と回答形式でのベストプラクティス(例)AWS Well-Architected Frameworkホワイトペーパーより…

例：信頼性の質問(抜粋)

災害対策のリカバリプランは策定していますか？

□ RTO、RPOが定義されている□ DRを考慮した戦略を定義済み□ DRサイトにも最新のAMIや設定を展開し、構成の差異がないようにしている

□ DRサイトへのフェイルオーバーを定期的にテストしている

□ 自動的なリカバリを実装している


AWS Well-Architected Frameworkの活用シーン



様々なフェーズでAWS W-Aをご活用いただけます(新規構築時)

要件検討設計構築運用

継続的なKAIZEN(定期健康診断)システム要件の確認

ベストプラクティスに則った設計

サービス開始前の確認(納車前点検)

システム要件を検討する際の

材料として、ホワイトペー

パーを活用

ホワイトペーパーで、ベスト

プラクティスを理解し、設計

を実施(リスクの把握)

サービス開始前に、チェック

リストでベストプラクティス

に則っているかの確認(リスク

の把握)

運用中のシステムに対して、

リスクや改善出来る項目の洗

い出しを実施



様々なフェーズでAWS W-Aをご活用いただけます(既存システムに対して)

次の設計時にリスクの洗い出し改善計画改善

運用中のシステムに対して、

様々なリスクや、コスト最適

化など改善出来る項目の洗い

出しを実施

改善必要箇所について、対策

や改善計画(優先度付け)を検

討

対策や改善契約を元に、実際

にシステム変更や改修を実施

する

事情により、既存システムの

改善ができない場合も、次期

システムの設計時に活かすこ

とが出来る

運用設計



AWS W-Aを活用されたお客様の声網羅的なチェックリストにより、

サービス開始前にセキュリティリスクを

発見できて非常によかった

オンプレミスからスピード感を持って移行したので、

以前から「漠然と100%活用できてない。

なんとかしないと…」とは思っていた。

改善すべきポイントが明確になってよかった(稼働中のシステムに対して)コスト削減にまで、

手がまわってなかった、リザーブドインスタンスを

活用したコスト削減が出来て助かっている稼動中システムの問題点が明確になった。

既存システムは改修出来ないが、

次期システム以降の設計に活かしていきたい。

また是非W-Aかどうかのチェックをしたい

自社の設計に対して、AWSのベスト

プラクティスとのと答え合わせが

出来てよかった。自信を持てた


AWS利用開始時に最低限おさえておきたいこと


AWS利用開始時に最低限おさえておきたいこと

[1]AWS利用開始時に

最低限おさえておきたいこと

• セキュリティ(5項目)

• コスト最適化 (3項目)

• 信頼性 (2項目)

[2]AWSサポート• AWSサポートの活用

• Trusted Advisor

[3]まとめ

参考:システム設計における優先度(AWS Well-Architected Frameworkホワイトペーパーより)AWS Well-Architected Frameworkは、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、運⽤性という 5 本の柱を基本としています。ソリューション

を設計する際にビジネス要件に基づいて柱の間でトレードオフを⾏うことになり、こうしたビジネス上の決定がエンジニアリングの優先付けにつながります。開発環境では

信頼性を犠牲にすることでコストを削減するという最適化を⾏う場合や、ミッションクリティカルなソリューションでは、信頼性を最適化するためにコストをかける場合などがありま

す。E コマースソリューションでは、パフォーマンスが収益と顧客の購入優先順位に影響を与える可能性があります。セキュリティと運用性は、通常、他の

柱とトレードオフされることはありません。


セキュリティ


AWS Well-Architected FrameworkAWS Well-Architected Frameworkホワイトペーパーより…

セキュリティの質問(抜粋)[SEC 1]どのようにしてルートアカウントでのログインを保護していますか？

[SEC 2]マネージメントコンソールやAPIを操作するシステム管理者の役割と権限を、

どのように制限していますか？

[SEC 3]AWSのリソースに(アプリケーションやスクリプト、サードパーティのツール等から)

自動的にアクセスする場合の権限はどのように制限していますか？

[SEC 4]AWSインフラのログを蓄積し分析していますか？

[SEC 5]どのようにネットワークやホストベースの境界防御をしていますか？


セキュリティで最初にやっておきたいこと

[1]AWSルートアカウントは極力使用しない

[2]ユーザには最小限の権限を付与する

[3]認証情報を埋め込まない

[4]証跡の取得

[5]各レイヤでのセキュリティ対策


1.AWSルートアカウントは極力利用しない

AWSルートアカウントとは？• アカウント作成に使用したメールアドレスと設定したパスワードでのサインイン

• アカウントの全ての AWS サービスとリソースへの完全なアクセス権限を持つ

AWSルートアカウントはMFAを設定し、”極力”利用しない• 十分に強度の強いパスワードを設定したの上、多要素認証(MFA)で保護し、通常は極力利用しないような運用を推奨

• Security CredentialのページからAccess Keyを削除する(ただしAccess Keyを使用していないか確認が必要)

一部、ルートアカウントが必要となる操作もあります(https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html)

AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM) https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-identity-and-access-management-aws-iam

https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_tasks-that-require-root.html

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-aws-identity-and-access-management-aws-iam


1.AWSルートアカウントは極力利用しない

ルートアカウントではなくIAMを利用する

AWS Identity and Access Management (IAM)とは？• AWSリソースへのアクセスを安全に制御するためのサービス以下の機能を提供

ユーザ/認証情報管理• IAMユーザ / パスワード• MFA (多要素認証)• 認証情報のローテーション

AWS リソースへの安全なアクセス• IAMロール

アクセス権限管理• IAMグループ• IAMポリシー




2.ユーザには最小限の権限を付与する

IAMユーザとIAMグループとは？IAMユーザ• AWS操作用のユーザ。マネジメントコンソールへのサインインや、API または CLIの使用時に利用する

• 名前、マネジメントコンソールにサインインするためのパスワード、API または CLI で使用できるアクセスキーで構成されている

• AWSサービスへのアクセス権限をJSON形式でポリシーを記述する

IAMグループ• IAMユーザをまとめるグループ• AWSサービスへのアクセス権限をJSON形式でポリシーを記述




2.ユーザには最小限の権限を付与する

ユーザに最小限の権限を付与する• IAMユーザとIAMグループを利用する• 最小限のアクセス権限から開始し、必要に応じて追加のアクセス権限を付与する

その他IAMユーザ関連のベストプラクティス• 特権のある IAM ユーザ(機密性の高リソースまたは API にアクセスが許されているユーザー)に対してはMFAを有効化する

• 認証情報を定期的にローテーションする(認証情報漏洩時のリスク軽減)




3.認証情報を埋め込まない

IAMロールとは？• Amazon EC2のようなAWSサービスに対して、

AWS操作権限を付与するための仕組み• 認証情報はSTS(Security Token Service)で生成し、自動的に認証情報のローテーションが行われる

EC2やLambdaにはIAMロールを利用• 認証情報をOSやアプリケーション側に持たせる必要がなく、認証情報の漏えいリスクを低減可能メタデータ

IAMロール利用

プログラム

IAMユーザー利用

IAM Role


認証情報をEC2内に持たせる認証情報の保管、ローテーション

等の検討が必要

IAMロールによる権限はEC2上に恒久的に保管されるものではなくテンポラリ。ローテーション等は自

動で行われる。

プログラム

SDK/CLI



3.認証情報を埋め込まない

参考 : git-secrets を使った認証情報の管理• AWS Labsの認証情報をgitリポジトリにコミットすることを防ぐツール

コミットの防止$ git secrets --register-aws$ git add git-secret.py$ git commit -m "This is a test commit for git-secret"git-secret.py:1:AWSAccessKeyId = ”AKIAIOSFODNN7EXAMPLE"git-secret.py:2:AWSSecretKey = " wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY "[ERROR] Matched one or more prohibited patterns

既存レポジトリのスキャン$ git secrets --scan

AWS Labs git-secrets https://github.com/awslabs/git-secrets

https://github.com/awslabs/git-secrets


4.証跡取得(ログ取得)

AWS CloudTrailによる操作ログの取得を設定する• AWSユーザのAPI操作などのアクションをログ取得保存するサービス• セキュリティインシデント発生時の分析に活用

• CloudTrailのログをCloudWatch Logsに転送し監視することも可能→全リージョン有効化の上、必要に応じた期間を設定することを推奨

その他ログも有効化する(手動での有効化が必要)• Amazon S3バケット• Amazon API Gateway

• ELB• Amazon CloudFront• VPC Flow Logs

AWS Black Belt Online Seminar 2016 AWS CloudTrail & AWS Confighttps://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-aws-cloudtrail-aws-config

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2016-aws-cloudtrail-aws-config


4.証跡取得(ログ取得)→脅威の検出

Amazon GuardDutyの活用• CloudTrailやVPC Flow Logs等のデータから疑わしいアクティビティを検知するサービス

• GuardDutyはAWSが管理する基盤で動作し、エージェント等の導入は不要で性能影響もなし

• 検知したイベントは重度に応じてラベリングされ、推奨される対策とともに提示される(処理したログ量に応じた課金体系なので、30日の無料試用で実績量を測定することを推奨)


5.各レイヤでのセキュリティ対策

アクセス設定を必要最低限に設定• インターネット等の外部からのアクセスを必要最小限に限定していなかったり、不必要なポートが開いていたりサービスが稼働していると外部からの攻撃を受けるリスクとなる

ネットワークレイヤ –ネットワークACL-• VPCのサブネット単位で設定するスレートレスなファイアーウォール• ベースラインとなるポリシーを設定するのに用いる

各リソース (EC2, Amazon RDSなど) –セキュリティグループ-• インスタンス(グループ)単位に設定するステートフルなファイアーウォール• サーバの機能や用途に応じたルール設定に適している

AWS Black Belt Online Seminar利用者が実施する AWS 上でのセキュリティ対策) http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-aws-56260969

http://www.slideshare.net/AmazonWebServicesJapan/awswebinar-aws-56260969


5.各レイヤでのセキュリティ対策

ネットワーク境界での防御オプションを活用

AWS WAF• ウェブアプリケーションを対象とした悪意のあるウェブリクエストを検出し、ブロックすることを助けるWeb アプリ

ケーションファイアウォール

• SQL インジェクションやXSSといった一般的なウェブの弱点から保護するためのルールを作成して利用する• ALB(Application Load Balancer)とCloudFrontに設定できる

AWS Shield• 分散サービス妨害 (DDoS) に対する保護サービスで、レイヤー 3 および 4を標的とした既知の攻撃を総合的に防御• 全てのユーザはデフォルトで自動的にShield “Standard”プランの保護適用が設定済• さらに高度なレベルの保護が必要な場合は、Shield “Advanced”プランも選択可能

WAF利用の観点でも、ALBやCloudFront導入は検討すべきサービス

AWS Black Belt Online Seminar 2017 - AWS WAF –https://www.slideshare.net/AmazonWebServicesJapan/20171122-aws-blackbeltawswafowasptop10

AWS Black Belt Online Seminar 2017 -AWS Shield –https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-shield

https://www.slideshare.net/AmazonWebServicesJapan/20171122-aws-blackbeltawswafowasptop10

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-shield


コスト最適化


AWS Well-Architected FrameworkAWS Well-Architected Framework ホワイトペーパーより

コスト最適化の質問(抜粋)[COST 2]コスト目標に応じてリソースをサイジングしていますか？

[COST 3]コスト効率を高めるために適切な購入オプションの検討を実施していますか？

[COST 6]AWSのコストをどのように管理していますか？


コスト効率化で最初にやっておきたいこと

[6]適切なサイジング

[7]購入オプションの検討

[8]使用料金の把握


6.適切なサイジング

AWS CloudWatchでリソース利用状況を把握する• AWS上で稼働するシステム監視サービス• システム全体のリソース使用率、アプリケーションパフォーマンスを把握

• 予め設定した閾値を超えたら、メール通知、AutoScalingなどのアクションも可能することも可能

• またCloudWatch LogsでOS上やアプリケーションのログも取得可能

AutoScaling

EC2 Action

CloudWatch

[Custom Metric]Memory Free / Filesystem Free

Notification

CPUUtilizationDiskReadBytes / DiskWriteBytes /

NetworkIn / NetworkOut

AWS Summit Tokyo 2017資料「AWS の運用監視入門」(PDF)https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T3-5.pdf

https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T3-5.pdf



利用状況に応じた適切なインスタンスタイプなどを選択

使用率が安定している場合• 使用率が低い/高い場合は、インスタンスファミリーやタイプの見直し• 使用率が適切な場合は、リザーブドインスタンス(後述)の購入も検討

使用率が一定でない場合• 時刻ごとの台数増減、AutoScaling活用を検討• バッファベース(Amazon SQSや

Amazon Kinesisを活用した)の処理も検討






使用率が安定している場合• 使用率が低い/高い場合は、インスタンスファミリーやタイプの見直し• 使用率が適切な場合は、リザーブドインスタンス(後述)の購入も検討







インスタンスタイプの見直しを検討する

インスタンスファミリーとサイズ• 利用特性に合わせて、汎用(M5,M4,T2)、コンピューティング最適化(C5,C4)、メモリ最適化(R4)などのインスタンスファミリーと、サイズ(large,smallなど)を選択

m4 . xlargeインスタンス

ファミリー(特性)世代サイズ



最新インスタンスファミリーを活用する• 最新インタンスファミリーのほうが高性能かつ安価なことが多い

• アジアパシフィック(東京)のEC2メモリ最適化インスタンスの価格比較例

vCPU 4コア(ECU13.5)メモリ30.5GB

vCPU 4コア(ECU13.0)メモリ30.5GB

この場合ではR4の方が約20%安価*インスタンスタイプによる異なる

r4.xlarge r3.xlarge$0.3200 $0.3990


7.購入オプションの活用


使用率が安定している場合• 使用率が低い/高い場合は、インスタンスファミリーやタイプの見直し• 使用率が適切な場合は、リザーブドインスタンスの購入も検討







検討すべき購入オプション① -時間課金系サービス-• AWSには、さまざまな購入オプションがあります。お客様のビジネスニーズに合った最も費用対効果の高い購入オプションを選択してください

リザーブド

インスタンス

(オプション)

スポット

インスタンス

(オプション)

長期(1年or3年)の利用コミットによる割引料金の適用

AWS余剰リソースをより安価に利用可能

オンデマンド

インスタンス

(デフォルト)

初期費用なし、コミットなしの従量課金

EC2 RDS ElastiCache Redshift

ElasticMapReduce

EC2

EC2 RDS ElastiCache RedshiftElasticMapReduce

・常時稼働しているサーバ- DB,キャッシュサーバ- (最低限必要の)Web/Appサーバ

・分散処理のタスクノード、クローラ・メディアプロセッシング

・ピークなど増減するWeb/Appサーバ・一時利用のキャンペーンサイト・昼にしか使わない開発サーバ

近年、ECSやSpotFleetの機能追加などから活用シーンが拡大している

AWS Black Belt Online Seminar 2017 AWS のコスト最適化リザーブドインスタンスhttps://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-2017-cost-optimization-reserved-instance

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-2017-cost-optimization-reserved-instance



リザーブドインスタンスの適用箇所を検討• コストエクスプローラーのリザーブドインスタンス関連ビューを活用して、適用箇所を検討する。下記はカバレッジ(どれだけ適用されているか)のビュー(https://aws.amazon.com/jp/aws-cost-management/reserved-instance-reporting/)

• 後述のコストエクスプローラー有効化の設定が必要

https://aws.amazon.com/jp/aws-cost-management/reserved-instance-reporting/



検討すべき購入オプション② -その他 -• その他、さまざまな購入オプションがあります。お客様のビジネスニーズに合った最も費用対効果の高い購入オプションを検討

Amazon Cloudfrontリザーブド

キャパシティ

長期(1年)利用コミットによる割引料金の適用

Amazon DynamoDBリザーブドキャパシティ

長期(1年)利用コミットによる割引料金の適用


コスト最適化の参考資料

【AWS Black Belt Online Seminar】AWS Well-Architected Frameworkによるコスト最適化

AWS Black Belt Online Seminar Well-Architected Frameworkによるコスト最適化https://www.slideshare.net/AmazonWebServicesJapan/20180313-aws-black-belt-online-seminar-wellarchitected-framework-90468212

https://www.slideshare.net/AmazonWebServicesJapan/20180313-aws-black-belt-online-seminar-wellarchitected-framework-90468212


8.使用料金の把握[準備]

IAMユーザの請求情報へアクセス有効化• IAMユーザが請求情報にアクセス出来るようにするための設定。IAMポリシーとは別に設定が必要(https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html)

コストエクスプローラーの有効化• 料金情報可視化ツールのコストエクスプローラーも有効化することを推奨

(https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/cost-explorer-access.html)

ルートアカウントでの操作が必要

ルートアカウントでの操作が必要

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/cost-explorer-access.html


8.使用料金の把握①

請求情報とコスト管理ダッシュボード、請求書• 利用状況サマリとサービスごとのご利用状況が確認可能

• 日頃から確認することを推奨


8.使用料金の把握②

コストエクスプローラー• サービスごとや、アカウントなど様々なビューで、使用量と使用料金が確認可能

• コストエクスプローラー有効化後のデータが閲覧対象になる


8.使用料金の把握③

請求アラーム(Billing Alert)の活用• 利用状況を監視し、閾値を越えたら通知することが可能

• 設定した閾値を越えた場合、Simple Notification Service(SNS)にて通知SNSの機能により、EメールやHTTP/HTTPS等で通知出来る(https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/monitor-charges.html)

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/monitor-charges.html


信頼性


AWS Well-Architected FrameworkAWS Well-Architected Framework ホワイトペーパーより

信頼性の質問(抜粋)[REL 6]どのようにデータのバックアップをしていますか？

[REL 7]システムはコンポーネントの障害や不具合に耐えられるようにしていますか？その手段は？


信頼性で最初にやっておきたいこと

[9]データのバックアップ

[10]障害や不具合への対策


9.データのバックアップ

AWS各サービスのバックアップ機能を活用する①

EC2のAMI• 必要に応じて、

EC2のAmazon マシンイメージ (AMI)を作成

Amazon EBSのスナップショット• 必要に応じて、EBSのスナップショットを取得• 作成時はデータ整合性を保つため、静止点を設ける事を推奨

EC2 EC2

AMI作成AMIからEC2起動

スナップショット作成

スナップショットから

EBS作成

AWS Summit Tokyo 2017資料「Amazon EC2 入門」(PDF)https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T4-7_v2.pdf

AWS Black Belt Online Seminar 2017 -Amazon EBS -https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-

store-ebs-83913049

トラブル発生時を想定した、復旧テストで手順を確認しておくことを推奨

https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T4-7_v2.pdf

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-amazon-elastic-block-store-ebs-83913049


9.データのバックアップ

AWS各サービスのバックアップ機能を活用する②

RDSの自動バックアップ機能• 1日1回のスナップショット取得と、スナップショット取得から5分前までのトランザクションログ取得し、Point-in-Timeリカバリ(DBインスタンス作成)を実現

• 最長35日まで設定可能(それ以上の期間をバックアップしたい場合、手動でのスナップショット取得が可能)

AWS Summit Tokyo 2017資料「Amazon Relational Database Service (RDS) 入門」(PDF)https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T3-6.pdf

トラブル発生時を想定した、復旧テストで手順を確認しておくことを推奨



10.障害や不具合への対策

単一障害点の排除• 冗長化しておくなどの準備が重要

(…ですが本資料では詳細は扱わず、別途扱います)

アベイラビリティーゾーンアベイラビリティーゾーン

Auto Scaling Group

この1台が停止しても、システムの停止にはつながらない

AWS Summit Tokyo 2017資料「Architecting for the Cloud -クラウドにおけるアーキテクチャの設計原則」(PDF)https://d1.awsstatic.com/events/jp/2017/summit/slide/D3T2-3.pdf




すぐに出来る対策①

RDSのMultiAZデプロイメント(オプション)• 同期レプリケーション(冗長化)と自動フェイルオーバーを実現• データ冗長化と、可用性向上を実現できる

• 非常に有効なので本番環境では、必ず設定すべきオプション

AWS Summit Tokyo 2017資料「Amazon Relational Database Service (RDS) 入門」(PDF)https://d1.awsstatic.com/events/jp/2017/summit/slide/D2T3-6.pdf

Region

Multi-AZ

Availability zone

Availability zone



マネージドサービスの活用

AWSの多様なサービスは、大半が「マネージドサービス」お客様からの「○○の管理や運用が大変なので、AWSでマネージドサービスを提供欲しい」という声にお答えした結果として充実



すぐに出来る対策②

ELB(Elastic Load Balancing)の活用• AutoScalingの活用や、各種セキュリティサービスの観点からも活用したい

EC2 - AutoScalingの活用• 最小台数を設定し、インスタンス異常時にも起動している台数を維持する

(https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-maintain-instance-levels.html)

EC2 - AutoRecovery• インスタンスの異常を検知し、復旧する仕組み

• CloudWatchアラームの”Recover this Instance”を活用(https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html)

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/as-maintain-instance-levels.html

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html


AWSサポート - Trusted Advisor -


AWSサポートの活用

AWSはサポートを(あえて)バンドルしていない• デフォルトでは、サポートをバンドルせず、最適なプランを選択できる

• お客様の「24時間365日体制の電話サポートが必要」「専任担当者アサインが欲しい」「サポート不要なので1円でも安価に利用したい」などの様々なニーズにお答えできるように、3種類のサポートプランをご用意

サポートプランの選択• サポートプランにより、連絡手段、応答時間などが異なる

• 本番環境用アカウントでは「Trusted Advisor(後述)」も利用できるビジネスプラン以上を推奨


AWSサポートの活用

最適なサポートプランを選択できる

プランデベロッパービジネスエンタープライズ

サポートへのコンタクト方法

Webフォーム電話、チャットWebフォーム

電話、チャットWebフォーム

対応時間平日9時-18時 24時間年中無休 24時間年中無休選択できる最も高い緊急度

12時間(営業時間内） 1時間 15分

AWS Trusted Adviser 4項目全ての項目全ての項目

問合せ可能回数無制限無制限無制限

サポートAPIの利用なし可能可能

テクニカルアカウントマネージャー

なしなしあり

料金（月額）毎月のAWS利用額の3%

（最低$29）

毎月のAWS利用額の10%（最低$100）

AWS利用総額の$10,000を超える分は7%さらに$80,000を超える分は5%

さらに$250,000を超える分は3%の支払い

毎月のAWS利用額の10%（最低$15,000）

AWS利用総額の$150,000を超える分は7%さらに$500,000を超える分は5%

さらに$1,000,000を超える分は3%の支払い

本番環境用におすすめ開発環境用におすすめ


Trusted Advisor

ご利用実績を元に、自動的にセキュリティリスクの指摘やコスト最適化提案を実施するツール• 全項目の確認にはAWSサポート(ビジネスプラン・エンタープライズプラン)が必要


Trusted Advisor

(ビジネスプラン以上の)チェックは50項目以上• 本資料の項目チェックにも最適

カテゴリヘルスチェックチェックする内容例

コスト最適化コスト最適化の可能性がある項目に対する推奨事項

使用率の低いEC2インスタンス利用頻度の低いEBSボリュームなど

セキュリティセキュリティ弱体化につながる恐れのある設定

セキュリティグループMFA設定IAM設定CloudTrailのロギング設定など

信頼性お客様システムのアプリケーションの可用性や冗長性を高めるためのベストプラクティスからの推奨事項

RDSのマルチAZ構成EBSスナップショットAmazon RDS バックアップなど

パフォーマンス効率

アプリケーションの拡張性や応答性の改善、過剰なキャパシティのチェックなどパフォーマンス最適化のための推奨事項

サービス制限高負荷なEC2インスタンスCloudFrontのキャッシュヒット率チェックなど


まとめ


まとめ

本セミナーでご紹介した内容

• 今回は「AWS利用開始直後のお客様」に向けて、AWS上にシステムを設計、構築、運用す

る際のベストプラクティス集”AWS Well-Architected Framework”から、特に優先度が高

い -AWSを利用開始時におさえておきたい-項目を抜粋してご紹介しました

(今回だけでなく)定期的な見直しで、より”Well-Architected”に• 稼働中のシステムに対しても、現在W-Aかどうかのチェックを実施することも重要

→コスト効率が高められる場合や、次のシステム設計・構築時に活かせる場合も


まとめ

ベスト・プラクティスに則った設計

• 本編は抜粋版ですので、ぜひ”AWS Well-Architected Framework”ホワイトペーパーもご

参照いただき、” Well-Architected”なシステムを実現してください(http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf)

AWSでは技術個別相談会を実施しています• 詳しくはイベント告知サイトをご参照ください

(https://aws.amazon.com/jp/about-aws/events/)

• AWSを活用したシステムの設計や運用の技術相談がしたい

• ベストプラクティスに則っているかチェックしたい

• ベストプラクティスに則った設計にするための対策を教えてほしい

http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf

https://aws.amazon.com/jp/about-aws/events/


ベストプラクティスに則った” Well-Architected”なシステムで、

皆様のビジネス成功を！


オンラインセミナー資料の配置場所

AWS クラウドサービス活用資料集• https://aws.amazon.com/jp/aws-jp-introduction/

AWS Solutions Architect ブログ• 最新の情報、セミナー中のQ&A等が掲載されています。• http://aws.typepad.com/sajp/

https://aws.amazon.com/jp/aws-jp-introduction/

http://aws.typepad.com/sajp/


公式Twitter/FacebookAWSの最新情報をお届けします

@awscloud_jp検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

http://on.fb.me/1vR8yWm


Documents

AWSご利用開始時に最低限おさえておきたい10のこと · 以前から「漠然と100%活用できてない。 なんとかしないと…」とは思っていた。

AWSご利用開始時に最低限おさえておきたい10のこと · 以前から「漠然と100%活用できてない。なんとかしないと…」とは思っていた。