#はじめに
クラウドコンピューティングの勉強を始めたくて、AWSアカウントを作成。コンソールからぽちぽちと触ってみる。
あまりに簡単にサービスが立ち上がるので、楽しくなっていろいろ試していると……
「え、知らないうちに請求が来てるんだけどなんで！？」
なんて経験、誰しもあるのではないでしょうか。
あるいはクラウド破産という言葉を聞き、自分もそうなってしまうのではないかと怖くて手が出せない人もいるかもしれません。
世の中の良いサービスにお金が支払われるのは悪い事ではないのですが、予期せぬ課金はさすがに堪えるものです。
予期せぬ課金を防止するためのポイントは、言ってしまえば課金されるパターンあるあるを知ることです。
つまりこの記事は、私のAWSアカウントに請求が来てしまった失敗談集でもあります。
請求に怯えながらコンソール画面を見ている・見る予定がある人のお役に立てれば、きっと私の予期せぬ利用料金たちも浮かばれるでしょう。
##この記事では説明しないこと
・初学者向けの範囲を逸脱した解説
→あくまで「ハンズオンとしてAWSアカウントを作成し、無料利用枠内で小さなサービスを作ってみる」場合を想定しています。
・セキュリティ対策
→AWS高額請求といえば、「重要なキーを誰でもアクセスできるところに置いてしまい、アカウントを乗っ取られた」などのセキュリティ周りでやらかしたパターンが有名ですが、当記事は「ユーザーの手で立ち上げたサービスにおける予期しない課金」を対象とします。
#予期せぬ課金パターンたち
##EC2編
###インスタンス
1年間無料対象枠に入っているインスタンスタイプは「t2.micro」のみです。また、無料利用枠には750時間制限（/月）があります。
個人用のハンズオンで無料利用枠を超えることはなかなかありませんし、コンソールからEC2を立ち上げる場合、他のインスタンスを誤って選択する可能性も低いでしょう。
注意すべきなのは、ハンズオンなどでCloudFormationテンプレートからスタックをデプロイする場合です。
CloudFormationのテンプレートを指定すると、次に「スタックの詳細を指定」の画面が出てきます。
つい読み飛ばしてしまいがちですが、よく目を通してみてください。
InstanceTypeがt2.largeになっていますね。当然このままデプロイすると料金が発生します。
どうしてもインスタンスサイズが大きくないとうまくいかない場合は選択するしかありませんが、もしt2.microでもハンズオンが行えそうであれば、サイズを変更してしまってください。
###Elastic IP
Elastic IPは、実行中のインスタンスに関連付けられている場合1つまで無料です。
「実行中」というのがポイントで、停止しているインスタンスに関連付けられているElastic IPや、インスタンスを削除したものの解放し忘れたElastic IPは料金が発生します。
インスタンスを停止する場合、もしくは削除する場合は必ずその前にElastic IPを解放するように癖をつけておくと安心です。
関連付けの解除方法については、公式ドキュメント内「Elastic IP アドレスの関連付け解除」をご確認ください。
私の初めての請求も、停止したインスタンスに関連付けていたElastic IPでした。
##VPC編
###NATゲートウェイ
VPCにおいて料金発生ポイントは多くないのですが、NATゲートウェイは曲者です。
まず、NATゲートウェイは通信の方向に関わらず料金が発生します。AWSはデータインに関しては料金が発生しない場合が多く、NATゲートウェイが例外であることがまず注意点となります。
更に、AWS公式のVPC料金ページを見ていただくと分かるのですが、NATゲートウェイは結構高額です。一番安いバージニア北部リージョンでも、0.045USD/時の起動価格＋データ転送料金として0.045USD/GBが生じます。
そして東京リージョンで利用すると更に高いです。
ここで考えるべきなのは、「本当にNATゲートウェイが必要な構成なのか？」ということです。
AWSリソースとの通信であれば、エンドポイントを利用した通信で事足ります。VPCエンドポイントを利用する場合、NATゲートウェイよりはるかに安価で済みます。
VPC間で通信するだけの構成であればそもそもNATゲートウェイを経由させる必要はありません。ほとんどのAWSサービスに於いて、同一リージョン内の通信は無料です。
私の経験談でもあるのですが、簡単なサービスをデプロイする程度のハンズオンであればNATゲートウェイは不要であることが多いです。
或いはNATゲートウェイをなるべく利用しないような構成を考えることも、ひとつの学習になることでしょう。
##RDS編
###インスタンスタイプ
EC2同様、「db.t2.micro」以外のインスタンスタイプは無料利用枠の対象には入っていません。
（Oracle BYOL＝独自ライセンス形式であれば「db.t3.micro」が無料利用枠に入りますが、なかなか個人のハンズオンで利用する機会はないと思います）
注意点はEC2の場合と同様、CloudFormationのスタックから起動させる場合です。インスタンスのサイズはきちんと確認しておきましょう。
###スナップショット
AWS公式のRDS料金ページの大見出しをざっと見る限りでは、「スナップショット」の料金は書かれていないように見えます。
よく見ると分かるのですが、スナップショットの料金については「バックアップストレージ」の項に記載されています。
かいつまんで読んでみると、「つまり、ほとんどのお客様にはバックアップストレージの料金が発生しません」の文字が目に入るかもしれません。
しかし、更にその後をじっくり読んでください。
DB インスタンス終了後のバックアップストレージの料金は毎月 0.095USD USD/GiB です。
そう、RDSインスタンスを稼働させている間はバックアップストレージの料金はかからない（場合が多い）のに、インスタンスを終了させるとバックアップストレージの料金が発生するのです。
ハンズオンでDBを立ち上げ、終了時に削除。でもRDSの請求があるぞおかしいな、という場合はこれが原因かもしれません。
日割りなので、1日に積みあがっていく金額としてはそうでもないことだけが幸いなのですが、ふとCost Explorerを起動したときに
上記のようになっているとかなりゾッとします（見て分かる通り、この時は気付くまでに1週間ほどかかっています……）。
スナップショットに課金されてしまうことを防ぐには、RDSを削除する前にスナップショットを削除してしまうのが一番です。
ただしスナップショットの作成タイミングによっては、削除した後にスナップショットが作成されてしまう場合もあるので、要注意です。
RDSスナップショットの削除方法に付いては、AWS公式ドキュメントをご参照ください。
もしハンズオンに於いてスナップショットが不要であれば、最初から作成しないように設定するのが一番簡単です。
コンソール画面からデータベースサーバーを作成する際に、上記のチェックを外すだけです。
（※既存のCloudFormationテンプレートからRDSを作成する場合は、スナップショット不要の設定が行えないようです）
##S3編
S3の無料利用枠はAWS公式のS3料金ページによると、S3の無料利用枠は「S3標準ストレージクラスで5GBのAmazonS3ストレージ、20,000GETリクエスト、2,000PUT、COPY、POST、あるいはLISTリクエスト、データ送信15GB」です。
ハンズオンの範囲ではとても超えそうにない……と思いがちですが、実はとある設定をしていると簡単に超えてきます。CloudTrailの証跡作成です。
CloudTrailのログをS3に保存するようにすると、AWSにアクセスして何かする度に自ずとPUT数が増えるため簡単に無料利用枠をはみ出ます。
請求ダッシュボードの無料利用枠があっという間に100％を超える様は、初見だと度肝を抜かれるのではないでしょうか。
ただし他の場合と異なるのは、CloudTrailをきちんと設定し、アカウントに不審な動きがないか気を付けることが回り回ってコスト削減につながる場合があることです。
「この記事では説明しないこと」の項で少しだけ触れましたが、AWS高額請求で多いのはアカウントが乗っ取られるパターンです。そうならないためにも、CloudTrailのログをきちんと保存し、S3のPUT数が無料枠を超えてしまうことには目を瞑る、というのが、AWSのベストプラクティスではあります。
どの程度サービスを利用するかにもよりますが、CloudTrailでログを保存する場合、個人のハンズオン目的での利用であれば月200円程度で済みます。
#それでも人は過つ
人間は間違える生き物です。気を付けていても避けられないことがあります。
とはいえ、サービスコンソール（GUI）画面に、個々のサービス利用料金が表示される機能はありません。
しかし、間違いに備えておくことで、課金による影響を最小限にすることは可能です。
つまり、利用料金が発生したらすぐに気付けるよう、通知を設定しておきます。
「AWS Budgets」は、AWS利用料金についての予算を設定し、予算の一定割合を超過するとアラートという形で通知を送信することができます。
予算とアラート用のしきい値を非常に小さい額に設定しておけば、利用料金の発生がすぐに分かります。
AWSに慣れてきたら、メールよりもLINEなどで通知が来た方が便利かも、と思うようになりかもしれません。
また、AWS Budgetsはアラートを一度オンにするとオフに戻すことはできません。
Amazon CloudWatchの「EstimatedCharges」メトリクスを利用すると、AWS内の他のサービスのトリガーとして利用でき、例えば一定金額を超えた時点でAWS Lambdaを動かしてLINEに通知する、という使い方が可能になります。
初心者向けの範囲を超えてしまうので、Amazon CloudWatchドキュメントをご参照ください。
もし料金が発生していることが分かったら、すぐに詳細を確認しましょう。
請求が来たサービス一覧をただ眺めていても、理由が分からない場合が多いからです。
前日までの請求詳細は「Cost Explorer」で確認できます。
当日の請求確定は次の日に持ち越されてしまうため、その日の消し忘れは分からないところだけが難点です。
そのため、アラートに気付いたらすぐに確認、すぐに削除するようにしましょう。
（この辺りをカバーできるサービスとしてAWS Trusted Advisorが存在するのですが、月100ドルかかるビジネスプラン以上を利用する必要があり、個人利用には少し難しいでしょう）
また、失敗から料金発生が起こってしまっても、次に繋がる勉強になったと割り切ることも大切です。
逆に言えば割り切れるほど小さな失敗で済むように、アラートは絶対設定しておきましょう。
#おわりに
以前、初めてクラウドサービスを触る人向けのハンズオンを作成するため、他のクラウドサービスとの比較検討を行う機会がありました。
そこで感じたのは、GCPやAzureといったバウチャーで無料利用枠を用意してくれるクラウドサービスに比べて、AWSは無料利用枠の概念が分かり辛く初学者のハードルが高いのではないか、ということです。
ただ、ハードルの高さに初学者が臆してしまうのはもったいないと感じるほどに、AWSは魅力的なサービスを取り扱っていることも確かです。
公式からのハンズオンや学習体系も充実している分、多くの人が臆しているポイントであろう「料金」の不安をわずかでも取り除けたらと思っています。
当記事がAWS初学者の支えになれば幸いです。
弊社WebサイトではAWSを含むさまざまな技術記事を公開しています。ぜひご覧ください。