Lambda関連のことを調べてみた

Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる


コンテナを**リクエスト処理時間ベースの料金体系**で実行できるサーバレス環境としては、Google の Cloud Run（[2019年11月GA](https://cloud.google.com/run/docs/release-notes#November_14_2019)）と AWS Lambda（[2020年12月にコンテナに対応](https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/)）が特に有名でしょう。

これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」と

mockito.MockedStatic を使うときの書き分け ２つ

# はじめに

`mockedStatic` あんまり使ったことがなく、『エラーが何で起きてるか分からん！』と質問されたときに即答できなかったのが悔しかったので備忘。

# もくじ

– [mockito.MockedStatic の書き方２つ](#mockitomockedstatic-の書き方２つ)
– [サンプルコード](#サンプルコード)
– [メソッド参照を使う場合](#メソッド参照を使う場合)
– [ラムダ式を使う場合](#ラムダ式を使う場合)
– [使い分け](#使い分け)
– [参考](#参考)

# 実行環境

– Java8 以降
– JUnit5
– Mockito 4.11.0

“`gradle:build.gradle
dependencies {
testImplementation(‘org.mockito:mockito-core:4.11.0’)
testImplementation(‘org.mockito:mockito-inline:4.11.0’) // 3.4.0以降でないと使えない
}
“`

※ `mo

AWS SAP対策#3 LambdaからAuroraへの接続をより効率よく行う

AWS SAP試験対策 #3

# 問題(ざっくり)
あるWebアプリケーションは、Lambda関数でAurora MySQLデータベースをクエリします。データベースは複数のリードレプリカで構成されています。アクセスが集中する期間では、アプリケーションのパフォーマンスが低下します。アプリケーションが多くのデータベース接続を行うために遅延が発生している模様です。パフォーマンスを向上させるにはどうすればいいですか？

① ゲートウェイロードバランサーを作成して、Auroraリードレプリカ間で接続を分散する。
② Auroraサーバーレスデータベースクラスターで自動スケーリングを使用する。
③ RDS Proxy接続プールをAuroraデータベースのクラスターエンドポイントに接続する。
④ データベース接続を開くためのLambda関数コードをイベントハンドラーの外に置く。

\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*
\*

# 回答
**④ データベース接続を開くためのLambda関数コードをイベントハンドラーの外に置く

S3 Object Lambdaを利用したOn-Demandイメージ変換サービスの紹介

こんにちは。ムシンサ・コミュニティ開発チームのバックエンドエンジニア、チョ・ユシンです。 今回はAWS S3 Object Lambdaを利用してオンデマンドイメージ変換サービスを構築した事例を共有したいと思います。

### イメージ変換サービスとは？
一般的にサーバーでイメージを提供するためには、オリジナルイメージよりも小さいサイズのイメージを提供する方がサーバーのリソースおよびトラフィックコストを節約できます。最近ではスマートフォンの発展により、スマートフォンのカメライメージのサイズが基本的に10MB前後で保存されるため、100枚のイメージを提供するだけで1Gbpsのネットワーク帯域を占有してしまいます。また、イメージサイズが大きい場合、クライアント側でもイメージをレンダリングするのに時間がかかり、ユーザーエクスペリエンスにも悪影響を与える可能性があります。

従来のイメージ変換および提供方法は、AWSチュートリアルにも記載されているように、S3の保存イベントを通じてリサイズされたイメージを保存し提供する方式です。変換されたイメージがオリジナルイメージと同様にストレージに保存され

コンテナイメージからLambda関数をデプロイする

## はじめに
コンテナイメージからLambda関数のデプロイにトライ。
（コンテナイメージからのデプロイ自体は2020年のアップデート）

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-image.html

## コンテナイメージからLambdaをデプロイする
コンテナイメージからLambda関数をデプロイすることでデプロイ可能なMaxのサイズが10GBになる。当時のre:Inventの動画を見ても機械学習などパッケージが大きいケースでもLambdaを使いやすく、というのが念頭に置かれている印象。

2020年の記事

https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/

zipファイルアーカイブからLambda関数をデプロイする方法では、解凍後のzipファイルのサイズが250MBまでに制限される

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/g

【AWS×Webアプリ】CloudFrontのキャッシュ削除（Terraform）

## 目的
・AWS上の静的Webサイトホスティングを有効にしたS3をCloudFrontで公開。
・S3のコンテンツを更新した際に、CloudFrontのキャッシュ削除を行うLambdaを実装。

## 前提条件
・Terraformを使用してAWS上にリソースを作成する。
・Pythonを使用してLambdaを実装する。
・作成する内容は以下と同様

https://qiita.com/Haruki-N/items/f9e8fb32fd20285b57ad

## TFファイル
“`aws_s3.tf（前回からの追加箇所のみ抜粋）
resource “aws_s3_bucket_notification” “WebBucket_notification” {
bucket = aws_s3_bucket.WebBucket.id

lambda_function {
lambda_function_arn = aws_lambda_function.DeleteCache.arn
events = [“s3:ObjectCreat

ECSタスクをスケジュール管理してコスト削減する方法

サービスのデプロイ先をLambdaからECS on Fargateに変更するにあたり、本番環境以外にかかるコストをできるだけ削減しようと、いろいろ試みてきました。
– vCPUとメモリを最小構成(0.25 vCPU, 0.5 GB)にする
– Fargate Spotを使用する

ECS側の設定で工夫できるのはこれくらいだったのですが、1時間あたりのvCPUとメモリ単位でコストがかかる料金体系ということで、LambdaとEventBridgeで業務時間外だけECSタスクを停止するような仕組みをつくりました。

Lambda関数のコードやEventBridgeのTerraform設定などをそのまま記載するので、コピペしてコスト削減に活用していただければ幸いです。

https://aws.amazon.com/jp/fargate/pricing/

# Lambda関数
EventBridgeとの組み合わせでスケジュール実行できるため、ECSタスクの停止と起動処理の実行環境にはLambdaを選びました。

単一責任の原則(Single responsibility principle)

CloudFormationでlambdaのソースコードを更新する方法

# 背景
CloudFormation(以降、cfnと記載)を使用して、lambdaソースコードの更新を行いたい時があると思います。
cfnでは、テンプレートファイルに変更があれば更新してくれますが、lambdaのソースコードをS3にアップロードしている場合、lambdaのS3BuketやS3Keyは変化しないので、テンプレートファイルには変更が起きず、結果的にcfnでの更新ができません。
“`
Resources:
layer:
Type: AWS::Lambda::LayerVersion
Properties:
Description: ‘pacakge deploy test layer’
LayerName: ‘PacakgeDeployTestLambdaLayer’
Content:
S3Bucket: Hoge
S3Key: Layer.zip // Layerの内容を更新してもここの値は一定

Lambda:
Type: AWS::Lambda::Fu

[Lambda]Pythonライブラリをアップロードする

## まとめ

“`bash
mkdir hoge
cd hode
pip3 install ライブラリ名 -t .
“`

## 経緯

– Slackに記事のURLが投稿された時、その記事の要約をPerplexity APIを使用して投稿したい
– AWS Lambdaに置くか
– pythonのライブラリ必要やん！
– ほな入れよか

“`zsh
pip3 install requests /rss_summary

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
xyz, where xyz is the package you are trying to
install.

If you wish to install a Python library that isn’t in Homebr

python-lambda-local を使って AWS Lambda 関数をローカル環境で実行する

# はじめに
Lambdaのプログラムをテストする際、毎回 Lambda 関数を更新して実行するのは面倒ではないですか？
そこで良い方法ないかなと調べていたところ、 **python-lambda-local** というツールを知りました。

https://github.com/HDE/python-lambda-local

# 仕様
Python 3.7+
今回試した環境のバージョンは 3.9.6 でした。
“`bash:バージョン
$ python3 –version
Python 3.9.6
“`

# インストール
pip でインストールすれば完了です。

“`bash:インストール
$ pip install python-lambda-local
“`

# オプション
使い方とオプションは以下になります。

“`bash:使い方
$ python-lambda-local [-h] [-l LIBRARY_PATH] [-f HANDLER_FUNCTION]
[-t TIMEOUT] [-a ARN_ST

MacでLambdaレイヤーARMアーキを作成

# はじめに
　***arm64でLambda関数をデプロイせざるを得ないケースで、Layerを追加したい場合向け。*** imageデプロイを使えばどうとでもなるのだが、それは根本解決にはならない。前に一度やったのだが、やり方を失念してしまったため、備忘として記録する。
Cloud9やEC2を使ってLayerを作成する方法もあるが、***AWSが提供するdocker imageを使えばローカル環境であらゆるLayerを作成できるし、インタラクティブにやりたい***ので、本記事ではその方法について記述する。

# 環境
– 言語: python3.12
– OS: macOS Sonoma14.5
– RAM: 64GB
– Docker: 25.0.3

# 手順
この[Docs](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-layers.html#python-layer-compatibility)で推奨されている通り、Amazon Linuxベースコンテナイメージに基づくDocker環境に依存関係をイン

CDK×Lambda×golang×Dynamoでアプリを作ってみる DynamoDB処理のLambda実装編PUT&DELETE（第五回）

さて、今回は更新と削除のメソッドを作成していきたいと思います！
とは言っても構造体などはgetItemやputItemに似ているので非常に分かりやすかったです。

とりあえず全体像は以下の通りになります。
“`
package main

import (
“encoding/json”
“net/http”

“github.com/aws/aws-lambda-go/events”
“github.com/aws/aws-lambda-go/lambda”
“github.com/aws/aws-sdk-go/aws”
“github.com/aws/aws-sdk-go/aws/session”
“github.com/aws/aws-sdk-go/service/dynamodb”
“github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute”
)

var (
tableName = “MyDynamoDB”
dynamoDb = dynamodb.New(session.Must(sess

【Python】Lambda Layerの作成方法

# Lambda Layerを作成したいがめんどくさい
Lambda LayerはAWS Lambdaに標準で用意されていないライブラリや自分で作成した関数などを取り込む際に利用します。
一見zipファイルを作成してアップロードするだけなんですが、いくつか落とし穴があります
– Amazon Linuxで作成する必要がある（場合がある）
– LambdaはAmazonLinuxで動いている
– macOSなどでインストールしたものがAmazonLinuxで動かない場合があるため
– 求められるディレクトリ構造が実はある
– apiでのzipアップロードはファイルサイズの制限がある

などなどで躓いたのでやり方をまとめておきます

## AmazonLinuxでのpython実行環境の用意
構築方法は別記事にまとめました。ローカル環境（macOSやWindows）でインストールしたライブラリをアップロードすると、動くときもありますが動かないときもあります。仮に動いたとしても、基本的にはAmazonLinuxで作成するほうが良いでしょう。
pythonはLambdaで使用す

【Lambda】Parameter Storeの値を取得する処理を共通化する

## まとめ

処理をmjsファイルに記述してレイヤー登録する

—

例として、supabaseを使用するためのパラメータを登録・取得してみます
lambdaからsupabaseをいじいじする記事は[こちら](https://qiita.com/akitika/items/3ef5aeb279ac5e9fc97d)

## 1. ファイルの用意

“`bash
touch getParameters.mjs
“`

## 2. 処理をmjsファイルに記述

以下のように記述してみます

“`js:getParameters.mjs
import { SSMClient, GetParameterCommand } from “@aws-sdk/client-ssm”;

const client = new SSMClient({ region: “ap-northeast-1” });

export async function getParameter(name) {
const params = {
Name: name,
WithDecrypt

【Lambda】Supabaseに接続する

## まとめ

zip化したnodejsをレイヤーとして使う

## 1. Node.jsランタイムを使用する

当初はpythonを使用するつもりだったのですが、pythonでsupabaseライブラリを使うのが結構面倒だったので、nodeを使用しました

## 2. レイヤーとして使用するnodejsを用意 -> デプロイ

“`bash
# nodejsディレクトリを作成
mkdir nodejs
cd nodejs

# supabaseライブラリをインストール
npm init
npm install supabase

# zip化
cd ../
zip -r hogehoge.zip nodejs
“`

:::note alert

注意1: 作成するディレクトリ名は必ず**nodejs**という名前にすること

注意2: ファイルではなく**nodejsディレクトリ自体をzip化する**こと

:::

zipファイル自体の名前はなんでもOKです
作成したzipをlambdaのレイヤーとしてデプロイしましょう

レイヤー登録のわかりやすい手順は[こちら](http

【ALB・CloudWatch・Lambda】サーバーダウン等の異常をALBで検知した際にSlackに通知する

## 自己紹介
はじめまして、はる（[@lemonade_37](https://twitter.com/lemonade_37)）と申します。
駆け出しエンジニアとして約3ヶ月が経過しました🐣

## 概要
サーバーダウンにいち早く気づき、異常の対処や再起動ができるために、
ALBの異常を検知した際に、Slackに通知を送る機能を実装します。
下記の構成でEC2にデプロイされており、ロードバランサー（ALB）で1分毎にHTTPリクエストを送信し、サーバーが起動しているか確認する機能はすでに導入されている前提とします。

今回のインフラ構成図のイメージです。

### 環境
– Docker
– Ruby 3.2.3
– Rails 7.1.3
– PostgreSQL

:::note warn
間違っている箇所や、紹介

GithubActionsでECRのImageをもとにLambdaをデプロイする方法

## 概要
– GithubActionsと ECRのイメージをもとにLambdaをデプロイするCICDを構築したため、記録として残しておく。
– 本記事を通して、下記が実現できるように記載していく
– ローカルでコード編集
– Commitして、GithubへPush
– GithubActionsが実行
– 編集後のコードをLambdaに自動デプロイする
– 最終的な構成として、キャプチャのよう流れとなる


## 前提
– Githubの操作（CommitやPushなど）経験があること
– AWSのアカウントがあること
– この記事内ではオレゴンリージョンを使用しているため、リージョンコードが `us-west-2`で進めています。なので、東京リージョンなどを使用する際は適宜書き換えてください
– C

【Cognito】メール認証、電話認証をせずにユーザー認証させるように頑張ってみたお話

## 結論
ユーザー登録後(ここ重要)lambdaで強制的に権限を変更する
つまり、登録からログインする前に何かしらでlambdaを起動させる必要がある

## サインアップフォーム

“`js:signin.tsx
import React, { useState } from ‘react’;
import { CognitoUserAttribute, CognitoUserPool } from ‘amazon-cognito-identity-js’;
import { poolData } from ‘../../../../lib/cognito’;

export const SignUp = () => {
const router = useRouter()
const [state, setState] = useState({
password: ”,
email: ”,
error: ”
});

const handleChange = (event) => {
setState({
..

CDK×Lambda×golang×Dynamoでアプリを作ってみる DynamoDB処理のLambda実装編GET&POST（第四回）

さて、今回は以下のようにファイルを記述してAPIGatewayで用意したエンドポイントへアクセスし、DynamoDBのレコードを作成＆取得できるようにしていきます。長くなってしまうので今回はGETとPOSTをまずは作成し、次回更新と削除を実装していきたいと思います。

いつも通り詳しい解説をしていきます。
“`lambda/dynamoDBHandler/main.go
package main

import (
“github.com/aws/aws-lambda-go/events”
“github.com/aws/aws-lambda-go/lambda”
“github.com/aws/aws-sdk-go/aws”
“github.com/aws/aws-sdk-go/aws/session”
“github.com/aws/aws-sdk-go/service/dynamodb”
“github.com/aws/aws-sdk-go/service/dynamodb/dynamodbattribute”
“encoding/json”
“net/http

AWSの利用をZscalerからに制限する

# 概要

AWSのセキュリティを強化する機能としては、MFA（多要素認証）が一般的です。

しかしMFAを利用しても、自宅からアクセスできてしまう問題があります。

また複数のAWSアカウントを管理し、IAMユーザが数百人に達すると、全ユーザの動向を把握するのは難しくなります。
メンバ管理をしている責任者が適切に運用してくれないと、退職したユーザにアクセスされてしまう可能性もあります。

アクセスキーにMFAを強制するとロジックの作り込みが必要になりますし、人間がアクセスキーを使用する際には手順が増え、ユーザに説明するのも、自分が利用するのも手間がかかります。

このような問題は、IP制限を設定することで多くが解決できます。アクセスキーが漏洩した場合のリスクも大幅に抑えられます。

会社からのアクセスに限定するには、自社拠点のIPアドレスに制限すれば良いのですが、弊社では全クライアントにZscalerがインストールされているためこの方法が使えません。

本記事では、Zscaler環境下でAWSにIP制限をかける方法、特にその運用の自動化を解説します。

なお、これを読みに来た人はZs