KMSで認証情報を暗号化しLambda実行時に復号化する ｜ Developers.IO
データベースやAPIサーバーなど外部システムと連携する際には、往々にして認証情報が必要になります。 今回は AWS Key Management Service (以下 KMS) の共通鍵暗号の仕組みを使い、暗号化した認証情報を AWS Lambda 関数のコードに埋め込み、関数呼び出し時に認証情報を復号化する方法を紹介します。 基本的なアイデアは次のブログで書かれており、KMS を使った暗号化処理だけを自分向けメモも兼ねて抜き出しました。 http://ijin.github.io/blog/2015/08/06/github-to-lambda-to-slack/ KMS ではマスターキーを使って暗号・復号する処理が API で切り出されているため、この API を使って認証情報を暗号化します。 KMS と Lambda の連携 以下の流れで動作確認します。 AWS KMSマスターキー
LambdaでAWSの料金を毎日Slackに通知した結果課金されてしまった - Qiita
はじめに ブログにも書いてます 請求アラートは設定していますが、それとは別にAWSの料金をLambdaのcronで定期チェックしてSlackに通知するを設定して１ヶ月間運用してみました。 毎日金額がわかるとやっぱり安心できますよね。 推移 おわりに 安心のために2円(2017/09/01のレート)支払うことになった。 悲しい。 Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
AWS Lambda(Node.js)からAmazon RDSへIAM認証で接続する - Qiita
概要 現在開発しているburariというおでかけアプリでは、APIGatewayからLambdaを実行し、RDSのデータを取得している。 以前まで、LambdaからRDSへの安全な接続にはVPCが必須となっており、AWS Lambdaの定期実行をSAMを使って実装するにも書いたとおり、コールドスタート問題が懸念になっていたが、IAM認証でLambdaからRDSに接続できるようになったため、ついにVPCから解放される日がきた。VPCから解放されることにより、LambdaからSNSやKMSへの接続にNATが不要になるため、お財布にも優しいサービス運営が待ち受けている。 今回は接続まわりを実装してみる 💪💪 環境 Amazon RDS (MySQL v5.7.17, t2.micro) AWS Lambda (Node.js v8.10) Sequelize (ORM for Node.js
Serverless Framework+Node.jsをつかったLambda関数の開発フロー - Qiita
今回は、Serverless Framework+Node.jsをつかったLambda関数の具体的な開発フローを書いてみる。動作確認やテスト、CI連携まで一貫して行なったので、参考になればと思う。 つくったもの Webアプリケーション側である変更がはいった際に、複数のRDBとElasticsearchにまたがるデータを合わせて更新する、という、中間的な役割を実装した。S3に更新のデータが5分毎にPUTされるので、そこからイベントを取る。 フロー全体 一連の開発フローとしては以下のような流れになる。 ロジック実装/ユニットテスト ローカルでの結合テスト development環境での結合テスト PR作成(CIでテストの実行) レビュー マージ(CIでテストの実行) staging(production)環境へデプロイ staging(production)環境での結合テスト UIがないという
AWS LambdaでDynamoDBから取得した値に任意の集計をかける（グルーピング処理追加） - Qiita
以前の投稿の更新版です。前の仕組みでは一つのデータに対しての集計しかけられなかったのですが、それでは実運用上あまりに不便、と思ったので、指定した値でグルーピングできるようにしてみました。 AWS LambdaでDynamoDBから取得した値に任意の集計をかける インプットデータのフォーマット変更 ほとんど使い方は以前のものと一緒ですが、以下の点だけ変えました。 IDは配列形式（["sensor1", "sensor2"]）で指定するように仕様変更した。 テーブル名を環境変数から取得するようにした。 IDは配列形式（["sensor1", "sensor2"]）で指定するように仕様変更した こんな感じが最新のフォーマットです。 { "label_id": "id", "label_range": "timestamp", "id": [ "sensor1", "sensor2" ], "ag
Serverless Frameworkでremoveの前にS3 Bucketの中身を空にするpluginを作った - Qiita
about Serverless Frameworkは便利ですね。 LambdaだけじゃなくてAWSリソースも一元管理できますし。 sls removeで一括削除もできる、マジ便利です。 ただ、sls removeは現実的によくありそうなシチュエーションで失敗してしまいます。 そのシチュエーションに陥ると、手動でstack削除を行い、それとは別に原因のリソースを取り除く必要があります。 地味に面倒です。 ということで、失敗を起こさないようにするために作ったのが今回のpluginです。 現象 sls removeに失敗する理由は単純、CloudFormationで作成したS3 Bucketが空ではないから。 Serverless Error --------------------------------------- An error occurred while provisioning
AWS LambdaでImageMagickによる画像への文字埋め込みで好きなフォントを使う方法 - Qiita
LambdaでImageMagickを用いて好きなフォントを使う方法 方法は単純。 TrueTypeFontファイルへのパスをfontに渡してあげるだけ。 なのでデプロイパッケージに好きなフォントのttfファイルを含めてあげればできる。 下にサンプルソース。 (imagemagickのコマンドを使用する、こっちのほうが個人的には楽だった) const exec = require('child_process').exec; const aws = require('aws-sdk'); const s3 = new aws.S3({region: "ap-northeast-1"}); const fs = require ('fs'); const uuid = require('uuid'); exports.handler = (event, context, callback)
AWS Lambda と Fastly instant purge を利用して S3 コンテンツの更新を即時反映する - Qiita
Fastly CDN の特徴のひとつに、Instant purge（コンテンツの即時削除）があります。通常、CDN では更新の多いコンテンツはキャッシュすることができませんが、Fastly では Purge を即座に行うことが可能であるため、更新の多いコンテンツでもキャッシュすることが可能です。 ただし、コンテンツが変更されるたびに Instant purge を手動で行うのは理想的な運用とはいえません。ここでは AWS Lambda を利用して、S3 でのファイル更新を検知して、自動的に Instant purge を実行する方法を紹介します。 Lambda の設定 Services から Lambda を選択し、Create a Lambda function をクリックします blueprint が表示されますが、ここでは Blank Function を選択します トリガーの設定画
serverless frameworkで今日コミットしてるか教えてくれるcron作ってみた - Qiita
なぜ作ったか jqueryコミッターのgithubプロフィールに憧れて こんなありがたいブログ記事もあります write-code-every-day 毎日コードを書くように思い出させてくれるcron?bot?を作りました。 わざわざserverlessでlambdaでやる必要なくねっていうのは許してください。。 serverless framework好きなので使いました。 やってくれること いまのところ、4時間ごとと23時にコミット状況をslackに通知してくれます こんな感じ 成果物 githubにおいてあります 必要なもの awsアカウント → lambdaを使うので serverless frameworkのインストール (npm使うのでnodeが必要です。lambdaに合わせてv6.10がオススメ) githubアカウント https://github.com/settings
AWS Lambda & DynamoDBのベストプラクティスを求めて - Qiita
こんにちはsekitakaです。 serverlessな環境での開発も随分慣れてきましたが、コードの再利用性についてどうしようか悩んでいるので考えたこと&暫定結論を公開します。 ベストプラクティスを模索中なのでコメントでの議論も大歓迎です。 前提条件 共通するDynamoDBのテーブル(例:User)を参照する3つのプロジェクトがある。 プロジェクトP1 プロジェクトP2 プロジェクトJ1 以下のような状況になっている。 プロジェクトP1には既にUserデータのデータを取得する関数がある プロジェクトP1,P2はPythonで実装されており、プロジェクトJ1はJavaScriptで実装されている。 プロジェクトは全てLambda関数郡としてデプロイされる。 お題 Userテーブルからのデータ取得を各プロジェクトに組み込むにはどんな方法がよいか考える 案 案1 - 車輪の再発明を恐れない 各
Serverless Frameworkで既存のS3バケットにトリガーをアタッチする - Qiita
Serverless Frameworkで既存のS3バケットにトリガーをアタッチしようとすると、デプロイ時に以下のようなエラーが出てしまった。 Serverless: Packaging service... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading service .zip file to S3 (3.85 KB)... Serverless: Updating Stack... Serverless: Checking Stack update progress... .........................Serverless: Deployment failed! Serverless Error ------------------------------------
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Lambdaのユニットテストのベストプラクティス(Node.js) - Qiita
Returning binary data (jpg) from Lambda via API Gateway