Lambda関連のことを調べてみた

Kinesis Lambdaにおける処理順序の保障

## Kinesisのシャード

Kinesis clientは挿入する各レコードに、partition keyを指定する。
Kinesisは、このpartition keyをハッシュ値を元に、どのシャードにレコードを入れるかを決定する。
シャード内では、レコードの読み取り順序が書き込み順序と同じになることが保証される。

## kinesis Lambdaの並行性について

Pararellizatino Factor は、1 Kinesis shardあたりにいくつのLambdaが張り付くかを意味する。
以下で設定する。

### デフォルトは、Parallelization Factor = 1

デフォルトで、1 Lambda per 1 Kineiss shard。
結果として、シャード内のレコードの処理順序は、書き込み時の順序と一致

サーバーレスはなぜ人気なのか

サーバーレスアーキテクチャが近年人気を集めているのには、いくつかの大きな理由があります。

## 管理の簡素化

サーバーレスは、サーバーやOS、ミドルウェアなどの提供や管理をクラウド提供事業者が行うため、開発者はコードの作成に集中できます。
これにより、アプリケーションの開発とデプロイのプロセスが簡素化されます

## 課金方式の柔軟性

サーバーレスは利用単位で課金され、処理のリクエスト数と実行時間に応じて料金が決まります。
これにより、サービスの利用頻度に応じてコストを削減できる可能性があります

## スケーラビリティ

サーバーレスアーキテクチャは需要に応じて自動的にリソースがスケールするため、トラフィックの急増にも迅速に対応できます

## 用途の多様性

サーバーレスは動的なWebサイトやモバイルアプリのバックエンド、簡単なデータ処理、新規サービスのスタートアップ、マイクロサービスアーキテクチャの実現など、さまざまな用途に適用可能です

## 注意点

ただし、サーバーレス単体ではプログラムの実行しかできず、データベースやストレージなどの他のサービスとの組み合わせが必

【AWS】S3に必要なファイルが全てアップロードされたことを確認してステートマシンを動かす実装例【Lambda】

## 初めに
前回の記事ではS3にファイルがアップロードされたことを契機にEventBridge経由でステートマシンを実行する方法を投稿した。
しかしステートマシンを動かすために必要なファイルが複数ある場合、S3のファイルアップロード契機だけだと1ファイルごとにステートマシンが実行されてしまい、不必要な実行がされてしまったり、誤った結果が保存されてしまう危険がある。
そのため、今回の記事ではステートマシンが必要とするS3のファイルが複数の場合で、それら全てのファイルが処理実行日に作成されたものか(昨日作成されたものをステートマシンで処理しようとしていないかどうか)を確認した後でステートマシンを実行する実装例を記載した。
※前回の記事
https://qiita.com/Nana_777/items/8dc23b9fc331ba7a7905

## 使うAWSサービス
・Amazon EventBridge
・Amazon S3
・AWS Lambda
・AWS StepFunctions

