この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは植木和樹です。AWSでは各種ホワイトペーパーなどの資料を多数公開しています。
今回は上記ページからダウンロードできる「AWS 運用チェックリスト（PDFファイル）」を読んでみました。運用チェックリストという名前ではありますが、AWSを利用する方は一度目を通しておくのをお勧めする内容でした。
チェックリストは大きく3つ「ベーシック」「エンタープライズ」「セキュリティ監査」に分かれています。このうちベーシックは15項目程とコンパクトにまとまっていて、簡易チェックリストとしてお手頃です。
残念ながらまだ日本語訳がされていないようですので、今回ベーシック部分だけをザックリ読んで簡単なコメントを書いてみました。
ベーシック運用チェックリスト
原文は「我々は〜〜〜を設定しています（理解しています）」という形式なのですが、チェックリストっぽく疑問形にしてみました。
担当者別IAMユーザーの使用
AWS環境構築するにあたってクレデンシャル（パスワードや鍵などの認証情報）を共用せず、ユーザー毎のIAMユーザーを使っていますか？
IAMユーザーを複数人で共用するのは危険です。セキュリティ事故が起きた時にCloudTrailでログを追っても個人を特定できないためです。
ストレージタイプの選択
Amazon EBS-Backed と Instance Store-Backedインスタンスの違いと、それらによるデータの永続性・バックアップ・リカバリーの違いを理解して、 適切なインスタンスを選んでいますか？
インスタンスをストップさせてもデータが消えてほしくない場合はEBSを用いましょう。Ephemeralディスクは料金がかからないため一時ファイル置き場やスワップファイル置き場に適しています。
動的なIPアドレス
AWSの動的なIPアドレスの仕組みを理解し、アプリケーションの構成要素を再起動しても正常に機能することを保証していますか？
（例えばELBなどのロードバランサーを使用する、VPCを使用して固定プライベートIPアドレスにする、Elastic IPを使用する、またはダイナミックDNSを使用するなど）
EC2の動的グローバルIP（Public DNS/Public IP address）はインスタンスを再起動（Stop/Start）するとIPアドレスが変わってしまいます。外部にサービスを公開する場合にはELBやElastic IPを使用しましょう。
データ領域用EBSの利用
システム領域とデータ領域でEBSをわけて使用していますか？
分けた方が望ましい時は、システム領域（Amazon Linuxだと通常8GB）とは別にデータ領域用のEBSを使いましょう。データ領域がいっぱいになってもOSの停止なしで（または最小限の停止時間で）EBSを拡張することができます。システム領域のEBS拡張手順はより複雑です。
バックアップ
EBSのスナップショット機能やその他のバックアップツールを用いて、定期的にEC2のバックアップを取っていますか？
バックアップは定期的に取りましょう。簡単で安いです。
リストア・リカバリ手順の確認
独自AMI（Golden AMI）から、EBSスナップショットから、ブートストラップ方式、自前のバックアップ・リカバリツールを用いるなど方法は問いませんが、障害に備えて定期的にEC2インスタンスやEBSのリカバリ手順を試験していますか？
本番運用が始まってしまうと、リカバリ試験を行うことは難しくなります。ローンチ前に試験し、その後も定期的に手順を確認しておきましょう。
なお原文には"golden"イメージ、"bootstrapping"という用語がでてきます。Amazonの言うGoldenイメージは、ミドルのインストールなどの基本的なシステム構成を含めた汎用のイメージを指すようです。Bootstrappingは、インスタンスの初回起動時に行う、本番で使うための残りの構成(ミドルの追加設定やアプリデータの配置など)を指します。通常はCloud-init + User Dataで担当する部分です。
重要データの分散配置
アプリケーションにとって重要なコンポーネント（EC2やデータ）をマルチAZに分散配置していますか？
適切にゾーン間でデータレプリケーションを行っていますか？
アプリケーションの可用性に影響するコンポーネントに障害があった場合にどのような異常が起きるのかテストしていますか？
障害で停止／紛失すると困るものは複数AZに分散配置しましょう。
システムの冗長性
マルチAZに配置されたコンポーネント（EC2やデータ）がどのようにフェイルオーバーするか理解していますか？
また、適切にサードパーティ製品、Elastic Load Balancing、Elasitic IPを使用してますか？
実際にEC2やデータに障害を発生させ、期待通りの可用性を保てているかも確認しておきましょう。AWSが冗長構成でもアプリケーションが対応できていなかった、なんてことがないように。
OS・アプリケーションのアップデート計画
OS・アプリケーション・独自AMIへのパッチ適用やアップデート、脆弱性対策に関する取り決め（プロセス）を定期的に検証していますか？
1年間運用していれば、その間にOSやアプリケーションのパッチや新しいバージョンがリリースされているものです。どのようなルールでそれらを適用するか（即時か定期的か等）、あらかじめ決めておきましょう。
OSユーザー
適切なOSユーザーのクレデンシャルを使用し、キーペアや秘密鍵をシステム管理者で共有していませんか？
鍵の共有はしないようにしましょう。
セキュリティグループ
安全なセキュリティグループを設定していますか？階層的なネットワークトポロジを作成する際にはセキュリティグループを適切に"入れ子"にしていますか？
AWSのセキュリティグループは、通信元や通信先に別のセキュリティグループを指定することができます。例えば「"db"セキュリティグループに属するRDSと通信できるのは、"app"セキュリティグループに属するEC2インスタンス」というようにです。"入れ子"というのはこの意味かと思います。セキュリティグループで通信元／通信先を指定するとIPアドレスを意識しなくて良いですし、同じサブネット内にあるEC2をより細かく区別することができます。
ELB、S3のDNS名
DNSでELBやS3を指定する際にはAレコードは使わず、CNAMEレコードを使用していますか？
ELBやS3のIPアドレスは不定なためです。なおDNSサーバーにRoute53を使うならELBはALIASレコードを使うべきです。
独自AMIの公開
カスタマイズした独自AMIを外部公開する前には、ホスト鍵を含む公開鍵や秘密鍵、SSHのauthorized_keysファイルといった各種クレデンシャルや機密情報を削除していますか？
Publicに公開したAMIに機密情報が含まれないようにしましょう。Guidelines for Shared Linux AMIs - Amazon Elastic Compute Cloud に公開にあたっての注意事項がまとまっていますので参考にしてください。
パフォーマンステストの実施
ローンチする前にパフォーマンステストを行っていますか？
インスタンスタイプが適切か、ちゃんとAutoScaleするか確認しておきましょう。
Trusted Advisor
本番環境用のAWSアカウントでビジネスまたはエンタープライズレベルのAWSサポート契約を結んでいますか？
運用レビュー対象にAWS Trusted Advisorのレポートを含めていますか？
Trusted Advisorは設定が甘いセキュリティグループやEBSスナップショットの取り忘れを警告してくれます。定期的にレビューして設定を見直しましょう。
まとめ
いかがでしたでしょうか。原文には各チェックリストの解説ページのURLも併記されていますので、もし分からないことがあれば、参照先のページで学習してみるのが良いと思います。
すでにAWSでインフラを構築している方／これから構築しようと考えている方は、実際にインフラ構築する前だけでなく、運用を開始する前にも改めてチェックしてみてはどうでしょうか？また運用フェーズに入っていても定期的にこのチェックリストでレビューしてみましょう！
0
