運用担当者のためのAWS改善マップ

AWSに限らず、システム運用をしていると様々な課題が見つかります。 課題はシステムや担当者の立場によって、様々です。 情報システム管理部門の場合、内部統制がよく課題にあがります。 特定のサービスのみ利用できるように、IAMやAWS Organizationsを利用したり、AWS Service Catalogを利用すると課題解決できるかもしれません。

具体的な課題を見つけられれば、その解決に努めれば良いかと思います。 しかし、システム運用を担当されているかたの中にはAWS環境を見直したいが、そもそも何が出来るのかわからないといったかたも多いかと思います。 改善にはすぐに出来るもの、重要度が高いもの、アプリケーションの改修が必要なものなど、様々な内容があります。フェーズごとに検討すると良い内容をご紹介します。

改善ポイントの分類

改善項目を2つの視点で、分類します。

観点

5つの視点から改善ポイントを分類します。

• セキュリティ
• 信頼性
• パフォーマンス
• コスト
• 運用性

フェーズ

重要度や即効性などを考慮し、優先順位をつけます。 3段階にわけ、ファーストフェーズを最優先します。 優先順位は実環境に合わせて、カスタマイズしてください。

ファーストフェーズ

重要度が高いまたは、即効性のある項目です。

セカンドフェーズ

ファーストフェーズと合わせて実施すると効果の高い項目です。

サードフェーズ

必要に応じて実施すると良い項目または、アプリケーション改修が必要な内容です。

セキュリティ

概要

Trusted Advisor

AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。

セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。

insightwatch

insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。

IAMの見直し、定義

IAM のベストプラクティスに基づいた見直しを行います。 どこまでベストプラクティスに沿った対応を行うかはケースバイケースです。判断はこちらの資料が参考になります。

最低でも、AWS IAM ベストプラクティスのご紹介 – AWSアカウントの不正利用を防ぐためにの内容は確認、対応しましょう。

AWS ログ有効化

なにかあった時に、後から追跡できるようにAWSサービスのログ出力を有効化しましょう。 ログ有効化は比較的簡単に行えます。 課金は発生しますが、本番サービスのAWSサービスログは有効化しておくといいでしょう。

Amazon GuardDutyは、マルウェアへの感染が疑われるケースや、IAMの悪用が疑われるケースに気がつくことができます。 課金は発生しますが、本番/検証問わず有効化しておくといいでしょう。

• OS、アプリケーションログ（CloudWatch Agent、Fluentdなど）
• AWSサービスログ
  • ELBログ
  • Amazon RDSログ
  • VPC フローログ
  • AWS APIログ、変更記録
    • AWS CloudTrail S3出力
    • AWS Config
• 脅威検出
  • Amazon GuardDuty（マネージド型の脅威検出サービス）

脆弱性診断

OSやミドルウェアを対象にしたプラットフォーム診断と、Webアプリケーションを対象にしたWebアプリケーション診断を行いましょう。 脆弱性のあるOS、ミドルウェア、Webアプリケーションを利用していると、悪意のあるユーザーから攻撃を受けるなどしてセキュリティインシデントに繋がります。

プラットフォーム診断は、Amazon Inspectorで実施できます。 OSやミドルウェアの脆弱性が見つかったら、バージョンアップなどの対応を行います。

Webアプリケーション診断は、専門のセキュリティベンダーに依頼します。 価格や手法はベンダーによって様々ですが、ツールを利用した診断は安く、エンジニアが対応する度合いによって高くなる傾向があります。 弊社では、ツールを利用したフートスキャンを提供しています。

セキュリティ製品（アンチマルウェア,IDS/IPS,WAF）

責任共有モデルに置いて、OS以上のレイヤーはユーザーの責任範囲です。 AWS Security Best Practicesでは、マルウェア対策として、アンチウイルス、ホストベースのIDSが紹介されています。 セキュリティ対策としてWAFを考える場合、WAFを導入する理由を整理して、製品を選ぶと良いでしょう。

