Lambda関連のことを調べてみた2022年01月21日

Lambda関連のことを調べてみた2022年01月21日
目次

【AWS】LambdaからCognitoユーザーを削除する

LambdaからCognitoユーザーを削除することがあり、少し手間取ったので残しておきます。

## 前提
– **Cognitoの削除が可能なポリシーをLambdaのロールにアタッチしていること。**
– ※今回はAWS管理ポリシーの AmazonCongitoPowerUser をLambdaのロールにアタッチしています。
– LambdaのランタイムはNode.js 14.x です。

## Lambdaのコード

“`javascript:index.js
let aws = require(“aws-sdk”);

exports.handler = async (event) => {

// eventから削除するCognitoユーザーのユーザー名リストを受け取る
let userNameList = event.userNameList;

// Cognitoユーザーの無効化メソッドをコール
await disalbeCognito(userNameList);

const response = {

元記事を表示

LINE + AWS Lambda + API Gateway でおうむ返しBotを作る

# 野望
・インターフェース:LINE公式アカウント
・処理:AWS Lambda(+API Gateway)
・DB:Notion
として簡単なツールを作ろうとしています。

イメージはこんな感じ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/455207/35a9401a-055e-9151-b992-e381700d741f.png)

# 今回やったこと
まずはLINE公式アカウントに対する投稿の取得とLambdaでのLINE Messaging API動作検証のため、投稿した内容をそっくりそのまま返すおうむ返しBot的なものを作りました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/455207/40233e98-ac4e-3f51-5010-c4adf4a3f354.png)

# 前提
・LINE Developersでユーザ登録を実施し、公式アカウントを作成している

元記事を表示

さっくり解説するAWS Lambda

#はじめに
私自身、業務で3年ほどAWS Lambdaを触っていますが、
まだまだ知らないことも数多くあり、自身の復習も兼ねて、
少し用語が多く難しいかもしれませんが、初心者にもなるべく分かりやすく解説してみようと思います。
※この記事には、私の独断と偏見が多少含まれています。

#AWS Lambdaとは

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/392337/2f46cec1-8287-36a1-866f-ccfe79a20dfc.png)

公式ドキュメントによると、

>Lambda はサーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービスです。Lambda は可用性の高いコンピューティングインフラストラクチャでコードを実行し、コンピューティングリソースの管理をすべて担当します。これにはサーバーおよびオペレーティングシステムのメンテナンス、容量のプロビジョニングおよびオートスケーリング、コードのモニタリングおよびログ記録などが含まれます。

元記事を表示

aws-nodejs-typescriptのテンプレートを使ってみる

## はじめに

業務でServerlessFrameworkを触ることがあり、typescriptのテンプレートを使用すると
`serverless.yml`から`serverless.ts`になったことやビルドツールが`webpack`から`esbuild`になったことにより詰まったので、シェアできればと思い、まとめてみます。

## Serverless Frameworkとは

Serverless Frameworkとはなんでしょうか?
https://github.com/serverless/serverless によると、

>The Serverless Framework – Build applications on AWS Lambda and other next-gen cloud services, that auto-scale and only charge you when they run. This lowers the total cost of running and operating your apps, enabling you to

元記事を表示

API Gateway + Lambdaを設定して、ブラウザから関数を呼び出せるようにする。

# 目的
AWS外のサービスからURL形式でLambdaを呼び出せるようにAPI Gatewayの発行とLambdaの統合をしました。

# 前提
AWSアカウントを有しており、コンソール上で操作ができること。

# やったこと
①適当なLambdaの作成
②API Gatewayの発行とLambda統合

# ①適当なLambdaの作成
AWSコンソール > Lambda にて関数の作成を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/455207/865f24af-71ba-8f97-d5c9-34f3bee156a1.png)

今回はNode.jsで適当なLambdaを作るだけなので「一から作成」とNode.jsのバージョンを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/455207/5752a4a4-23a1-cd11-f7d3-115940b3a258

元記事を表示

Lambdaで当日との日付の差分を算出する [ Node.js・Python ]

#はじめ
Lambdaで、当日の日付を`20220116`の形にし、5日後の日付`20220121`を引くと、`5`という数字が出せるようにすることを目的として、Lambdaを作成したため、まとめます。

#Lambdaコードの流れ

###当日の日付

1. 2022-01-16 11:41:21.282791(タイムゾーンはUTC)
– ↓UTCをJSTに変換する
2. 2022-01-16 11:41:21.282791(タイムゾーンはUTC)
– ↓タイムスタンプに変更
2. 1642765665851
– ↓年、月、日のみに変換。(時間、分、秒は、切り捨て)
2. 20210116

###5日後の日付

1. 2022-01-16 11:41:21.282791(タイムゾーンはUTC)
– ↓日付を5日進める
1. 2022-01-21 11:41:21.282791(タイムゾーンはUTC)
– ↓UTCをJSTに変換する
2. 2022-01-21 11:41:21.282791(タイムゾーンはUTC)
– ↓タイムスタンプ

元記事を表示

Workload Identityを使用してAWS LambdaからBigQueryにキーレスで接続する

# はじめに
AWS LambdaからBigQueryに接続し、その結果を使って後続の処理を行いたい場合、Lambda上にGCPのサービスアカウントの認証キーを配置することで可能になりますが、認証キーの発行やLambda上への配置はできればしたくありません。

そういった時に便利なのが、GCPのWorkload Identityです。

https://cloud.google.com/blog/ja/products/identity-security/enable-keyless-access-to-gcp-with-workload-identity-federation

この方法では、GCPのサービスアカウントとAWS等のロールを紐付け、サービスアカウントの権限を借用して認証することができます。

今回はこの方法でLambdaからBigQueryに接続する方法を確認して行きます。

# 実行準備
以下は作成済みである前提で進めて行きます。

– GCP側
– プロジェクト
– BigQueryにについて操作可能なGCPのサービスアカウント
– Big

元記事を表示

SAM CLI + DynamoDB Local 環境構築手順メモ

* SAM CLIとDynamo DB Localを使用してローカル環境でサーバーレスアプリを構築する手順についてメモする。

## 前提条件

* Docker、docker-composeインストール済みであること。

* dynamodb-admin(DynamoDB GUIツール)インストール済みであること。[インストール手順](https://qiita.com/KWS_0901/items/5768bafe84cf86766645)

* SAM CLIインストール済みであること。

* ディレクトリ構成

“`shell
local_app – dynamodb — docker-compose.yml
| |_ docker – dynamodb
|_ sam-app
“`

## 構築手順

### DynamoDB Local準備

1. `docker-compose.yml`準備

“`yaml
version: ‘3.8’
services:
dynamodb-local:

