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

CloudFront Functions の活用パターン集

# はじめに

CloudFront Functions（以後CF2）は、L@Eと異なり、軽量のため、L@Eより優先して使用を検討する必要がようなので、CF2について使用パターンをまとめました。

ビューアーレスポンスは使用しなかったため、ビューアーリクエストのみのパターンになります。

# CF2とL@Eの比較

| 1 | 2 | 3 |
|:-:|:-:|:-:|
| | CloudFront Functions | Lambda@Edge |
| ランタイムサポート | JavaScript(ECMAScript 5.1準拠) | Node.js、Python |
| 実行場所 | 218 以上の CloudFrontエッジロケーション | 13 の CloudFrontリージョンのエッジキャッシュ|
| CloudFront トリガー | ビューアリクエスト / ビューアレスポンス | ビューアリクエスト / ビューアレスポンス / オリジンリクエスト / オリジンレスポンス |
| 最大実行時間 | 1 ミリ秒未満 | 5 秒 (ビューアトリガー)

AWS Lambda Function URLsでEverything(It’s you)をおうむ返しするLINE bot

Lambda関数をHTTPSエンドポイントから実行可能になったとのことで、LINEおうむ返しbotを作って「Everything(It’s you)」してみました。

https://aws.amazon.com/jp/about-aws/whats-new/2022/04/aws-lambda-function-urls-built-in-https-endpoints/

## 必要なもの

1. AWSアカウント（Lambda作成）
2. LINE Developers登録

## Lambda側

#### 関数の新規作成


こんな感じに作成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/119864/6cdef038-f

Serverless アーキテクチャでWeb API を構築するハンズオンをRubyで実装してみた

