Lambda関連のことを調べてみた2021年10月11日

Lambda関連のことを調べてみた2021年10月11日
目次

作業先のS3バケットがLambdaのトリガーとなっていないかを確認する方法

#背景
S3へのオブジェクト作成をトリガーを利用してLambdaを活用することは多いと思います。
そうすると、S3にファイルを作成する処理を書くときに

「あれ、このバケットのこの場所、トリガーになってないよね、、、?」

と思うことが出てきました。
さっと確認できると安心感も増すものです。

#解決方法

API レベル (s3api) コマンドにこれを満たす get-bucket-notification-configuration というものがあります。

参考:[API レベル (s3 api) コマンド](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-s3-apicommands.html)

#具体的な方法
せっかくなので
・S3の条件(Prefixとか)
・S3のパス
・Lambda関数のARN

が1行で一覧で出力できるようなjqを書いてみました(あと一歩スマートな書き方があるかもです)

“`
aws s3api get-bucket-notification-config

元記事を表示

[AWS Step Functions] EC2とRDS(Aurora)をグループ単位かつ指定した順番に起動/停止する

## はじめに

EC2とRDS(Aurora)を、グループ単位かつ指定した順番に起動/停止する仕組みを AWS Step FunctionsとLambda(Python 3.9)で作りました。

## もう少し詳しく

作成した StepFunctions ステートマシン の詳細を説明します。
以下のように複数のEC2,RDS(Aurora)がある場合に、タグを使いをグループ化と起動順序を設定します。
タグに必要な情報を設定し、起動したいグループと命令(起動命令 or 停止命令)を指定すると、順番に従いリソースを起動or 停止します。

具体的な設定例も含め説明します。以下図のような構成でEC2,RDS(Aurora)を作成します。


※図にはリソースごとのタグ情報を記載しています

各リソースにはこのようにタグを設定します。

元記事を表示

LocalStackを用いたAPI Gateway+Lambda+DynamoDB API作成方法 メモ

* LocalStackを用いて、DynamoDBにデータ登録を行うAPIをAPI Gateway + Lambdaで作成する方法についてメモする。

## LocalStack 準備

* [こちら](https://qiita.com/KWS_0901/items/f9579d9c360cf42dc97d)の手順でDocker LocalStack環境を準備しておく。

## Dynamo DB 準備

* テーブル(`sample-table`)作成

“`shell
aws dynamodb create-table –table-name sample-table –attribute-definitions AttributeName=Data,AttributeType=S –key-schema AttributeName=Data,KeyType=HASH –provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 –endpoint-url=http://localhost:4

元記事を表示

LocalStackを用いたS3オブジェクト登録API(API Gateway+Lambda)作成方法 メモ

* LocalStackを用いて、S3バケットにオブジェクト登録を行うAPIをAPI Gateway + Lambdaで作成する方法についてメモする。

## LocalStack及びS3 準備