元記事を表示

【Cognito】カスタム認証チャレンジでトークン認証を実装して、SAMでデプロイしてみる。

## 柔軟性のある認証フローを作成できる

Cognitoを触ってみて、最初は色々不便だなあと思っていました。
しかし、ちゃんとドキュメントを読んでいくうちに、拡張性が高く、結構柔軟な実装が可能だと気づきます。
その柔軟性を担保してくれいている仕組みの一つが「カスタム認証チャレンジ」です。

![カスタム認証チャレンジフロー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/632997/68970d48-a8e7-e239-0e05-0373418f10d5.png)

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-lambda-challenge.html より引用

## 何が便利なのか

ログイン方法を複数指定することができます。
一般的な認証方法の1つにユーザ名とパスワードを入力するパスワード認証があります。
例えば、カスタム認証フローを使えば、あるロールのユーザにはパスワード認証を、あるロールの

元記事を表示

Microsoft Teamsで勤怠管理bot

# はじめに

会社の上司は部下の生存確認をしたいお年頃になったようです。
在宅勤務も増え、上司は目隠しでサッカーやってる感覚でしょう。
さすがに「ピッチに出てるか否か」ぐらいは知りたい、ということだったので
ビジネスチャットツールであるMicrosoft Teamsで勤怠管理botをつくってみました。

#構成
部下は何かとAPIを使いたいお年頃になってきましたので、ご多分に漏れずAWSでサクッとつくります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1989761/60718c97-a63d-76f0-08b3-5f97b2710da7.png)

1.TeamsのOutgoing Webhook設定
2.Lambdaで情報を受け取って処理
3.出退勤時刻と名前をDynamoDBに保存
4.FlaskをバックエンドにDynamoDBのデータを読みこんで表示
5.上司はWeb上で勤怠管理ができるようになって楽ちん
こんな感じです.1のWebhook設定をよしなにすれば、Slackで

元記事を表示

aws lambda + python3.9 + selenium (python 旧バージョンで止まった人向け)

# 対象者

