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

fetchの呼び出し @Javascript & Node.js 実験室

fetchは、HTTP呼び出しで標準的に使っていますが、Content-Typeに従った呼び出し方をいつも忘れてしまうので、備忘録として残しておきます。

実動作の確認のためのソースコードを以下に挙げておきました。
　https://github.com/poruruba/fetch_laboratory

Javascriptからの呼び出しを中心に示しますが、同じコードがそのままNode.jsでも動作します。
ちょっとだけ、Lambdaでの動作も示しておきます。

# 呼び出し方法の種類

今回扱う呼び出し方法は以下の通りです。

・Get呼び出し
　HTMLのページ取得でおなじみです。パラメータをQueryStringに指定します。例えば、以下のような呼び出しです。
　http://localhost:10080/api?param1=abcd

・Post（Content-Type: application/json）呼び出し
　パラメータをBody部にJSONで指定するWebAPI呼び出しでは一番一般的ですね。

・Post（Content-Type: applicatio

AWS Lambda+Twitter APIで駄ツイートを定期的に削除してみた

## 心象
– お気に入りもRTもされない駄ツイートが自動で消える様にしたい。
– なんとなくかっこいいイメージのLambdaを使ってみたい。
– 「Qiitaに投稿しました。」なら駄ツイートにならない。

結果：思いのほか簡単に出来ましたので共有します。

## 必要なもの
### Twitter DevelopersでのApp登録
https://developer.twitter.com

Twitter APIの利用申請の方法については省略します。
今回はAPIの学習目的でツイートの削除を行う旨をTwitter Developersにて申請し、Twitter APIの利用に必要な以下のキーとトークンを取得しました。

– API key
– API secret key
– Access token
– Access token secret

### AWSアカウント
https://aws.amazon.com
使用するサービスは以下です。

