はじめに
ITスクールRareTECHで学習しているゆーせーです。
個人開発やチーム開発でAWSを実際に運用しています。
AWSは使った分だけ課金されます。
触り始めた頃は気づきませんが、 一瞬で“爆死” します
気づいたときには数千円 → 数万円に跳ね上がることがあります。
特に NAT Gateway、ALB、CloudWatch Logs は初心者ほど事故ります。
私自身、個人開発やチーム開発で実際にAWSを利用してきましたが、個人開発で実際に課金爆死を経験し、
月6,000円 → 1,200円 まで抑えることができました。※１つの個人開発で利用した値段です
ただしこれはスキル不足ではなく、設計の問題でした。
本記事では、私が実際に遭遇した料金爆発の例と、そこからどうやってコストを抑えたかをまとめます。
AWS課金の考え方
AWSの料金は「サービス単位」ではなく、課金軸（料金が発生する要素） で見ると理解しやすくなります。
ほとんどの料金爆発はこの課金軸の理解不足から発生します。
AWSの課金は大きく次の４つの軸で決まると考えます。
① リソースの保有量に応じて発生する料金
いわゆる固定費に近い部分かな
代表例：
● EC2（インスタンス起動時間）
● ALB（時間単価＋LCU）
● RDS（インスタンスサイズ × 稼働時間）
● EBS（ストレージ容量）
上記は起動しているだけで料金が発生します
初心者が最初に踏みがちなミスは「使っていないのに残しっぱなし」。
私も残しっぱなしで 何も動かしていない のに数千円無駄にしました、、、
EC2を停止したから無料だと思っている貴方！！
⇒そんなわけはありません。EBS料金は普通に発生します。
② データ転送量に応じて発生する料金
AWSで最も事故が多い課金軸がこれです！！
代表例：
● NAT GatewayのOUTBOUNDデータ転送
● インターネットへのアウトバウンド通信
● CloudFront → オリジン間の通信
特にNAT Gatewayは
「 固定費 + 転送量 × 単価 」の二重課金。
apt update / docker pullなどを気軽にやる
⇒NAT経由でどんどん課金が膨れていきます。
③ リクエスト回数に応じて発生する料金
S3やAPI Gatewayなどの利用に応じた課金。
代表例：
● S3のPUT/GET/LIST
● API Gatewayのリクエスト数
● Lambdaの呼び出し回数
ストレージ代が安く見えても、
リクエスト課金が本体なので、設計次第で爆死します。
１万ファイルを毎回LISTしてチェック
⇒LISTだけで数千円いくことも！
④ 実行時間に応じて発生する料金
特にサーバーレス系に多いです。
私は勉強したばかりのタイミングで使用して死にました
代表例：
● Lambda（メモリ × 実行時間 × 回数）
● Fargate（vCPU/メモリ × 時間）
Lambdaは無料っぽく見えるので事故が多いです、、
重い処理をLambdaで実行
⇒長時間稼働 × 大メモリで一瞬で料金が増えます。
まとめ
AWSの料金は「サービス」ではなく「課金軸」で理解する
今回取り上げた例もすべて、次の４つの軸のどれかが原因でした。
● 固定費がかかるもの → ALB/EC2/RDS/NAT Gateway
● データ転送量で増えるもの → NAT Gateway
● リクエスト数で増えるもの → S3/API GateWay
● 実行時間で増えるもの → Lambda
そして料金爆発の大半は、使った量そのものでなく
設計ミスによって"無意識に使われ続けている"こと が原因です。
● NATを常時経由する構成にしていた
● ALBを使うほどの規模でなかった
● CloudWatch Logsを無制限保持にした
● S3に大量にLIST/PUTを投げていた
● Lambdaで重い処理を回していた
上記は私が実際に犯してしまった ミス です
こうした問題は、サービスを変えるのではなく設計を見直すことで解決できます！！
AWSは難しいのではなく、
「 どの課金軸が効く構成なのか 」を理解できればコストコントロールできます！
本記事で紹介したポイントを押さえておけば、個人開発でもチーム開発でも、AWSのコストを安定して抑えることができます！
長くなりましたが、ここまで読んでいただきありがとうございます
長々と語りましたが、AWSを学習して数か月の戯言です。間違った解釈もあるかと思いますが、温かい目で見守っていただけると嬉しいです