AWS(5)セキュリティのベストプラクティス

概要

偶発的もしくは意図的な盗難漏洩不整合削除からミッションクリティカルな情報を保護するために、Information Security Management System (ISMS)を作成するためのガイドライン。

責任共有モデル

AWSでは、AWS が安全なインフラストラクチャとサービスを提供する一方で、ユーザは安全なオペレーティングシステム、プラットフォーム、データを用意する責任を持つ責任分担モデルを採用している。例えばEC2の場合は、設備やハードウェアの物理的セキュリティ、ネットワークインフラ、仮装化インフラはAWSが管理する一方で、AMI、OS、アプリケーション、データ、認証情報等は、ユーザ自らが管理しなければならない。

インフラストラクチャサービスの責任共有モデル

Trusted Advisorの利用

Trusted Advisorを利用してサービスの状況を確認し、セキュリティの設定ミスシステムパフォーマンスの向上に関する提案使用率の低いリソースの確認などを行うことができる。例えば、管理ポートへのアクセスが限定的なものであるかや、IAMが設定されているか、MFAが有効化されているかなどが確認できる。

アセット

ISMSを設計する前に情報アセットを特定し、これらを保護するために必要なソリューションを技術面とコスト面から検討する必要がある。アセットは、業務の情報やプロセスなどを含む本質的な要素と、ハードウェアやソフトウェア、人員などを含む本質的な要素をサポートする要素の2つに大別される。

アセットの例

アセット名 アセットの所有者 アセットカテゴリ 依存関係 コスト
顧客向けアプリケーション eコマースチーム 必須 EC2, RDS…
AWS Direct Connect 最高情報責任者(CIO) ネットワーク ネットワーク運用, Direct Connect

これらのアセットを保護するために、情報セキュリティマネージメントシステム(ISMS) の実装、運用、モニタリング、確認、保守、改良に関する基準を定める必要がある。このとき、ビジネスニーズや目標、プロセス、組織の規模や構造などを考慮して基準を定める。ISMSの設計には、ISO27001 などの標準的なフレームワークを参考にすると良い。

段階 内容 詳細
1 スコープと境界の定義 スコープに含めるリージョン、AZ、リソース等を定義する。除外するリソースがある場合はその除外理由を明記する。
2 ISMSポリシーの定義 情報セキュリティの方向性と指針、法律や契約の要件、リスクの評価方法や承認方法
3 リスクの評価方法の選択 ビジネスニーズ、セキュリティ要件、IT機能と要件、法規制
4 リスクの特定 アセットとアセットに対する脅威を記した登録簿の作成、脆弱性とその結果
5 リスクの分析と評価
6 リスクへの対処 リスクを受け入れる、回避する、リスクレベルの査定
7 セキュリティコントロールフレームワークの選択 ISO 27002、NIST SP 800など
8 マネジメントによる承認の取得 残留リスクの報告と承認
9 適用宣言書の作成 選択したフレームワーク、導入済/予定のフレームワーク、除外したフレームワークとその理由

AWSアカウント

AWSアカウントは非常に強力な権限を有するので日常的な使用はせず、極力IAMユーザを使用する。またIAMユーザは、(特定のグループに所属するIAMユーザが1名だけであった場合でも)IAMグループを利用し、またきめ細やかに権限を付与し、タスクに必要な最小限のアクセス権限を付与する。また、AWSのアカウントは、セキュリティの観点から単一アカウントで処理する、開発ステージごとにアカウントを分割する、などビジネスやガバナンスの要件を満たすように設計することが必要である。AWSアカウントを複数有する場合は、一括請求アカウントを利用することで、管理の複雑さを低減し、スケールメリットを享受することができる。

アクセスキーを利用する場合は、定期的に更新を行う。また、IAMユーザの認証にはMFAの併用が望ましい。複数のAWSアカウントを横断的に利用する場合には、クロスアカウントアクセスの利用も検討する。社内に既にディレクトリサービスを有する場合には、IDフェデレーションの利用も可能である。EC2から他のAWSリソースを利用する場合はIAMロールを使用する。

データの保護

リソースへのアクセス保護

リソースへのアクセスは、各リソースを作成したユーザが他のユーザに対してアクセスを許可するリソースポリシーと、IAMユーザやIAMグループを使用して付与される機能ポリシーのいずれかを単独でもしくは組み合わせて使用する。

保管時のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

  • 偶発的な情報開示や漏洩
  • データの不整合や不正な書き換え
  • 過失による削除
  • システム障害や災害に備えたシステムの可用性

S3におけるデータ保護

  • アクセス権限の付与
  • バージョニング
  • レプリケーション
  • バックアップ
  • サーバサイド暗号化
  • クライアントサイド暗号化

EBSにおけるデータ保護

  • レプリケーション
  • バックアップ(スナップショット)
  • 暗号化

RDSにおけるデータ保護

  • 暗号化関数の使用
  • アプリケーションレベルの暗号化

Glacierにおけるデータ保護

  • サーバサイド暗号化
  • クライアントサイド暗号化

DynamoDBにおけるデータ保護

  • Base64エンコード

EMRにおけるデータ保護

  • S3のサーバサイド暗号化
  • S3のクライアントサイド暗号化
  • アプリケーションレベルの暗号化

伝送中のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

  • 偶発的な情報開示や漏洩
  • データの不整合や不正な書き換え
  • なりすましや中間者攻撃

伝送中のデータを保護するために、AWSではIPSecSSL/TSLをサポートしている。また、Remote Desktop Protocol(RDP)の使用やSSHの使用も有効である。