– Lambda (Twitter APIへのアクセス)
– Key Management Service (APIキーを格納する環

lambda＋API Gateway構成を作ってみる

lambdaとAPI辺りの学習です。
外部APIをコールするlambdaをコールするAPI(via API Gateway) を意味もなく作る備忘録。
それだけだとつまらないので天気予報を取得し、取ってきたjsonをそのままDynamoDBに格納する構成を作る。

_contents_

* Node.jsでAPIをコールする方法。
* AWS環境でAPI Gateway + lambdaの設定方法。
* ローカル環境でAPI Gateway + lambdaの設定・実行方法。

## 事前準備

* OpenWeatherにSign UpしてAPIキーを入手。
* AWS SSM パラメータストアへURIとキーを登録。

## SSMとDynamoDBのSDK(Node.js)の使い方

### Node.jsからパラメータストアを参照

“`js
const AWS = require(‘aws-sdk’);
const ssm = new AWS.SSM();
const res = ssm.getParameter({Name: “パラメータ名”, WithDecryptio

GoとLambdaでAWS使用料金を毎日LINE通知させる

## AWSの使用料金こわい
おっしゃ AWSのコンソールいじるで〜 :nerd:
お、そういや〜AWS今いくらかかっとんねんやろ :nerd:
マイ請求ダッシュボード　ポチ〜っと :nerd:

んん！？？ :innocent::innocent::innocent:

ECSを放置して＄100超えの請求がきたり、
キルしたはずのRDSインスタンスが知らぬ間に復活していて地味に＄40くらい請求がきたり、
~~この通過儀礼を~~いい加減なんとかしようと簡単な料金通知システムを作りました。 :nerd:

## やったこと
Go言語でLINE notifyの通知APIをキックする関数を実装して
AWS Lambdaにデプロイ:nerd:Cronで定期実行して、毎日AWSの使用

AWS API GatewayのHTTP API(β版)がLambda関数に渡す値が想定と違っていた話

最近 AWSのAPI Gatewayに、HTTP API(β版)が実装された。
試してみたところ、ちょっとハマったので備忘録に。

“`html

“`
まずは、ありきたりなフォームを作成して、作成したHTTP APIにsubmitする。
統合先のLambda関数で確認すると、bodyの情報がREST API(Lambdaプロキシ統合を使用)のときと違う。

“`javascript
// Lambda関数(Node.js 12.x)
exports.handler = async event => {
console.log(event.body);
// REST API(Lambda

LambdaでCognito認証(ユーザー認証)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└__ユーザー認証__　←イマココ

#ユーザー認証 (InitiateAuth)

##概要
通知されたIDとパスワードの組み合わせが正しいかを検証します。
登録された情報と一致した場合、ユーザー認証に必要なIDトークンを発行します。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.ht

LambdaでCognito認証(ユーザー確認)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├__ユーザー確認__　←イマココ
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5)

#ユーザー確認 (ConfirmSignUp)

##概要
作成したユーザーの連絡手段(メールアドレスor電話番号)が有効か確認します。
通知された確認コードが正しければ、ユーザーのアカウントステータスを「CONFIRMED」にします。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentit

LambdaでCognito認証(ユーザー作成)

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

[トップ](https://qiita.com/minmax/items/a36b081c073eff4a6533)
├__ユーザー作成__　←イマココ
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5)

#ユーザー作成 (SignUp)

##概要
通知されたIDとパスワード(とその他の情報)でユーザーアカウントを作成します。
続けて、登録したメールアドレスor電話番号に確認コードを通知します。

##ドキュメント
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.html

LambdaでCognito認証

#はじめに

SDKをローカルに持ってきてゴニョるサンプルは検索に引っかかるのですが、
クラウド側(Lambda関数内部)で完結するサンプルが見つからない…
よし、ならば投稿してしまえ。

__トップ__　←イマココ
├[ユーザー作成](https://qiita.com/minmax/items/8c2aa57b76e09b8192ed)
├[ユーザー確認](https://qiita.com/minmax/items/ed4f81e61c2617d5c6cf)
└[ユーザー認証](https://qiita.com/minmax/items/12e65cd51d85f419faa5) ※なお、続く認可はAPI Gatewayのオーソライザーにお任せします。

※メインはLambda関数のコードの紹介です。付随する情報は簡潔に記します。

#概要
ローカルにダウンロードしたSDKを使うのではなく、
クラウド側で用意されているSDKを使ってCognito認証しよう。
というのが今回のコンセプトです。

↓こちらを使います。
https://docs.aws.amazon.com/A

Serverless Framework for AWS Lambda Development

## 0 .Intro

[Serverless Framework]([https://serverless.com/](https://serverless.com/))

> The complete solution for building & operating serverless applications.

就自己這陣子的使用經驗上來看，我覺得這樣的敘述還算名符其實。

目前最主要會用場景為開發在自己的MBPR 上利用Golang 開發AWS Lambda，利用Serverless Framework CLI所提供的功能來開發，部署以及在本機做測試，整體的流暢度滿高的。 雖然Serverless還有提供其他Monorting, integration或policy目前還沒有使用到，但是整理的使用經驗大勝[SAM CLI]([https://github.com/awslabs/aws-sam-cli](https://github.com/awslabs/aws-sam-cli))，特別是早期被SAM對於Golang的支援踩到太多的坑了。

除了AWS之外，其他ser

Amazon API GatewayにBasic認証をかける方法

# はじめに

ちょっとしたテスト用のAPIをAmazon API Gatewayで作ったのですが、あんまり外部公開はしたくない…でもガッチガチなセキュリティが必要なほど重要なものでもない…
というわけでBasic認証をかける方法を調べたメモです。
いくつかハマリポイントがありました。

# 大まかな流れ
API GatewayでBasic認証する大まかな流れ。

1. API Gatewayのオーソライザーに認証をするLambda関数を指定する。
2. オーソライザーのIDソースにauthorization (header)を設定する。
3. API Gatewayの「ゲートウェイのレスポンス」の401レスポンスにWWW-Authenticateヘッダーを追加する。
4. メソッドリクエストの設定でオーソライザーを指定する。

## Lambda関数の作成
AWS Lambdaのダッシュボードから関数を作成します。Rubyが好きなのでここではRubyを選択しています。

名前は適当に、実行ロールは「基本的な Lambda アクセス権限で新しいロールを作成」でOKです。

“`rb:

Lambda(Python)でGoogle Driveへファイルアップロード

# Lambda(Python)でGoogle Driveへファイルアップロード

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

以下を見てからこの記事をみるといい感じです。
* [Lambda(Python) + Rekognition で顔検出](https://qiita.com/w2or3w/items/48bc05684c6dafbf5253)

## イントロダクション
S3ってファイルを保存するだけならいいのですが、そのファイルを人が参照するのには向いてないですよね。画像にしてもWebブラウザ上でそのまま見ることができず、一度ダウンロードしてから見る必要がある。ちょっと手間なんですよね。
その点、Google DriveはPCにしろスマホにしろ、ブラウザやアプリでいい感じに画像を参照することができますのでいい感じで

AWS Lambda における Python 2.7 ランタイムのサポート(2020.1時点)

## Python 2.7 のサポート終了
2020年1月1日に Python 2.7 のサポートが終了しました。（[PEP 373](https://www.python.org/dev/peps/pep-0373/)）
2系の最終リリースである python 2.7.18 のリリースは2020年4月に予定されています。

## AWS Lambda における Python 2.7 ランタイムのサポート
AWS LambdaにおけるPython2.7ランタイムについては、2020年1月時点では廃止予定は
アナウンスされておらず、引き続き作成、更新、実行が可能です。

> Python 2.7 reached end-of-life on January 1st, 2020. However, the Python 2.7 runtime is still
> supported and is not scheduled to be deprecated at this time.

**Runtime Support Policy**
https://docs.aws.amazon.

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