AWS再入門2018 運用チェック編

こんにちは。池田です。先日、うっかり左太ももを痛めてしまい歩行速度が普段の半分以下になっています。日々の適度な運動やストレッチを意識していこうと思います。

AWS再入門2018シリーズ14弾となる今回は前回のセキュリティチェック編と同じく、AWSホワイトペーパーで公開されているOperational Checklists for AWS（AWS 運用チェックリスト）という資料を基に筆者なりに整理/解釈した内容をご紹介したいと思います。 この資料は2013年6月に公開されておりますが、2種類のチェックリストとその使い方、各チェック項目の解説がまとめられており、現在でも有益な内容だと思いますので原文をご一読されることをお勧めします。

Basic Operations Checklist

We use AWS Identity and Access Management (IAM) to provide user-specific, rather than shared credentials for making AWS infrastructure requests.

◻︎ 個人及び必要なリソースに見合った、必要な権限のみを付与したIAMユーザを用意し、個別に利用します。ルートアカウントをはじめ、特定のアカウント情報を複数人での共有はしません。

We understand which of our instances is Amazon Elastic Block Store (Amazon EBS)-backed versus instance store-backed, have intentionally chosen the most appropriate type of storage, and understand the implications to data persistence, backup and recovery

◻︎ Amazon EBS-BackedとInstance Store-Backedの違いを理解し、どちらの利用を選択したか把握しています。また、データの永続性を含めたバックアップとリカバリプランに適切なストレージを選択しています。

We understand AWS dynamic IP addressing and have ensured that our application will function when application components are restarted (e.g., using 3rd-party or Elastic Load Balancing, Amazon Virtual Private Cloud (Amazon VPC) static address assignments, elastic IP addresses, or dynamic DNS).

◻︎ AWSが各リソースへ提供するIPアドレスの仕組みを理解し、外部リソースや他のAWSリソースを用いた適切な設計をしています。リソースの再起動時にも適切な動作となることを確認しています。

We use separate Amazon EBS volumes for the operating system and application/database data where appropriate.

◻︎ OSとアプリケーション、データベースが使用するデータは、必要に応じて異なるAmazon EBSボリュームに格納するよう設計しています。

We regularly back up our Amazon Elastic Compute Cloud (Amazon EC2) instances using Amazon EBS snapshots or another 3rd-party backup tool.

◻︎ Amazon EBSスナップショットや他の仕組みを利用して、EC2インスタンスのバックアップを定期的に取得するよう設定しています。

We regularly test our process of recovering our Amazon EC2 instances or Amazon EBS volumes when they fail, either through customized ”golden” Amazon Machine Images(AMIs), Amazon EBS snapshots, bootstrapping, or using our own backup and recovery tools.

◻︎ インスタンスやボリュームに対して、選択したバックアップ方法およびリカバリ手順での復旧訓練を定期的にスケジュールし、実行します。

We have deployed critical components of our applications across multiple availability zones, are appropriately replicating data between zones, and have tested how failure within these components affects application availability.

◻︎ 重要なリソース、コンポーネントは複数のアベイラビリティゾーンに配置し、適切な複製がなされることと単一アベイラビリティゾーンでの障害によっても可用性が損なわれないことをテストしました。

We understand how failover will occur across application components deployed in multiple availability zones and are using 3rd-party or Elastic Load Balancing and elastic IP addresses where appropriate.

◻︎ 複数のアベイラビリティゾーンに展開された各種リソースがどのようにフェイルオーバーされるのかを理解しています。またElastic IP アドレスの特性や利用方法を理解し、サードパーティ製品やElastic Load Balancingに対し適切に割り当てています。

We regularly test our process for patching, updating, and securing our Amazon EC2 operating system, applications, and customized AMIs.

◻︎ 各種リソースへのセキュリティパッチ適用を含む更新やセキュリティ検査を定期的に実施するよう計画を立てます。

We use appropriate operating system user account access credentials and are not sharing the AWS instance key pair private key with all systems administrators.

◻︎ セキュリティチェックリストを活用し、各リソースに適切なアクセス権を設定したアカウントを使用します。各EC2インスタンスのキーペアの共有はしません。

We have implemented secure Security Group rules and nested Security Groups to create a hierarchical network topology where appropriate.

◻︎ セキュリティグループに対し、適切なセキュリティグループルールを実装しています。必要に応じてネットワーク構成図を作成します。

We use “CNAME” records to map our DNS name to our Elastic Load Balancing or Amazon Simple Storage Service (Amazon S3) buckets and NOT “A” records.

◻︎ ELBやS3バケットに対してDNS名を設定する場合はCNAMEレコードを使用します。Aレコードは使用しません。

Before sharing our customized Amazon Machine Images with others, we removed all confidential or sensitive information including embedded public/private instance key pairs and reviewed all SSH authorized_keys files.

◻︎ カスタムAMIを他のユーザーと共有する場合は、キーペアやSSH authorized_keysファイルのほか機密情報を全て削除したものを利用します。

We have fully tested our AWS-hosted application, including performance testing, prior to going live.

◻︎ AWS環境での本番稼動前に、性能試験やアプリケーションテストなど各種試験を全て実施しました。

We have signed our production AWS accounts up for business or enterprise support and have a plan for incorporating AWS Trusted Advisor reports into our ongoing operational reviews.

◻︎ AWSアカウントには適切なサポート契約を結び、AWS Trusted Advisorレポートなど継続的に運用状況をレビューしていく計画を立てています。

Enterprise Operations Checklist

Billing & Account Governance

◻︎ AWSからの請求処理の方法とアカウントの管理方法について、十分な検討をしたうえで決定しましたか？想定しているアカウントの数は妥当ですか？

Security & Access Management

◻︎ AWSを利用する上で必要となる各種リソースやデータ群とそれらへのアクセス管理について、十分な検討を通じて決定しましたか？

Asset Management

◻︎ 各AWSリソースに対して、それを特定する方法と監視、監査するための手段について確認しましたか？

Application HA/Resilience

◻︎ 設計した各リソースは、高可用性や障害からの復旧要件を十分に満たすよう実装されていますか？

Application DR/Backup

◻︎ 設計した各リソースは、ディザスタリカバリとバックアップ計画の要件を十分に満たすよう実装されていますか？

Monitoring & Incident Management

◻︎ 各リソースとそれぞれの項目に対して適切な監視ツールを設定し、インシデント管理の手順を構築しましたか？

Configuration & Change Management

◻︎ AWSリソースの設定や変更の管理について方針を策定しましたか？

Release & Deployment Management

◻︎ AWSで利用するアプリケーションのリリースと展開について、従来の管理方法に統合可能か確認し、必要に応じた対応を行いましたか？

まとめ

チェックリストとして使えるように、各項目はできるだけ簡潔にしてみました。「Basic Operations Checklist」と「Enterprise Operations Checklist」どちらも各項目に対して「Yes」となることが望ましい内容となっています。 汎用的な内容ではありますがAWSを利用していく上で重要な確認事項が網羅されていますので、業務マニュアルや手順書へ組み込んで活用するのも良いなぁと感じました。この投稿をお読みくださった方の、より良いAWSライフの一助となれば幸いです。