この記事は？
先日、社内の業務を自動化するために、lambdaを用いてバッチを作成していました。 要件を実現するために、lambdaをVPCに設置することになったため、 その時に考えたことをこちらにアウトプットしたいと思います。
要件
大まかに、 以下の3つがバッチで実現したいことになります。
- slackのAPIを使ってデータを取得する
- 取得したデータをEC2で動くSQLserverにデータをinsertする
- 月に1回、月初に実行する
問題点
lambdaは、以下のキャプチャのように、 VPCに設置するかどうかを選ぶことができます。
作成時に設定
作成後に設定
VPC内に設置することで、VPC内のリソースにアクセスできるようになります。 したがって、今回の要件を満たすためには、 VPC内へのlambdaの設置はマストになってくると考えました。
ただ、ここで1つの問題が発生します。 VPC内にlambdaを設置する際には、private subnetを指定しなければなりません。 すなわち、VPC内に設置したlambdaは、 基本的にはインターネットへの通信を行うことができない状態になってしまします。
解決策
案1
private subnetにlambda、 public subnetにNATゲートウェイを設置する。
メリット
1つのlambdaを作成することで、要件を達成できる
デメリット
NATゲートウェイの料金がかかる
時間単位料金以外は微々たるものにしかならなさそうなので、 時間単位料金のみを計算すると、
0.062 USD / h × 24 h × 30 days = 44.64 USD
1月あたり約5500円！！！！（@2022/03/30 10:30 (GMT+9) 現在） 月に1度しか動かないバッチに対して、これはさすがに料金が高すぎます、、、
そこで発見したのが以下の方法になります。
案2
VPC外に設置したlambdaで、 slackからデータを取得し、 S3に保存する
VPC内に設置したlambdaで、 S3から取得したデータを、 EC2のSQL Serverにinsertする
メリット
NATゲートウェイが不要
デメリット
lambdaを2つと、 s3を作成する必要がある
/w=3840,quality=90,fit=scale-down)
考えたこと
- awsの各リソースが、どこに設置されるものなのかを意識することが重要だと感じた。
- private subnet内で常にインターネットと通信を行う必要がある、 すなわち、常にNATゲートウェイを立てておく必要のあるサービスの1部として、 今回のような要件を満たすlambdaを作成する場合は、 VPC lambda × NATゲートウェイの構成でも良いと思いました。
最後に
結果的にこちらの構成で、バッチを作成していくことになりました。 技術の指定は特になかったため、勉強中の以下の技術を使って実装を行いました！
- Golang
- terraform
これらの技術を使った感想や、考えたことなども、追々記事にできたらと考えています🤔