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

Elasticsearch Service 6.8 に取り込んだログ（INDEX）を Curator で削除するメモ（Lambda Python 3.8 版）

Curator による取り込みログ（INDEX）削除の Elasticsearch Service 6.8 / Lambda Python 3.8 対応化メモを残しておきます。

**旧記事：**

– **[Elasticsearch Service (6.0/6.2) に取り込んだログ（INDEX）をCuratorで削除するメモ](https://qiita.com/hmatsu47/items/e4b8a5bd44de0bee1682)**

# 手順

## 1. IAM Role の確認／作成

ログ取り込みで IAM Role は作成されてるはずですが、なければ作成します。

* **[IAM Role の作成](https://qiita.com/hmatsu47/items/826b00ff008d4e3edecf#iam-role-%E3%81%AE%E4%BD%9C%E6%88%90)（以前の ALB/CLB 取り込みメモより）**

## 2. AWS Lambda ファンクションの作成

### Lambda にアップロードする .zip ファイルの作成（A

AWS+NodeJSでサーバレスな環境構築⑤

# はじめに
[前回](https://qiita.com/isacRU/items/b4ab67d12f2d2377aea8)ではAPI Gateway(REST API)+Lambda(NodeJS)+DynamoDBの組み合わせてCRUDを作りました。今回はS3+Lambda+DynamoDBを組み合わせていきます。S3をトリガー（S3バケットにJsonファイルがアップロードされた段階)にし、Lambda(NodeJS)で取得したJson形式のデータをDynamoDBテーブルに保存します。
表現等がわかりにくければ、容赦無くご指摘いただければ幸いです。
※サーバレスでピンとこない方は[こちら](https://qiita.com/isacRU/items/fe4751603d3da32b2daf#%E3%82%B5%E3%83%BC%E3%83%90%E3%83%AC%E3%82%B9%E3%81%A3%E3%81%A6%E3%81%AA%E3%81%81%E3%81%AB)をご覧ください。

# DynamoDBを作成
DynamoDBダッシュボード＞テーブルの作成

Lambda＋API GatewayのレスポンスをJSONとしてパース出来ない

# はじめに

「[内閣府の祝日CSV](https://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html)をLambda上でJSON形式に加工して、API Gateway経由で使えるようにする」というプログラムを考えたのですが、API GatewayのレスポンスがJSONとして正しくパース出来ないことが分かりました。

Lambda上で動いているRubyプログラムは単体のスクリプトとして問題なく動作することを既に確認していましたが、原因が分かるまで少し時間がかかったので、その記録をまとめてみました。

# 使用した環境

* Lambda（Ruby）
* API Gateway

# 正しく動作しなかったコード

* `JSON.pretty_generate`や`JSON.generate`、`JSON.dump`などでシリアライズした結果を返すと、**API Gatewayを通して取得したレスポンスの前後に不要なダブルクォート（”）が付いてしまい、JSONとしてパース出来ませんでした。**
* その後にさらに調べてみると、API Gate

serverless-prune-pluginでLambdaのバージョンを整理する

ちょくちょく忘れるので忘備録

## インストール

“`
$ npm i -D serverless-prune-plugin
“`

## serverless.yml

“`yaml
plugins:
– serverless-prune-plugin

custom:
prune:
automatic: true
number:3
“`

customの方を設定してないと、`sls deploy`で消えない。

## CLIから手動削除

“`
# 直近3バージョンを残してすべて削除
$ sls prune -n 3

# helloのLambda関数を直近3バージョンを残して削除
$ sls prune -f hello -n 3

# ドライラン。削除予定の数が見れる
$ sls prune -n 3 -d

“`

ステージごとにAPIを作成することなく 各ステージごとにバックエンドポイントを振りわける

やりたいこと↓。
1つのLambda関数を作成し、それぞれのエイリアスを、各ステージにデプロイする。

大まかな手順は以下のとおりです。

1.Lambdaで新しいバージョンを発行する。
2.Lambdaでエイリアスを作成し、紐づける。
3.APIGatewayでステージ変数を参照する設定をする。
4.Lambda関数に権限を追加する。
5.ステージ変数を追加する。

それではやってみます。

#1.Lambdaで新しいバージョンを発行する。#

「新しいバージョンを発行」

「バージョン：1」を作成しておきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/93af00c2-c955-9ef7-4e87-90ef94b81

CloudFront のアクセスログを Elasticsearch Service 6.8 に取り込むメモ（Lambda Python 3.8 版）

[ALB](https://qiita.com/hmatsu47/items/432b1f18f40bba16f5d1) 同様、CloudFront のログの取り込みについても Elasticsearch Service 6.8 / Lambda Python 3.8 対応化メモを残しておきます。

こちらの記事のアップデートです。

– **[CloudFrontのアクセスログをElasticsearch Service (6.0/6.2) に取り込むメモ（手抜き編）](https://qiita.com/hmatsu47/items/552ec1e4bc8e43051d9e)**

※ほとんど [ALB](https://qiita.com/hmatsu47/items/432b1f18f40bba16f5d1) と同じ手順です。

# 手順

## 1. Amazon Elasticsearch Service の起動

[ALB の元記事](https://qiita.com/hmatsu47/items/826b00ff008d4e3edecf#1-amazon-elast

脆弱性情報をAWS Lambdaで取得してみたら

# 結論から言うと

– 人力で脆弱性情報を収集するのは大変だよ。
– MyJVN APIを使って脆弱性情報を取得してみた。
– ほとんど[こちら](https://dev.classmethod.jp/server-side/os/myjvn-api/)を丸パクリ（真似）させていただいた。

# きっかけ

仕事で脆弱性情報（OS、アプリ、NW機器など諸々）とかを収集して、ちゃんと対策しないと駄目だよ〜と言う流れになった。だけど、毎日NVDやJVNやJPCERTやCISCOとかのサイトに順番にアクセスして脆弱性が出ていないか目視でチェックすると言う運用に、いろいろ違和感を覚えたので、なんとかして楽できないかと考えていたところMyJVN APIの存在を知る。

MyJVN APIとは、JVN iPediaの脆弱性情報を検索するためのAPI検索情報を与えることで脆弱性情報の一覧や詳細をXML形式で受け取ることができるらしい。ベンダID、製品名、製品ID、CVSS深刻度、発見日/更新日/発行日などからフィルタリングが出来そう。

ちなみにJVNとは「Japan Vulnerability

dart2nativeでもAWS LambdaのCustom RuntimeでサーバーレスDartしてみた

どうも前に[こんな記事](https://qiita.com/qazx7412/items/8bda5d97614d272ed829)を書いた者です。
ちょっとNimやKotlin/Nativeを相手にしている合間に[dart2native](https://dart.dev/tools/dart2native)なるものができてDartからシングルバイナリが作れるようなっていました。
シングルバイナリが作れるようになったのですからcliを作りやすくなりますしサーバーサイドのデプロイも今までよりも楽になりますしこれはエラいことです。
Lambdaのような意地でも必要なものを全部詰め込まなければならない環境ならなおさらです。

ということでこの正月にdart2native対応したので変更点を中心に簡単にまとめ直します。
毎度のことですが最終的な成果物は[こちら](https://github.com/limit7412/lambda_dart_sls)においてあります。

## デプロイスクリプト
まずデプロイ用のシェルスクリプトから見てみましょう。
前回のスクリプトがシェルとしてはそれな

LambdaとS3とRDSと。ハマった話。

## はじめに

スタートアップ系企業に転職し、言語もPHPからPythonに変わった。
基本的にサーバレスアーキテクチャですべて構築していくスタンスなため、イチから勉強中。
Lambdaでは基本的にRDSを使っちゃいけないっていうのが、暗黙の了解っぽいんだけど、言われている通り様々な問題にぶつかっている。

今回Lambda(Python)でS3とRDSを同時に使おうとしたときにハマったのでそのメモ。

## やろうとしたこと
LambdaがS3にあるファイルを取得し、その内容をRDSに保存していくといういたってシンプルなもの。

## 構成
– Lambda(Python3.6)
– psycopg2
– boto3

– RDS (public access許可、IP制限)
– S3

構成の都合上RDSをpublicにしたかったので、IP制限（アクセス制限）で限定的に公開する形をとった。
LambdaはIPをもっていないのでVPC配下に置くことでセキュリティーグループに属することができる。
セキュリティーグループに属せれば、そのグループをRDS側で許可するという算段。

AMIバックアップを取るLambdaファンクション（Python3系版）

## 初めに
コチラの記事の2系から3系に上げたときの話です。
https://qiita.com/Hiroyama-Yutaka/items/9fab02438dc22c0b85ea

Python2系のサポートが2019/12末で無くなりました。
一応1年は動くようにしておくけど、3系に上げてくださいね。とAWSからメールが来ております。
その時の修正内容を備忘録的に書いておきたいと思います。

“`Python3
#!/usr/bin/python
# -*- coding: utf-8 -*-

import json

import boto3
from boto3.session import Session

import time
from datetime import datetime as dt

import pprint

TAG_KEY_BACKUP_GENERATION = ‘Backup-Generation’
TAG_KEY_AUTO_BACKU

CognitoUserPoolの情報をLambda経由でRDSへ連携した

#前書き
勉強用に何かしらのウェブサービスを作ろうと常々考えていたのですが、やはり認証基盤を自分で一から作るのは手間が非常にかかるので足踏みをしていました。
そこでCognitoを使おうと思ったのですがサーバーレス構成もNOSQLも使ったことがないのとNOSQL辛いよというアドバイスを頂いたので、とりあえず作るということを優先して日頃なれているRDBに認証情報を放りこみたかったという感じです。
なお技術スタックとしてLambdaではNode.js、RDSにはPostgreSQLを採用しました。

#流れ
1. CognitoのイベントをLambdaでフックする
2. LambdaでCognitoの認証情報を取得する
3. LambdaからRDSへデータを書き込む

## 1. CognitoのイベントフックをLambdaで行う
Cognitoは`サインアップ前`や`確認後`などそれぞれのイベントに合わせてLambdaでフックすることができます。
今回のユースケースでは`確認後`に行うのが適切でしょうか。今回私は`確認後`で設定しました。
https://docs.aws.amazon.

LINE Messaging API 〜 API Gateway 〜 SQS 〜 Lambda を連携する

## 前書き
– LINEのchatbot基盤を作ります
– LINE Messaging APIとAWSの各種マネージドサービスとの連携方法についてまとめます
– セキュリティ設定については別記事にまとめます（一旦ゆるゆるに設定）
– Lambdaで使用する言語はGoを採用します

## 構成

作成するchatbotの流れは以下の通りです。最終的には送信したメッセージをDynamoDBに保存してLINE Messaging APIを呼び出しますが、本記事では対象外とします。

1. LINE公式アカウントを友達登録する
2. 公式アカウントにメッセージを送る
3. LINE ServerからAPI Gatewayにリクエストが送信される（webhook URL）
4. AP

echobotを作成し、Slackに通知する。

#はじめに

AWSアカウントを作成したので、料金管理のため料金通知botを作成したい。
そのため、まずはechobotを作成してbotを試してみる。

#Lambdaを作成する
「AWSマネジメントコンソール」から「Lambda」を作成する。
諸々の設定を行い、以下のようにコードを書きかえる。

“`HTTPステータス200(OK)と本文にeventをJSON形式にしたものを返す.
import json

def lambda_handler(event, context):
# TODO implement
return { ‘statusCode’: 200, ‘body’: json.dumps(event) }
“`

#API Gatewayの作成
「AWSマネジメントコンソール」から「API Gateway」を作成する。
「APIの作成」をクリックする。
「アクション」→「メソッドの作成」から「POST」を選択し、以下のようにセットアップする。

– 統合タイプ「Lambda関数」
– Lambdaプロキシ統合の使用→チェックを入れる
– Lambd

Lambda(Python) + Rekognition で顔検出

# Lambda(Python) + Rekognition で顔検出

この記事は[サーバーレスWebアプリ Mosaic](https://mosaic.w2or3w.com “Mosaic”)を開発して得た知見を振り返り定着させるための[ハンズオン記事](https://qiita.com/w2or3w/items/87b57dfdbcf218de91e2)の1つです。

以下を見てからこの記事をみるといい感じです。
* [Lambda + OpenCVで画像処理 (グレー画像作成)](https://qiita.com/w2or3w/items/e6feac50c751bbc64697)
* [AppSyncをフロントエンドとバックエンドで利用する](https://qiita.com/w2or3w/items/70f6b6d8d13b60afaee5)

## イントロダクション
顔検出を実現する手段としてOpenCVが最初に思い立つ古い人間なのですが、OpenCVで納得いく検出をさせようと思うとなかなかしんどいんです。で、このAWS Rekognitionを利用してみたので

AWS APIGateway＋lambda＋S3を使ってダウンロード機能を実装する

# 背景
AWS使ってサーバーレスで自分用の家計簿的なwebサービスを勉強も兼ねて開発中。大分自分が欲しかった機能は実装出来てきた。
今後の為にもDynamoDBをバックアップをしたい。DynamoDB自体にバックアップ機構はあるものの、間違えてテーブル自体を削除してしまった時（構築スクリプトミスとか）の為に、CSVやjsonファイルなどでローカルPCに置いておきたい。

# 方法を考察
手法は色々あると思うが、大きく分けて以下の２つになる。

– どこかサーバー側で、aws-cliなどを使ってファイル出力する
– web画面にダウンロード機能を追加する

やっぱりここはダウンロード機能。このサービス開発は勉強も兼ねてるし。
ここで、単純にwebページからダウンロードと言ってもまたそこで細かい手法が存在する。

1. データを取得して、クライアント側で文字列作成してダウンロード処理
2. サーバー側で生成したファイルストリームをダイレクトレスポンスで返す
3. S3にアップして、そのアドレスを返し、リダイレクト
4. S3にアップ。フォルダ一覧ページも用意してそこからリンク

AWS+NodeJSでサーバレスな環境構築④

# はじめに
今回は[前回](https://qiita.com/isacRU/items/b4ab67d12f2d2377aea8)の続きで、DELETE(対象ユーザーの削除), GET(全ユーザーの取得) PATCH(対象ユーザーの更新)を作っていきます。

# DELETE(対象ユーザーの削除)
指定されたidを元に、対象のユーザーが削除されるようにしていきます。
### Lambda関数の作成と設定

ソース

“`javascript:index.js
‘use strict’;
const AWS = require(‘aws-sdk’);
const myRegion = “us-east-2”;

AWS.config.updat

AWS+NodeJSでサーバレスな環境構築③

# はじめに
[前回の記事](https://qiita.com/isacRU/items/f5a16683331779805a1b)ではDynamoDBのテーブルと項目作成、Lambda関数で使うロールやインラインポリシーの設定を行いました。今回はその続きで、API Gateway(REST APIでCRUD実装)をトリガーにし、Lambda(NodeJS)関数呼び出して、DynamoDBに参照や更新をできるようにします。
表現等が不適切の場合はご指摘いただければ、幸いです。
※サーバレスに関してよくわからない方は、[こちら](https://qiita.com/isacRU/items/fe4751603d3da32b2daf)をご覧いただければと思います。

# アーキテクチャ図

# 流れ
– ソースで直接(Api gatewa

クロスアカウントでLambdaの自動デプロイをしてみた

今回`Lambda`の自動デプロイをクロスアカウントで実行したので覚書として残しておきます。
`Lambda`のデプロイには`CloudFormation`で実施しています。
`Lambda`の`CloudFormatino`の設定については下記を参照してください。
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html
完成図としては以下となります。

* ソースコードは開発アカウントの`CodeCommit`で管理します。
* masterブランチにソースコードがPUSHされると、開発環境の`CodePipline`が動作します。
* 開発アカウントの`Codebuild`上で“Cloud

Java8 ラムダ式の filter() で使用する条件をパラメータで渡す

ラムダ式は変数に代入して再利用することができますが、そのフィルタ条件などは固定されています。
[Java8 ラムダ式を変数に代入して再利用する](https://qiita.com/blueskyarea/items/169a04b77a297ead9774)

そのため、そのフィルタ条件を変えたい場合、別々の式を定義する必要があるかもしれません。
例えば、
”文字列の長さが5の文字列のみ”をフィルタするラムダ式と、
”文字列の長さが8の文字列のみ”をフィルタするラムダ式が欲しい場合、以下のように2つの式を定義する方法が考えられます。

“`java:lengthFiveOrEight
// 文字列の長さが5
final Predicate lengthEqualFive = name -> name.length() == 5;
// 文字列の長さが8
final Predicate lengthEqualEight = name -> name.length() == 8;
“`

条件が常に固定であれば問題ありませんが、そのアプリケーションが柔

AWS+NodeJSでサーバレスな環境構築②

# はじめに
[前回の記事](https://qiita.com/isacRU/items/fe4751603d3da32b2daf)ではAPI Gateway+Lambda(NodeJS)を組み合わせてWEBページを表示するというアウトプットでした。今回はDynamoDBのテーブルと項目作成、Lambda関数で使うロールやインラインポリシーの設定を載せていきます。サーバレスに関しては個人的に興味があるとのと、次の案件で用いるからその予習になります。自身も初めてということもあり、表現がわかりにくいところもあるかもしれません。その場合は容赦無く、コメントで指摘していただければ幸いです。
※サーバレスに関してよくわからない方は、前回の記事をご覧いただければと思います。

# DynamoDBってなぁに？
簡単に言ってしまうと、AWSがマネージドサービスとして提供しているNoSQL(非リレーショナル)データベースになります。「値」とそれを取得するための「キー」だけを格納するというシンプルな機能を持った「Key-Valueストア」です。

**一般的なユースケース**
・ミリ秒単位のアクセスレ