脆弱性診断とアップデートなどの対応を行った上で、セキュリティ製品を導入するとシステムを保護しやすくなります。

AWSサービスのセキュリティ設定見直し

AWSサービスはそれぞれセキュリティ設定を持っていることがあります。 S3であれば、バケットポリシー、MFA deleteといった形です。

S3,SQS,DynamoDB,KMSなど各サービスのセキュリティ設定を見直しましょう。 見直しが必要なリソースが見つかった場合は、運用ポリシーを決め、AWS Config Rulesを利用してセキュアな設定を維持します。 まずはマネージドConfigルールで対応できるか確認すると、運用は楽になります。 マネージドConfigルールは、こちらで確認できます。

暗号化

暗号化は2つに分けて考えます。 保管されたデータの暗号化と、通信データの暗号化です。

保管されたデータの暗号化は要件に応じて実施するといいかと思います。 AWSのサービスを利用すれば、簡単に暗号化できます。 具体的な手法や手順はEBS、RDS、S3などのユーザーガイドを参照します。

通信の暗号化は、暗号化されたプロトコルを利用できないか検討します。 HTTPならHTTPS、FTPならFTPSやSFTPといった形です。 プロトコルの変更が難しい場合、VPNの利用を検討します。

ログ可視化、分析

集めたログを可視化したり、分析します。 Amazon Elasticsearch Serviceを利用しKibanaでダッシュボードを作成したり、Sumo Logicのようなパートナー製品を利用します。

信頼性

概要

Trusted Advisor

フォールトトレランスの項目では、スナップショット、EC2アベイラビリティゾーンのバランスなどを確認できます。 検証環境であれば片方のアベイラビリティゾーンだけ使うといったことはよくあります。 不要な指摘は、非表示にできます。

復旧手順のテスト

AWSリソースのバックアップは取得していますか？ また、バックアップを取得しているだけで満足していませんか。 復旧手順の中には、EC2のローンチ、Elastic IPの付け替え、Route 53のレコード変更、RDSエンドポイントの変更など様々な内容があります。 最低限、必要な復旧作業の大枠だけでも整理しておけると安心です。

AWSサービス制限の確認

AWSサービスには、引き上げが可能なソフトリミットと変更不可能なハードリミットがあります。 ドキュメントや、Trusted Advisorのサービス制限項目を確認します。 まずはTrusted AdvisorからElastic IPなど制限にかかりやすい項目について、確認し必要であれば引き上げを申請しましょう。

AWS Config導入

AWS 環境の変更管理には、AWS Configが便利です。 セキュリティグループなどAWSリソースの変更を記録します。 運用をしていく中で、セキュリティグループなどが意図しない設定になってしまうケースがあります。 AWS Configは、あとから時系列で変更を追跡できます。

負荷分散（CloudFront,ELB）

CloudFrontでキャッシュしたり、ELBでEC2の不可分散を行います。 既存環境に設定する場合は、ミドルウェアなどの設定変更が必要になるケースがあるのでご注意ください。

障害からの自動復旧

AWSリソースを監視し、障害発生時は自動で再起動するといった対応を行います。 CloudWatchアラームを利用したり、パートナー製品を利用します。

Auto Scaling導入

需要の変化に追従できるように、EC2 Auto Scalingを検討します。 時間、アクセス量、リソース状況などに応じてEC2を増減できるようになります。 アプリケーションの改修やデプロイの考慮が必要な場合があるので、留意ください。

パフォーマンス

概要

Trusted Advisor

Trusted Advisorは、パフォーマンスについても指摘してくれます。 例えば、セキュリティグループのルール数が多いとパフォーマンスが低下する場合があります。 指摘項目を元に、セキュリティグループ、EC2インスタンスタイプ、EBSのオプションなどを見直します。

モニタリング

CloudWatchやパートナー製品を利用して、リソースやシステムをモニタリングします。 最低限のモニタリングを行う場合、CloudWatch、CloudWatch Agent、Route 53のヘルスチェックが手軽に導入できます。