S3へ伝送中のデータ保護

  • SSL/TSLを用いた通信

RDSへ伝送中のデータ保護

  • SSL/TSLを用いた通信
  • X.509証明書

DynamoDBへ伝送中のデータ保護

  • HTTPSの利用

OSとアプリケーションのセキュリティ保護

OSとアプリケーションのセキュリティを保護するためには以下が奨励される。

  • ルートアクセスキーとシークレットキーの無効化
  • IPアドレスを限定したインスタンスへのアクセス
  • pemファイルのパスワード保護
  • ユーザの管理
  • 認証情報の更新
  • IAMユーザのアクセス権を定期的に管理

AMIを公開する場合は、認証情報をOS上から消去しておくなど、セキュリティ面には十分注意する。

万が一、OS等への侵入が確認された場合に、根本的な原因追求を行うためにフォレンジックを行う。

ブートストラッピング

PuppetやChefなどを利用してセキュリティプログラムの更新や、パッチの適用、ステージに合わせた環境設定の実行、リモートモニタリング等を実施する。

マルウェアからの保護

信頼できないAMIやコードは実行しない。また、信頼できないソフトウェアリポジトリも使用しない。ユーザに付与する権限は必要最小限とし、ウイルスおよびスパム対策ソリューションを必ず利用する。

その他の対策

  • ベンダー指定のデフォルト値を削除する
  • 不要なユーザを無効化する
  • EC2に複数の機能を持たせない
  • 必要なサービスやデーモンのみ有効化する
  • 不要な機能やWebサーバは無効化する

インフラの保護

インフラを保護するためには以下を行う。

VPCの利用

VPCを利用することで、AWSのパブリッククラウド内にプライベートクラウドを作成できる。他のAWSユーザからリソースを隔離できるということだけでなく、インターネットから隔離することもできる。また、IPSecやDirect Connectを利用することでオンプレミス拠点とAWS間をセキュアに接続することも可能である。

セキュリティグループやNACLを使用することで、セキュリティゾーニングを実現することができる。この際に、セキュリティゾーン間の通信を制御するかゾーン間の通信をモニタリングするかゾーンごとにアクセス権限を付与するか、などを検討する必要がある。

セキュリティのテスト

セキュリティコントロールとポリシーの有効性を定期的にレビューする。新しい脅威や脆弱性に対処するためには、外部脆弱性評価外部侵入テストアプリケーションとプラットフォームの内部グレー/ホワイトボックスレビューを行う。なお、侵入テストを行う場合には、AWSにリクエストが必要な場合がある。

メトリクスの管理と向上

有効性の測定を行う上では、メトリクスの利用が有効的である。

  • 手順のモニタリング
    • 処理結果からエラーを迅速に検出する
    • セキュリティ侵害やインシデントに迅速に対応する
    • セキュリティアクティビティが想定通りに実行されているか判断する
    • セキュリティイベントを検知してインシデントを防止する
    • 対処が効果的であったか判断する
  • ISMSの有効性のレビュー
    • セキュリティ監査、インシデント、有効性測定
    • 関係者からの提案およびフィードバック
    • ポリシーが目的に合っているかの確認
  • 有効性の測定
    • セキュリティ要件を満たしているかどうか
  • 定期的なリスク評価レビュー
    • 残留リスクの許容可能なリスクのレビュー
    • 法改定など外部イベントに適しているか
  • 内部監査
  • 定期的な管理レビュー
    • スコープが適切か
  • セキュリティ計画の更新

DoSおよびDDoS攻撃の緩和と保護

DoSおよびDDoSについて懸念がある場合には、AWSのサポートの契約が望ましい。サポートに契約することで、AWSがDoSおよびDDoS攻撃の事前および事後にサポートを提供できる。AWSは、トラフィックが攻撃によるものかは判断できないために、アクティブに対処することはしない。これらの攻撃に対処するためには、以下の手法を検討する。

  • セキュリティグループやNACLの使用
  • WAFの使用
  • レート制限
  • ハーフオープンセッションの制限

モニタリングと監査、インシデント対応

ログファイルを蓄積することで、適切なモニタリングとて監査、インシデント対応を行うことができる。

エリア 考慮事項
ログ収集 収集方法に注意する
ログ転送 ログファイルを安全、確実、タイムリーに転送する
ログストレージ 一元管理し分析を行う
ログ分類 分析に適した形式
ログ分析 ログファイル内のイベントを相互に関連付ける
ログの保護 改ざん等を防ぐ

AWS DynamoDB(3)使用する上で注意すること

適切なスキーマ設定

DynamoDBは限られた範囲のクエリを効率よく処理できるがそれ以外はコストが掛かる。重要なクエリを安価に効率よく実行できるようなスキーマ設計が需要である。アプリケーションのユースケースを注意深く解析して、単一のテーブルで処理可能な構造とする。

スキーマを構成する上で確認すべき点は、データサイズデータ形式クエリ負荷である。

  • 関連するデータをまとめる
  • ソート順を決定する
  • クエリを分散する
  • グローバルセカンダリインデックスを使用する

パーティションキー

効率的なパーティションキーの設計とし、クエリを分散させる。ただし、一部のパーティションに負荷が偏った場合でも、アダプティブキャパシティが自動的に適用され、ある程度は影響を緩和することができる。

アダプティブキャパシティ

負荷を分散させるために、格納された値を元にパーティションキーにサフィックスを付加する手法も存在する。