## アーキテクチャ図
![S3イベントplusLambda.png](https://qiit

AWS CDK for Goを使用して、Go言語で書かれたLambda関数を定期実行する

## はじめに

AWS CDK（Cloud Development Kit）は、クラウドリソースをコードで定義し、デプロイするためのオープンソースのソフトウェア開発フレームワークです。この記事では、AWS CDK for Goを使用してGo言語で書かれたLambda関数を定期的に実行するスケジュールを設定する方法を説明します。

## 前提条件

– AWSアカウントがすでに設定されていること。
– AWS CDKを操作するCLIがインストールされていること。

CDKのCLIのインストールについては[こちら](https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/cli.html)をご覧ください

## 環境

– Go 1.20

## プロジェクトの初期化

新しいディレクトリを作成し、その中に移動します。

“`bash
mkdir go-lambda-cdk
cd go-lambda-cdk
“`

以下のコマンドを実行して新しいCDKプロジェクトを初期化します。

“`bash
cdk init app –language=

s3にJSON読み書きを行うaws lambda に docker imageを cdkでデプロイしたメモ

[前回](https://qiita.com/hibohiboo/items/85b192ec15572c3dbffd)は代替ベースイメージからの作成を試した。
今回は、公式イメージを使ってS3へつないでファイルの読み書きを行うことをテストする。
[ソース](https://github.com/hibohiboo/aws-cdk-v2/tree/master/python-lambda-project)

## ディレクトリイメージ
“`
.
├─cdk
│ ├── bin
│ │ └── python-docker-lambda-s3.ts
│ ├── lib
│ │ └── python-docker-lambda-s3-stack.ts
│ └ package.json
└─python-lambda-project
├── s3Data
│ └── test.json
└─ s3
├── Dockerfile
├── lambda_function.py # lambdaで実行したいコード
└── requirem

AWS lambdaの新機能

AWSのLambdaでロギングについて新機能が追加されました！

>AWS Lambda では、JSON 構造化形式でネイティブにログをキャプチャし、ログレベルを調整し、Lambda 関数用の Amazon CloudWatch ロググループを選択できる高度なロギングコントロールを発表しました。
(公式サイトより引用)

# 変更内容
+ JSON形式でLambdaログを取得
+ ログレベルの制御
+ CloudWatchのロググループを選択

# JSON形式でLambdaログを取得
LambdaのログをJSON形式で管理できるようになったため、keyとvalueの値からログの検索がしやすくなりました。
また、Kibanaなどのダッシュボードで分析しやすくなりました。

# ログレベルの制御
ログレベルを変えるにはソースコードを変更する必要がありましたが、Lambdaの新機能でログレベル（INFO、WARNING、ERRORなど）を調整できるようになりました。
これによりデバッグがしやすくなりました。

# CloudWatchのロググループを選択
Lambdaがログを送るCloud

初めてのAPI-Gateway+Lambda

## 初めに
流行りのAWSの勉強をしているものの実際に動かしたことがなかったため手始めに5分で作れるレベルのアプリを作成してみました。
触ってみると理解が進むのと、作成も複雑ではないのでご活用ください。

## 対象の方
– AWSでLambdaを使って簡単なアプリを作成してみたい人
– API GatewayやLambdaを知っているものの動かしたことのない人

## やりたいこと
フロントからAPI-Gatewayに対してリクエストを投げ、API-GatewayからLambdaを呼び出し結果を返却するアプリの作成。
## 前提
– AWSのアカウントを作成済みであること。
## Lambda
– AWSマネジメントコンソールからLambdaで検索し、関数の作成を押下。
– 必要項目を入力し「関数の作成」を押下。
※関数名はお好みで指定して

GoのLambda関数のランタイムをGo1.xからprovided.al2に変更しました（Serverless Framework）

# はじめに

AWSサービスから以下のようなメッセージが来たので、Lambda のランタイムを`GO 1.x`から `provided.al2`に変更しました。
Web検索で調べたところ、SAMの記事に対して`ServerlessFramerwork（SLS)`の記事が少ないように感じたので、
その時の苦戦したところやわかりにくかったポイントをまとめておこうと思います。

“`
お客様の AWS アカウントに現在 Go 1.x ランタイムを使用する 1 つ以上の Lambda 関数があることを確認しましたので、ご連絡いたします。

Amazon Linux AMI のメンテナンスサポートが 2023 年 12 月 31 日に終了するのに合わせて、AWS Lambda での Go 1.x ランタイムのサポートを終了します [1]。Lambda は、provided.al2 ランタイムを使用して Go プログラミング言語を引き続きサポートします。provided.al2 ランタイムを使用すると、AWS Graviton2 プロセッサのサポートや、より小さなデプロイパッケージとより高速な

クロスアカウントのIAMロールの設定について（アシュームロールの設定）

# はじめに
業務としてクロスアカウントでRedshiftのData APIの実装をすることになりました。
その実装をするにあたって、IAMロール周りの設定がややこしかったため、自分の備忘録も兼ねて記事にしました。
この記事を読んでいただければ、クロスアカウントのIAMロール設定がわかると思います。

今回のテーマとなる構築として、
「アカウントAのLambdaを使用してDataAPIを実装」
→「アカウントBのRedshiftにクエリを投げる」
を想定しています。
その中で、本記事はIAMロールの設定だけにフォーカスしています。

AWSの他サービスで使用するクロスアカウントのIAMロールの設定も基本的な考え方は同じはずなので、お役に立てればと思います。

# 記事内の登場用語と略称について
登場用語
Redshift・・・列指向型のRDS、速い
Lambda・・・サーバレスのコンピューティングサービス、15分の壁
DataAPI・・・サーバレス、非同期実行でRedshiftクラスターにSQLクエリを投げられるAPI
IAMロール・・・The☆権限（AWSのエラー原因の超常連）

AWS SQSの実用について（メリット、注意点、パラメータ設定）

## はじめに
SQSの概要や設定項目の説明記事はたくさんありますが、実用面に着目している解説記事が少なかったので、今の自分の理解の記録を残す意味でも記事にします。ここで、あえて「SQSとは…」や、「設定項目の説明」などはせずにスキップします。

## SQSのメリット
なぜSQSを使うか。SQSメッセージの生成(プロデューサ)はLambda, API Gateway, SNS, S3イベントあたりが主なところで、メッセージの使用先(コンシューマ)はLambdaであるケースが多いと思います。しかし、ここで挙げたプロデューサからLambdaを実行することも可能です。つまりSQSをスキップできるアーキテクチャとなっているケースも多いです。ではなぜ、SQSを使うのでしょうか。
SQSを使うメリットとして一般的に、柔軟性、冗長性を持たせて処理を疎結合化すると言われます。そう言われても少し抽象的なので、その柔軟性、冗長性とは何なのかを具体的に挙げていきます。また、SNSとSQSは用途が被ることが多いので、SQSのメリットをSNSと比較しながら見てみましょう。

– **SQSの強み、メリット**

LambdaとRDSのセキュアな接続 ~SSL/TLS証明書の選択と実装~

最近、アーキテクチャにRDSのリードレプリカを組み込む作業を行ったのですが、Lambda(NestJS)からRDS(リードレプリカ)へのSSL/TLS接続を設定する際、以下のエラーメッセージが表示されました。

“`objectivec
Error: self-signed certificate in certificate chain
“`
この問題の原因と解決方法を備忘録として残します。

# 原因
単純に、使用する証明書が不適切だったのが原因でした。

## RDS Proxyを介する場合の証明書
元々の構成では、Lambda(NestJS)からRDS Proxyを経由してRDS(プライマリ)に接続しており、この場合には[`AmazonRootCA1.pem`](https://www.amazontrust.com/repository/AmazonRootCA1.pem)証明書を使用していました。

RDS Proxyを使用する際には、AWSが提供する`AmazonRootCA1.pem`というルート証明書が重要です。この証明書は、RDS Proxyの身元確認と通信の暗

node.jsでのdynamodb操作をまとめた（sdk v3）

# node.jsでのdynamodb操作まとめ

node.jsでのdynamodb操作操作をする機会があったため、各種操作方法をまとめておきます。
環境は以下です。

– node.js v18
– aws sdk v3

## 公式サイト

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-dynamodb/

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_lib_dynamodb.html

## 想定するDynamoDBスキーマ

– パーティションキー
– AccountType
– ソートキー
– user_id
– 属性
– role_id

## 共通

DynamoDBClientのみで頑張って書いても大丈夫ですが型定義など書かないといけないのでめんどくさいです。
DocumentClientを使うとスッキリかけます。
詳しくは公式サイトを確認してください。

Node18でLambdaからDynamoDBにデータを登録する関数を作ろうとしたら思ったより深い罠にかかった話。

## 前置き
業務で、「LambdaでJsonのデータをもとにDynamoDBにデータを投入する関数を作る」というタスクをいただきました。過去のQiita記事やインターネットの記事を参考にしましたが、どれもうまくいかず…
詳しく調べてみるとNode18ではインターネットに転がっている従来のソースではうまく動作しないことが多いようです。
そこで、本記事では私と同じ問題で躓いている方をお助けできるよう、また、自分の備忘録として、記事として残そうと思います。

## 結論
結論だけ見たい方、時間がない方向け。
シンプルなサンプルソースとサンプルJSONが以下となります。

#### サンプルソース
“`mjs:index.mjs

import { DynamoDBClient } from “@aws-sdk/client-dynamodb”
import { DynamoDBDocumentClient, PutCommand } from “@aws-sdk/client-dynamodb”;

export const handler = async (event) => {

AWS CDK – EFS での Python Lambda パッケージ管理

# 内容

[AWS CDK – Python Lambda Layer デプロイ](https://qiita.com/takmot/items/8c6aa3961f93102e2316) で、
外部パッケージを Layer や Lambda に組み込んだが、
Lambda に 250MB のサイズ制限があるため、
pandas 等、重いパッケージを入れるとすぐに制限に引っかかる
そのため、 EFS に外部パッケージをインストールし、Lambda から使用することでこれを回避する
EFS への外部パッケージインストールは ECS を使用する
また、CDKデプロイで自動的に環境を構築したいので、
Custom Resource で ECS Task を起動する

# 実装

## VPC

適当な VPC 環境一式と、
EFS と Lambda に割り当てる Security Group　を作成し、
インバウンドルールで Lambda から EFS へのアクセスを許可している

“`typescript:CDK実装
// VPC

ZappaでFlaskをLambdaにデプロイ

## はじめに
ご覧いただきありがとうございます！
zappaを使ってLambdaにデプロイする方法を自分の備忘録も兼ねて書いてみました。
初心者なので、間違いがあればご指摘いただけると幸いです。

## zappaとは？
zappaとは、AWS Lambda上でFlaskやDjangoなどのWebアプリケーションを簡単にデプロイできるフレームワークです。
zappaを使うとLambda関数やAPI Gatewayの設定など、複雑なAWSリソースのセットアップを自動的に行なってくれるため、手動で設定する手間を省いてくれます。

## 1. Flaskをインストール
pythonの仮想環境を用意してFlaskをインストールします。

“`
$ pipenv install Flask
“`
## 2.ファイルの作成
“Hello world!”を表示するファイルを用意します。

“`hello.py
from flask import Flask

app = Flask(__name__)

@app.route(‘/’)
def hello():

AWS LambdaでRubyのGemをレイヤーを使って利用する方法

# 概要
“`ruby:lambda_function.rb
def lambda_handler(event:, context:)
p “”.blank?
end
“`
AWS Lambdaで上記の関数を実行しようとすると、active_supportのGemがないので、undefined method blank?と怒られてしまいます。
上記のような関数も実行できるように、AWS LambdaでGemを使う方法をまとめてみました。

# ローカル環境での準備
Gemfileに `gem ‘activesupport’` を追加し `bundle install` します。
`bundle install`によってインストールしたファイルはこの後レイヤーにアップロードするので
`–path .` のオプションをつけてカレントディレクトリにインストールされるようにします。
“`
touch Gemfile
“`
“`:Gemfile
source ‘https://rubygems.org’
gem ‘activesupport’
“`
“`
bundle i –

【メモ】SAMのLambdaの記述

# 前提
Runtimeはpythonを指定。
今回使用したキー情報のみを記述。

## 記述例

“`yaml
AWSTemplateFormatVersion: ‘2010-09-09’
Transform: AWS::Serverless-2016-10-31
Resources:
# S3 Buckets
BucketName:
Type: AWS::S3::Bucket

# Lambda Functions
FunctionName:
Type: AWS::Serverless::Function # Serverless::FunctionがLambdaのこと
Properties:
Handler: app.handler #ここはファイル名.メソッド名で記述する。pythonの場合、app.pyのhandler関数を呼び出すということになる
Runtime: python3.11
CodeUri:

クロスアカウントでのECR参照

ECSやLambdaで自作のImageを参照する際、クロスアカウントでECRリポジトリを参照したい場合のメモ。
結局、どちらもECR側にPermissionを設定するだけで可能。
重要な注意点は、**リージョンを跨いでクロスアカウント参照することは不可能**という点です。

# Lambda

公式手順: https://aws.amazon.com/jp/blogs/compute/introducing-cross-account-amazon-ecr-access-for-aws-lambda/

## ECRのPermission

今回のLambdaが置いてあるアカウントのIDを222222222222とした際の例。

“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “CrossAccountPermission”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::2222222

AWS CleanRoomsのクエリを定期的に実行するLambda関数

## 記事の目的
AWS CleanRoomsのコラボレーションによるデータ共有は、共有する側/される側でCleanRoomsでクエリを実行できるレベルの知識やクエリ実行する手間が必要となるため、非エンジニアにデータ共有したいといった要件の場合は運用面でのハードルがある。
自動で定期的にクエリを実行するようにして、S3に保存されている結果ファイルだけを共有するようにしたいと思ったが、調べた限りCleanRooms自体にはクエリを自動的に定期実行する仕組みがない模様。
ということで、CleanRoomsのクエリを定期実行するLambda関数を作ってみた。

## 前提
### ローカル
– mac（Windowsの場合はコマンド等を適宜読み替え）
– Node.js バージョン20.x がインストール済みであること
– AWSの認証情報が設定済みであること

### AWS
– CleanRoomsのコラボレーションが作成済みであること
– 実行するクエリの分析テンプレートを登録済みであること
– 記事内のAWSマネコンのリンク東京リージョン

—
## ソースコード
htt

Lambda コンソール上での SAM テンプレート

## はじめに

Lambda コンソール上でSAM テンプレートを生成出来るようになったみたいです。

– Application Composer にエクスポート
– ダウンロード

上記のどちらかできるみたいです。

## ダイアグラム/テンプレートの切り替え
それぞれの切り替えについて記載します。

## ダイアグラム
元々はこのダイアグラムだけでした。
こちらは、Lambdaを中心にコンポーネントの関連付けを視覚的に表示したものとなります。
– API Gateway
– Layers
など


## テンプレート

対象のLambdaを SAM テンプレートで表示することができるようになりました。

![スクリーンショット 2023-11-15 15.31.31.png](https