Snowflakeを用いた高頻度処理が招く高額請求をいかに回避するか

データプラットフォームや情報分析基盤においてはデータの加工と保持のためにSnowflakeを採用することが多いです。

Snowflake自体には問題はありません。ただ、15～60分ごとにSnowflakeへデータを投入することでBIツールから（ほぼ）リアルタイムなデータ閲覧を実現する……という類のサービスでSnowflakeを使うのはコスト面に問題を生じさせる恐れがあります。

当記事ではこの点について調査し、解決策を考えてみます。

Snowflakeのコスト

Snowflakeは独自の実行基盤を持つサービスではなく、AWS、Azure、GCPといったクラウドサービス上に構築されるクラウドDBサービスです。

従量課金制を採用しており、請求金額には「どのプラットフォーム上に構築したか？」「どのリージョンを使っているか？」等が請求金額に関わってきます。

以後、断りないかぎり「AWS」の「AP Northeast 1 (Tokyo)」上にSnowflakeを構築したものとして話を進めます。また、1ドルは160円として計算します。

請求対象は大きく「コンピュート料金」と「ストレージ料金」の2つで決まります。前者はややこしいので、後者から説明します。

ストレージ料金

Snowflakeでは、その月の月全体での平均ストレージ量が請求金額になります。たとえば、月初は10 TB、月半ばで15 TB、月末で20 TBとストレージ量が膨らんでいった月の場合、その月の平均ストレージ量は15 TBと見なすことができます。

請求金額はAWSのAP Northeast 1 (Tokyo)だと1月あたり、1 TBで25ドル（4,000円）です。

毎月1 TBずつデータが蓄積していき、各月のデータを3年保持しないといけない（3年を過ぎたデータはバッチ処理等で自動削除）場合、サービス開始時からの請求金額の推移は以下のようになります。　

経過年数	使用ストレージ量	当月の請求金額	これまでの請求金額合計
0.5 年稼働	6 TB	24,000 円	84,000 円
1.0 年稼働	12 TB	48,000 円	312,000 円
2.0 年稼働	24 TB	96,000 円	1,200,000 円
3.0 年稼働	36 TB	144,000 円	2,664,000 円
10.0 年稼働	36 TB	144,000 円	29,040,000 円

ストレージ料金は安いように思います。

あと、Snowflakeには「Time Travel」と「Fail-safe」というデータのバックアップ機能があります。それら機能が保持するデータもストレージ量として計算されることに注意してください。詳しくはそれら機能の仕様を見ていただきたいですが、私の経験では、これら機能のストレージ量はそんなに大きくないことが多く、ストレージ料金に大きく影響を与えるようなことはありません。

コンピュート料金は大きく3要素で構成される

コンピュート料金とはSnowflakeの計算資源の使用量に応じて請求される料金です。計算資源の使用量は、Snowflakeでは「クレジット」という単位で集計されます。その月の使用クレジット量に、クレジット単価を掛けたものが実際の請求額になります。

クレジット単価はSnowflakeを構築するプラットフォーム、リージョンに加えて、Snowflake契約時のエディションにも左右されます。

Snowflake構築プラットフォームが「AWS」で、リージョンが「AP Northeast 1 (Tokyo)」だと1クレジットあたりの単価は以下のとおりです。

エディション	1クレジットあたりの単価
STANDARD	2.85 ドル
ENTERPRISE	4.30 ドル
BUSINESS CRITICAL	5.70 ドル

クレジットが発生する機能はいくつかあるのですが私の経験では以下3つにさえ注意しておけばひとまずOKです。

• ウェアハウスの起動時間
• Snowpipeで取り込んだデータ量
• Cloud Services Computeの処理量

Snowpipeとはイベントを検知するとデータの取り込みを行う機能です。取り込んだデータ量1 GBあたり0.0037クレジットが発生します。これはSnowflakeを構築したリージョンなどには左右されず固定です。

Cloud Services Computeは認証、メタデータの管理、アクセス制御、SQLクエリのコンパイルや最適化といったSnowflakeの基盤側の処理です。事前に見積もることは不可能であり、実際にサービスを動かすか、本番に近い環境を作って動かして計測することでしかクレジット発生量を見積もれません。体感では「1日あたり、その日のウェアハウス起動時間によって生じたクレジット量の10～25 %」くらいになります。あと、各日のCloud Services Computeのクレジット発生量のうち、その日のウェアハウス起動時間のクレジット発生量の10%までは請求対象外になります。