キャパシティを上げた状態でOnDemand課金に切り替える

OnDemandを使用する場合は、バーストトラフィックに耐えれるように、まずキャパシティを上げた状態にしておき、それからOnDemand課金に変更する。ただし、課金体系への変更には制限があることから頻繁な変更はできないことに留意が必要。

大きな項目データは、圧縮するかS3に保存する

圧縮したバイナリデータを保存したり、S3に保存してこのオブジェクト識別子をDynamoDBに保存することができる。

時系列データは複数テーブルによる構成も検討する

時系列データの場合、当日データに書き込みや読み込みが偏り、ホットスポットが発生する。これを回避するために期間ごとにテーブルを分割して、バッチ処理で新しいテーブルの作成と新しいテーブルへの切り替えを行う。

クエリの最適化

Scanクエリはなるべく使わない

Scanは非常に低速でデータ数が大きくなると非効率となるので避ける。

条件付き書き込みやアトミックカウンターを使用する

複数が同時に更新する場合は、条件付き書き込みを使用する。

AWS Lambda(3)使用する上で注意すること

エントリポイントをコアロジックから分離

トリガを受ける関数と処理を行う関数を分離することで、単体テストが実施しやすくなり、また依存関係が完結となり関数のパフォーマンスも向上する。

再帰的な処理を記述しない

意図しない処理が発生する可能性があるため。

メモリ使用量を計測し適切なサイズに設定する

AWS CloudWatch LogsのMax Memory Usedを参照して最適なメモリサイズを設定する。

実行時間を計測し適切なタイムアウト値を設定する

同時実行数にも関連するので、実際の値を正確に把握する。

AWS(4)Well-Architectedフレームワーク

Well-Architected Framework

AWS Well-Architected フレームワークは、以下の5つの評価項目で構成されている。

  • 必要なキャパシティを勘に頼らない
  • 本番規模でシステムをテスト
  • 自動化
  • 発展的なアーキテクチャを受け入れる
    • クラウドは自動化とテストが容易で設計変更のリスクを低減できる
    • システムを継続して進化させる
  • データ計測に基づいてアーキテクチャを決定する
  • 本番で想定されるトラブルをあらかじめテストする

1. 運用上の優秀性

設計の原則

  • 運用のコード化を行う
  • ドキュメントに注釈を付ける
  • 頻繁に小さく可逆的な変更を行う
    • システムを小さく設計
    • 失敗した場合に戻せるように
  • 運用手順を頻繁に見直す
  • 発生しうる障害を予想する
  • 運用の失敗を改善に役立てる

ベストプラクティス

準備(本番環境への移行)

  • チェックリストによる検証
  • イベントと障害に対するテスト
  • CloudFormationの利用
  • CloudWatch等を利用した解析
  1. 運用の優先順位を決定する要因は明確ですか?
    • リスクを評価して優先事項を決定することが重要である。
    • ビジネスニーズを評価する
      • 運用事項の決定には、ビジネスチームと開発チームの両方が参加する
    • コンプライアンス要件を評価する
      • 規制や業界標準のルールを考慮する
  2. 運用性を向上させるワークロード設計をしていますか?
    • 設計標準を共有する
      • システム設計に共通の設計標準を取り入れることで複雑性を軽減する
      • 設計標準に対する変更や追加をリクエストする手順を作成し継続的に改善する
    • クラウド運用に向けて設計する
      • 伸縮性や従量課金制などのクラウドの特徴を活用して迅速な改善やテストなどの運用を実現する
    • ワークロードの動作を深く理解する
      • 計測ツールを用いてシステムで何が起こっているかを計測する
    • 顧客の行動を深く理解する
      • 計測ツールを用いてシステムの使用状況を計測する
    • 障害を軽減しフローを改善するための手法を確立する
      • フローを改善して品質向上やバグ修正を迅速に行えるアプローチを確立する
    • デプロイのリスクを軽減する
      • 頻度の高い変更、自動デプロイ、テスト、カナリアデプロイワンボックスデプロイブルーグリーンなどの手法を導入する
  3. ワークロードが運用可能であることをどのように確認していますか?
    • 継続的改善の文化を育てる
    • ビジネスに対する価値の理解を共有する
      • ビジネスにとってシステムがどの程度重要であるのかをチーム全体で共有する
      • 運用上の問題に対応するために必要なリソースを全てのチームが活用できる環境の提供
    • 担当者の能力を確保
      • トレーニングを受けた担当者を適切な人数配置する
    • ガバナンスとガイダンスを文書化し共有する
      • コンプライアンスについて理解しやすく評価可能な標準ルールを共有する
      • 標準ルールの変更、追加をリクエストする手順を作成する
    • チェックリストを使用する
    • 運用手順書ランブック)を使用する
    • 障害対応手順書プレイブック)を使用する
    • 復旧演習を行う

運用

