- 1. LocalStackを用いたKinesisをトリガーとしたLambda実行
- 2. AWS Cloud9を使ってGoのコードをLambdaにデプロイする
- 3. Amplify CLIを使って、ローカルで実行&AWSにデプロイ
- 4. CloudWatchAlarmのアラーム発動時間をスケジューリングしました。(EventBridge + Lambda + CloudWatch)
- 5. Lambda(SAM)からAmazon SNSトピックへpublishを行う方法メモ
- 6. Amplify FunctionsをTypeScriptで書く
- 7. 【AWS】LambdaからCognitoユーザーを削除する
- 8. LINE + AWS Lambda + API Gateway でおうむ返しBotを作る
- 9. さっくり解説するAWS Lambda
- 10. aws-nodejs-typescriptのテンプレートを使ってみる
- 11. API Gateway + Lambdaを設定して、ブラウザから関数を呼び出せるようにする。
- 12. Lambdaで当日との日付の差分を算出する [ Node.js・Python ]
- 13. Workload Identityを使用してAWS LambdaからBigQueryにキーレスで接続する
- 14. SAM CLI + DynamoDB Local 環境構築手順メモ
- 15. 【Cognito】カスタム認証チャレンジでトークン認証を実装して、SAMでデプロイしてみる。
- 16. Microsoft Teamsで勤怠管理bot
- 17. aws lambda + python3.9 + selenium (python 旧バージョンで止まった人向け)
- 18. 【これで理解できる】SQSのデッドレターキューを理解したかったのでSQS+Lambdaのリトライ処理を実装してみた
- 19. Amazon Lexで受け答えした情報を、Lambdaを用いてDynamoDBに書き込む
- 20. AWS SAMで管理するAWS Lambda関数を、単一のAWSアカウント内の複数環境にデプロイする
LocalStackを用いたKinesisをトリガーとしたLambda実行
* LocalStack上で動作するKinesisへのレコード登録をトリガーとしてLambdaを起動し、LambdaからDynamoDBへレコード登録を行う方法についてメモする。
## 構成
![kinesis-trigger.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/586535/fb89f035-75f4-e38c-492d-6b74c842b769.png)
## Kinesis準備
* ストリーム作成
“`shell
aws kinesis create-stream –stream-name test-stream –shard-count 1 –endpoint-url http://localhost:4568 –profile localstack
“`* ストリーム確認
“`shell
aws kinesis describe-stream –stream-name test-stream –endpoint-url http://local
AWS Cloud9を使ってGoのコードをLambdaにデプロイする
# はじめに
久々に投稿するのですが、学生時代に投稿した昔の自分のQiitaが(意味不明で)可愛いですね。今回Cloud9を触ってみたので、「Cloud9でGoのコードを書き、それをLambdaにデプロイするまで」を書いていきたいと思います。
# 目次
– Lambdaの作成
– Cloud9の作成と使い方
– Cloud9からLambdaにGoコードをデプロイ
– デプロイしたLambdaを実行する
– Cloud9を使ってみた所感# Lambdaの作成
まずはLambda関数を作成しておきます。
手動で作ったのですが、そういえばCloud9の中からcliで作れるのでしょうか。関数名は`cloud9-demo`にしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/347108/03661b31-bae4-2735-8bb3-871b0fc5c99e.png)今回はデモ用に作成したので、
– メモリは512MB -> 128MB
– 最大時間は15秒 –
Amplify CLIを使って、ローカルで実行&AWSにデプロイ
Amplify CLIを使って、REST APIや静的コンテンツのサーバを立ち上げます。
ローカル環境で実行・デバッグして確認したのち、AWS上にデプロイ・実行します。ローカル環境でのデバッグには、node.jsとVisual Studio Codeを使います。
AWS上には、API Gateway、Lambda、S3を使います。
上記の橋渡しに、Amplify CLIを使います。今回使うのは、AmplifyではなくAmplify CLIです。
なぜこのような言い方をしているかというと、Amplifyは、いろいろ自動化してくれているのですが、何をしているかよくわからないので、長期的にメンテナンスがしづらく、バグに遭遇する可能性もあるためです。
なので、Amplify CLIを使って、API Gateway、Lambda、S3を一つ一つ作っていきます。それと、Amplifyで構築すると、今までS3やAPI Gateway、Lambdaにばらばらで分散していたパーツ群がAmplifyに集約されるので、まとめてみやすくなります。
目指す形は以下の通りです。
![image.p
CloudWatchAlarmのアラーム発動時間をスケジューリングしました。(EventBridge + Lambda + CloudWatch)
#はじめに
こんにちは、山田です。
今回は、CloudWatchAlarmのアラーム発動時間をスケジューリングしました。#構成図
EventBrigdeにて、CloudWatchAlarmを無効/有効化する時間帯をスケジューリングする。
Lamandaにて、時間になったら、CloudWatchAlarm無効/有効化アクションを実行する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1096361/686c6f7c-fea9-a093-84ff-8aafd5422b9c.png)#Lambdaの作成
① AWS管理コンソール -> Lambda -> 関数 -> 関数の作成をクリックする。② 関数名を入力する。
※今回は`「CloudWatchAlarm-enable-action」`と`「CloudWatchAlarm-disable-action」`としました。③ 使用する言語は`Python3.8`を選択する。
④ 設定 -> アクセスの権限 -> 実行ロール
Lambda(SAM)からAmazon SNSトピックへpublishを行う方法メモ
* LocalStack上で動くAmazon SNSのトピックに対して、AWS SAM CLIで動くLambdaからpublishを行う方法をメモする。
## 構成
![sam-sns.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/586535/ede9f228-fef0-f12c-76cc-62a82f1aefe6.png)## LocalStack準備
* `docker-compose.yml`
“`yaml
version: “3.8”
networks:
container-link:
name: docker.internal
services:
localstack:
container_name: “${LOCALSTACK_DOCKER_NAME-localstack_main}”
image: localstack/localstack
ports:
– “127.0.0.
Amplify FunctionsをTypeScriptで書く
早速`amplify add function`していく。
“`:console
❯❯❯ amplify add function
? Select which capability you want to add:
❯ Lambda function (serverless function)
Lambda layer (shared code & resource used across functions)? Provide an AWS Lambda function name: function名
? Choose the runtime that you want to use: (Use arrow keys)
.NET Core 3.1
Go
Java
❯ NodeJS
Python? Choose the function template that you want to use: (Use arrow keys)
CRUD function for DynamoDB (Integration with API
【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のドキュメントによると、テンプレートを複数環境向けに利用するには、パラメーターやマッピング、条件セクションで環境間の差異を吸収してい