BFT名古屋 TECH BLOG

日々の業務で得た知識を所属するエンジニアたちがアウトプットしていきます。

【AWS】よく使うAWSサービスの料金について -こんなところでお金がかかるんですと言いたい話-

こんにちは! BFT名古屋支店の佐野です。

今回はAWSのサービスを利用した時の料金、つまりお金の話です。
検証するにも、実際に本番運用するにも、とにかくお金は掛かります。AWSには無料利用枠も多数ありますが、それでもどこかで料金が発生している場合が殆どと思います。

f:id:bftnagoya:20220407105408p:plain

そこで、AWSの環境を検証あるいは運用するという時に「これは使うだろう」というサービスをピックアップして、その料金や見積もりの方法についてお話します。


はじめに

今回の記事では、筆者の経験からAWSを運用する際に使うことの多かった以下のサービスに着目して解説を行ないます。

これ以外だとS3やLambda、CloudWatchあたりのサービスを思い浮かべますが、これらは料金の度合いで見ると割合が低くなりがちなため、省いています。
またAWSの全体の見積もりに関しては公式ドキュメントにある各サービスの料金表の他、AWS Pricing Calculator”という公式の見積もりツールがあるため、具体的な料金については取り扱いません。
なお本記事の料金については「アジアパシフィック(東京)」リージョンが前提となります。
AWS Pricing Calculatorとその利用方法については以下の公式ドキュメントを参照ください。

docs.aws.amazon.com


VPCで発生する料金

AWS内に仮想ネットワーク環境を構築するVPCは、ほぼすべてのAWS利用ユーザーが使用しているサービスと言えるでしょう。
そしてVPC自体には料金は発生せず、サブネットやネットワークACL、セキュリティグループの作成についても同様です。
インターネットへの出口になるInternet Gatewayについても、料金はかかりません。そのため、これらを使っているだけならVPCで料金が発生することはないです。

ですが、そういった無料要素の多いVPCだからこそ、料金が発生する要素を見逃すこともあります。
以下で並べるVPCのオプション機能は、特に利用するシーンが多い有料要素になります。

NATゲートウェイ

NATゲートウェイはその名の通り、ネットワークアドレス変換(NAT)を行なうゲートウェイです。
簡単に言えばこれを経由することで、インターネットに向けて開かれていないプライベートサブネットから、パブリックサブネットにあるインターネットゲートウェイを通ってインターネットに出ることができます。
そしてインターネットから来る通信は、プライベートサブネットに到達することができない……というのを実現するためのサービスとなります。
なのでセキュリティ性を保ったまま、プライベートサブネット内のEC2からインターネットに通信ができる、ということができるようになりますが、NATゲートウェイ起動時間とデータ転送量に応じて課金されます。

その価格は、起動している時間(=配置されている時間)1時間あたり0.062USD、データ転送料金も1GBあたり0.062USDと、他のVPCオプションに比べて割高です。
またデータ転送料金はデータイン/データアウトに関わらず発生するため、何気なしに使っていると一気にコストがかさんでしまう原因になってしまいます。

エンドポイント(interface型)

先にプライベートサブネットからインターネットに通信の足を出したい場合はNAT ゲートウェイが必要ということを説明しましたが、AWSサービスにのみ接続を行なうという場合はVPCエンドポイントを使っても同様のことが可能です。
特にS3用やDynamoDB用となるGateway型のエンドポイントは無料で利用できるので、ファイルやデータのやりとりをする場合にインターネットではなくエンドポイントを経由する形を取ることは然程珍しいことではありません。

しかしそれ以外のエンドポイントはinterface型といい、いわゆるPrivateLinkと言われるものになります。
こちらは起動時間とデータ処理量に応じて課金され、またデータ転送料金もデータイン/データアウトに関わらず発生します。
そして料金は1時間の起動時間あたり0.014USD、1GBのデータ処理あたり0.01USDのコストとなり、NATゲートウェイと比べれば6分の1と低コストです。

