#はじめに
AWSで10万円溶かしたバカがいるらしい（私です）
しかも、Webサービスなど全く構築していない状況で発生した課金だと言うから救いようがない。
ドコモ口座事件も記憶に新しい現在、私は最初に新手の詐欺を疑った。しかし、普通に利用明細を見ると紛れもなく自分の過失であることが判明した。
こんなバカげた話が何故起こったのかということを今日は詳述していきたい
#前段
AWSについて理解を深めようと思いudemyで以下のコースを受講した
これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）
8月から9月にかけてこのコースを一通り履修したのが悪夢の始まりであった ＃このコースが悪い訳ではまったくなく、むしろ内容は分かりやすかった。
内容は、EC2やS3、各種DBやauto scailing、ロードバランサ、kinesis等を一通りハンズオンで動かしてみるもので実際にマネジメントコンソールやAWS CLIを触って動かすものだった。
もちろん講義中では、度々課金発生個所が存在し、その都度不要なリソースは削除するよう命じられていた。
序盤の課金対象はNATゲートウェイなどで、消し忘れていてもデータ転送がない限り課金はほぼないようなものであった。
そして、このコースを受講してから約1ヶ月。
それまで月600円ほどであった私の利用明細が突如、変貌した。
#課金体系
ここで一度、AWSの課金体系に触れておこう。
ご存知の通り、AWSのサービスは従量課金制となっており使った分だけ課金されるようなシステムになっている。
以下は課金の目安である。＃料金はインスタンスのスペックやデータ転送量に依存する
| No | 種類 | 料金 |
|---|---|---|
| 1 | サーバ | 約2円/1時間 |
| 2 | ストレージ | 約10円/1GB/1ヶ月 |
| 3 | データ転送 | 約20円/1GB |
例えば、無料利用枠の推奨メモリである『t2.micro』の場合、東京リージョンだと0.0152USD/時間の課金が発生し、現在の為替レートだと約1.6円/1時間となる。
AWSの課金項目は大きく2種類存在しており、上表1,2のように起動している時間だけ課金が発生するものと上表3のようにデータ転送が発生した場合にのみ課金が発生するものがある。
何を思ったのか私は3のようなデータ転送を行っていないから、使わないサーバの消し忘れを甘く見ていたのであった ＃普通に考えれば起動している時間だけ課金が発生するものの方が高いに決まっている
#実際の利用明細
以下が実際に今月私が請求されたAWSの利用明細である。
私はこの驚愕の数字に軽く1時間は茫然自失していた。
もうじきハロウィンの季節だが、ドッキリにしては痛手がすぎる。
AWS サービスの料金
$796.20
API Gateway
$0.00
CloudTrail
$0.00
CloudWatch
$0.00
Data Transfer
$0.00
DynamoDB
$0.00
DynamoDB Accelerator (DAX)
$554.48
Elastic Compute Cloud
$90.82
Elastic File System
$0.00
Elastic Load Balancing
$0.00
Key Management Service
$0.00
Kinesis
$0.03
Lambda
$0.00
Relational Database Service
$77.98
Route 53
$0.50
Secrets Manager
$0.00
Simple Notification Service
$0.00
Simple Storage Service
$0.00
税金
$72.39
$796.20
日本円にして、８万４千円也。 今月に足が出た分を足して合計ちょうど１０万円ほど。 私の薄っぺらな財布は一瞬にして底をついた。さながら、特別定額給付金を返還させられた気分である。#高額請求の犯人
AWSは99.999999999%（イレブンナイン）の高可用を謳っており、とにかく可用性が高い。99.999999999%（イレブンナイン）を謳っているのはS3のデータ耐久性であり、全てのサービスがそこまでの可用性を誇るわけではありませんでした。
さりとて、AWSは色々な単位で冗長設計を推奨している。
サーバインスタンスを立てるならマルチAZ構成を取るのは当たり前であり、サービスを絶対に落とさないためにあの手この手を使っている。
そこで上記の利用明細内訳を確認するとDAXとやらがほとんどを占めているのが分かる。
DAX(DynamoDB Accelerator)とは、DynamoDBと互換性のあるキャッシングサービスだそうで、ユースケースは以下の通りである。
１．DAXは、メモリ内キャッシュとして、結果整合性のある読み取りワークロードの応答時間を1桁のミリ秒からマイクロ秒まで1桁短縮します。
２．DAXは、DynamoDBとAPI互換のマネージドサービスを提供することにより、運用とアプリケーションの複雑さを軽減します。したがって、既存のアプリケーションで使用するには、最小限の機能変更のみが必要です。
３．読み取りが多いワークロードまたはバースト性のあるワークロードの場合、DAXは、読み取り容量ユニットをオーバープロビジョニングする必要性を減らすことにより、スループットの向上と潜在的な運用コストの節約を実現します。これは、個々のキーを繰り返し読み取る必要があるアプリケーションにとって特に有益です。
しかし、私のウェブサービスは、マイクロ秒単位でのワークロードなど発生しなければ、DynamoDBとAPI互換もしておらず、個々のキーを繰り返し読み取る必要があるアプリケーションなんて到底あるはずがなかった。
まったく役目を果たしていない本機能が、まったく意味のない高可用性で起動していたのだ。
DAXのクラスターを確認してみるとこうだ。
| インスタンスサイズ | クラスター数 |
|---|---|
| dax.r4.large | 3ノード |
r4.largeと言えば、メモリ15.25GiBで0.133USD/時間のそこそこ良いインスタンスタイプである。
これが3つのクラスター構成を取って1ヶ月間起動しっぱなしであったのだ。そりゃあ、高額請求も無理はない。願わくばソシャゲの一つでも運用してみたかった。
#無料利用枠とは
ところで、AWSは様々なの無料利用枠というものを設けており、大まかに言って無期限無料のものと12ヶ月間無料というものがある。かく言う私も12ヶ月間無料が適用されるユーザであり、この言葉に謎の安心感を覚えていたのもまた事実である。
12ヶ月間無料というのは、例えば以下のようなものだ。
| サービス種別 | 無料枠 |
|---|---|
| EC2 | 750時間 |
| S3 | 5GB |
| RDS | 750時間 |
しかし、これには注意が必要だ。
※ただし、t2.microに限る
ということである。
t2.microというのは、vCPU 1コア、メモリ 1GiBのインスタンスサイズの最小タイプである。
これを選ばないと課金が発生するのだ。＃まぁ、今回はそれ以前の問題だったのだが
#今後の対策
今回の件から私が得るべき教訓は、
###1.Budgetsを作成すること
###2.使わないリソースはこまめに消すこと
###3.もっと勉強すること
以上の３つであると考える。
言うまでもないがまず第一にやるべきことは１である。初心者だからと言って、何もサービスを開発していないからと言ってコストの閾値監視を怠っていたのだ今回の最大のミスであろう。
#おわりに
AWSは良くも悪くも画面ポチポチで全てが完結してしまう。オンプレを知る者からしたら非常に楽チンなものになるが、逆に無知なまま好き勝手利用すると請求が恐ろしいことになりかねない。
結論を言おう。
やはり俺のアマゾンウェブサービスは間違っている