* [こちら](https://qiita.com/KWS_0901/items/f9579d9c360cf42dc97d)の手順でLocalStackとオブジェクト登録先のバケット(`sample-bucket`)を準備しておく。

## API Gateway 準備

* REST API を作成する

* リソースID(`id`)を控える

“`shell
aws apigateway create-rest-api –name ‘LambdaS3TestAPI’ –endpoint-url=http://localhost:4567 –region us-east-1 –profile localstack
{
“id”: “A-Z2699261A-Z3”,
“name”: “‘LambdaS3TestAPI'”

元記事を表示

API Gateway POSTメソッド+Lambda 作成の備忘

##構成

[Client] ⇒(リクエスト ※1)⇒ APIGateway ⇒ Lambda

※1
 IAM認証・・・不正リクエスト対策
        ※Client PCがウイルスにかかり、APIにリクエストが動く場合など
 IP制限 ・・・不正アクセス対策

##POSTのAPI リクエストのcontent-type
世の中のAPIを見ると、リクエストのcontent-typeが、
application/jsonのものと、application/x-www-form-urlencodedのものがあります。
両方に対応しているAPIもありました。
application/jsonの数が増えつつあるというところでしょうか。

“`x-www-form-urlencoded.
flg=1&id=2
“`

“`application/json.
{“flg”:1,”id”:2}
“`

##API Gatewayの設定について
####・リソースポリシーで、IP制限を設定
https://aws.amazon.com/jp/premiumsupport/knowledge

元記事を表示

AWS Step Functions のステート定義におけるリトライの書き方

## 指数バックオフアルゴリズム  
SFN(Step Functions) は指数バックオフによるリトライが行われます。
(エクスポネンシャルバックオフ)

https://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html

SFNにおける式はこんな感じ
`リトライ時間 = IntervalSeconds * BackoffRate ^ (Attempts-1)`

https://d1.awsstatic.com/webinars/jp/pdf/services/20190522_AWS-Blackbelt_StepFunctions.pdf#page=36

簡単に言うと、ランダム時間でリトライ間隔を決めるアルゴリズムです。

いきなりこんな式を見てもピンと来ないので、エラー時に成功するまでn回リトライするようなケースを考えてみます。

### よくあるリトライ
* `リトライ間隔 = 2秒` (固定)
* `リトライ回数 = n回`

サーバーレスフレームワークでLambdaからLaravelを利用してRDSに接続する(検証手順付き)

## やりたいこと
LambdaからLaravelを利用してRDSに接続したい。最終的にIaC化する。

![rds_vpc_lambda_sample.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/140953/cd80867a-d183-c254-0c1d-70c7fece5730.png)
画像:https://dev.classmethod.jp/articles/rds-proxy-deploy-with-serverless-framework/

## 検証手順
以下の手順で検証していきます。

1. VPCとRDSとLambda(Python)を手動で構築して接続確認
2. LambdaとRDSの間にRDS proxyを挟む
3. Brefを利用して言語をPHP(Laravel)に変更
4. 手動で構築したものをIaC化する

## 1. VPCとRDSとLambda(Python)を手動で構築して接続確認
なんでLaravelを使いたいのにPython?と思われるかもしれませんが、

元記事を表示

terraformで構成管理しつつaws lambdaをデプロイする

DMMデータインフラ部に所属している[yuua](https://qiita.com/yuua0216)です
terraformで作成しlambdaをデプロイする際にterraformにlambda関数を含めるとchangeがでたり、扱いづらく
悩むときがあるのでその際の手順的な備忘録です

今回のlambdaはlambda containerではありません

## 初回の手順

1.terraformで基本的なlambdaの事前の情報を作成する(配置先など)
2.lambda関数をzip化しs3バケットに配置する

## 継続的なデプロイの手順

基本的にgithub actionsなどのCI/CDを使います

1.github actionsでlambda function / lambda layerをバケットに配置
2.github actionsでupdate functionの実行

## 下準備

lambdaを配置するようのs3 keyなどをterraformで作成します

“`s3.tf
// bucket作成
resource “aws_s3_bucket” “l

元記事を表示

AWS IoT Coreとlambdaを連携してAWS DynamoDBに環境データを登録する

# はじめに
> AWS IoT CoreとAWS Lambdaを連携してAWS DynamoDBに環境データを保存してみようと思います。

# 開発構成

– イメージは、こんな感じです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533263/1bed232c-edc8-6df3-b507-a262ced95f79.png)

# 検証環境

– RaspberryPi3B+
– 温湿度センサー(DHT22)
– AWS IoT Core
– AWS Lambda
– AWS DynamoDB

# 前提

– RaspberryPiから送られてくるデータをAWS IoT Coreで受信出来ていること

# DynamoDB作成

1) マネージメントコンソールにログインし**DynamoDBサービス**を開きます