ただし、これはエンドポイント1つ分のコスト。
サービス毎に専用のエンドポイントを用意しがちなエンドポイントでは、置けば置くほどこのコストが掛かってくることになります。
コストを考える場合、NAT ゲートウェイと併せて、何をプライベートな通信に載せるか載せないかを吟味する必要が出てくるでしょう。


EC2で発生する料金

仮想マシンであるEC2インスタンスですが、従量課金形態をとっているこちらは起動時間に応じた料金が発生することは、多くのAWSユーザーが既知のことでしょう。
つまりEC2インスタンスを置いていたとしても、停止さえしていれば料金は全くかからない……
と、いうことには残念ながらなりません。
EC2インスタンスのデータを保存するEBSは、たとえEC2インスタンスが停止していたとしても料金が発生します。

EBS

EBSは、EC2インスタンスを作成した際におおよそ同時に作成され、EC2インスタンスのボリュームとして使用されるものです。
料金はプロビジョニングされた容量1GBにつき0.12USDであり、例えば100GBをボリュームとして割り当てていた場合、月額12USDがコストとして掛かります。

度々EC2インスタンスを起動して利用するという場合であれば、これは受容すべきコストですが、もし長期間EC2インスタンスを停止したたま使用する予定がない、と言う場合はスナップショットやAMIを取得しておき、EBSは削除してコストを低減するという手段もあります。
スナップショットは作成時にブロックレベルで圧縮されて保管され、圧縮後の容量に応じて課金がされます。
その料金も1GBあたり0.05USDであるため、通常のEBSを残しておくよりもかなりコストを低減できます。


RDSで発生する料金

RDS、およびAuroraはインスタンスとストレージの稼働時間に応じた料金が発生します。
基本的にEC2インスタンスよりも割高となり、Auroraに関してはさらにI/Oリクエスト数に応じた料金も生じます。
とはいえ、これらはもちろん起動していなければ料金は掛からないので、ずっと停止していれば料金は掛からないはず…
と思いきや、RDS(とAurora)のデータベースインスタンス停止後、7日間経つと自動的に起動してしまうという特徴があります。
停止したからと言って安心して放っておくと、いつの間にか起動していて料金ががっつり……ということは残念ながら珍しくはありません。
不要なデータベースインスタンスはスナップショットを取得した上で削除しておくか、以下の記事でまとめているRDSの自動停止を行なうための仕組みを実装するか、何かしら対策する必要があります。

bftnagoya.hateblo.jp

またLambdaとRDSを併用するような場合、RDS Proxyを使うケースも出てくると思いますが、RDS ProxyもRDSに準じる高コストが発生しやすいサービスのひとつです。

RDS proxy

RDS Proxyは接続元となるLambdaなどのクライアントと接続先となるRDSの間に設置できるデータベースプロキシです。
例えばLambdaによって膨大な数のアクセスが同時にRDSへ行ってしまうと、同時接続数が多くなってRDSの性能が低下したり、アクセス不能になってしまうことがありますが、RDS Proxyはその接続をプーリングして上手いこと調整してくれるものになります。
Lambdaを利用したサーバーレス構成では、ほぼほぼ必須となるオプションと言えます。

そのRDS Proxyに掛かるコストですが、関連付けた(接続先の)データベースインスタンスのvCPUの数に依存します。
具体的には1vCPUあたり0.018USD/時間であり、例えば2つのvCPUを持つデータベースインスタンスに関連付けて常に稼働させていた場合、25.92USD掛かることになります。
このため関連付ける先のRDSのvCPU、つまり性能を上げていくたびにRDS Proxyの料金も増えていくということです。

RDSが停止している間はRDS Proxyの関連付けが外れるため、RDS Proxyの料金も掛かることはありませんが、課金の仕組みを把握せずにRDSの性能を上げてしまうと、思わぬ高コストに見舞われてしまいます。


さいごに

今回挙げたものは、料金見積もりから抜けてしまいやすいものでもあります。
特にRDS ProxyはAWS Pricing Calculatorに入っていないため、見積を行なう時は手計算が必要です。
たとえ検証目的であっても、思わぬコストの発生を避けるためにも、使用するサービスの料金詳細は予め把握しておいた方が良いでしょう。

というわけで、今回はここまで。 また別の記事でお会いしましょう!