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

【AWS Lambda】Slackに通知を送信する

今回はCloudFormationでLambdaを触ってみるということで、Slackに通知を送信するLambda関数を構築していきたいと思います。

調べてみたところ、Lambdaを構築する場合はCloudFormationの `AWS::Serverless` というマクロ機能を利用するみたいです。
[AWS::Serverless変換](https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/transform-aws-serverless.html)

マクロを利用すると「AWS SAM 構文」なるものでLambdaを定義できるようになり、 `aws cloudformation package` コマンド実行時に、通常のCloudFormationテンプレートに展開されます。

マクロ機能を利用するには、テンプレート内で下記のように宣言します。

“`template.yml
Transform: AWS::Serverless-2016-10-31
“`

# SlackのWebhook U

AWS SAM+Lambda+Go+WSLではじめるサーバーレスアプリケーション開発

# 目的

AWS SAM を使って Go 言語でサーバーレスアプリケーションを開発するための、環境構築の手順をまとめます。個人的な備忘録を兼ねているため、必須ではない細かな設定なども記載しています。Lambda でサーバーレスアプリケーションの開発をはじめようと思っている方の参考になれば幸いです。

# 当記事に含まれる内容

当記事に含まれる内容は下記の通りです。ソフトウェアのインストールなどは既にわかりやすい記事があるので、そのリンクを貼っています。

– Hello World アプリケーションについて
– WSL2 の設定
– Docker の設定
– AWS CLI の設定
– Session Manager プラグインの設定
– SAM と Go のインストール
– Ubuntu の環境変数設定の自動化
– VSCode の設定
– SAM プロジェクトの新規作成
– SAM プロジェクトのデプロイ
– AWS コンソールから各サービスを確認

# Hello World アプリケーションについて

Hello World アプリケーションは、SAM プロジェクトを新規作

AWS SAMでLambdaに設定したS3イベントトリガがコンソールに表示されない問題の対応

AWS SAMでLambdaにS3イベントトリガを設定したところ
動作は想定どおり行われるが、AWSコンソールのイベントトリガには
何も表示されない事象が発生しました。

これは既知の問題のようで
https://github.com/aws/serverless-application-model/issues/300
で議論されていました。

上記にも記載されていますが対応方法のサンプルです。

最初の定義。以下ではAWSコンソールにイベントトリガが表示されない。

“`yaml
MyFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: MyFunction/
Runtime: python3.8
Handler: app.handler
FunctionName: !Sub
– “${prefix}MyFunction”
– { prefix: !FindInMap [“EnvMap”, !Ref Env,

React+AmplifyにContent-Security-Policy-Report-Onlyを設定しCloudWatchにログをためる話

##背景
業務で開発しているReactアプリの中で、XSSの対策としてContent-Security-Policyの設定を行うか議論があり、
そのための判断基準を設けるために一旦、Content-Security-Policy-Report-Onlyを設定してレポートを収集して分析を行う流れになった。

##Content-Security-Policy(CSP)とは
[簡易な認識] : XSS対策の一環で、HTTPのヘッダーの中にそのサイトで使用するJSのスクリプトやコンテンツ、画像やフォントなどを読み込む場所をホワイトリストとして設定することで
それ以外の場所から読み込まれるものはブロックするもの。

詳しい内容はいろんなサイトが紹介している

https://developer.mozilla.org/ja/docs/Web/HTTP/CSP

##Content-Security-Policy-Report-Onlyとは
Content-Security-Policyを設定するとブロックされたものは表示できなくなり、変に設定するとアプリとして壊れるかもしれない。
そこでCSP

作業先の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に接続する(検証手順付き)

以下に移行しました。

https://zenn.dev/mgmgmogumi/books/0214f64645951a

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に環境データを保存してみようと思います。

# 開発構成

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


# 検証環境

– 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)

# 開発構成
– 構成イメージとしては、こんな感じです。

# 検証環境

– 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 .
“`