そして、コンピュート料金の大部分を占めるのがウェアハウスの起動時間によって生じるクレジットです。コンピュート料金を見積もるときはここが一番重要であり、Snowflakeが高頻度処理と相性が悪い主な理由でもあります。

ウェアハウスの起動時間に対する請求

ウェアハウスとはSQLクエリを動かすときのマシンパワーをDBオブジェクトとして定義したようなものです。例えば、日常使いであれば低性能だが安価なウェアハウスを使い、短い時間で処理を完了させなければならない場合は高価だが高性能なウェアハウスを指定する……といったことができます。

SnowflakeではSQLクエリを実行するときはウェアハウスを必ず指定する必要があります。ストアドプロシージャーとして実装しなければならないような複雑な処理から、単純なSELECT文に至るまで、いずれにおいてもウェアハウスは必ず指定しなければなりません。

ウェアハウスは停止状態と起動状態の2つの状態を持ち、起動状態でないとSQLクエリを受け付けません。ウェアハウスの起動・停止は手動で行えるほか「停止状態でSQLクエリが来た場合は自動起動する設定」や「最後にSQLクエリを処理してから○○秒経過すると自動停止する設定」といったものもあるので、上手く設定して起動時間を抑えることがコスト削減において重要になります。

実際に試算してみます。

Snowflakeの標準的なウェアハウス「Standard Warehouse Gen 2」の各サイズにおける1時間あたりのクレジット量は以下のとおりです。「サイズ」というのはマシンパワーのことであり、XSが最も低性能、4XLが最も高性能です。

サイズ	1時間あたりのクレジット量
XS	1.35
S	2.70
M	5.40
L	10.80
XL	21.60
2XL	43.20
3XL	86.40
4XL	172.80

上記のとおり、サイズを1つ上げるごとにクレジット発生量は倍になり、ひいては請求金額も倍になります。ただし、性能も倍になっているかは明らかではありません。

XSサイズのウェアハウス1つを常時起動していると、1日あたりのクレジット発生量は 24 * 1.35 = 32.4 クレジット、1月あたりは 32.4 * 365 / 12 = 985.5 クレジットになります。

985.5クレジットの各エディションごとの1月あたりの請求金額は以下のとおりです。

エディション	1月あたりの請求金額
STANDARD	449,388 円
ENTERPRISE	678,024 円
BUSINESS CRITICAL	898,776 円

ストレージ料金に比べて、ウェアハウスの使用料金は高額であることがわかります。しかも、最小サイズであるXSでこの金額です。

ちなみに、BUSINESS CRITICALエディションで契約し、最上位サイズである4XLのウェアハウスを常時起動させた場合、1月あたりのクレジット発生量は126,144クレジット、請求金額は115,043,328円――およそ1億1,500万円となります。

Snowflakeのコスト試算から見えてくるもの

先の計算によって、Snowflakeはストレージ料金が安く、コンピュート料金が高い（正確にはウェアハウス起動時間料金が高い）サービスであると言えます。いちおうフォローしておくと、ウェアハウスは常時起動を想定したものではなく、必要なときだけ起動することが推奨されるので、常時起動しておくのは現実的ではありません。

しかし、だからこそ、Snowflakeは高頻度で動く処理とはコスト面で相性が悪いと言えます。

ウェアハウスの起動・停止と請求の仕組み

ウェアハウスの状態は一時停止状態・起動状態に分かれ、最後にSQLクエリを処理した時点から、ある程度時間が経つと一時停止することでウェアハウス起動時間を抑える仕組みになっています。一時停止するまでの時間は秒単位で決めることができます。

であれば、自動停止までの時間を「1秒」にすればコストを最小――実際にウェアハウスを動かしている時間とほぼ同じ時間にまで抑えられそうですが、実際にはそうはなりません。

第1に、ウェアハウスの一時停止タイミングは、原則として、ウェアハウスが起動してから30秒ごとに訪れます。よって、起動してから5秒でSQLクエリ処理が終わったウェアハウスは次の一時停止タイミングである30秒までの25秒間は起動し続ける可能性があります。もしかするとSQLクエリ処理が終わってから1秒後に自動停止するかもしれませんが30秒間隔以外での停止をSnowflakeは保証していません。

第2に、ウェアハウスが一度起動すると必ず60秒ぶん起動したものとみなされます。たとえば、起動してから30秒で停止するように設定したウェアハウスを1回起動するごとに一時停止させるかたちで時間を空けて5回動かした場合、使用者は 30 * 5 = 150 秒動かしたものと認識しているでしょうが、実際には 60 * 5 = 300 秒動かしたことになります。

