Lambda vs Glue Python Shell

Lambda vs Glue Python Shell

Glue Python Shellは闇深き環境を生きるITエンジニアに差し込む一筋の光

Lambdaを選ぶべきか、Glue Python Shellを選ぶべきかの選択を迫られたので備忘録として残す。GlueにはSpark環境ではない、Pythonを動かすことができる環境が存在する。
https://docs.aws.amazon.com/glue/latest/dg/add-job-python.html

AWSで小さいファイルの転送したり、外部APIを叩いたり、小さいデータをDBへINSERTするなど、ちょっとした処理をPythonでサクッと実装するとき、第一候補として上がるのはLambdaだろうが、Glue Python Shellも似たようなことができる。

前提

本記事では下記のようなユースケースを想定して比較する。

• 長くても1分程度で終わるような処理である。
• CPUのアーキテクチャは問わない
• メモリは1GBもあれば足りる
• 1ヶ月で3000回ほど実行する
• 外部ライブラリ(PandasやGlue環境にインストールされていないライブラリ)を使用する
• VPCの内部に配置し、NATを通じて外部とやりとりする
• Terraformでインフラコードを管理している

LambdaとGlue Python Shellの比較

項目	Lambda	Glue Python Shell
実行環境	エフェメラル（使い捨て）	エフェメラル（使い捨て）
実行時間制限	最大15分	長時間対応可(デフォルトで48時間)
CPUアーキテクチャ	x86_64 または arm64	x86_64
言語	Pythonほか複数対応	Pythonのみ
使用可能Pythonバージョン	3.9 ~ 3.13	3.9(3.6も可だが非推奨)
ライブラリ	デフォルトなし。レイヤーやzipに同梱	一部標準でインストール済み。ジョブ実行直前に追加インストール可能
ライブラリ管理方法	レイヤーまたはソースに同梱	ジョブ設定でPyPIからインストール
環境変数	利用可能	利用不可（ジョブパラメータで代用）
デプロイ方法（Terraform）	zipをアップロードしてデプロイ	S3にソースをアップロードし、Glueの設定でパス指定
VPC配置	可能（NAT経由で外部アクセス）	可能（NAT経由で外部アクセス）
タスク制御	StepFunctionsを使用	Glue WorkflowsまたはStepFunctionsを使用

※ 記事作成時点(2025年8月)のものである。

コストはほぼ変わらない。Lambdaの無料使用回数がない前提だとGlue Python Shellの方が月5ドルくらい高い。Glueは1分あたりの課金となるため高くなりがちだが、DPU(処理単位)を0.0625の最低に設定すれば、価格に大きな差は生じない。

一点注意すべきは、Glueでは外部ライブラリをインストールする時間も実行時間に含まれる点である。ライブラリのインストールに時間がかかる場合にはよりお金がかかるため、重いライブラリをインストールする場合は気をつけるべきである。

結論

似たようなことができるが、下記の条件で使いわけるべきだろう。

• Lambdaを選ぶべきケース

  • 新しめのPythonバージョン、ARMアーキテクチャを使いたい
  • コストを少しでも抑えたい
  • 15分以内に終わらない場合は異常とみなし、ハンドリングする

• Glue Python Shellを選ぶべきケース

  • Glue Workflowsとの統合が必要
  • 処理時間が15分以上になりうる

あとがき

そもそもなのだが、15分以上時間がかかるちょっとしたタスクってなんだろう？それって本当にちょっとしたタスクなのだろうか？重めのデータ処理が必要ならGlueのSparkやRay環境を使うべきだろうし、大量データ転送ならばAWS DataSyncとかSnowballとか別のサービスがある。

Glue Workflowsがない場合にGlue Python Shellを使うべきケースがあるとするなら、不安定すぎて15分以上レスポンスが返ってこないことがしばしばある外部サーバにリクエストを投げる場合だろう。そういう外部サーバはきっとレスポンスを返す承認を得るためにハンコリレーをしていて、部長がハンコを押すのを渋っているに違いない。

そんな闇と対峙するエンジニアに差し込む一筋の光、それがGlue Python Shellなのかもしれない。