期待されている成果、およびその測定方法を決定し、システムと運用に関する測定基準(メトリクス)を特定する。システムとそのシステムに対する運用の正常性の双方を考慮する。イベント対応の優先度を定めて、影響の度合いに応じて追加の担当者を巻き込むエスカレーショントリガーも含める。計画外のイベントが発生した原因と影響範囲を確認し、今後の運用に反映させるとともに、計画外のイベントであっても自動的に処理されるようにシステムの設計を行う。デプロイやリリース管理、変更ロールバックなどはマニュアルで行なってはならない

  1. 運用状態をどのように確認していますか?
    • ビジネスと顧客について求められる成果を定義する
      • 成功とはどのようなことを指すのか定義し文書化する
    • 成功のメトリクスを特定し達成されているかどうかを確認する
    • ワークロードのメトリクスを特定し達成されているかどうかを確認する
    • 運用のメトリクスを特定し達成されているかどうかを確認する
    • 基準値を定める
    • メトリクスを収集および分析する
    • 分析結果をレビューし対応を確認する
    • 運用のビジネスレベルレビュー
      • ビジネスの目標を達成するために改善が必要な分野を特定する
  2. 運用上のイベントをどのように管理していますか?
    • ビジネスへの影響に基づいて運用イベントの優先順位を決定する
    • イベントやインシデントを管理する方法を確立する
    • アラートを設定したイベントごとの運用手順書(ランブック)を確立する
    • 意思決定者を確立する
    • 障害報告ルートエスカレーションパス)を定義する
    • プッシュ通知
    • ダッシュボードを通じてステータスを通知
    • 根本原因分析のためのプロセスの確立

進化

システムを継続的に少しずつ改善していくことが必要。システムと運用の両方に関して改善できる部分を洗い出し、優先順位を付ける。また、チームを超えて、運用から学んだ知見を共有する。

  1. 運用をどのように進化させていますか?
    • 継続的な改善プロセス
    • 改善の要因の定義
    • フィードバックループを取り入れる
    • 得られた知識を文書化して共有
    • 運用メトリクスの評価を行う

AWSのサービス

AWS CloudFormationを用いてシステム構築を行う。またそれぞれのフェーズで以下のサービスを活用する。

フェーズ AWSサービス 目的
準備 AWS Config システム標準を作成しそれに準拠しているか確認する
運用 Amazon CloudWatch システムの運用状態をモニタリング
進化 Amazon Elasticsearch Service ログデータを分析

2. セキュリティ

設計の原則

  • 強固な認証基盤を整備する
  • 追跡可能性を実現する
  • 全てのレイヤーにセキュリティを適用する
  • セキュリティのベストプラクティスを自動化する
  • 転送中および保管中のデータを保護する
  • データへの直接的なアクセスや手動処理を減らす
  • セキュリティイベントに対して準備を行う

ベストプラクティス

アイデンティティとアクセス管理

権限を持つユーザのみが管理者の意図した方法でリソースにアクセスできるようにする。IAMを用いてきめ細やかなポリシーを適用し、ユーザやグループ、ロール、リソースにアクセス許可を割り当てる。認証情報はシステム間で共有しない。プログラムによるAPIアクセスなどには、STSを用いた一時的な認証情報の利用も検討する。

  1. ワークロードの認証情報をどのように管理していますか?
    • MFAの導入
    • パスワードの要件を決定
    • 認証情報を定期的に更新
    • 認証情報を定期的に監査
    • 一元化されたIDプロバイダーを使用
  2. AWSサービスへの人為的なアクセスをどのように制御していますか?
    • 認証情報を共有しない
    • ユーザのライフサイクルポリシを定義
    • 最小権限を付与
    • アクセス要件を明確に定義
    • ロールやフェデレーションを用いてアクセス権を付与
  3. AWSサービスへのプログラムによるアクセスをどのように制御していますか?
    • 認証情報を共有しない
    • 動的な認証
    • 最小権限を付与
    • アクセス要件を明確に定義

発見的統制

発見的統制には様々な手法があり、アセットとその詳細な属性の一覧を作成し、意思決定やライフサイクル管理を促進することで、運用の基準を確立する手法や、内部監査を使用して、実態がポリシーと一致しているかの確認を行う手法などが存在する。AWSにはこれらを実現するために、Cloud TrailCloudWatchAWS ConfigAWS GuardDutyなどの様々なサービスが提供されている。

またログ管理も非常に重要である。また、潜在的なセキュリティインシデントを特定するためにログを分析することも重要である。

  1. ワークロードのセキュリティイベントをどのように検知していますか?
    • 利用可能なロギングを有効化する
    • AWS CloudTrailを分析する
    • ログを一元的に収集し自動的に分析する
    • 重要なメトリクスとイベントをモニタリングし、アラートを送信する
    • AWS Marketplace や APNパートナーのソリューションを活用する

インフラストラクチャ保護

多層に渡る防御などによって組織や規則上の義務を果たす必要がある。AWSが提供しているサービスやパートナーが提供するサービスを利用して、境界保護の強化、出入口のモニタリング、広範囲のロギング、モニタリング、アラート等を行う必要がある。

  1. ネットワークをどのように保護していますか?
    • VPCを使用してトラフィックを分離・制御する
    • 境界でトラフィックを制御する
    • 利用可能な機能を使用してトラフィックを制御する
      • セキュリティグループ
      • ネットワークACL
      • サブネット
    • AWS Marketplace や APNパートナーのソリューションを活用する
  2. AWSのセキュリティ機能と一般的なセキュリティ脅威に関する最新情報をどのように認識していますか?
    • リリース毎に新しいセキュリティサービスを評価する
    • セキュリティサービスを使用する
  3. コンピューティングリソースをどのように保護していますか?
    • デフォルトの設定を強化する
    • ファイルの整合性を確認する
    • 侵入検知を利用する
    • AWS Marketplace や APNパートナーのソリューションを活用する
    • 設定管理ツールを使用する
    • 定期的パッチ適用脆弱性スキャンを実行する

データ保護