クラスター

クラスターについても触れておきます。

ウェアハウスには「クラスター」という概念があります。ウェアハウスは処理を行う単位ですが、実際にはウェアハウス内のクラスターが処理しているとみなすことができます。ちょうどCPUに対するコアのような関係です。ウェアハウスがCPU、クラスターがコアです。

そのような関係なのでクラスターが0のウェアハウスはありません。必ず1つはクラスターを指定する必要があります。

ウェアハウスの起動時間はウェアハウスというよりクラスター数に掛かっており、クラスター3つのウェアハウスを動かした場合、そのウェアハウスが3つぶん起動していたものとしてクレジットが発生するので注意が必要です。

複数のクラスターを立ち上げてクエリ待ちが生じないようにしたいが、かといって常に複数のクラスターが必要なわけではなく、クレジットを抑えたいという人向けに、負荷に応じてクラスター数を調整する設定もあります。

最短起動で高頻度起動するといくらかかるのか？

最短起動時間である60秒を1回あたりの起動時間とし、Snowflakeで高頻度処理をさせたらどのような請求金額になるかを考えます。

前提は以下のとおりです。クラスターとはウェアハウスの起動数であり、以下前提でクラスター数を3つにすればXSサイズのウェアハウスが3つ起動します。クラスター数が増えても処理性能自体に変化はありませんが、同時に処理できるデータ量が増えます。

• Snowflake環境はAWSのAP Northeast 1 (Tokyo)
• STANDARDエディションで契約
• Standard Warehouse Gen 2のXSサイズを使用
• クラスターは1つ

請求金額は以下のとおりです。

処理間隔	1月あたりのウェアハウス起動時間	請求金額
1 分	730 時間	449,388 円
2 分	365 時間	224,694 円
3 分	243 時間	149,796 円
4 分	183 時間	112.347 円
5 分	146 時間	89,878 円
10 分	73 時間	44,939 円
15 分	49 時間	29,959 円
30 分	24 時間	14,980 円
60 分	12 時間	7,490 円

やっぱりストレージ料金に比べて高いです。

加えて、以下のとおり、この前提はかなり甘く作っていますので実際にはもっと高額請求になる可能性が大きいです。

• 商用システムでSTANDARDエディションが選ばれている案件を見たことがない（最低でも1つ上のENTERPRISEエディション）
• 処理が必ず60秒で終わるのは現実的ではない
• クラスター1つで計算している前提であり、システム負荷増大に伴ってクラスターが増す設定ならば請求金額が増す

少しだけ前提を引き上げて、より現実的な金額を求めてみます。

• Snowflake環境はAWSのAP Northeast 1 (Tokyo)
• ENTERPRISEエディションで契約
• Standard Warehouse Gen 2のSサイズを使用
• 1回の処理が3分かかるとする

処理間隔	1月あたりのウェアハウス起動時間	請求金額
3 分	730 時間	1,356,048 円
4 分	548 時間	1,017,036 円
5 分	438 時間	813,629 円
10 分	219 時間	406,814 円
15 分	146 時間	271,210 円
30 分	73 時間	135,605 円
60 分	37 時間	67,802 円

ちょっと実行条件を上げただけで金額が跳ね上がりましたね。

Snowflakeでデータ加工をするのがそもそも間違いでは？

ここから見えてくるのはSnowflakeでデータ加工をすること自体があまり良いアーキテクチャーとは言えないということです。パフォーマンス的には問題ないのでしょうがコストが重いです。

SnowflakeはBIツールなどから参照される「完成済みデータ」の置き場として使い、ウェアハウスは完成済データ投入処理と外部からの参照処理時のみ動くようにするのがコスパ良いです。

では、データ加工はどうすればよいのかといえば、別のサービスを頼ることになります。それらで完成済データを作ってSnowpipeで取り込むのがおススメです。Snowpipeでデータを取り込むと1 GBあたり0.0037クレジットで済むからです。

STANDARDエディションにおけるSnowpipe請求金額目安は以下のとおりです。

取り込むデータ量	クレジット発生量	請求金額
0.1 TB	0.37	169 円
1.0 TB	3.70	1,687 円
10.0 TB	37.00	16,872 円

Snowpipeを使わずともウェアハウスでCOPY文を実行して取り込むといったアプローチも考えられます。しかし、先の請求金額から逆算するかたちでウェアハウスの起動時間を求めると、たぶん、ほとんどのシステムにおいてはSnowpipeを使って取り込むほうが安いです。