* aws lambda + python3.9 で Layers に headlesschrome + selenium を使って動かなかった渋い経験がある人(127 エラーに泣いた日々)
* 現在 python3.7 で動かしているけど、いつ AWS から見限られるかでおびえている人

※ python の書き方や、aws lambda の使い方云々については取り上げてません(参考記事だけは残してます)

# 前置き(どうでもいい人はスキップ)

ふとしたきっかけはこちらの記事

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

この記事を見た時、Docker のことはよくわかっていないけれど、Docker イメージ(OS+必要なアプリケーションや実行ファイルをまとめたもの)を作って ECR に配置すると、Lambda で使えるようになったよ!ということらしい

その時は、いまいちピンと来てなかったが、、、
ある日ネットサーフィンしていると以下に出会う

元記事を表示

【これで理解できる】SQSのデッドレターキューを理解したかったのでSQS+Lambdaのリトライ処理を実装してみた

本記事は以下ブログの内容を転記したものです。
以下ブログの方が見やすいと思います。気になる方はどうぞです。

https://memomaru.life/lambda-sqs-dlq-retry/

## はじめに
最近、仕事でSQSを使う機会があったのですが、デッドレターキューやSQSによるリトライ処理がイマイチ理解できていませんでした。
AWSの公式ドキュメントやブログ記事などを見てもあまり理解できなかったため、実際にサンプルアプリを作って検証しました。

## 実施内容(概要)

実施内容は以下です。

– LambdaにSQSでメッセージを送信する
– Lambdaはエラーとなるような処理とする
– 複数リトライ後、SQSのメッセージがデッドレターキューに入ることを確認する
– デッドレターキューに入ったメッセージを使って再処理できることを確認する

## 実施内容(詳細 – 設定)

### IAM

一般的なユースケースからLambdaを選択し、`次のステップ:アクセス権限`を押します。

ポリシーとして`AmazonSQSFullAccess`と`CloudWatchL

元記事を表示

Amazon Lexで受け答えした情報を、Lambdaを用いてDynamoDBに書き込む

#はじめに
Lexで答えた情報をLambdaを用いて、DynamoDBに書き込むことをやります。

![スクリーンショット 2022-01-15 15.58.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/988747/ca13abec-3ae8-6ab0-3657-9db538a92b5d.png)

#流れ
1. DynamoDBのテーブル作成
1. Lex作成
1. Lambda作成
1. LexにLambdaを設定

#DynamoDBのテーブル作成
以下の設定で作成します。
テストですので、オンデマンドモードにして、安く済ませます。

– テーブル名:`Lex-Write-Lambda`
– パーティションキー:`telephoneNumber`:`文字列`
– ソートキー:`date`:`文字列`
– 項目:`age`:`数値` (テーブル作成後)
– 項目:`timeStamp`:`数値` (テーブル作成後)
– テーブルクラス:DynamoDB 標準 – IA
– キャパシティー

元記事を表示

AWS SAMで管理するAWS Lambda関数を、単一のAWSアカウント内の複数環境にデプロイする

# Whats’?

AWS SAMで管理するAWS Lambda関数を、単一AWSアカウント内の複数回(別環境として)デプロイするのにはどうすればよいのかな?ということで、試してみました。

# AWS CloudFormationと複数環境

AWS SAMは、AWS CloudFormationの拡張です。

> AWS SAM は AWS CloudFormation の拡張であるため、AWS CloudFormation の信頼性の高いデプロイ機能を利用できます。

https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/what-is-sam.html

このため、AWS SAMで管理している内容を複数の環境に適用するには、AWS CloudFormationの考え方に従うのが妥当でしょう。

AWS CloudFormationのドキュメントによると、テンプレートを複数環境向けに利用するには、パラメーターやマッピング、条件セクションで環境間の差異を吸収してい

元記事を表示

イベントソース・パイプライン

# イベントソース・パイプライン
フロー:DataLake → Glue → QuickSight
CloudWatchに吐き出されたGlueの実行ログを、Lambdaで集計・抽出し、S3バケットへアップロードします。
Lambda関数は、Step Functionで起動させています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2432928/f8780266-a47a-91ee-0ba6-0eb3c5b5785b.png)

## EventBridge (旧:CloudWatch Events)
EventBrightのイベント実行ルールを設定しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2432928/94d9b6b5-3833-a57d-3092-b3fac05ab9f3.png)
イベントパターンをスケジュール(モード)に設定し、スケジュールに基づいたアクション

元記事を表示

Lambdaでrds自動起動停止

#自動起動
#iam role作成
AWSコンソールへログイン
https://console.aws.amazon.com/iamv2
左ペインロール押下
ロールを作成押下
一般的なユースケース:lambda
ポリシー:AmazonRDSFullAccess
ロール名:control-rds
作成

#lambda関数作成
https://console.aws.amazon.com/lambda
関数の作成押下
関数名:start-rds
ランタイム:python3.9
デフォルトの実行ロールの変更
既存のロールを使用する:control-rds
関数の作成
以下コード入れる

“`
import boto3

