目次
はじめに
“クラウド破産”、インパクトの強い言葉です。
2021年現在、AWSやAzure、GCPなど、パブリッククラウドが広く使われるようになり、身近なものとなりました。本番環境つまり商用利用が一般的ではあるかと思いますが、エンジニアであれば、自己学習のため、検証目的で利用するといったケースも多いのではないでしょうか。ここではパブリッククラウドを利用する中で誰でも一度は遭遇したであろう利用料金に関するトラブルにフォーカスしてみたいと思います。
課金対象となるリソースの削除忘れで課金されてしまった、想定していたよりも課金額が大きかった、最悪のケースだとセキュリティ情報の流出などの被害により高額課金されたなど、利用料金に関するトラブルは様々です。こうしたちょっとしたミスが重なると、数十万・数百万円という巨額請求にあうこともあり得ます。”クラウド破産”という言葉があるほどですから。
本記事ではパブリッククラウドの中からシェアNo.1を誇るAWSに注目して、このようなトラブルを事前に防ぐ、または発生してしまった際の被害を小さくするための施策をご紹介します。
“クラウド破産”とは？
“クラウド破産”とは、前述の通り、クラウドサービスの使用料金が意図せず高額になる (例えば数日で数十万円など)、という事象を指す俗語です。
誰にでも起こるものではありませんが、リスクとしては確実に存在するもので、請求ルールのわかりにくさ、利用者の理解不足、リクエスト数などの見積もりが困難、インターネットからのアクセス数などコントロールしにくいものが原因として挙げられます。
“クラウド破産”の事例
クラウド破産の事例として、ウェブ上にもいくつか情報があります。いずれも先人たちが同じ轍を踏まないように、と公開しているものです。
ベンチャーがうっかり従量課金の翻訳サービスでクラウド破産しかかった話
想定される”クラウド破産”のケース
さっそくですが、想定外の料金が課金されるケースとして、大きく２パターンがあります。
リソースの削除忘れや過剰利用による高額請求
不正アクセスによる高額請求
それぞれの対処方法について、ご紹介します。
“クラウド破産”のケース1 過剰利用による高額請求への対策
まず、リソース削除忘れや想定を上回る過剰利用に起因した高額請求への対策について、ご紹介します。
すぐにできる方法として
請求アラームを用いた請求額検知と、リソースの作成・削除運用簡易化による過剰利用防止があげられます。順を追ってご紹介します。
請求アラームを用いた請求額検知
最初の対処法として、請求アラームの設定が考えられます。
AWSのサービス「Cloud Watch」を使用して該当月の使用料金が、所定の金額に達した際に、登録したメールアドレスにアラームメールを送信する設定になります。具体的な設定例として、アカウント内の概算合計請求金額が９ドルを超過したら、注意喚起メールを発報するなどが可能です。
実際に設定する際は、サービス「Cloud Watch」の「アラームの作成」から作成します。
この設定により、登録したメールアドレスに概算合計請求金額が一定額を超過したら、注意喚起メールが発報されますので、メールを受信したらコンソールにログインして、原因調査などを行うことができます。
実際には以下のようなメールが発報されてきます。
リソースの作成・削除運用簡易化による過剰利用防止
もう一つの対処方法として、リソースの削除忘れを少しでも減らすために、検証環境の運用を簡易化していくことが考えられます。そこで役に立つのが「CloudFormation」というサービスです。このサービスにより、テンプレートからスタックを作成して、スタック単位でのリソース作成/削除運用を実施できるようになります。
例えば、NATゲートウェイのように、検証で作成する頻度が高く、サーバリソースなどに比べれば比較的目立たない上に、通信量で課金されるタイプのものは、削除忘れによる高額請求に繋がりやすいです。こうした場合は、スタック単位で管理することで削除忘れを防止したいものです。
では、実際の設定例を見てみましょう。CloudFormationで、NATゲートウェイのスタックを作成しています。
このように設定した場合、スタックを削除してしまえば、中に含まれるNATゲートウェイのリソースも同時に削除できます。テンプレートの設定によっては、スタックのパラメータを更新することでも、リソースの作成削除が可能です。
これを利用することで、スタックにまとまった単位でリソースを作成したり、削除したりすることが可能となるので、一部のリソースの削除忘れなどを防止することに繋がります。
“クラウド破産”のケース2 不正アクセスによる高額請求への対策
ケース1では、自身のリソース削除忘れなどへの対策をご紹介しました。
次はアクセスキーの流出等による不正アクセスに起因した高額請求への対策についてご紹介します。
すぐにできる対策としてこちらは３つの方法をご紹介します。
IAMユーザの権限を制限すること、送信元 IP に基づいて アカウントやインスタンスへのアクセスを拒否すること、多要素認証 (MFA)を設定することです。
いずれも商用システムで利用する場合は基本中の基本なのですが、個人で利用する場合などは設定を怠ったり、慣れていないと忘れてしまうこともある設定です。順を追ってご紹介します。
IAMユーザの権限を制限する
まず、アクセスキー流出に対する対処法ですが、アクセスキーを発行するユーザの権限に「AdministratorAccess」等の強い権限を与えないことも有効な対処法になります。
強い権限を持つユーザは検証の際にリソースの作成が自由にできるため便利ではありますが、流出してしまった場合の被害も大きくなるので、アクセスキーを発行するユーザには検証環境であっても必要最低限の権限のみに絞ることが大切です。
また、インターネットにスクリーンショットやログ、スクリプトコードを公開する際には、アクセスキーに関する情報が含まれていないか、注意することも大事です。
送信元 IP で アカウントやインスタンスへのアクセスを拒否する
アカウント不正利用の防止策として、送信元 IP に基づいて AWS へのアクセスを拒否する対処法も有効です。
以下のようなポリシーを対象IAMユーザに割り当てることで、許可しているIP以外からのコンソールやCLIを経由したアカウント内リソース操作を拒否することができます。
ただ、CloudFormationからEC2インスタンスを作成するなど、AWSサービスが利用しているIPアドレスからリソース操作する場合は、この設定が接続エラーを引き起こす場合もあるため、利用するサービスや検証内容に合わせてこちらの設定を見直して利用されることをオススメします。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"（許可IP）"
]
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
}
上記以外にも、セキュリティグループの設定で、EC2インスタンスやRDS等のAWSリソースへの接続元IPを絞ることも有効です。
セキュリティグループを作成する際は、ソースとして「マイIP」を選択することで、許可先IPを、セキュリティグループ作成中のネットワークに設定することも可能です。
これにより、第三者からのEC2インスタンスやRDSなど、AWSリソースへの不正アクセスを防止できます。
多要素認証 (MFA)を設定する
次の対処法として、アカウントの不正利用を防止するためにMFAコードを要求する設定にすることもご紹介します。
多要素認証 (MFA)による２段階認証を導入することで、認証された端末なしでは、リソースへの操作ができなくなり、セキュリティーレベルを大きく向上できます。 実際に、コンソールログインに対して多要素認証 (MFA)を導入する際は、サービス「IAM」から対象ユーザを選択し「認証情報」を選択、その後「MFAデバイスの割り当て」を設定します。設定したユーザでの次回ログイン以降で、多要素認証 (MFA)が必要になります。
以上の設定で、コンソールログインに対する多要素認証 (MFA)を設定できますが、必要なポリシーを該当IAMユーザに付与することでアクセスキーを使用したCLI操作に対しても同様の設定を行うことができます。
設定後は以下のように、MFA認証前のコマンドが実行に失敗するようになります。
さいごに
いかがでしたか。パブリッククラウドはいつでも、どこからでも、使いたいときに、使いたいだけ従量課金型で利用できるありがたいプラットフォームではありますが、それだけに想定外の高額請求にあうリスクも持っています。
筆者も検証用に作ったリソースを消し忘れてしまい、想定外の金額を請求されたことがありました。金額こそ高額ではなかったものの、精神的なショックの方が大きかったと記憶しています。
“クラウド破産”という多少大げさな言い方をしておりますが、便利で手軽に使えるパブリッククラウドと、上手に付き合うためにも、AWSを利用する際には上記の設定を試してみてはいかがでしょうか。
この記事で取り上げているAWSについては、サーバーレスというキーワードでクラウドが当たり前の時代 サーバーレス アーキテクチャの導入によるコストメリットを考えるでもご紹介しておりますので、合わせてお読みください。