Snowpipe請求金額ぶんの、Standard Warehouse Gen 2のXSサイズの起動時間は以下のとおりです。

取り込むデータ量	Snowpipeの請求金額	ウェアハウスの起動時間
0.1 TB	169 円	0.3 時間
1.0 TB	1,687 円	2.7 時間
10.0 TB	16,872 円	27.41 時間

データの取得と加工をどうするか

ここまでの試算からSnowflakeはデータ保管に特化するのが良いとわかります。

BIツールからSnowflakeのデータを見るとき、テーブルとの間にビューを挟むことが多いですがウェアハウス起動時間を抑えたいならば可能なかぎりビューを挟むのはやめておくべきで、BIツールからテーブルを直接参照するかたちが好ましいです。

とはいえ、テーブルとBIツールの間にビューを挟む構成は色々便利なので、ビューのなかで、あまりにもややこしい結合などをしていないのであれば徹底して排するようなことは不要と考えます。

さて、Snowflakeをデータ置き場とするならば、データの取得や加工はどうするかが問題となります。Snowflakeでデータの加工等を行わないのであれば別サービスに任せる必要があります。

候補となるサービスがないか調べてみます。1ドルは160円とします。AWS関連サービスの場合、リージョンは「アジアパシフィック (東京)」とします。

AWS Lambda

AWS LambdaはJavaScriptやPythonなどのプログラミング言語で実装されたスクリプトを保存・実行できるサービスです。ここにDBやファイルやAPIからデータを取得して、加工して、S3などへCSVファイルとして出力するスクリプトを「Lambda関数」として定義しておいて、EventBrdigeなどから定期実行させれば期待する処理が実現できます。

Lambdaの料金は「Lambda関数の呼び出し回数」と「メモリ使用量」の2点で計算される従量課金制です。

Lambda関数の呼び出し回数は100万回あたり0.2ドル――32円です。また、1月あたり、Lambda関数群への呼び出し回数合計が100万回までは無料となります。1つのLambda関数あたり100万回まで無料ではなく、Lambda関数全てを対象として100万回まで無料です。

こう聞くとLambda関数の数は少なくして1つのLambda関数を長く使うのがお得に思えますが、Lambda関数は処理開始してから15分経つと強制終了するので、軽い処理を1つのLambda関数に与えるのが基本となります。データプラットフォームでいえば、BIツールのダッシュボードごとに1つのLambda関数を用意するのが良いでしょう。

いくつのLambda関数があるかと、どれくらいの間隔で呼び出すかをもとに1月あたりのコストを試算してみた結果が以下です。1分ごとに実行するものとしましたがめちゃくちゃ安いので呼び出し回数は無視して良さそうです。

Lambda関数の数	リクエスト総回数	料金
100 個	4,380,000 回	108 円
500 個	21,900,000 回	669 円
1,000 個	43,800,000 回	1,370 円

もう1つの課金対象であるメモリ使用量ですが、こちらは仕様やコスト試算方法がちょっと複雑です。

Lambdaがスクリプトを動かすためにはCPUとメモリが必要なわけですが、CPUとメモリは全Lambda関数で固定ではなく、設定によって調整することができます。ただし、CPUとメモリを個別に設定することはできず、メモリのみを設定できます。そして、設定されたメモリ量に応じてCPU性能が上下します。メモリを増やすほどCPUも強力になります。AWSのドキュメントによれば「1,769 MiBで1 vCPU」「10,240 MiBで 6 vCPU」ということらしいのでCPU性能とメモリ量は綺麗な比例関係にあるようです。

請求においてはLambda関数が使ったメモリ量と時間に応じて課金が発生します。例えば、0.1 GiB設定のLambda関数を10秒動かすと1.0 GiBぶん使ったことになります。そして、Lambda関数群全てのメモリ使用総量が1月あたり60億GiBまでは、1 GBあたり0.0000166667ドルの請求となります。

なお、ありがたいことに1月あたり40万GiBまでは無料となります。

では、Lambda関数が1,000個あるとして、それらがどれくらい動くかでコストを試算してみましょう。Lambda関数1つあたりの料金ではなく、1,000個全部含めての試算です。

まずは5分間隔で実行するという超高頻度な間隔です。試算する前から予想はできていましたが高いですね。ただ、5分間隔でないとダメなケースってそうないと思います。

