- 1. AWS API GatewayのHTTP API(β版)がLambda関数に渡す値が想定と違っていた話
- 2. LambdaでCognito認証(ユーザー認証)
- 3. LambdaでCognito認証(ユーザー確認)
- 4. LambdaでCognito認証(ユーザー作成)
- 5. LambdaでCognito認証
- 6. Serverless Framework for AWS Lambda Development
- 7. Amazon API GatewayにBasic認証をかける方法
- 8. Lambda(Python)でGoogle Driveへファイルアップロード
- 9. AWS Lambda における Python 2.7 ランタイムのサポート(2020.1時点)
- 10. Elasticsearch Service 6.8 に取り込んだログ(INDEX)を Curator で削除するメモ(Lambda Python 3.8 版)
- 11. AWS+NodeJSでサーバレスな環境構築⑤
- 12. Lambda+API GatewayのレスポンスをJSONとしてパース出来ない
- 13. serverless-prune-pluginでLambdaのバージョンを整理する
- 14. ステージごとにAPIを作成することなく 各ステージごとにバックエンドポイントを振りわける
- 15. CloudFront のアクセスログを Elasticsearch Service 6.8 に取り込むメモ(Lambda Python 3.8 版)
- 16. 脆弱性情報をAWS Lambdaで取得してみたら
- 17. dart2nativeでもAWS LambdaのCustom RuntimeでサーバーレスDartしてみた
- 18. LambdaとS3とRDSと。ハマった話。
- 19. AMIバックアップを取るLambdaファンクション(Python3系版)
- 20. CognitoUserPoolの情報をLambda経由でRDSへ連携した
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-plugincustom:
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で新しいバージョンを発行する。#
「新しいバージョンを発行」
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/5fa34ecb-5306-3bb4-d71e-0f2e805212a6.png)「バージョン: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 Sessionimport time
from datetime import datetime as dtimport 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.