[マネージメントコンソール](https://aws.amazon.com/jp/free/?trk=ps_a134p000003yhoPAAQ&trkCam

元記事を表示

AWS CLI による Lambda Layer のアップデートについて

CodeBuildを使ってLambdaに対して自動デプロイしていたのだが、Layer部分で急にエラーが出るようになったので調べてみた。

## TL;DR

– CodeBuild だけでなく、コンソールからの AWS CLI でも起きる
– update-function-configuration を利用しなければ影響はない
– Lambda関数の説明に「aws:states:opt-out」を追加すれば、取り敢えずは今まで通り動く
– 2021/12/1 以降は上記説明を付けても無理そうなので、検討必要

## Error Log

“`
An error occurred (ResourceConflictException) when calling the UpdateFunctionConfiguration operation: The operation cannot be performed at this time. An update is in progress for resource: [ARN]
“`

## ResourceConflictExc

元記事を表示

Layer付きのAWS Lambda functionをServerlessFrameworkでローカル実行するとLayerが参照できない

# 概要

タイトルの通り、Layerを用いて一部ライブラリを共通化しているAWS Lambda functionを、serverlessでローカル実行しようとした時につまずいたので備忘録として残しておく。

# 経緯

最近、趣味でAWS Lambda上で動かすpythonプログラムを作成していて、デプロイが楽になるとのことなのでserverlessを導入していた。
その際、functionを複数作成しており、一部ライブラリはLayerを用いて共通化していた。

作成したプログラムの構成は以下。

“`
プロジェクトルートディレクトリ
├─function1
│ └─src
│ └─handler.py
├─function2
│ └─src
│ └─handler.py
├─layer
│ ├─layer1
│ │ └─layer1のpythonライブラリ・ソース群
│ └─layer2
│ └─layer2のpythonライブラリ・ソース群
└─serverless.yml
“`

また、serverless.ymlの記述内容は以下。
(本

元記事を表示

AWS StepFunctionsで、クロスアカウント でAWS Lambdaを呼び出す

### TL;DR

– Resourceキーの値をLambdaのARNから、`arn:aws:states::: Lambda:invoke` に変更する
– Parametersキーを追加して、呼び出したいクロスアカウント 先のLambdaのARNを指定する
– クロスアカウント先のLambdaには、呼び出し元のAWSアカウントからの呼び出しを許可する必要がある

### 事前準備

1. AWSアカウントを2つ用意する(アカウントA, アカウントB)
2. アカウントBに対して、以下のようなLambdaを用意する

“`js
exports.handler = async (event, context) => {

const response = {
body: JSON.stringify({
foo: ‘Hello, world’,
bar: ‘Goodbye, world’,
})
};

return response;
};
“`

## 手順

### ス

元記事を表示

AWS IoT CoreとAWS Lambdaを連携して温度データをslackに送信する

# はじめに
> raspberryPiで温度センサーのデータをAWS IoT Coreで受信してlambdaと連携しslackに送信する所までやってみようと思います。

AWS IoT Coreの作り方などは、前の記事で書いています.

– [AWS IoT Coreを使ってみた](https://qiita.com/arakirai1128/items/8d2b790d10d3b1b1ee32)

# 開発構成
– 構成イメージとしては、こんな感じです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/533263/39185cbf-8f4a-7e28-ec75-7765af1c3aa3.png)

# 検証環境

– raspberryPi3B+
– 温湿度センサー(DHT22)
– AWS IoT Core
– AWS Lambda

# 前提
– デバイスから送られてくるデータをAWS IoT Coreで受信出来ていること

# Lambdaの作成

1) マネージメントコ

元記事を表示

TypeScriptによるServerless Frameworkの利用

# はじめに

– Serverless FrameworkをTypeScriptテンプレート(aws-nodejs-typescript)で利用した情報があまり見当たらなかったので、プロジェクト作成から設定内容、ファイル構成なんかについて記載します。
– 今後利用する方の参考になればと。

# プロジェクト作成

– Serverless Frameworkをインストールした後にプロジェクトを作成します。
– テンプレートにaws-nodejs-typescriptを利用します。

“`bash
$ sls create –template aws-nodejs-typescript –path serverless-typescript-sample
“`
– [こちら](https://github.com/serverless/serverless/tree/master/lib/plugins/create/templates/aws-nodejs-typescript)にある内容でプロジェクトが作成されます。
– README.mdファイルに詳細が記載さ

元記事を表示

AWS CDKのaws-lambda-nodejsで”Error: spawnSync docker ENOENT”が出るとき

# 問題
Lambda関数をTypeScriptで書くために`aws-lambda-nodejs`を使おうとしたら、下記のエラーが出た。

“`sh
Error: spawnSync docker ENOENT
at Object.spawnSync (node:internal/child_process:1083:20)
at Object.spawnSync (node:child_process:812:24)
at dockerExec

“`

# 解決策
実行環境がmacOSの場合は、ビルドモジュールである`esbuild`を手動でインストールするのが良いらしい。

“`
$ npm install –save-dev esbuild@0
“`
or

“`
$ yarn add –dev esbuild@0
“`

# 参照
https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-nodejs-readme.html#local-bundling

元記事を表示

[Go言語] Golang + AWS Lambdaを実行するとfork/exec /var/task/main: exec format error: PathError

## 概要
Serverless FrameworkやSAMやbuildしたものをそのまま上げてみるなどして、AWS LambdaにGoをデプロイするとどのケースでも以下のエラーがCloudWatchに出力されていた。筆者はM1 Macを使っていることで詰まった。

“`
fork/exec /var/task/main: exec format error: PathError
null
“`

## 解決策

### 一般的な解決法
go buildがなんかしらおかしいはずです。以下のようにgo buildはしましたか?
生成したバイナリのディレクトリ位置も確認してみたください。

“`
$ GOOS=linux go build .
“`

### M1 Macユーザー
go build時にLambdaで指定しているアーキテクチャに合わせていますか?
デフォルトはx86_64のため設定を変更をしていなければ以下のようにamd64でbuildするようにする

“`
$ GOARCH=amd64 GOOS=linux go build .
“`

元記事を表示

AWS PrivateLink 経由で ALB 配下 の Lambda 関数を起動する

## はじめに
2021/9/28 のアップデートで NLB のターゲットグループに ALB を指定できるようになりました :tada:

https://aws.amazon.com/jp/about-aws/whats-new/2021/09/application-load-balancer-aws-privatelink-static-ip-addresses-network-load-balancer/

これにより AWS が提供する機能だけを使用して、ALB 配下にある Lambda 関数を PrivateLink 経由で呼び出すこともできるはずです。ALB ターゲットタイプの使い方や注意点等は他の記事に譲るとして、本記事では以下の構成を試してみます。

![image.png](https://qiita-i

元記事を表示

Lambda, Amazon Textractを利用してS3に保存した画像からテキストを抽出する(Golang)

# はじめに

S3に画像を追加すると、自動的にその画像内のテキストを抽出し、テキストファイルとして保存する、というシステムを[Lambda](https://aws.amazon.com/jp/lambda/)・[Amazon Textract](https://aws.amazon.com/jp/textract/)・Golangを利用して作りました。

作成手順を共有します。

### 完成イメージ

![ocr.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/455240/80ef8a6e-a645-99ad-8d4e-ab1f62fb8046.png)

### Textractとは

[Amazon Textract](https://aws.amazon.com/jp/textract/)はAWSが提供するクラウドOCRサービスです。詳しくは以下の記事を参照してください。

https://qiita.com/windows222/items/07c3683c052d6e2b

元記事を表示

AWS Systems ManagerのParameter StoreからLambdaでパラメータ取得

#パラメータの作成
パラメータの作成ボタンからパラメータを2つ作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630191/e0952c93-d95a-2fcf-0e27-29c49235b86a.png)


今回サンプルとして作ったパラメータの値は、テキスト型の架空のURLです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630191/7195f374-0777-6d22-7080-ee26d10364ab.png)

#Lambdaの作成
①関数名とランタイムだけ変更し関数を作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/630191/ce775a2c-51e1-39ee-912c-45b7a3c3b57c.png)


②設定タブ→アクセス権限

元記事を表示

AWS Lambda プロビジョニング済み同時実行を設定する

# プロビジョニング済み同時実行とは
コールドスタートを防ぐ機能です。コールドスタートとは Lambda 関数の呼び出し時にインスタンスを初期化してから関数を実行することです。プロビジョニング済み同時実行数に 0 より大きな値を設定することで追加料金が発生します。

# 設定手順

「新しいバージョンを発行」をクリックします。

![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/1ea6eb7a-33a1-d93e-f774-d6ba8ae349e4.png)

「発行」をクリックします。

![2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621414/fec4f794-71ac-537d-ffe0-6e6a56ace2be.png)

「設定タブ」$\to$「プロビジョニングされた同時実行」$\to$ 「編集」の順にクリックします。

![3.png](https://qiita-image-s

元記事を表示

OTHERカテゴリの最新記事