メモリ量	実行時間	料金
0.1 GiB	0.5 分	69,013 円
0.1 GiB	1.0 分	139,094 円
0.1 GiB	2.0 分	279,254 円
0.1 GiB	3.0 分	419,414 円
0.5 GiB	0.5 分	349,334 円
0.5 GiB	1.0 分	699,735 円
0.5 GiB	2.0 分	1,400,536 円
0.5 GiB	3.0 分	2,101,338 円
1.0 GiB	0.5 分	699,735 円
1.0 GiB	1.0 分	1,400,536 円
1.0 GiB	2.0 分	2,802,139 円
1.0 GiB	3.0 分	4,203,742 円

次は15分間隔です。これでも結構頻度は高いですが現実的なラインに入ってきました。

メモリ量	実行時間	料金
0.1 GiB	1 分	45,653 円
0.1 GiB	2 分	92,653 円
0.1 GiB	3 分	139,094 円
0.1 GiB	5 分	232,534 円
0.1 GiB	10 分	455,134 円
0.5 GiB	1 分	232,534 円
0.5 GiB	2 分	466,134 円
0.5 GiB	3 分	699,735 円
0.5 GiB	5 分	1,166,936 円
0.5 GiB	10 分	2,334,938 円
1.0 GiB	1 分	466,134 円
1.0 GiB	2 分	933,335 円
1.0 GiB	3 分	1,400,536 円
1.0 GiB	5 分	2,334,938 円
1.0 GiB	10 分	4,670,943 円

次は60分間隔です。個人的には「リアルタイムでデータを更新したい」と言われたら1時間ごとの更新間隔とするのが実用的、かつコストも抑えられて良いと思います。

メモリ量	実行時間	料金
0.1 GiB	1 分	10,613 円
0.1 GiB	2 分	22,293 円
0.1 GiB	3 分	33,973 円
0.1 GiB	5 分	57,333 円
0.1 GiB	10 分	115,734 円
0.5 GiB	1 分	57,333 円
0.5 GiB	2 分	115,734 円
0.5 GiB	3 分	174,134 円
0.5 GiB	5 分	290,934 円
0.5 GiB	10 分	582,934 円
1.0 GiB	1 分	115,734 円
1.0 GiB	2 分	232,534 円
1.0 GiB	3 分	349,334 円
1.0 GiB	5 分	582,934 円
1.0 GiB	10 分	1,166,936 円

AWS Glue

AWS GlueはLambdaに似ていますが15分上限という仕組みが無くなり、よりガッツリとしたETL処理をするためのサービスという感じです……というよりAWS GlueこそETLするためのサービスであり、Lambdaは軽量な処理をするためのサービスで、軽量なETL処理ならば任せても良いという感じでしょうか。

GlueはDPUという単位でCPUとメモリを設定してジョブを作成し、ジョブの動いているDPUあたりの時間に対して課金が発生します。1 DPUは4 vCPU・メモリ16 GBに相当し、1 DPUか0.625 DPU（0.25 vCPU・1 GB）のどちらかを選べます。もうちょっと間を刻んで欲しいのですが、現仕様では両極端なこの2つしか選べません。

処理時間は1秒単位で集計され、1回の起動あたり最低でも60秒起動したものとして扱われます。

無料枠はありません。

Glueにはいくつかの実行形式があるのですが、基本的にはGlue Python Shellを選ぶことになるかと思います。名前からもわかるようにPythonでジョブというETL処理単位を作って、スケジューリングして動かします。スケジューリングはGlue内でジョブごとに定義できます。

1 DPUで1時間動かすと0.44ドル請求され、これが請求単位となります。

ここまでの情報をふまえて資産をしてみます。15分制限のあるLambdaと違い、Glueは細かく分ける必要ないのでジョブ数は300個とします。

5分間隔で実行する場合は以下のとおりです。やっぱり5分間隔だと高いですね。

DPU	処理時間	料金
0.0625 DPU	1 分	192,720 円
0.0625 DPU	2 分	385,440 円
0.0625 DPU	3 分	578,160 円
1.0000 DPU	1 分	3,083,520 円
1.0000 DPU	2 分	6,167,040 円
1.0000 DPU	3 分	9,250,560 円

15分間隔で実行する場合は以下のとおりです。

DPU	処理時間	料金
0.0625 DPU	3 分	192,720 円
0.0625 DPU	6 分	385,440 円
0.0625 DPU	9 分	578,160 円
0.0625 DPU	12 分	770,880 円
1.0000 DPU	3 分	3,083,520 円
1.0000 DPU	6 分	6,167,040 円
1.0000 DPU	9 分	9,250,560 円
1.0000 DPU	12 分	12,334,080 円