ELBでのTLS終端

TLSの終端をELBにオフロードすることで、EC2のCPU負荷を低減します。

サービスの検討（ElastiCache,CloudFront,Aurora）

インメモリデータキャッシュとして、ElastiCacheを利用したり、Webコンテンツをユーザーに地理的に近いエッジにキャッシュするCloudFrontを検討します。 アプリケーションの改修が必要なケースがあるので留意ください。

コスト

概要

Trusted Advisor

使用頻度の低いEC2,EBS,ELB,Redshiftや、関連付けられていないEIPなどを確認できます。 利用されていないEC2を見つけたり、インスタンスサイズ変更のきっかけを見つけられます。

検証インスタンスのスケジュール停止

EC2 Schedulerやパートナー製品で利用しない時間帯のEC2を停止します。 検証用のインスタンスであれば、平日日中帯だけ起動しておけばコストを削減できます。

課金アラーム

課金アラームを設定し、コストを把握できるようにします。

コスト配分タグ

コスト配分タグを利用し、システムや利用部門ごとのコストを把握します。 タグに対応してないサービスもあるので、基本的にはシステムや部門ごとにAWSアカウントを分けた方が良いです。 1つのアカウントで複数サービスが稼働している場合は、コスト配分タグを活用します。

S3ライフサイクル

S3のストレージコストが課題の場合、S3ライフサイクルを利用して、一定期間経過したファイルをGlacierにアーカイブしたり、削除します。

リザーブドインスタンス購入

EC2には、ニーズに応じた購入オプションがあります。 ベーシックな購入オプションはオンデマンドインスタンスです。 オンデマンドインスタンスは、起動するEC2に対して秒単位で課金されます。

TrustedAdvisorを参考にしたり、実運用の中で適切なタイプを設定できたら、リザーブドインスタンスを購入します。 EC2料金について、1-3年の料金を一部または全額前払いすることで、大幅なコストダウンが可能です。

ソフトウェアライセンス最適化

CPUコア数に応じてソフトウェアライセンス費用が発生するプロダクトでは、CPU最適化オプションを利用することでソフトウェアライセンスのコストを下げられる可能性があります。

Auto Scaling導入

需要の変化に追従できるように、EC2 Auto Scalingを検討します。 時間、アクセス量、リソース状況などに応じてEC2を増減できます。 アプリケーションの改修やデプロイの考慮が必要な場合があるので、留意ください。

スポットインスタンス

スポットインスタンスは、EC2の購入オプションの1つです。 最大90%の割引を受けられます。 スポットインスタンスは需要によって価格が変動し、入札価格がスポット料金を超える時にEC2を利用できます。 入札価格がスポット料金を下回ると、EC2は停止あるいは終了します。

マネージドサービスの導入

AWSの利用をはじめたばかりの場合、EC2の台数が多くなる傾向にあります。 EC2をマネージドサービスに置き換えることで、AWS利用費や運用費用を削減できます。

リレーショナルデータベースであれば、RDSを検討します。 バックアップ/リストアや、DBエンジンのアップデート、冗長化などを簡単に行えるため、運用費用や冗長化のためのソフトウェアライセンスのコストを抑えられます。

運用性

概要

運用チェックリストの確認

Operational Checklists for AWSを確認します。 英語に抵抗がある方は、弊社の記事を参考にしてください。

モニタリング

CloudWatchやサードパーティのツールを利用してモニタリングを行います。

自動化アクション

AWSでの自動化アクションは様々ですが、AWS Summitでのセキュリティ・オートメーションのセッションが参考になります。

おわりに

運用担当者のためのAWS改善マップということで、フェーズ毎に対応すべきこと、対応すると良いことをご紹介しました。 この記事が改善のきっかけになれば幸いです。

参考

• AWS Well-Architected
• AWS IAM ベストプラクティスのご紹介 – AWSアカウントの不正利用を防ぐために