- 1. Lambdaの明瞭な出力ログ [Python, Node.js]
- 2. Terraformを使ってEC2インスタンスの自動起動/自動停止環境を構築する
- 3. API Gateway の API バージョン指定(ベースパス)で Lambda の処理を分岐させる
- 4. Amplify CLIでLambda関数を定期実行させる方法
- 5. AWS Lambda Layer(レイヤー)を作成する方法
- 6. Visual Studio Code 上でAWS Lambda が編集できるようになるまで
- 7. AWS Organizations 内のアカウントリストを組織構造と一緒に csv 出力する
- 8. チャットからLambda関数の実行を予約する
- 9. Amazon Connect と、LambdaやLexとの連携方法
- 10. lambdaとは一体何者か。
- 11. 【AWS】Go Lambdaのローカル開発環境を作る ( aws-sam-cli + M1mac )
- 12. Lambda Layersで自作モジュールを共通ライブラリ化する [Python,Node.js]
- 13. AWS Lambdaから別Lambdaを呼び出す際にPickle形式でデータをやりとりする
- 14. AWS Lambda(Python)でmultiprocessing【Python,Lambda】
- 15. AWS Lambdaで環境変数のTZは指定しないほうが良いかもしれない件
- 16. AWS IoT Coreに証明書を使わずユーザー名/パスワード認証で接続する
- 17. lambdaからECS:RunTaskを使用し、Taskを起動する
- 18. Serverless Framework
- 19. AWS Lambda は、Amazon SQS、Amazon DynamoDB、Amazon Kinesis をイベントソースとするイベントフィルタリングをサポートしました
- 20. lambda 関数作るときのメモ
Lambdaの明瞭な出力ログ [Python, Node.js]
#はじめに
Lambdaの出力ログは、CloudWatchLogsで確認しますが、json形式の明瞭なログ出力を書き留めます。#Python
DynamoDBの数値を取り出す際、データとしてDecimal(数値)として取り出されますが、json.dumpsを実行すると、エラーが起きました。
そのため、Decimalを取り除くロジックをつけています。`ensure_ascii=False`は、文字化け対策です。
“`python
import json
from decimal import Decimal# json形式でログを出力するため、Decimalがある場合取り除く
def decimal_to_int(obj):
if isinstance(obj, Decimal):
return int(obj)def lambda_handler(event, context):
print(“Received event:” + json.dumps(event, default=decimal_to_int, ensure_ascii
Terraformを使ってEC2インスタンスの自動起動/自動停止環境を構築する
# はじめに
もう何番煎じかわかりませんが、EC2インスタンスの自動起動・停止を実現する環境が欲しくなったので構築します。
会社で検証に使っているAWS環境が1週間ごとに消えてしまう仕様なので、毎回手動で設定しなくてもいいように**Terraform**を使って環境構築の自動化を行いました。# 実現したかったこと
* AWS EC2インスタンスの自動起動・停止を行い、利用料を削減する
* 平日の9:00〜21:00の間だけ稼働させる。ただし休日に作業したい際や、夜通し動かしたいといった要件に備えて柔軟にスケジュール設定できるようにしておく
* 検証環境のため、対象サーバは基本全部。インスタンスが増えてもコードや設定をいじらずに対応できるようにする。また一応特定のインスタンスをターゲットにできるようにしておく
* できる限り最小限の稼働で環境構築を行う# 成果物と使い方
以下のGitLab.comに今回作成したコードをあげています。
「とにかく使えればいい」場合はこちらからcloneなりforkしてREADMEを参照の上お使いください。
突貫工事のため、コードが汚いですがご了承く
API Gateway の API バージョン指定(ベースパス)で Lambda の処理を分岐させる
## はじめに
ある API で v2 と v3 を並行稼働させることになりました
URL は以下の想定
– https://xxx.com/v2/some_items
– https://xxx.com/v3/some_itemsv2 と v3 を個別の REST API やステージとして構築すれば簡単に実装できます
しかし、この API では API_KEY を使った使用量制限などを行っているため、
個別に実装してしまうと、 v2 と v3 で API_KEY を別々にしなければなりません– 全ユーザー用に新しい API_KEY を発行する必要がある
– ユーザーは新しい API_KEY を使う必要がある
– 新旧どちらの API_KEY も発行できるようにシステム改修する必要があるそこで、 v2 も v3 も同じ REST_API 、ステージに設定した上で、
ユーザーがアクセスしてきた URL によって処理を分岐させることにしましたこれにより、ユーザーは同じ API_KEY のまま URL を変えるだけで移行が可能になります
この実装のため、検証した内容
Amplify CLIでLambda関数を定期実行させる方法
# Amplify CLIでLambda関数を定期実行させる方法
## 注意点
先に注意点を書いておきます。
`amplify add function`の時点で、定期実行の設定をする必要があります。
「え、更新すればいけるやろ?」と思いますが、私はできませんでした。
また、調べても`amplify add function`の時点で設定している記事しか見つかりませんでした。
**もし後からでも設定できる場合は、教えてください。**## Amplify CLIでLambda関数を定期実行させる方法
**amplifyの環境が設定済みという前提で書いています。**
もし`amplify`がわからない場合は、こちらを参考にしてください。
[Amplify SNS Workshop](https://amplify-sns.workshop.aws/ja/)最初に`amplify add function`を実行します。
そうすると、以下の基本的な設定の質問が出てきます。
### 基本的な設定“`bash
? Provide a friendly name for your r
AWS Lambda Layer(レイヤー)を作成する方法
## Lambda Layerとは
複数のLambda関数に、共通の外部ライブラリやビジネスロジックを追加できる仕組みです。
1つのLambda関数に、5つまでLayerを追加できます。
しかし、Layerのサイズには、制限があります。## Lambda Layerを作成する方法
### nodejsディレクトリを作成する
ディレクトリ名は必ず**nodejs**にする必要があります。
(それ以外の名前では、ダメだと思います。)### 必要なライブラリをインストールする
“`bash
npm init
npm install (必要なライブラリ)
“`
`npm init`と`npm install (必要なライブラリ)`を行い、`node_modules`ディレクトリが作成され、中にインストールしたものが入っていれば大丈夫です。### zipにしてアップロードする
上記で作成した`nodejs`ディレクトリをzip形式にして、アップロードします。
アップロードする場所は、`AWSのコンソール`→`Lambda`→`レイヤー`→`レイヤーの作成`の順に進むと、アップロー
Visual Studio Code 上でAWS Lambda が編集できるようになるまで
### Visual Studio Code 上でAWS Lambda 編集できるようになるまで
(自分用のメモとして残しておきます)
タイトルの通りです。
AWS Lambdaを学習中ですが…Lambdaだとソースが見にくい…
ので、Visual Studio Code 上で以下のことができるようにしました。
・ソースのダウンロード&直接編集
・テストの実行
・(編集した)ソースのアップロード### 事前準備
(1) Visual Studio Code のインストール
https://azure.microsoft.com/ja-jp/products/visual-studio-code/(2) Visual Studio Code のプロキシ設定(※必要な場合のみ)
(記載例:http://userName:password@proxy.xxxTsts.jp:8080 )
(記載場所) ![無題3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2518095
AWS Organizations 内のアカウントリストを組織構造と一緒に csv 出力する
## はじめに
AWS Organizations でマルチアカウント管理していると、アカウントの一覧を定期的に取得したいときはありませんか?アカウント情報だけではなく、所属する OU の情報も一緒に出力する方法を紹介します。
## 実はコンソールから csv をダウンロードできる
コンソール上でも通知が出ているように、最近組織内のアカウントリストを csv 出力することができるようになりました。アクションから「アカウントリストをエクスポート」でダウンロード可能です。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/125105/1333de19-3353-0d66-e9af-375ee8c6ba97.png)
これはこれでとても便利なのですが、2022年1月時点では以下の問題があります。
### コンソールからしかダウンロードできない
AWS CLI や SDK 経由でダウンロードができないため、定期的に取得したいといったケースでは自動化が困難です。以下のドキュメントに記載が
チャットからLambda関数の実行を予約する
#はじめに
LINEからLambda関数の指定時刻実行を予約したかったのでLambda関数を作成しました。#つくるもの
###イメージ
![訓練時.drawio (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2457109/4e3230bb-7a9b-559f-befb-7b9a711ebe3d.png)* LINEから受け取ったメッセージを基にLambdaでboto3を実行し、指定のLambda関数を実行予約するEventBridgeルールを作成します。
* 定期実行ではないため実行予約1つにつき1つのEventBridgeルールを作成します。
* ルール名は<Lambda関数名-実行時間>とし、この関数から作成された事を示すためのTagと実行時刻(UTC)Tagを付与します。
* Tagを参照しこの関数から作成されたEventBridgeルールの中で、実行済みのEventBridgeルールをチャットから一括削除出来るようにします。
* 実行対象に取れる関数のリージョンは1つのみです(
Amazon Connect と、LambdaやLexとの連携方法
#はじめに
下記のような構成で、connectのシステムを構築した際、
お問い合わせフローから、LambdaやLexを使用する際のパラメータの渡し方などのまとめます。パラメータを`問い合わせ属性`と呼びます。
>Amazon Connectでは、顧客とのやり取りはそれぞれ問い合わせ として処理されます。やり取りには、音声通話、チャット、または Amazon Lex ボットを使用した自動的な対話があります。
各問い合わせは、特定のやり取りに固有の、いくつかのデータを保持することができます。このデータは、問い合わせ属性としてアクセスされます。
例:
– 顧客の名前。
– エージェントの名前
– 電話やチャットなど、問い合わせに使用されるチャネル
– その他![スクリーンショット 2022-01-30 18.01.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/988747/b63d3fb3-8a3b-7ace-2fe4-82400f4d9b26.png)
#Connectのお問い合わせフロ
lambdaとは一体何者か。
##目的
めも。labmdaを名前しか知らなかったので軽く調べた。##lambdaとは
* サーバーレスでプログラムを実行できるAWSのクラウドサービス。
* あるイベントが発生したら、プログラムを実行するなどの関数(=lambda関数)を
定義しておくことで、自動でプログラムを実行してくれる。* 使用状況は、関数に対するリクエスト数とコードの実行時間に基づいて決まる、従量課金制。
無駄なコストがかからない。##そもそも”サーバーレス”とは
Webサービスの開発に必要なサーバーの構築や保守をしなくても、サーバー上でプログラムを実行できること。“レス”と言っているが、サーバーが必要ないわけではなく、管理が必要ないことを指す。
サーバーレスにも種類があってその中の一つがFaaS(Function as a Service)と呼ばれるサービスである。lambdaもFaaSである。
##FaaSの特徴
* イベントドリブン式
* イベントごとに実行されるコードを書く
* 開発費用を抑えられる
* イベントが発生すると処理が動くので、動いた分だけ払えばOK
【AWS】Go Lambdaのローカル開発環境を作る ( aws-sam-cli + M1mac )
# はじめに
`aws-sam-cli`を利用すれば、手元の端末内にLambdaの実行環境を再現して、動作検証できる。
手元でコードを修正しながらその場で動作確認できるため、ディプロイの手間とLambdaの費用を削減できる。
nodejsとpythonの導入手順は多い中、Golangのドキュメントが少ないように感じたため、ここで纏める。### やること
* 開発用にarm版Golangをローカル環境にインストールする
* `aws-sam-cli`でローカル環境にLambdaとAPIGatewayを構築する### 前提
* arm版(M1チップ)の`macOS`環境をベースに説明する (goenv導入部分以外は大差ないはず)
* Z shell (zsh) をベースに説明する (環境変数の通し方以外は大差ないはず)
* Dockerは既にインストールしてあるものとして説明する# もくじ
1. Golangをセットアップする
* aws-sam-cliをセットアップする
* ローカル環境でLambdaを起動する# 1. Golangをセットアップする
#
Lambda Layersで自作モジュールを共通ライブラリ化する [Python,Node.js]
#はじめに
Lambda Layersを用いることで、モジュールを共通ライブラリとして、複数のLambdaで使用できるようなので、PythonとNode.jsのパターンで方法をまとめます。メリットとして、Lambdaのソースコードの量を減らすことができること、各Lambdaごとにモジュールをアップする手間がなくなることがあげられます。
Lambda Layersについて
>Lambda レイヤーは、追加のコードやデータを含めることができる .zip ファイルアーカイブです。レイヤーには、ライブラリ、 カスタムランタイム 、データ、または設定ファイルを含めることができます。レイヤーを使用すると、コードの共有と責任の分離を促進し、ビジネスロジックの記述をより迅速に繰り返すことができます。#自作モジュールのディレクトリ構造
Lambda Layersにアップロードされたモジュールは、`/opt`の領域に展開されます。
そのため、指定されたディレクトリ(`下記の表参照`)にPythonモジュールを格納してアップロードすることでLambdaを実行した際にモジュールとして自動的に読み込
AWS Lambdaから別Lambdaを呼び出す際にPickle形式でデータをやりとりする
Lambdaから別Lambdaを実行するのはアンチパターンにも載っている方法ですが、やってみたので書いておきます。
https://aws.amazon.com/jp/blogs/news/compute-operating-lambda-anti-patterns-in-event-driven-architectures-part-3/
# 呼び出し元
FooのdataclassをいくつかリストにしてPickle形式にシリアライズして送信先のLambdaに送信しています。
返り値もPickleで返ってくるので読み込んでプリントします。“`py
import json
import pickle
from typing import List
from dataclasses import dataclass
from datetime import datetime
from base64 import b85decode, b85encodeimport boto3
@dataclass
class Foo:
i: int
d: datetim
AWS Lambda(Python)でmultiprocessing【Python,Lambda】
# はじめに
Lambda高速化のためのmultiprocessingを使った並列処理です。パッと使いたいときの自分用テンプレです。
# 実装
LambdaのPython3.6です。“`python
import json
import boto3
from multiprocessing import Process, Pipe
import timedef worker(conn, num):
# ここに処理を記述
# boto3を使う場合
# session = boto3.Session()
# s3 = session.client(‘s3′)
print(num)
response = f’process: {num}’
time.sleep(1)
conn.send(response) # 処理結果
conn.close()def lambda_handler(event, context):
results = []
processes = []
AWS Lambdaで環境変数のTZは指定しないほうが良いかもしれない件
##はじめに
Lambdaで現在日時を取得する際は、
リージョン関係なくデフォルトでUTCとなっています。そのため業務等では扱いやすいようにJSTに変換して運用するかと思いますが、
その方法で2022年1月現在、よく見かけるのが2パターン存在します。本記事はPython3.9を使用していますが、
他の言語に読み替えていただいても内容は問題ありません。##1.Lambdaの環境変数でタイムゾーンを設定する方法
まずは環境変数なしで取得してみます。
![スクリーンショット 2022-01-28 18.36.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/392337/2f5a7920-6d0c-6973-6e14-63b00bc016e7.png)
“`python
from datetime import datetimedef lambda_handler(event, context):
current_at = datetime.now().strftime(‘
AWS IoT Coreに証明書を使わずユーザー名/パスワード認証で接続する
AWSのIoT Coreに接続するためには、証明書が必須と思っていましたが、カスタム認証を使うと、ユーザー名とパスワードで認証ができます。
証明書を使った認証は、IoT Coreが自動でやってくれますが、ユーザー名とパスワードによる認証の場合は、認証用のLambdaを作成して認証を行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1180441/616cd98d-052f-48e1-3502-978d313630e1.png)
※図は公式ドキュメントからの引用です。MQTT接続で行う場合には以下の制約があります。
* 接続ポートはMQTTSの8883ではなく443である必要がある
* ALPN拡張に`MQTT`の値を指定する必要があるhttps://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/custom-auth.html
> オーソライザーを呼び出すには、MQTT とカスタム認証を使用して AWS I
lambdaからECS:RunTaskを使用し、Taskを起動する
業務でLambdaの実行時間に引っかかる処理を切り分けるためにLambda->ECSTask実行を行いました。
ServerlessFlameWorkを使用したNode.js/TypeScript環境でECSのTaskを実行する手順です。
Python3&boto3を使用した記事は[こちら](https://qiita.com/ken992/items/1d4ee5e33c04744d1d1c)です。## 環境
“`
Node v14.7.0
“typescript”: “^4.1.3”
“serverless”: “^2.23.0”,
“serverless-esbuild”: “^1.17.1”,
“`## 結論
“`typescript:ecsTask.ts
import { ECSClient, RunTaskCommand, RunTaskCommandInput } from ‘@aws-sdk/client-ecs’;const client = new ECSClient({
region: ‘ap-northeast-1’,
});cons
Serverless Framework
[Serverless Framework](https://www.serverless.com/) とは、AWS などでサーバレスのサービスを作る手順を省略するツール。自分で CloudFormation を書くより簡単。よく似たツールとして AWS SAM というのもある。
インストール。開発に使う node と混ざるのが嫌なので standalone binary を選んだ (実際には node_modules があるとそちらを優先して使うようだ)。~/.serverless/bin にインストールされるので .zshrc の読み込みが必要。
curl -o- -L https://slss.io/install | bash
AWS 環境の選択。AWS_PROFILE や AWS_DEFAULT_REGION の region 設定は無視されデフォルトの region は us-east-1 になるので注意。
export AWS_PROFILE=hoge
## ドキュメントの構成
ドキュメントは https://www.serverless.c
AWS Lambda は、Amazon SQS、Amazon DynamoDB、Amazon Kinesis をイベントソースとするイベントフィルタリングをサポートしました
# はじめに
https://aws.amazon.com/jp/about-aws/whats-new/2021/11/aws-lambda-event-filtering-amazon-sqs-dynamodb-kinesis-sources/
> AWS Lambda は、イベントソースとして SQS、DynamoDB、Kinesis のコンテンツフィルタリングオプションを提供するようになりました。イベントパターンのコンテンツフィルタリングでは、お客様が指定したフィルタリング条件の下で、SQS、DynamoDB、Kinesis からのみ Lambda 関数がトリガーされるような複雑なルールを書くことができます。これにより、お客様の Lambda 関数へのトラフィックを減らし、コードを簡素化し、全体的なコストを削減することができます。
>
> お客様は、SQS、DynamoDB、Kinesis をトリガーとする Lambda 関数のためにイベントソースマッピングを作成または更新する際に、最大 5 つのフィルター条件を指定することができます。フィルターの組み合わせは、デフォルトで
lambda 関数作るときのメモ
### 1. 概要
lambda関数作成するとき、忘れてググるやるまとめる
### 2. 目次
– [1. 概要](#1-概要)
– [2. 目次](#2-目次)
– [2.1. layer の追加](#21-layer-の追加)
– [3. 参考](#3-参考)#### 2.1. layer の追加
1. `pip install -t {dir_name} {package_name}` でパッケージをdir_nameにインストールする
* dir_name を python にする事で、lambda関数内でパスを指定する必要がなくなる
2. `zip -r9 layer.zip python` で zip化する
3. AWS コンソールからレイヤーの作成→zipをアップロードする
4. arn を取得し、レイヤーの追加でarnを指定する### 3. 参考
* [Lambda レイヤーの作成と共有](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.htm