クラウド破産とは、前述の通り、クラウドサービスの使用料金が意図せず高額になる （例えば数日で数十万円など）事象を指す俗語です。

　誰もが経験することではありませんが、リスクとしては確実に存在します。原因として、請求ルールの分かりにくさ、利用者の理解不足、リクエスト数などの見積もりが困難のしにくさ、インターネットからのアクセス数などをコントロールしにくいことが挙げられます。

想定されるクラウド破産のケース

　早速ですが、想定外の料金が課金されるケースは、以下のパターンがあります。それぞれの対処方法について、ご紹介します。

• リソースの削除忘れや過剰利用による高額請求
• 不正アクセスによる高額請求

クラウド破産のケース1　過剰利用による高額請求への対策

　まず、リソースの削除忘れや、想定を上回る過剰利用に起因した高額請求への対策についてご紹介します。すぐに実践できる方法として、請求アラームを用いた請求額検知と、リソースの作成、削除運用の簡易化による過剰利用防止が挙げられます。順を追ってご紹介します。

請求アラームを用いた請求額検知

　最初の対処法として、請求アラームの設定が考えられます。AWSのサービス「Cloud Watch」を使用して、当月の使用料金が所定の金額に達した際に、登録したメールアドレスにアラームメールを送信するよう設定します。具体的な設定例として、アカウント内の概算合計請求金額が9ドルを超過したら、注意喚起メールを発報するといった運用が可能です。

　設定する際は、サービス「Cloud Watch」の「アラームの作成」から作成します。

　この設定により、登録したメールアドレスに概算合計請求金額が一定額を超過したら、注意喚起メールが発報されますので、メールを受信したらコンソールにログインして原因を調査できます。実際には以下のようなメールが発報されてきます。

リソースの作成・削除運用簡易化による過剰利用防止

　もう一つの対処方法として、リソースの削除忘れを少しでも減らすために、検証環境の運用を簡易化するという対策が考えられます。そこで役に立つのが「CloudFormation」というサービスです。このサービスにより、テンプレートからスタックを作成して、スタック単位でのリソース作成、削除を実施できるようになります。

　例えば、NATゲートウェイのように、検証で作成する頻度が高く、サーバリソースなどに比べれば比較的目立たない上に通信量で課金されるタイプのものは、削除忘れによる高額請求につながりやすいというのが現状です。スタック単位で管理することで削除忘れを防止したいものです。

　設定例を見てみましょう。「CloudFormation」で、NATゲートウェイのスタックを作成しています。

　このように設定した場合、スタックを削除してしまえば、中に含まれるNATゲートウェイのリソースも同時に削除できます。テンプレートの設定によっては、スタックのパラメータを更新することでも、リソースの作成を削除できます。

　スタック単位でリソースを作成したり、削除したりできるので、一部のリソースの削除忘れなどの防止につながります。

クラウド破産のケース2 不正アクセスによる高額請求への対策

　ケース1では、リソースの削除忘れなどへの対策をご紹介しました。次はアクセスキーの流出などによる不正アクセスに起因した高額請求への対策をご紹介します。

　すぐにできる対策として3つの方法を紹介します。AWSリソースへのアクセスを管理するサービス「AWS Identity and Access Management」（IAM）ユーザーの権限を制限すること、送信元 IP に基づいてアカウントやインスタンスへのアクセスを拒否すること、多要素認証 （MFA）を設定することです。

　いずれも商用システムを個人で利用する場合などは設定を怠ったり、慣れていないと忘れてしまうこともある設定です。基本中の基本ではありますが、順を追ってご紹介します。

IAMユーザーの権限を制限する

　まず、アクセスキー流出に対する対処法ですが、アクセスキーを発行するユーザーの権限に「AdministratorAccess」などの強い権限を与えないことも有効な対処法になります。

　強い権限を持つユーザーは検証の際にリソースの作成が自由にできるため、便利ではありますが、アクセスキーが流出してしまった場合の被害は甚大です。アクセスキーを発行するユーザーには検証環境であっても必要最低限の権限のみを付与することが大切です。

　また、インターネットにスクリーンショットやログ、スクリプトコードを公開する際には、アクセスキーに関する情報が含まれていないかを注意することも大事です。

送信元 IPでアカウントやインスタンスへのアクセスを拒否する

　アカウントの不正利用の防止策として、送信元 IP に基づいてAWSへのアクセスを拒否する対処法も有効です。

　以下のようなポリシーを対象IAMユーザーに割り当てることで、許可しているIP以外からのコンソールやCLIを経由したアカウント内のリソース操作を拒否できます。

　ただ、CloudFormationから「Amazon Elastic Compute Cloud」（EC2）インスタンスを作成するなど、AWSサービスが利用しているIPアドレスからリソース操作する場合は、この設定が接続エラーを引き起こす場合もあります。利用するサービスや検証内容に合わせてこちらの設定を見直して利用されることをオススメします。

　上記以外にも、セキュリティグループの設定で、EC2インスタンスや「Amazon Relational Database Service」（RDS）などのAWSリソースへの接続元IPを絞ることも有効です。

　セキュリティグループを作成する際は、ソースとして「マイIP」を選択することで、許可先IPをセキュリティグループ作成中のネットワークに設定することも可能です。これにより、第三者からのEC2インスタンスやRDSなどのAWSリソースへの不正アクセスを防止できます。

多要素認証 （MFA）を設定する

　次の対処法として、アカウントの不正利用を防止するためにMFAコードを要求する設定にする方法もご紹介します。

　MFAによる2段階認証を導入することで、認証された端末なしではリソースへの操作ができなくなり、セキュリティレベルを向上できます。 実際に、コンソールログインに対してMFAを導入する際は、IAMから対象ユーザーを選択し「認証情報」を選択、その後「MFAデバイスの割り当て」を設定します。設定したユーザーは次回以降のログインで、MFAを求められます。

　以上の設定で、コンソールログインに対するMFAを設定できますが、必要なポリシーを該当IAMユーザーに付与することで、アクセスキーを使用したCLI操作に対しても同様の制限を設けられます。設定後は以下のように、MFA認証前のコマンドは実行できません。

さいごに

　いかがでしたか。パブリッククラウドサービスはいつでも、どこからでも、使いたいときに、使いたいだけ従量課金型で利用できるありがたいプラットフォームではありますが、それだけに想定外の高額請求が起こるリスクを孕んでいます。

　筆者も検証用に作ったリソースを消し忘れてしまい、想定外の金額を請求されたことがありました。金額こそ高額ではなかったものの、精神的なショックが大きかったと記憶しています。

　クラウド破産と多少大げさな言い方をしておりますが、便利で手軽に使えるパブリッククラウドサービスとうまく付き合うためにも、AWSを利用する際は上記の設定を試してみてはいかがでしょうか。