60分間隔で実行する場合は以下のとおりです。

DPU	処理時間	料金
0.0625 DPU	5 分	80,300 円
0.0625 DPU	10 分	160,600 円
0.0625 DPU	15 分	240,900 円
0.0625 DPU	30 分	481,800 円
0.0625 DPU	45 分	722,700 円
1.0000 DPU	5 分	1,284,800 円
1.0000 DPU	10 分	2,569,600 円
1.0000 DPU	15 分	3,854,400 円
1.0000 DPU	30 分	7,708,800 円
1.0000 DPU	45 分	11,563,200 円

Lambdaと比較してみたところ、Glueのほうが少し割高な感じがします。ただ、そのぶん15分上限がないのがウリというところでしょうか。

EC2

EC2は仮想環境を提供するサービスであり、1つの仮想環境を「インスタンス」と呼びます。

インスタンスは「インスタンスタイプ」といういくつかの種類から1つを選んで作成することとなり、選んだインスタンスタイプによって、OSやCPUやメモリが変化します。ストレージはインスタンスタイプには含まれず、Amazon EBSという別サービスでストレージを用意し、それをインスタンスと紐づける仕組みになっています。

請求対象は「インスタンスの起動時間」「ストレージの契約時間」の2点です。他にもデータ転送量とかも対象になりますが脇に置いておきます。

インスタンスは作成したら起動しっぱなしではなく停止させることができます。そして、インスタンスが起動している時間に応じて請求が発生します。請求金額はインスタンスタイプによって異なり、高性能なインスタンスタイプであれば高額な請求となります。あと、インスタンス自体についても、いろいろと種類がありますが、基本的にはオンデマンドインスタンスを選ぶことになるでしょうから、以後もこの認識で話を進めます。

ストレージは作成したらその瞬間から請求が発生し、インスタンスと異なり停止という概念がありません。ストレージの請求を止めたいならばストレージを削除するしかなく、ストレージを削除すればストレージに入っているデータは全て消えます。

他にもロードバランサー・NATゲートウェイ・Elastic IP等々、いろいろと周辺サービスの契約も必要になります。よって、EC2の金額だけを調べても本当は不十分なのですが、いったんEC2の料金を見てみることにします。

EC2で、外部からデータを抽出し、加工し、S3へCSVファイルとして出力するETLシステムを常駐させる案を考えてみます。S3へ上げたCSVファイルはSnowpipeで取り込むものとします。

OSはLinuxとします。インスタンスタイプは、かなり色々な種類があるのですが、本番用インスタンスタイプとして候補になるもののうち、再安価なのは「m8i.large」でしょうから、これを選びます。

m8i.largeは1時間あたり0.13671ドルです。ETLシステムを24時間365日立ち上げておくばあい、1月あたりの請求額は 0.13671 * 24 * 365 / 12 * 160 = 15,967.728 円です。

ストレージは「gp3」という最もスタンダードなものを選びます。gp3は1 GBあたり、1月0.096ドルの請求となります。仮に100 GB確保するばあい、1月あたりの請求額は 0.096 * 100 * 160 = 1,536 円です。こちらは安いですね。

ここまでを合わせると1月あたり、最低でも20,000円くらいと考えるのが良いのではないでしょうか？

ついでにElastic IPによる固定IPv4アドレス契約金額と、NATゲートウェイ利用金額についてもざっくりと試算します。

• Elastic IPによる固定IPv4アドレス契約金額: 0.005 * 24 * 365 / 12 * 160 = 584 円
• NATゲートウェイ利用金額: 0.062 * 24 * 365 / 12 * 160 = 7,241.6 円

やはり最低でも月2万円というところでしょうか。だいぶ甘い試算かもしれませんが、安く組むのであればEC2は有力候補になりますね。

ただ、EC2で実現するならば前述のとおり、いろいろと周辺サービスの設定も必要ですのでサーバーレスとはなりません。トラブルが起きたときの対応のために、運用経験のある人が保守チーム、ないしエスカレーション先にいる必要があるでしょう。

まとめ

以上をまとめると、ランニングコストを抑えるためだけならば、まずはEC2で何とかできないか考えたいですね。次いでLambda。Lambdaで処理しようとすると15分以内に収まらなさそうだったらGlueという感じでしょうか。

このあたりは構築するデータプラットフォームの要件次第でいくらでも変わってくると思いますので、机上で計算してもどうしようもない気がします。とはいえ、一度洗い出してみたかったので今回の結果でいったん満足です。