AWSでは、データの暗号化やキーローテーション、ロギング、高い耐久性、バージョニングなどのデータを保護するための様々な機能を提供している。また、保管中と転送中の暗号化を複数の手段で実現できる。

  1. データをどのように分類していますか?
    • データ分類スキーマを使用する
    • データ分類を適用する
  2. データ保護メカニズムをどのように管理していますか?
    • KMSCloudHSMなどのキー管理サービスを使用する
    • サービス内に存在する制御機能を利用する
    • クライアントサイドのキー管理を使用する
    • AWS Marketplace や APNパートナーのソリューションを活用する
  3. 保存中のデータをどのように保護していますか?
    • データの暗号化
  4. 転送中のデータをどのように保護していますか?
    • データの暗号化

インシデント対応

インシデント発生時に、システムの分離影響範囲拡大の抑制通常運用への復帰フォレッジング(証拠保全)などの対応を行うことが可能な体制を確立しておく必要がある。

  1. インシデントに対してどのように備えていますか?
    • セキュリティチームに事前にアクセス件を付与しておく
    • ツールの準備
    • ゲームデーの実施

AWSのサービス

内容 AWSサービス 備考
アクセス管理 IAM リソースへのアクセス管理
発見的統制 CloudTrail APIコールの記録
発見的統制 Config リソース設定インベントリ
発見的統制 Guard Duty 悪意のある動作や不正な動作の検出
発見的統制 CloudWatch リソースのモニタリング
インフラストラクチャの保護 VPC
インフラストラクチャの保護 CloudFront 安全な配信、DDoS攻撃を緩和するSieldとの結合
インフラストラクチャの保護 WAF アプリケーションファイアウォール
データ保護 KMS 暗号化キーの作成と管理
インシデント対応 CloudFormation クリーンルームの作成

3. 信頼性

高い信頼性を維持するためには、システム基盤を十分にモニタリングして、需要や要件の変更を処理するメカニズムを設けることが必要である。具体的には、インフラやサービスの障害からの復旧、必要に応じたリソースの動的な取得、設定ミスや一時的なネットワーク問題などの障害軽減などを検討する必要がある。

設計の原則

  • 復旧手順をテストする
  • 障害から自動的に復旧する
  • 水平方向にスケールして統合的なシステムの可用性を向上させる
  • キャパシティを勘に頼らない
  • 自動化の変更を管理する

ベストプラクティス

基盤

システムのアーキテクチャを設計する前に、信頼性に影響を与える基盤についての要件が整っていることが重要で、AWSの場合はこれらの要件は最初から組み込まれているか、必要に応じて対処できるようになっている。一方で、AWSでは意図せずに過剰にリソースをプロビジョニングしてしまわないように、サービスの上限が設定されている。

  1. AWSサービスの制限をどのように管理していますか?
    • 能動的にモニタリングし制限事項を管理する
    • 制限のモニタリングを自動化する
    • 変更できない制限に注意する
    • フェールオーバに備えて十分余裕をもったリソースを確保しておく
  2. AWS上でのネットワーク構成をどのように設計していますか?
    • オンプレミスと接続しない構成を検討する
    • AWSとオンプレミス間に可溶性の高い接続を実装する
    • 可用性の高いネットワーク接続を実装する
    • 複数のVPCで重複しないプライベートIPアドレス範囲を使用する
    • 拡張性と可用性を考慮してサブネットの割り当てを行う

変更管理

変更がシステムに及ぼす影響を把握し、KPIへの対応を自動化することができる。需要の変更に対応してリソースの追加や削除が自動的に行われるようシステムを設計しておくことで、信頼性が向上しビジネスの成功が運用の負担になることも避けられる。適切にモニタリングされていれば、KPIが予測された基準から逸脱したときにアラートを送ることができる。

  1. システムに対する需要の変化にはどのように対応していますか?
    • 自動的にスケールするワークロードとする
    • 負荷テストを実施する
  2. AWSリソースをどのようにモニタリングしていますか?
    • 全ての階層でモニタリングする
    • モニタリングに基づいて通知を行う
    • イベント発生時にイベントに自動で対応する
    • 定期的にレビューを実施する
  3. 変更をどのように実施していますか?
    • 自動化する

障害管理

障害が発生した場合にそのまま本番環境で診断して修復するのではなく、本番環境外で新しいリソースに置き換えて分析することが重要である。論理エラーと物理エラーの両方から確実に復旧できるように、定期的にデータをバックアップし、バックアップファイルをテストしておく目標復旧時間(RTO)や目標復旧時点(RPO)を定め、システムの回復性を事前に評価する。

  1. データをどのようにバックアップしていますか?
    • 手動のバックアップ
    • 自動化したバックアップ
    • 復旧テストの実施
    • バックアップの暗号化
  2. システムがコンポーネントのエラーに耐えるようにどのように設計していますか?
    • 全ての階層でモニタリングを行いエラーを検知する
    • 複数のAZにデプロイする
    • 疎結合のシステムにする
    • グレースフルデグラデーション
    • 自動機能を使用して修復を行う
    • 可用性に影響するイベント発生時に通知を行う
      • 自動修復された後でも通知を送信する
  3. システムの弾力性をどのようにテストしていますか?
    • 障害対応に備えた障害対応手順書(プレイブック)を用意する
    • 障害注入テストを行う
    • ゲームデーの実施
    • RCA(Root Cause Analysis)の実施
  4. 災害時のリカバリプランはどうなっていますか?
    • 目標復旧時間(RTO)や目標復旧時点(RPO)を定義する
    • 上記を達成するために災害対策(DR)戦略を定義する
    • 本番サイトとDRサイトのずれを管理する
    • DRサイトへのフェイルオーバを定期的にテストする
    • 復旧を自動化する