# 概要
AWSが提供している、[翻訳Web APIのハンズオン](https://pages.awscloud.com/event_JAPAN_Hands-on-for-Beginners-Serverless-2019_Contents.html)をRubyに変えて作ってみました。
※ハンズオン内ではpythonを利用されています。

# 前置き
ほとんどハンズオンの流れと同じため、AWS周りの流れは省略しています。

# 1. Lambda 単体で使ってみる
LambdaからTranslateを呼び出して「おはよう」を「Good morning」へ変換しました。
[Module: Aws::Translate](https://docs.aws.amazon.com/sdk-for-ruby/v2/api/Aws/Translate.html)

“`
require ‘json’
require ‘aws-sdk’

def lambda_handler(event:, context:)

translate = Aws::Translate::Cli

AWS Lambda HTTP APIでPOSTデータを取得・デコードする関数（関数URL対応）

## HTTP APIや関数URLでもPOSTデータを受け取りたい
手軽に実装できてお財布にも優しいHTTP APIですが、POSTデータを受け取るのに一手間必要です。
リクエストbodyはbase64エンコードされた状態で取得できるため、　デコード & jsonパースしてあげる関数を使えばOKです。

## コード
### Node.js
“`getBodyOnLambda.js
function getBodyOnLambda(event_body) {
let body_string_utf8 = Buffer.from(event_body, ‘base64’).toString(‘utf-8’);
//日本語が含まれる場合はdecodeURIする
//decodeURIComponentでは無くdecodeURIなのは、POSTされたデータの中に&が含まれているとJSON変換時にうまくいかないため
body_string_utf8 = decodeURI(body_string_utf8);
//パラメーター形式文字列のJSONへの変

【10分AWSハンズオン】ExpressをAWS Lambda+API Gatewayにデプロイする

# やること

Lambda 上の Express にアクセスできるようにする。

# 学べること

* サーバレス Express アプリケーションの作り方
* Lambda へのデプロイ
* API Gateway と Lambda の連携

# 扱わないこと

* Infrastructure as Code
* TypeScript
* CI/CD

# STEP 1 : Serverless Express

1-1. 適当なディレクトリに Node.js プロジェクトを作成し、必要なパッケージをインストールします。

“`sh
$ npm init -y
$ npm i express @vendia/serverless-express
“`

:::note warn
`Node.js` がインストールされている必要があります。
`n` という Node.js のバージョン管理ライブラリを使用するのがおすすめです。
Mac を使用している方で、Homebrew がインストール済みの方は、以下のコマンドで Node.js をインストールできます。

“`sh

【初心者】AWS Lambda Function URLs (関数URL) を使ってみる

# 1. 目的
– たまには新機能のキャッチアップもしないといけないと思い、ちょっと便利そうなAWS Lambda Function URLs(関数URL) を使ってみることにした。

# 2. やったこと
– 「[PokeAPI](https://pokeapi.co/)」(ポケモンデータの検索ができる公開API)にアクセスしてデータを取得するLambda関数を作成し、関数URLの機能を有効にして、インターネットからアクセス可能なURL(関数URL)を設定する。
– 上記のURLに対してブラウザからアクセスする。Lambda関数が実行されて、ポケモンデータの取得が行われ、結果が表示できることを確認する。

# 3. AWS Lambda Functions URLs とは（自分の理解）
– インターネット上にエンドポイント(関数URL)を作成し、そこをたたくことでインターネット経由(https経由)でLambda関数の実行が可能な仕組み。
– 従来は同様のことをやりたい場合、API Gatewayが必要だったが、場合によっては省略することができる。

# 4. 構成図

![func

GuardDutyの脅威検出結果をSlack/Teamsに通知する

# 初めに
生産技術部で製品の検査工程を担当しているエンジニアです。AWSのセキュリティ対応のため、GuardDutyを利用しています。GuardDutyを利用することで、悪意のあるアクティビティや異常な動作を継続的にモニタリングすることができます。しかし、検知した結果に気が付かなければ意味がありません。チャットツールに結果を転送することで、早急な対応ができる体制を目指します。

# Slack/Teamsへの通知方法
脅威を検知した結果は、自動的にEventBridge(旧Amazon CloudWatch Events)に送信されるため、EventBridgeでイベントをトリガします。

* Slackを利用されている場合は、EventBridgeからSNSに転送します。SlackはChatbotとの連携が可能なため、ChatbotをSNSのターゲットにします。
* Teamsを利用されている場合は、LambdaをEventBridgeのターゲットとし、Lambdaで結果を加工してIncoming WebhookでTeamsに転送します。

![guardduty-notifica

Cost Explorer API でアカウント毎に日別の請求額を取得する

## モチベーション
Cost Explorer API を使用してアカウント毎に DAILY の請求額を取得し、以下のようなデータを CSV で出力したい。

|Account Id|Account Name|2022/4/1|2022/4/2|2022/4/3| …|2022/4/30|
|—|—|—|—|—|—|—|
|000000000000|account-0000|42.792716528|40.124716527|43.123416527|…|50.922465287|
|111111111111|account-1111|32.263379809|30.235379809|31.263353594|…|22.133798094|
|222222222222|account-2222|751.71034839|720.51234839|772.62033294|…|651.71042035|
|333333333333|account-3333|4.6428|5.1234|7.8765|…|6.2234|
|44444444

【Serverless Framework】AWS Lambda構築手順

# まえがき
業務でServerless FrameworkでLambdaを構築する必要ができたので、構築手順をメモ。
# Serverless Frameworkとは
・Node.jsで記述したデザイン/設計書をもとに、各プロバイダ(AWS/GCP/Azure)上でサーバレスなリソースを構築できるフレームワーク。
# 環境構築
参考にさせていただいた記事。

https://serverless.co.jp/blog/25/

## Node.jsインストール
・Serverless Frameworkでは、Node.jsはv12以上が必要。

https://nodejs.org/ja/download/

## Serverlessインストール
“`
npm install -g serverless
“`
インストールされていることを確認
“`
% npx serverless –version
Framework Core: 3.15.2
Plugin: 6.2.2
SDK: 4.3.2
“`
「serverless」は長いので「sls」と省略してもOK。
“`

lambdaでEventBridgeなどからJSONで渡された中身をチェックする

下記をセットして、ログ出力されたJSONを見ながら実装する感じ

“`python
import logging
import json

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
logger.info(json.dumps(event))
return
“`

Runtime（ランタイム）とは？

# 使い方
例えばAWS Lambda関数で言語(実行環境)を指定する時に使用する。

“`
Function:
Runtime: python3.9
“`

# 由来
ランタイムという言葉の由来は
ランタイムライブラリ
ランタイムパッケージ
ランタイムエンジン
ランタイムモジュール
とのこと。

意味は**実行時に必要な物。**
略称として**修飾表現**が残ったから初見ではわかりにくいかも。

# 日本語でも同じ？
日本語でも値があれば**修飾表現**で足りることもあるから考え方は似ていると思う。

例えば
**帰宅時間 19:00**
**帰宅 19:00**

個人的には後者の書き方が簡潔で好きかな。
結びつけるとランタイムという略称にも賛同するようになってきた。

LambdaでDropboxにファイルアップロード

## データバックアップをcsv形式で外部ストレージに
例えば**RDS**や**DynamoDB**上のデータを定期的に抽出して外部ストレージに置いておきたい、しかも**S3**ではなく**Dropbox**に保存したいというケースがあったとします。
そこで、Lambdaから[Dropbox API v2](https://www.dropbox.com/developers/documentation/http/overview)を呼ぶ形で実装します。

以前書いた[PHPでDropbox APIを使ってアップロードする記事](https://qiita.com/tksnino/items/bcbde6eddcb553446f63)の応用となります。

### 利用するLambdaランタイム
– Python3.8

## 1. csvファイルを出力する
まずはデータベースから抽出したデータを整形してcsvとして出力する部分です。
`csv`ライブラリでさくっと。
“`python
import csv
#import os

file = ‘/t

LambdaをDockerコンテナイメージで動かす場合、rootユーザで実行されないらしい

ここにも記載されているが、`sbx_user1051`というユーザで実行しているらしい。
https://dev.classmethod.jp/articles/check-os-layer-because-change-amazon-linux-2/
（しかも`$HOME`などは設定されていない）

そのため、自前のDocker環境でroot権限を使用してコマンドが成功しても、Lambdaで起動時にエラーになる場合がある。
私が現在seleniumでchrome動かそうとしてこの問題にぶち当たっている。

Lambda(golang)でFargate Spotの終了通知を受けたECSのタスクをNLBから切り離す

# 初めに
生産技術部で製品の検査工程を担当しているエンジニアです。今回は、Fargate spot上のECSに中断通知が来た時のELBに対するDeregisterTargetの実行が保証されない課題に対して取り組みました。

Fargate Spotを利用する目的は、以下の資料にあるように、コスト削減が可能になるからです。
また、Fargateで立ち上げたECSのCapacity ProviderにFargateとFargate Spotを併用することで、システムの安定性とコスト削減を両立した仕組みを実現します。

https://d1.awsstatic.com/webinars/jp/pdf/services/202109_AWS_Black_Belt_Containers303-ECS-Spot-Fargate.pdf

# Capacity Providerの導入
参考実装：

https://github.com/TomoyukiSugiyama/ElasticStack/pull/35/files#diff-e294b70d2a4a1e225aa9f6a19dc7fff8

初心者がAWS Lambdaを活用してログインが必要なGoogle Formに自動回答するプログラムを作ってみた

みなさんこんにちは。コロナが収まったかと思えばまた蔓延したりとまだまだ大変ですね。

昨今は部活や大学、高校などで毎日体温を測定しGoogle Formなどで○○時までに提出するよう求められることがあると思います。僕も毎日(決まりでは)提出しないといけないのですが、根がズボラなのでサボりがちです。
こんなだらしない人間がこの問題を解決するにはプログラミングしかない！中学生の頃にHSP(Hot Soup Processor)を少し触った程度の初心者だけどプログラミングのいい勉強にもなるだろう、ということで毎日決まった時間に自動送信するプログラムを作りたいと思いました。

今回は、途中でログインが必要となるタイプのフォームに対してのプログラムです。**ただし、Google Workplace for Educationに登録されている大学のアカウントを用いたログインのため、Googleログインの途中で大学アカウントのログインページに移行しています。** そのためGoogleがHeadless操作を検知してログインできない、ということは起こりませんでした。一般のGoogleアカウントを用いた

NATインスタンス起動・停止のSlackスラッシュコマンドを作る

# はじめに
2,3年前に作成したスラッシュコマンドの詳細を、やっとこさですがまとめようと思います。
※ですので、一部情報が古い可能性があります。

# できること
/xxxnat status →NATインスタンスの状態を確認
/xxxnat start →NATインスタンスを起動
/xxxnat stop →NATインスタンスを停止

※実行結果が設定したSlackチャンネル全員に見える形で投稿されます

# 作ったもの（大きく分けて２つ）
1. NATインスタンスがstopped→runnninng/runnninng→stoppedに変わった時に通知するSlackbotを作る
2. 「/xxxnat start」「/xxxnat stop」と設定したチャンネルで発言すると、NATが起動/停止するWebhookを作る（「/xxxnat status」で今の状況も返してくれる）

# フロー
## 1. インスタンスステータス変化時に通知するSlackbot
![natbot_1.png](https://qiita-image-store.s3.ap-northeast-1

アプリ用EC2周りの構築でやったこと（２）　AutoScalingGroupの起動テンプレートVer設定

[「アプリ用EC2の構築でやったこと（１）　backup先のGolden image作成」](https://qiita.com/nsaito9628/items/bcb17830d4f547816896)の続きになります

前回同様にVPCまわり、セキュリティ、EC2、ユーザーアプリの話はありません

## 記事の内容
今回の記事では以下二つのLambda関数を説明します
* CloudformationでdeployしたAutoScalingGroupの起動テンプレートバージョンをLatestに変更する
* DLMの日次Backupで本番用AMIが更新されたら起動テンプレートのAMI Idも更新する

下図の赤枠部分に相当します

前回の続きということで図中ではBackup先リージョンでの操作を説明してますが東京にも同じ仕組みが実装されています

samでbuildとdeployをしていますが記事中では説明しません

![TP ver update.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/56

アプリ用EC2周りの構築でやったこと（１）　Backup先のGolden image作成

最近仕事でEC2を使ってユーザー部門向けWeb Serverを準備する機会がありました

直接運用に関わる立場ではないので、不具合が起きた場合にlog見てもらいつつも基本はstackのdeleteとdeploy(あとはaws lambda invoke)くらいで対応できるようにIaC化前提で構築しました

運用を考えたServer構築経験がないため調べることが多々あり印象に残った点を数回に分けて記録に残したいと思います

尚、VPCまわり、セキュリティ、EC2、ユーザーアプリの話はありません

[(お試しで初投稿した前回も本件の関連記事となります)](https://qiita.com/nsaito9628/items/62d82e534a34be2d5d37?utm_campaign=post_article&utm_medium=twitter&utm_source=twitter_share)

## 全体構成

今回詳細説明はしませんが投稿の背景となる全体構成について最初に説明します

通常は東京リージョンのEC2上でユーザー部門のアプリが動いています
EC2は開発用

CloudWatchLogsで取得したログを加工してEFSに格納するLambda作ってみた

# はじめに
日次でCloudWatchLogsからログを取得し、加工してEFSに格納する独自スクリプトを動かしてた。
だが以下の点でイケてないスクリプトでたちまち処理が失敗していた。

図1:既存構成

:::note alert
こんな感じ
・サービス利用増により、ログ量が莫大し処理が追いつかずにMaintenanceWindowsの**上限値5時間**をオーバしてしまう
・古き良き(?)シェル芸でログを加工しておりコードは煩雑化・処理は非効率で処理が行われてる
:::

## 実装方式

上記を解決するにはスクリプトを改修したり、そもそものサーバスペックを上げたりするといった流れになるがログ量は増える一方であったり、この処理のためにスペック上げるのは~~贅沢・贅肉すぎるし~~もったいないという形で以下で実装してみた

![image

LambdaのSecurityGroupが削除できなくて困った話

# はじめに
AWSの運用として、「このLambda使わなくなったから削除してー」と言われ、
リソースの削除後に、使われなくなったSecurityGroup（以下SG）も削除する。
というのはよくある運用かと思います。

その際に、SGが削除できない、正確にはLambdaのENIが自動で削除されなくて困った
という話になります。

# なにが起きたか
①　VPC内のLambdaを削除

②　Lambdaの実行ロールを削除

③　LambdaのSGを削除するために、
念の為、削除対象のSGがネットワーク・インターフェースにアタッチされていないか確認。
→あれ、まだ使われてるな…（削除したLambdaのENIが削除されていない）
時間かかってるだけかな、、明日になって確認してみるか。。
→翌日、まだアタッチされている。SGの削除を試みるも、もちろんネットワーク・インターフェースにアタッチされているため削除できない旨のエラーがでる。

# 原因
EC2などと同様に、Lambdaも削除後、使用していたENIも自動的に削除されるはずだが、
その際に、Lambdaの実行ロールを使用しているため、E