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

LambdaでS3オブジェクトに独自メタデータの追加・更新を行う

# はじめに

LambdaでS3オブジェクトを制御したかったので、オブジェクトに独自のメタデータ(ユーザ定義メタデータ)を追加・更新して対処した。
本文では、ユーザ定義メタデータについて、実際のソースと実行結果について記す。

# ユーザ定義メタデータとは

Content-Lengthなどのオブジェクトの追加情報を`メタデータ`という。
メタデータには2種類あり、主にAWSシステム上で制御される`システムメタデータ`とユーザが独自で定義できる`ユーザ定義メタデータ`がある。
今回はファイルの上書き回数(メタデータ名を`x-amz-meta-count`とする)をユーザ定義メタデータとして定義する。

# Lambdaソース

下記LambdaをCloudWatchEventsなどをトリガーとして実行する。
指定したバケット、ディレクトリ配下のファイルを取得し、そのファイルのメタデータに`x-amz-meta-count`がなければ追加する。
あれば、メタデータの値を＋1する。
最後に追加更新した内容でファイルを上書き(copy_object())する。

“`python

im

AWS LambdaのNode.jsのランタイム更新時確認手順書

なかったんで用意しておきました。まだ本番環境でサポート期限間近のランタイムを使っている人は参考にしてください。
※当時はNode.js 8.10系が対象でした。

## TL;DR
– AWS Lambdaのランタイムの更新はダウンタイムがないので本番環境への適用もサービス稼働中でOK
– ランタイム更新時の動作確認は推奨
– 更新はAWSがランタイムサポートポリシーで定めている日付より前に実施する

## 手順
1. 本番環境以外の環境で本番環境にデプロイされている資源と同じものをデプロイする
2. デプロイした環境のLambdaのランタイムを上げる
3. 動作確認を実施
4. 問題なければ本番環境(ST環境　→　本番環境の順番でも)のLambdaのランタイムを更新する

## 気になるところ

#### 廃止(更新)をすぎても更新可能なのか
これについてAWSサポートに問い合わせてみました。
AWSサポート内の過去事例として、廃止(更新)以降でもランタイムの移行(サポート対象バージョンへの移行)が可能だった例があったそうですが、ドキュメントにも明記がないように、それが必ずしも可能と

[Node.js]Google Cloud Functionsでimport/exrpot構文を使う

#Overview

フロントエンドはReact、バックエンドはNode.jsで作っていると、どちらでも利用する処理はソースコードを共有したくなります。
別の記事でesmというパッケージを知り、Google Cloud Functions(以降、GCF)でもimport/export構文を使いたくなりました。
GCFのフレームワーク内で動くから厳しいかな？と思っていたのですが、至って簡単だったので残しておきます。

#Target reader

– JavaScriptとNode.jsでソースコードを共有したい方。

#Prerequisite

– バックエンドはGCFを利用する、つまりNodeの起動オプションを指定するようなことはできない。
– Node.jsのバージョンはGoogle Cloud Function(GCF)に依存し、現時点ではV10系とする。

#Body

##どうしてimport/export構文にするの？

私のPJの場合、バックエンドで作成した機能をフロントエンドで実行するかも？という機能がいくつかあります。
そうなるとどちらも同じJSだし、フロント

Lambdaにライブラリを乗せるときにLayersを使ったら便利

Lambdaにデプロイするときライブラリも一緒にデプロイする場合があると思いますが、いざデプロイするとちょっとした修正がコンソール上でできず、ちょっとめんどくさかったです。
それについてぼやいたらLayersを使えばどうかとアドバイスをもらったので、その備忘録。

## デプロイする関数
APIをちょっとたたく関数。言語はPython。

## LambdaのLayers機能
公式。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html
ライブラリをレイヤーとして取り込め、共通ライブラリとして利用できる。
そのためLambda関数にライブラリを取り入れる必要がない。
他のユーザが公開してるLayerも使えるらしい。

## そのままデプロイすると
ライブラリだけで4.5MBでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/452110/5c17653e-7869-eb74-e0b

DynamoDBのチュートリアルを読み解く【5: トリガーを作成してテストする】

# はじめに

今回も[DynamoDBのチュートリアル](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html)を実施しました。
最後はLambdaでのトリガー作成です。

（バックナンバー）
[1.DynamoDB テーブル作成](https://qiita.com/kkino1985/items/f9091c1e1efb35009ce7)
[2.IAMポリシー/ロール作成](https://qiita.com/kkino1985/items/a087bc3077f36b4b1e21)
[3.SNSトピック作成](https://qiita.com/kkino1985/items/f40d950cfd6d464635fa)
[4.Lambda関数作成/テスト](https://qiita.com/kkino1985/items/4850f4bba7b8418c2cc8)

# 5.1 トリガー作成用ARN情報取得

今回はDynamoDB

LambdaバージョンをAWS CDKで構築する際にハマったエラー

## 概要

Lambda functionとそのバージョンの発行をAWS CDKにて構築する際に「Lambdaコード更新と発行されるバージョン番号の関係」を正しく理解できず、エラーに悩みました。

そこで、AWS CDKでLambda functionとそのバージョンを発行する場合の挙動について検証しました。

本記事では、これらの検証結果とその解説を記述しています。

## サンプルコード

以下GitHubにて公開しています。

[YoshinoriSatoh/o-aws-lambda-version-cdk](https://github.com/YoshinoriSatoh/o-aws-lambda-version-cdk)

## Lambda Version

Lambda versionについては、以下参考記事でも説明されています。

[https://qiita.com/quotto/items/4c364074edc69cb67d70](https://qiita.com/quotto/items/4c364074edc69cb67d70)

また、公式ドキュメント

(AWS) API GateWay + Lambda でAPIを実行してみた。

# Amazon API GateWay を使って、Lambdaで作成した関数を実行してみました。

＜大まかな手順＞
– AWS Lambdaで関数作成
– Amazon API GateWayで API作成
– APIを実行して、レスポンスを取得

`LambdaとAPI GateWay作成のリージョンは「東京 (ap-northeast-1）」に設定して進めますので、事前にリージョンをご確認ください。`

## AWS Lambdaでの設定
ではさっそく始めます。
まず、Lambdaで関数を先に用意します。

Lambdaのコンソール画面にて、左側のメニューから「`関数`」→「`関数の作成`」ボタンをクリック。

—

関数作成ページが表示されるので「`一から作成`」にチェック→`関数名`入力→`ランタイム`選択→「`関数を作成`

DynamoDBのチュートリアルを読み解く【4: Lambda 関数を作成してテストする】

# はじめに

引き続き[DynamoDBのチュートリアル](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Streams.Lambda.Tutorial.html)を実施しました。
今回はLambdaです。

（バックナンバー）
[1.DynamoDB テーブル作成](https://qiita.com/kkino1985/items/f9091c1e1efb35009ce7)
[2.IAMポリシー/ロール作成](https://qiita.com/kkino1985/items/a087bc3077f36b4b1e21)
[3.SNSトピック作成](https://qiita.com/kkino1985/items/f40d950cfd6d464635fa)

# 4.1 Lambda用Javascriptファイル作成

javascriptは専門外なので深入りはしませんが、使われているメソッドをピックアップします。

‘use strict’;
var AWS = r

Amazon S3 と AWS Lambda を使って PPAP を回避します。

みなさん、PPAP をご存知ですか？
以前、流行した、ﾍﾟﾝﾊﾟｲﾅﾎﾟｰｱｯﾎﾟｰﾍﾟﾝ ではなく…

>PasswordつきZIP暗号化ファイルを送ります
>Passwordを送ります
>Aん号化（暗号化）
>Protocol

のことです。
https://www.jaipa.or.jp/event/isp_mtg/asahikawa_190912-13/190913-3.pdf

つまり、社外に添付ファイルを送る際に使われるプロトコルです。
このプロトコルにはいろいろと問題があるといわれています。
例えば、パスワードを送り忘れたら受信者はいつまでたっても開けません。
受信者はパスワード入りメールがくるまで待ってないといけません。
そして、そもそも、メールでパスワードを送ってよいのかしら。。。

そんな PPAP を使わないで済む仕組みを Amazon S3 と AWS Lambda で作りました。

## 予備知識
Amazon S3 には事前署名 URL というものを生成する機能があります。
これを使うことで、期間を指定して(執筆時点で最大7日)、URLを知ってる人だけが

LambdaのNode.js 12.xでimageMagickを使用する

# 初めに
Webアプリケーションから画像をアップロードする際にS3にファイルをputし、Lambdaでサムネイルを生成して公開用のバケットに保存する処理を構築していました。(前任者が・・・)
新たに同じようなシステムを構築するのに参考にしようとLambdaの関数のコンソールにアクセスすると以下のメッセージが表示されていました。
Node.js 8.10を使っているので変更しないといけないよう。(把握しとけよ)
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtime-support-policy.html

# 対応

EC2(インスタンス)が削除されて残ってしまったボリュームの削除

#問題
複数ボリューム持ちのAMIからインスタンス作成時、「終了時に削除」にチェックを忘れると、インスタンスを終了してもボリュームが迷子になって残る。
存在監視より定期的に掃除しましょう。

#lambda

“`python:python3.8
import json
import boto3

def lambda_handler(event, context):
client = boto3.client(‘ec2′, region_name=’ap-northeast-1’)

res = client.describe_volumes(
Filters = [
{‘Name’: ‘status’, ‘Values’: [‘available’]}
,{‘Name’: ‘tag:lambda’, ‘Values’: [‘delete me’]} #status条件だけで足りない時
]
)
#print(res)

for vol in re

AWSマネージドでEC2サーバ群の1台にcronする

AutoScalingなどEC2冗長化されたシステムにて、いい感じに1台だけからバッチしたい。
そう思ったときにサクッと出来る仕組みがなかったので作ってみました。

## 要件とアイデア
やりたいことは次のような要件です。

* EC2内でコマンド実行したい
– サーバ内ミドルウェアに依存した処理やDB接続などを行う場合、Lambdaでやるとsecretsや通信経路などややこしくなります。
* AutoScaling環境など、複数のEC2があるけど1台だけで実施したい
– 集計をしてDBに書き込むなどのようなバッチだと複数台から同時実行されると困ります。
* crontab置きたくない
– AutoScalingではcrontabを1台だけ有効など難しく、また全部に置いて排他を行うのもややこしい。

これらを以下のようにAWSサービスを組み合わせれば解決できそうです。

* CloudWatch EventsのタイマーでLambdaを発火させる
* LambdaにてEC2リスト取得＆1台だけ選ぶ
* 同Lambda内から、選んだ1台に対してSSM RunCommandでコマ

AWS Lambda + LINE Notify で帰宅時に傘を忘れないようにLINEへ通知する

# はじめに
誰でも一度は、会社や学校に傘を置き忘れてしまった経験ありますよね？
もし翌日に雨が降ったら傘がなくて絶望です。。。

そこで、**帰宅時に傘を忘れないようにLINEに通知してくれるシステム**を作りました！

# 完成物


以下の記事で紹介されている、雨だったら朝に傘を持つように通知するシステムをベースにさせていただきました。

[Python + AWS Lambda + Line Notify で自動で毎朝Lineに本日のお天気を通知してみた。](https://qiita.com/Yougurut/items/6c5f2bd6f3f29b1ae465)

上記に追加する形で実装し、**雨だったら朝に傘を持つように通知** ＋ **帰宅時に傘を持ち帰るように通知** という二段構えで雨の日をサポートします！

# シス

[新機能] AWS BackupがEC2のバックアップに対応しました

*AWS Backup* で *EC2* の *AMI* が対応されたと聞き、すぐに確認しました。
それまでは、Lambdaでバックアップを日次で取得していましたが、Lambdaの管理の煩わしさや、万が一バックアップが取れていなかった時の不安から解放されそうです。
では、確認していきましょう?

# AWS Backup
>[AWS 公式 AWS Backup](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/whatisbackup.html)

ざっくりいうと、AWS内の特定リソースのバックアップを、AWSマネージドで管理できるサービスですね。
基本的には、バックアッププランというものを作成して、ターゲットとなるリソースを指定することで、各サービスの

Go lambda のデフォルト環境変数

# はじめに
`AWS SDK for Go`をLambdaで使用する際に特に設定無しで使用できるので
多分アクセスキーとか環境変数にセットされているんだろうなーと思いつつも
実際に試したわけではないので検証してみました。

# 検証
## 検証コード

“`Go
package main

import (
“context”
“fmt”
“github.com/aws/aws-lambda-go/lambda”
“github.com/aws/aws-lambda-go/lambdacontext”
“log”
“os”
)

func init() {
log.Print(“init start”)
showAllEnv()
log.Print(“init end”)
}

func Handler(ctx context.Context) (string, error) {
log.Print(“handler start”)
if lambdaCtx, ok := lambdacontext.FromContext(ctx); ok {
log.P

よくある表情解析LINE Botを作った

Qiita を筆頭にいろんなエンジニアの方が既に作っているもので何番煎じか分かりませんが、個人的にサーバレスアプリケーションを作るのが好きなのと、Golang に慣れることを目的として LINE チャネルに画像を送ると表情解析してメッセージを返してくれる Bot を作りました。

## できたもの

こういう感じで本田翼さんの笑顔の画像を送ると

幸福度合いをポイント化して返してくれます。

Lambda関数に手を加えず、API GatewayのLambdaプロキシ統合を切り替えられるか

# はじめに

AWS APIGatewayとLambdaを使ったサーバレスのシステムで、Lambdaプロキシ統合を使用することで、API Gateway側で、Lambda側へ渡すパラメータを細かく設定することなく、Lambda側でコントロールすることが出来るメリットがあります。

このLambdaプロキシ統合を使った連携を前提に開発を行う場合、Lambdaでは、この仕様に沿ったインプットとアウトプットを実装をする必要があります。

参考までに、Lambdaプロキシ統合を利用する場合、Lambdaでは以下のようなインプットに対応した実装が必要です。

リクエストが以下のような場合

“`sh
curl -XPOST \
-H “X-Param-Header:2” \
-d ‘{“param”: 3}’ https://YourApiDomain/xxx?param=1
“`

Lambdaに渡されるパラメータ（*event*）は

“`json
{
“httpMethod”: “POST”,
“headers”: {
“X-P

Serverless Frameworkで行うLambdaのコールドスタート対策

# 概要
AWS Lambdaで発生するコールドスタートを軽減させる為の対策を実施します。

以前私が書いた、[Serverless FrameworkでLambdaのコールドスタート対策を行う](https://qiita.com/keitakn/items/d1c524a97dc844cb02cc) の2020年版です。

[Serverless FrameworkでLambdaのコールドスタート対策を行う](https://qiita.com/keitakn/items/d1c524a97dc844cb02cc) は少し前までのベストプラクティスでしたが今後はこの記事の方法が推奨されるようになってくると思われます。

# 対象読者
– [Serverless Framework](https://github.com/serverless/serverless) でAWS Lambdaの開発を行っている方

# Lambdaのコールドスタートについて
[こちら](https://qiita.com/keitakn/items/d1c524a97dc844cb02cc#%E3%82

【AWS/Lambda】lambdaに固定IPをつける/VPCに所属させる

「困ったら大体lambda（とS3）」「lambda イズ 仙道」、AWSの基本ですね（）
ただ彼は基本的に固定IPを持ちません。仙道同様、気まぐれです。
今回はそんな彼に**固定IPを付与する方法**をまとめます。
また、結果として**VPC＆サブネットへ所属させる方法**にもなります。
# どんな時に役立つか
例えば

– 申請式で特定IPからのアクセスしか認められないサービスとの連携
– インスタンス内で動くIP制限付きサイトの死活監視
– プライベートサブネット内のインスタンスと通信

※インスタンスそのものの監視はcloudwatchでどうぞ
# 構成図
以下の形です。
# 手順
手順的には大まかに以下の形です。
1. lambdaをVPC内のプライベートサブネットに設置
2. lambdaのロールにvpc、eniに関する権限

Elastic Beanstalk 指定時間だけインスタンスタイプを上げる

#改善
12:00~13:00のみ負荷のかかるElastic Beanstalkの環境がある。
インスタンスタイプの調整で費用を抑える。
PMから指示がなくてもインフラはそうする。

#lambda_function.lambda_handler

“`python:python3.8
import json
import boto3
from datetime import datetime

def lambda_handler(event, context):
envName = str(event[‘env-name’])

instanceType = ”
currHour = datetime.now().hour + 9

if currHour > 24:
currHour = currHour – 24

print(currHour)

if(currHour == 11): #11時代に上げる
instanceType = ‘c5.xlarge’
elif