AWSのサービス

内容 AWSサービス 備考
基盤 IAM リソースへのアクセス管理
基盤 Config リソース設定インベントリ
基盤 Trusted Advisor サービスの制限を把握
基盤 Shield DDoSからの保護
変更管理 CloudTrail APIコールの記録
変更管理 Config リソース設定インベントリ
変更管理 Auto Scaling 需要管理の自動化
変更管理 CloudWatch リソースのモニタリング
障害管理 CloudFormation リソースを規則的にプロビジョニング
障害管理 Glacier 耐久性の高いアーカイブ

4. パフォーマンス効率

需要や技術の進歩に合わせてパフォーマンスを維持することが重要である。

設計の原則

  • 最新テクノロジーの標準化
  • グローバル化を即時に実現
  • サーバレスアーキテクチャの使用
  • 実験の頻度の増加
  • 適合したテクノロジーアプローチ

ベストプラクティス

選択

特定のシステムに最適なソリューションは、ワークロードの種類によって異なり、多くの場合は複数のアプローチを組み合わせたものとなる。複数のソリューションを使用して、様々な機能を有効化することで、パフォーマンスを向上させることができる。アーキテクチャを選択する際には、データ駆動型のアプローチを使用して判断を行う。

  1. 最も良いパフォーマンスのアーキテクチャをどのように選択していますか?
    • テストの結果(ベンチマーク)を元に検討する
    • 負荷テストの結果を元に検討する
  2. コンピューティングソリューションをどのように選択していますか?
    • 複数のサービスの中から検討する
    • インスタンスの設定オプションを検討する
    • コンテナの設定オプションを検討する
    • 関数の設定オプションを検討する
    • 伸縮性を活用する
  3. ストレージソリューションをどのように選択していますか?
    • ストレージ特性を検討する
    • 設定オプションを検討する
    • アクセスパターンを検討する
  4. データベースソリューションをどのように選択していますか?
    • データベース特性を検討する
    • 設定オプションを検討する
    • アクセスパターンを検討する
    • データベース以外の他のアプローチを検討する
  5. ネットワークソリューションをどのように選択していますか?
    • ロケーションを検討する
    • サービスを検討する
    • ネットワーク機能を検討する

レビュー

システム導入から時間が経つと、新しい技術とアプローチが利用できるようになる。AWSの新たなサービスや機能を利用することで、パフォーマンスを大幅に改善できる可能性がある。アーキテクチャのパフォーマンスが何で制約されているかを把握しておくことで、その制約を解決するリリースに気づくことができる

  1. 新しいサービスや機能をどのように取り入れていますか?
    • 評価するプロセスを作成する

モニタリング

システムを実装したらパフォーマンスをモニタリングし、エンドユーザが認識する前に問題を解決する必要がある。モニタリングメトリクスを利用して、閾値を超えたときにアラームを送信するようにする。誤検出が大量に発生していないかや、データを処理しきれなくなっていないかなどを確認する。

  1. 期待通りのパフォーマンスを発揮しているかをどのようにモニタリングしていますか?
    • モニタリング
    • 安全な境界を超えた場合にアラートを送信する
    • 問題の修正を自動化する

トレードオフ

ソリューションを構築する際にトレードオフを考慮することで最適なアプローチを選択できる。トレードオフによりアーキテクチャの複雑さが増す可能性があることに留意する。

  1. パフォーマンスを向上させるためにトレードオフをどのように利用していますか?
    • AWSサービスを利用する
    • パターンを使用する
      • キャッシュ
      • リードレプリカ
      • シャーディング
      • 圧縮
      • バッファリング

AWSのサービス

内容 AWSサービス 備考
レビュー AWSブログ 新しいサービス情報の取得
モニタリング CloudWatch リソースのモニタリング

5. コスト最適化

設計の原則

  • 消費モデルを導入する
  • 全体的な効率を評価する
  • データセンターの運用費を排除する
  • 支出を分析し帰属させる
  • 所有コストを削減するためにマネージドサービスとアプリケーションサービスを利用する

ベストプラクティス

コスト効率に優れたリソース

適切なサービスを用いた優れた設計システムでは、最もコスト効率に優れたリソースが使用されており、優れたコスト効果が得られる

  1. AWSサービス選択の際にコストをどのように評価していますか?
    • サービスを選択する
    • ライセンスコストを最適化する
    • サーバレスとコンテナベースのアプローチを使用する
    • 適切なストレージを使用する
    • 適切なデータベースを使用する
  2. コスト目標を達成するためにインスタンスタイプとサイズをどのように選択していますか?
    • メトリクスに基づいてリソースをサイジングする
  3. コスト削減のために料金モデルをどのように選択していますか?
    • リザーブドインスタンスとリザーブドキャパシティ
    • スポットインスタンス
    • リージョンごとのコスト差を考慮
  4. データ転送料金についてどのように計画していますか?
    • 最適化
    • CDNの利用
    • Direct Connectの利用

需要と供給の一致

需要と供給を最適に一致させることが最もコストが掛からないが、その一方で障害に備えて供給に十分な余力を残しておくことも重要である。AWSでは需要に応じて自動的にリソースをプロビジョニングできる。使用するパターンやプロビジョニングに掛かる時間についてもよく考慮する必要がある。

  1. リソースの供給と顧客の需要をどのように一致させていますか?
    • Autoscalingの利用
    • KinesisやSQSなどのバッファサービスの利用
    • 時間ごとに調整する

