- 1. AWS Step Functionsの実行結果をSlackへ通知する
- 2. Playwright PythonをAWS Lambdaで動かす
- 3. AWS Lambdaのタイムアウトを検知する (Terraform)
- 4. aws-cli Athena/Lambdaのラッパースクリプトを書いて作業を効率化する
- 5. AWS LambdaにおけるARM64とx86_64の性能比較
- 6. 【AWS,Python】LambdaのログをCloudWatchに残す
- 7. Azure と AWS の サーバーレス コンピューティングの主要な違いを個人的に比較
- 8. Lambda関数からプライベートサブネットのリソースへアクセスする方法
- 9. Lexを使って自動問い合わせ応対しよう!(1)
- 10. マイGPTを使って反社調査を行う
- 11. RevenueCat WebhookをAWS API Gateway、Rust Lambda、DynamoDBで処理する
- 12. FastAPIのAPIサーバをAWSのAPI Gateway+Lambdaを使って動作させる方法
- 13. AWS Lambda – Provisioned Concurrency設定時の振る舞い
- 14. Lambda関数でMySQLに接続する
- 15. 【API Gateway】バイナリペイロードを適切に扱う
- 16. Konnectの証明書の期限をLambdaで監視し、CloudWatch経由でメール通知する
- 17. [Amazon Web Services]LambdaでEC2の定期停止設定してみた
- 18. サーバーレスを小学生でも分かる様に解説する試み
- 19. コンテナイメージを使用した Lambda 関数を作成してみた
- 20. AWS Lamba関数をテストする際にbodyの書きかた
AWS Step Functionsの実行結果をSlackへ通知する
# はじめに
AWS Step Functionsの実行結果をSlackへ通知する手順について、以下の記事では、Step Functionsの実行結果を取得し、Slackに通知する方法を紹介します。この記事では、SNS(Simple Notification Service)とAWS Lambdaを使ってStep Functionsの実行結果をトリガーし、Slackに通知を送信する流れを説明します。# 構成
![Untitled Diagram.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1065841/9b1ef79f-827b-10b4-3062-575ed7ba49fa.png)# 目次
1. [SlackのWebhookURLを取得](#SlackのWebhookURLを取得)
1. [SNSトピックの作成](#SNSトピックの作成)
1. [StepFunctionsの実行結果をSNSへ通知する設定
Playwright PythonをAWS Lambdaで動かす
たまにPlaywrightをLambdaで動かしたくなりますよね。
すでにいろいろな方が挑戦されているようで、簡単に使えるLambdaレイヤーが公開されているようです。
https://developer.mamezou-tech.com/blogs/2024/07/19/lambda-playwright-container-tips/
ただ、そういうことじゃないんです。自分でやることに意味があるんです。なんとか動作しましたので、ご紹介。
## きっかけ
先日投稿したこちらの記事で、LangChainの「AsyncChromiumLoader」を紹介しました。
https://qiita.com/moritalous/items/44c0cff860f7b5697822
これをLambda化したいなぁと思ったのがきっかけです。(そしてBedrock Agentsから呼び出したい)
AsyncChromiumLoaderは内部でPlaywrightが使われているのですが、先ほど解説した「`chromium.launch`」の呼び出し部分のargsを外部から指定する方
AWS Lambdaのタイムアウトを検知する (Terraform)
## 概要
– `AWS Lambda` のタイムアウトを検知する実装を解説します
– 実装の `Terraform` コードサンプルを提供します
– `CloudWatchLogs MetricFilter` におけるハックをお伝えします## AWS Lambdaのタイムアウトを検知する実装
### 想定ケース
以下のように、EventBridge経由でLabmdaを実行するケースを考えます![architecture](https://raw.githubusercontent.com/RyuyaIshibashi/great-chatgpt-quotes-bot/master/chat_architecture.jpg)
引用:
https://qiita.com/rubita/items/966bcbfd58c6e9368556
### Lambdaの仕様
Lambdaは以下の仕様を持っています
– タイムアウト設定のデフォルト値は 3 秒です
– 最大値の 900 秒 (15 分) まで 1 秒単位で調整できます
– タイムアウトエラーとなった場合、2回までリト
aws-cli Athena/Lambdaのラッパースクリプトを書いて作業を効率化する
# はじめに
この記事は@ktatさんの[aws-cli のラッパースクリプトを書いて作業を超効率化する](https://qiita.com/ktat/items/6494390dec4b5b9c662b)を見て、AthenaとLambdaのラッパースクリプトを作ってみたものになります。
# 現状
業務上Amazon AthenaやAWS Lambdaをよく使うのですが、「クエリを書いて結果を見たい」「関数を実行させたい」場合に逐一コンソールへ入ってそれを行うのが面倒でした。
また、aws cliも
“`shell:Athenaの場合
# 一々execution idを取得した後、そのステータスを確認し、終了していたらget-query-resultsを実行して結果を得る
$ aws athena start-query-execution –query-string –そのほかの設定
$ aws athena get-query-execution –query-execution-id “start-query-executionで発行されたID”
$ aws
AWS LambdaにおけるARM64とx86_64の性能比較
## はじめに
AWS Lambdaは、ARM64(Graviton2)とx86_64の2種類のアーキテクチャで動作します。ARM64はモバイル向けや低消費電力が特徴のRISCアーキテクチャで、一方x86_64はサーバー向けに広く使われるCISCアーキテクチャです。
今回は、AWS Lambdaで**ARM64**と**x86_64**のパフォーマンスを、I/Oバウンド処理、CPUバウンド処理、並列処理の観点で比較しました。Pythonを用いたサンプルコードを実行し、メモリサイズごとの処理時間を測定しました。
## サンプルコード
次のPythonコードをAWS LambdaでARM64とx86_64の両方で実行しました。このコードは以下の3種類の処理を行います。
1. **I/Oバウンド処理**: ファイルの読み書きでI/O性能を測定。
2. **CPUバウンド処理**: 浮動小数点演算を大量に行うことでCPUの性能を測定。
3. **並列処理**: スレッドを用いた並列計算のパフォーマンスを測定。“`python
import time
import math
i
【AWS,Python】LambdaのログをCloudWatchに残す
下記記事で行っているWEBスクレイピングのlambdaのログをCloudWatchに残します。
https://qiita.com/otaruit/items/837f2eacf69e5917dd1d
# CloudWatchの設定
ロググループ、「ロググループを作成」と進みます。![Screenshot 2024-09-10 095839.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722467/c6e79306-946c-fd3d-bc79-cfa10382ac80.png)
# ロググループの設定
グループ名、保存期間を設定します。
![Screenshot 2024-09-10 100011.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/722467/e3402706-3ceb-9704-0f35-b7678ff4b9eb.png)#
# コード修正ログを出力させるようにprint()で要
Azure と AWS の サーバーレス コンピューティングの主要な違いを個人的に比較
Azure Functions と AWS Lambda は、どちらもサーバーレスコンピューティングの主要サービスであり、多くの類似点がありますが、重要な違いも存在します。
この比較では、機能面、性能面、そして特徴的な機能に焦点を当てて両サービスを詳細に比較します。## 機能面の比較
### サポートするプログラミング言語
– **Azure Functions:** C#, Java, PowerShell, Python, _JavaScript, TypeScript_ [^1]
– **AWS Lambda:** C#, Java, PowerShell, Python, _Go, Ruby_ [^2][^1]: https://learn.microsoft.com/ja-jp/azure/azure-functions/supported-languages
[^2]: https://aws.amazon.com/jp/lambda/faqs/### トリガーとバインド/イベントソース
– **Azure Functions:** Azure の各種サー
Lambda関数からプライベートサブネットのリソースへアクセスする方法
今回は、Lambda関数からプライベートサブネット内のAWSリソースにアクセスする方法について解説します!
この内容は、実務でもよく使うシーンがあり、さらにAWS認定ソリューションアーキテクト アソシエイト (SAA)の試験範囲にも含まれていますので覚えたい内容です!
よく忘れてしまう内容なので自分なりにまとめました。結論としては、Lambda関数からプライベートサブネット内のリソースにアクセスするには、Lambda関数にVPCアクセスの設定を行う必要があります。
**LambdaとVPCの関係**
Lambda関数は作成されると、自動的にLambda専用のセキュアなVPCに構成されます。このVPCからはインターネットやパブリックサブネット内のAWSリソースへはアクセスできますが、プライベートサブネット内のリソースには直接アクセスできません。**プライベートサブネット内のリソースへアクセスするには?**
Lambda関数からプライベートサブネット内のリソースにアクセスさせたい場合、Lambda関数にVPCアクセスの設定を行います。この設定では、アクセスしたいリソースがある
Lexを使って自動問い合わせ応対しよう!(1)
# はじめに
ヘルプデスクの対応、システムの改修、新しいツールの選定などなど、情シスってやることいっぱいですよね。
パンク気味になるとついつい問い合わせが漏れたり、一次対応が遅れがちになっちゃいます。
そこで!!今回はAmazon Lexを用いて私の代わりに一次対応させるbotを作って業務をじゃんじゃか楽にしちゃおうと思います!!!
今回は第一弾として想定される質問に対して一次応対できるようなbotを作ります!
(備忘録として書いたので過不足あれば教えてください!)# Amazon Lexとは
Amazon Lexは、音声認識とテキスト理解を組み合わせた対話型AIサービスです。Alexaのような対話型の仕組みをアプリやウェブサイトに組み込むことが出来ます。
主な特徴:
・ユーザーの音声や文字入力を理解
・適切な応答を生成
・タスクを実行(予約受付など)例えば、ユーザーが「予約したい」と言うと、システムは「何名様ですか?」と聞き返すなど、自然言語で対応します。これにより、カスタマーサービスの自動化や対話型インターフェースの作成が可能になるとのこ
マイGPTを使って反社調査を行う
## マイGPTとは
英語版では`My GPTs`と表示されますが、本記事では`マイGPT`と表記します。マイGPTは、OpenAIのChatGPTを使って、誰でも簡単にカスタムチャットボットを作成できるサービスです。プログラミングの知識がなくても作成可能です。
**My GPTs**を利用するには、有料の**ChatGPT Plus**か、それ以上のプランに加入する必要があります:point_up_tone1:
![myGPTpng.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320164/c4eb7f9b-59b4-d5a9-6560-845a6193c0f9.jpeg)## 早速作ってみよう
お馴染みな[ChatGPT画面](https://chatgpt.com/)の右上からメニューを開いてください、`マイGPT`をクリックしてください。
![2E91FE27-D8F8-4E7A-AA7F-03FE6165331B.jpeg](https://qiita-image-store.s
RevenueCat WebhookをAWS API Gateway、Rust Lambda、DynamoDBで処理する
RevenueCatは、iOS、Android、Webなど様々なプラットフォームでアプリ内サブスクリプションを簡素化する強力なサブスクリプション管理サービスです。その主要機能の1つは、購入、更新、キャンセルなどのサブスクリプションイベントについてバックエンドに通知するWebhookを送信する能力です。この記事では、AWS API Gateway、AWS Lambda(Rustで実装)、およびストレージ層としてDynamoDBを使用して、RevenueCat Webhookを処理する方法を探ります。
![RevenueCat-Webhooks with AWS.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3887819/8af63fd5-705c-983d-48e9-b334c03a9315.jpeg)
## アーキテクチャ概要
アーキテクチャは以下の主要コンポーネントで構成されています:
1. **RevenueCat Webhook**:RevenueCatはWebhookイベント(サブスク
FastAPIのAPIサーバをAWSのAPI Gateway+Lambdaを使って動作させる方法
# デプロイ手順
※FastAPIのアプリケーションがある
1. LambdaでFastAPIのAPIサーバを実行できるようにする設定をする([Mangum](https://github.com/Kludex/mangum))
1. [Serverless Framework](https://www.serverless.com/)でAWSにデプロイできるようにする
– LambdaにPythonライブラリがインストールされるようにする設定をする
1. [Serverless Framework](https://www.serverless.com/) でAWSにデプロイする## FastAPIのアプリケーションがある
app.py“`python
from fastapi import FastAPIapp = FastAPI()
@app.get(“/”)
def hello_world():
return {‘message’: ‘Hello from FastAPI’}
“`## LambdaでFastAPIのAPIサーバを実行でき
AWS Lambda – Provisioned Concurrency設定時の振る舞い
AWS LambdaにProvisioned Concurrencyを設定した際、不可解な現象に遭遇したため、原因を調査した。
### 発生した現象
Provisioned Concurrencyを設定したLambda関数について、同時実行がないにも関わらず下記のような `Init Duration` を含むログが出力され、コールドスタートが発生してしているように見える。さらに `Init Duration` の数値がOn-Demand Concurrencyの場合に比べて大幅に増加している。
“`
REPORT RequestId: xxxx Duration: xx ms Billed Duration: xx ms Memory Size: xx MB Max Memory Used: xx MB Init Duration: xx ms
“`### 解析結果
* 結論としては、ログに `Init Duration` が出力されているが、実際にはコールドスタートは発生していない。
* Provisioned Concurrencyを設定した場合も定期的にインスタン
Lambda関数でMySQLに接続する
AWSが提供しているライブラリには直接MySQLデータベースと接続する機能は含まれていないため、LambdaでRDSのMySQLに接続する場合、PyMySQLなどの外部ライブラリを使う必要がある。
## レイヤー追加
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3412108/f41bd875-cf0d-41bb-6c7f-74fa61612888.png)レイヤーソース:ARNを指定
パブリック公開されているレイヤーのARNを指定するhttps://github.com/keithrozario/Klayers/tree/master/deployments
ランタイムとレイヤーのPythonバージョンは合わせる
※バージョンが異なると、ライブラリのバイナリや依存関係が異なるため、互換性の問題が生じる可能性がある## lambdaコード
“`python
import pymysql
import osdef lambda_handler(event, con
【API Gateway】バイナリペイロードを適切に扱う
# はじめに
API Gatewayで扱うリクエスト、レスポンスに含まれるペイロードはテキストペイロードとバイナリペイロードに区分される。
| ペイロード | 説明 |
|:-:|:-:|
|テキスト|UTF-8エンコードされた JSON 文字列|
|バイナリ|テキストペイロード以外のペイロード|![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/7482c394-14ef-0951-549b-b77d379f76b4.png)
バイナリペイロードを扱うためには、Lambdaプロキシ統合の利用有無によって適切にAPI Gatewayを構成する必要がある。# Lambdaプロキシを利用する場合
必要な設定は以下の通りです。
– レスポンスのbase64エンコード
Lambdaプロキシの利用時にバイナリペイロードを処理するためには、Lambdaからのレスポンスをbase64でエンコードする必要がある。
– binaryMediaTypes
binaryMedi
Konnectの証明書の期限をLambdaで監視し、CloudWatch経由でメール通知する
API Gatewayの1つであるKong GatewayにはSaaS版があり、Konnectという名前で展開されている。
このKonnectでは証明書を登録し、管理する機能がある。
![20240916103714.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/547981/e44681f1-958c-2b26-9c5e-98fe6911cf27.png)Konnectはこの証明書の有効期限を監視・通知する機能を’24/9時点では提供していない。
しかし、APIによる期限の取得は可能となっているため、ユーザ自身が作り込むことで監視・通知することが出来るようになっている。
今回はこれを使って証明書の有効期限をLambdaで取得し、CloudWatchにメトリクスとして登録してアラート通知を受け取るようにしてみる。## Konnect APIの基礎
KonnectはAPIによる操作も可能で、操作にはPersonal Access Token(PAT)を使ってアクセスする。公式の説明ページは[こちら
[Amazon Web Services]LambdaでEC2の定期停止設定してみた
最近、個人AWSアカウントを活発に利用しており、EC2インスタンス台数が増加してきました。その中で、EC2利用後、ついついインスタンス停止を忘れてしまっており、余計なコストが発生しております。そこでLambdaを利用し、EC2の定期停止設定をしてみました。
## LambdaによるEC2定期停止設定の前提
\- 対象リージョンはバージニア北部であること(後続のコードを修正することで変更可能)
\- 定期停止対象のEC2に対して、タグ[key:EC2Auto_Stop, value:true]が付与済みであること## Lambda実行用IAMポリシー作成
まずはLambda実行用IAMポリシーを作成していきます。1.IAMコンソール>左ペイン「IAMポリシー」>右上「ポリシーの作成」を押下
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3822026/42b71a15-5695-5df1-aacb-5d218c1d4421.png)2.[アクセス許可を指定]にて、JSONで下
サーバーレスを小学生でも分かる様に解説する試み
## 従来の方式が抱えていた課題
昔のシステム開発では、オンプレミスのサーバーにOSをインストールし、その上にアプリケーションやミドルウェア(Webサーバー、DBMSなど)を設定するのが一般的でした。その後、仮想化技術の普及により、EC2などのクラウド上の仮想サーバーを利用するケースが増えました。しかし、これらの方式には以下のような課題があります。– (オンプレミスの場合) サーバーのハードウェア調達とOSのインストールに手間と時間がかかる
– OSやミドルウェアのインストール・設定に専門知識が必要
– OSやミドルウェアのバージョンアップ、セキュリティパッチ適用などの保守作業が必要
– 利用者がいない時間帯でもサーバーを起動し続ける必要があり、コストがかかり続ける
– スケーリングのために設定変更が必要で、トラフィックの増減に柔軟に対応しづらい
– ストレージについても、容量の見積もりや増設の作業が必要## サーバーレスの登場
こうした課題を解決するため、近年ではサーバーレスアーキテクチャが注目を集めています。主要なクラウドプロバイダーは以下のようなサーバーレス関数サービスを
コンテナイメージを使用した Lambda 関数を作成してみた
# 背景・目的
AWS Lambdaでは、コンテナイメージをサポートしています。こちらについて基本的な知識の整理と簡単な動作確認を行います。# まとめ
下記に特徴をまとめます。| 特徴 | 説明 |
|:–|:–|
|Lambdaのコード|下記で構成される
・スクリプト
・コンパイルされたプログラム
・上記の依存関係|
|デプロイ方法|デプロイパッケージを使用し、Lambdaに関数コードをデプロイする|
|Lambdaがサポートするデプロイパッケージ|・コンテナイメージ
・zipファイル|
|Lambda関数のコンテナイメージを構築する方法|・Lambda の AWS ベースイメージを使用する
・AWS の OS 専用ベースイメージを使用する
・非 AWS ベースイメージを使用する|
|Lambda の AWS ベースイメージを使用する|Lambda に AWS ベースイメージの 1 つを使用して、関数コードのコンテナイメージを構築する
ベースイメージには、Lambdaでコンテナイメージを実行するために必要な言語ラン
AWS Lamba関数をテストする際にbodyの書きかた
AWS LambdaとAPI Gatewayを使ってAPIを実装するユースケースは多いと思います。
自分がLambda関数のテスト機能を使う際に、リクエストの「`body`」の書き方で詰まってしまったので、その時の解決法を共有します。
# 問題点
テスト機能を使ってLambda関数を実行しようとした際、以下のような形式でリクエストを送信したところ、エラーが発生しました。
“`json
{
“body”:
{
“userId”:”test20240822@test.com”,
“displayName”:”test20240822″,
“email”:”test20240822@test.com”
}
}“`
この形式で送ると、Lambda関数内で`body`の内容がパースされず、以下のようなエラーメッセージが表示されることがあります:
“`
{
“errorMessage”: “Could not parse request body into json: Unexpected