rds = boto3.client(‘rds’)

def get_tags_for_db(db):
“””
get instance list
“””
instance_arn = db[‘DBInstanceArn’]
instance_tags = rds.list_tags_for_resource(ResourceNam

元記事を表示

SORACOM LTE-M Button plusをトリガーに、LINE Notifyで位置情報を通知する

#はじめに
SORACOM LTE-M Button powered by AWSを以前使っていたのですが、紛失。
しかし最近このLTE-Mボタンを使う機会ができたので、これを機にLTE-M Button Plusを買いました。

https://soracom.jp/store/5207/

そしてこのLTE-M ボタン Plusを使い、AWS lambda、そしてIFTTTを介してLINE Notifyの通知を使う事を実現してみました。

調べてわかったのですが、このボタンはPowered by AWSのモデルと違いボタンを押した位置座標を大まかではあるものの取得できる機能があります。そこで、今回はtwitterの動画にあるように、LINE Notifyに文章を送るだけでなく、今の位置情報をGoogle maps APIの中のStatick map APIを使って一緒に今の位置情報を画像で送ってみました。

この記事ではこの実現方法をまとめます。

#開

元記事を表示

RDS Proxyの挙動検証(lambda → RDS Proxy → RDS)

AWS RDS Proxyがどのように挙動するのかを検証する。
主にDB接続数まわり。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-proxy.html

# 検証環境
## 検証用処理
– `s3:ObjectCreated`のイベント発生をトリガに、lambda起動→RDS通信(特定カラムのupdate) という処理で検証する。([検証用lambda](https://github.com/tatsukoni-pra/lambda-rds-test))
– トリガとなるバケットパスにファイルを100個まとめてアップロードし、lambda関数を100個起動 → RDS接続を100個発生させる。

## 検証用RDS
– エンジンバージョン: `Aurora MySQL 5.7`
– DBインスタンスサイズ: `db.t2.small`(DB最大同時接続数は45)

# 検証
## RDS Proxy未使用時(lambda → RDS直接続)
処理前は以下の感じ。

“`
MySQL> SHOW G

元記事を表示

[AWS] Cloudwatch_LogsからLambda経由で軽いETLしつつOpenSearchでApacheログを可視化する方法

# やりたい事

2022/01/13開催の [SB Tech Festival](https://www.softbank.jp/biz/events/techfestival-deeptech-2022/) で登壇した内容、「ビッグデータ活用の第一歩AWS環境での大容量ログ可視化」の詳細手順(後半)ページです。

### このエントリで解説するのは以下のイメージ
![2022-01-11_09h20_031.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/99499/23980234-e06e-96dd-3d8b-0bba4493cd57.png)

前半部分のFargate+Firelens+CloudwatchLogsについては[こちら](https://qiita.com/Kedamari/items/fba00598c0bd9e08fdb9)の記事を参照してください。

# 手順
2022/01/11時点でECSコンソールは新しいエクスペリエンスが提供されていますが、本エントリでは旧UIをベー

元記事を表示

EC2インスタンスの自動停止起動

# 経緯
EC2インスタンスを、使用しない時間帯のみ止めてコスト削減をしたい。
Lambdaのみでの実装と、Instance Schedulerでの実装を行い、それぞれの複数インスタンス・複数スケジュール設定の場合やコスト、注意などをまとめる。

**【参考】**

https://aws.amazon.com/jp/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/

https://aws.amazon.com/jp/builders-flash/202110/instance-scheduler/?wsf.filter-name=*all

https://docs.aws.amazon.com/ja_jp/solutions/latest/instance-scheduler/deployment.html#step5

# Lambda のみで実装する

**〇手動方式〇**

**1. IAM ポリシーと IAMロール作成**

* ポリシーの作成。CloudWatch Logの書き込み、E

元記事を表示

OTHERカテゴリの最新記事