費用の把握

それぞれのビジネスオーナまたは製品オーナに属するコストを明確にすることで、リソースを効率的に使用して無駄を削減できる。コストの帰属を明確化することが必要。コスト配分タグを使用してAWS使用料とコストを分類および追跡できる。

  1. AWS使用量とコストをどのようにモニタリングしていますか?
    • リソースのタグ付け
    • Cost Exploerの使用
    • 予算超過の通知
    • ビジネス成果に基づいてコストを配分
  2. AWS使用量をどのように管理していますか?
    • グループとロールを定義
    • プロジェクトのライフサイクルを追跡
  3. 不要なリソースをどのように排除していますか?
    • 削除の自動化
    • 削除プロセスを定義

継続した最適化

AWSによる新たなサービスや機能のリリース時に、既存の決定事項を見直すことで、よりコスト効率のよいシステムとすることができる。定期的にデプロイについてレビューする際には、コストを削減する上でどのサービスが役にたつか評価する

  1. 新しいAWSサービスをどのように評価していますか?
    • 定期的なレビュー
    • コスト最適化を行う担当者を置く
    • ワークロードのレビューと分析
内容 AWSサービス 備考
コスト効率に優れたリソース Cost Explorer リザーブドインスタンス導入
需要と供給の一致 Auto Scaling 需要管理の自動化
費用の把握 Cost Explorer 使用状況の確認および追跡
継続した最適化 AWSブログ 新しいサービス情報の取得

AWS S3(4)使用する上で注意すること

パフォーマンス最適化

S3へのリクエストが100rpsを超える場合は、キー(ディレクトリ名やファイル名等)先頭部分の文字列をランダムにする。プレフィックスごとに3500rpsのPUT/POST/DELETEリクエスト5500rpsのGETリクエストを処理可能である。また、大量のGETリクエストが発生する場合には、CloudFrontを併用する。

データ整合性モデル

S3では、書き込み後の読み込み整合性を提供する。また、単一キーに対する更新はアトミックである。しかし、複数のデータセンタに複製することから、オブジェクトを書き込んだ直後に表示させると、オブジェクトが表示されなかったり、古いデータが表示されることがある。また、あるクライアントが書き込みを完了する前に別のクライアントが書き込みを始めた場合などは、整合性のある書き込み結果とならない場合もある。したがって、データベースのトランザクションログなど短時間に書き込みが連続するデータの保存には適さない

バケットの命名規則

バケット名は3文字以上63文字以内で、大文字やアンダースコア、ピリオドを含むことはできない。ハイフンは使用可能。また、バケット名は既存のバケット名の中で一意でなければならない。

ストレージクラス

S3 Standerd(低頻度アクセス)とS3(1ゾーン/低頻度アクセス)は、少なくても30日間保存する予定があり、サイズが128KB以上あるオブジェクトに最適である。

ライフサイクル

S3 Standerd(低頻度アクセス)とS3(1ゾーン/低頻度アクセス)は、現在のストレージクラスに少なくとも30日間は保存する必要がある。ライフサイクル処理は、UTC時0時に実行される。

参考

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html

AWS CloudWatch(2)システム運用における監視項目

AWSでシステム構築を行う場合、基本的にはこのCloudWawtchのみの監視で十分なことが多い。様々な監視項目が存在するが、システム運用を行う際に特に監視する必要のある項目は以下の通り。

DynamoDB

多くの項目がデフォルトで 1 分ごとにデータを送信するが、5 分間隔で送信されるデータも存在する。事前に設定した容量(スループット)が十分であるかを監視しておくと良い。

  • ProvisionedReadCapacityUnits
  • ConsumedReadCapacityUnits
  • ProvisionedWriteCapacityUnits
  • ConsumedWriteCapacityUnits

EC2

Amazon EC2 はデフォルトで 5 分ごとに CloudWatch にデータを送信する。インスタンスを作成する際に、「詳細モニタリングを有効」にチェックを入れることでこれを 1 分ごとに変更することができるCPU使用率を監視しておくと良い。メモリやディスクのメトリクスを取得するためには、CloudWatch Agentをインストールする必要がある

  • CPUUtilization

Kinesis

事前に設定した容量(シャード数)が十分であるかを監視しておくと良い。

  • PutRecords.Records
  • IncomingRecords
  • GetRecords.Bytes
  • IteratorAge

AWS EC2(2)使用する上で注意すること

EC2は、AWSマネージメントコンソールからクリック1つでインスタンスを起動できる、非常に便利なクラウドサービスである。一方でとても簡単に利用できることから、全ての制限が取っ払われ、自分の思い通りのまま自由にリソースを使用できるサービスだというような錯覚に陥りがちだ。EC2も元を辿ればデータセンターの中にある物理マシンである。使用する際にはいくつかの注意すべき点が存在する。

サービスで使用する際にTインスタンスは使わない

T2インスタンスは、AWSの公式説明によると「ベースラインを超えてバーストする能力がある CPU パフォーマンスのベースラインを提供する、バーストパフォーマンスインスタンスです」とある。しかし実際は、データセンター内の同一物理サーバ上に収納されている他のインスタンスが実験用途等で使用され、バースト上の負荷がそのインスタンスに掛かった場合は、自分のインスタンスにも影響が出る可能性がある。したがって商用サービス等の安定した運用が求められる利用方法の場合にTインスタンスを使用することはおすすめしない。

バックアップを用意しよう

インスタンスが落ちたり、リージョンごとサービスダウンする可能性もゼロではない。24時間365日稼動しているように見えるクラウドサービスにもダウンタイムは確実に存在する。少なくともアベイラビリティゾーンを分ける、可能であれば他のリージョンにもバックアップを取るなどの障害対策はしておこう。

古いインスタンスは使わない

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。古くなれば電源やHDDなどが故障するリスクも高まる。実際にハードウェアに異常が起こり、EC2のインスタンスが急に応答しない、インスタンスが落ちるなどの現象が発生することがあるようだ。したがって、古いインスタンスはなるべく使わず、M3を使うぐらいならM4を、C3を使うくらいならC4を使おう。ちなみにインスタンスに障害が発生した場合、Auto Recovery機能をONにしていれば、自動で再起動される。

リソースは枯渇する

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。用意しているリソース量が全て使用されればリソースは枯渇する。実際に東京リージョンでは、年末年始などの多くの企業がイベント利用を行うシーズンに、特定のインスタンスタイプが起動できないことがあるようだ。またリソースの枯渇だけでなく、メンテナンスが原因で新たなリソースが確保できないということもあり得る。どうしてもリソースの確保が必要であれば事前に確保しておき、実際に使用するまでインスタンスをStopしておくなどの対応が必要である。リザーブドインスタンスの利用も検討したい。

バージニアリージョンは諸刃の剣

バージニアリージョンは、AWS創業の地。新しいサービスが一番に投入されるリージョンでもあり、リソース量も他のリージョンと桁違いに大きい。しかし一方で施設の老朽化が進んでいるからか異常なほどサービスダウンが多い。日本でEC2を使ったサービスを展開をする際に、わざわざバージニアリージョンを使用するメリットはあまり無いが、リソース量が大きいためバックアップリージョンとして利用する価値はあるだろう。レイテンシーを気にするのであれば、リソース量は劣るが物理距離が近い、シンガポール等のアジアパシフィック地域のリージョンも候補に入れたい。

上限引き上げはお早めに

AWSのサービスには、それぞれサービス制限(スロットリング)が適用されており、例えば、EC2は初期状態では最大20台までしかインスタンスを起動できない設定となっている。上限値以上にリソースを使用する場合はサポートプランに加入の上、サポートに必要なリソース数とその理由を付けて上限値の引き上げや撤廃を申請する必要があるが、上限値の変更が必要な理由が不明確であったり必要以上のリソースを要求すると断られる場合もあるので、少なくとも処理に3営業日以上掛かることを見越して、早めに上限引き上げを申請しておいたほうがよいだろう。

Auto Scaleは過信しない

Auto Scaleはリソース量に合わせてインスタンス量を自動で調整してくれるとても便利なサービスである。しかし、閾値を超えたことを検知して新たなインスタンスを立ち上げるまで数分を要する。したがってバースト的な負荷には対応できない。瞬間的なアクセスが予想されるのであれば、Auto Scaleは使わずにあらかじめ手動で、一定数のインスタンスを立ち上げておこう。

CPU使用率が定常的に30%を超えるのであれば代替策を考えよう

CPU使用率が定常的に30%を超えるのであればもう1つ上のインスタンスに変更するか、同じインスタンスをもう1つ用意しよう。

性能の良いインスタンスで台数少なく運用する方がラク

どのような処理をするかにもよるが、低い性能のインスタンスを大量に並べるよりかは、性能の良いインスタンスを台数少なく並べたほうが運用がラクなことが多い。

EBSのボリュームサイズによってI/O性能は変化する

ディスク容量あまり使わないからと最小限のディスク容量しか確保していない状態で、大量のディスクアクセスが発生した場合に期待したディスクの読み書き性能が出ないことがある。汎用(SSD) ボリュームのパフォーマンスはボリュームサイズによって変化するように設計されており、ボリュームサイズが大きければ大きいほど、良いI/O性能が与えられる。一定量のディスクアクセスが発生する可能性がある場合は、1TBなど大きめのボリュームサイズを割り当てておくほうがよい。

とりあえずCPU利用率を見ていればOK

CloudWatchはいろいろな項目があるので、どの項目を確認すればEC2が正常であるのか判断に困るかもしれない。そんなときは取り敢えずはCPU使用率だけでも見ておこう。

「なんか遅い」というときは…

まずはCloudWatchを参照してサチっている項目を探そう
+ Tインスタンスを使用している場合は、CPUクレジットが枯渇していないか確認する
+ 汎用SSDを使用している場合は、ボリュームサイズとインスタンスに割り当てられたIOPSの上限を確認する
+ AZ間の通信が発生している場合は、AZ間のレイテンシが発生している場合がある。また、インスタンスタイプによるネットワーク帯域の上限も確認する。

あと、よくある質問をきちんと読む!
4年間SAをやった中で、よくされる10の質問と回答

そのほかに注意すること

  • インスタンスを停止状態から実行状態に移行するたびに 1 時間分のインスタンス時間が課金される
    • [追記] 2017年10月12日から秒課金がスタートしている。
  • インスタンス起動後に設定変更できない項目が存在する。VPCやサブネット、Roleなどは後から変更できない。Roleは使う予定がなくても取り敢えず作成しておいたほうが良い
    • VPC
    • サブネット
    • プライベートIP
  • Amazon Linux AMIには、SWAPは用意されていない。