- 1. RDSの自動起動と自動停止スクリプト
- 2. SAMでSlack通知Lambdaをデプロイ
- 3. lambda + typescript + s3のリファクタリングをしてテストケースを書いたメモ
- 4. Slackへ勤怠連絡を入力するAlexaスキルを作ってみた
- 5. Lambda@Edge とは
- 6. AWS SAM を用いて Hello World アプリケーションをデプロイしてみる
- 7. Chalice で Lambda Layer を利用する
- 8. AWS Lambdaで関数作ってAPIGatewayで公開するまでの学習
- 9. EC2のプロセス監視と自動再起動
- 10. localstack + aws cdk でAWS S3をローカル環境に立ち上げてLambdaでアクセスするメモ
- 11. AWS CDKでAPIGateway+Lambdaを作る
- 12. TerraformでHTTPS静的サイト(Route53 + ACM + S3 + CloudFront + Lambda@EdgeによるBasic認証)を作ってみた
- 13. SSM・CloudWatch Agentの自動更新とエラー発生時のメール配信
- 14. AWS Lambdaと開発環境(Eclipse)とでRDSの日時の値が異なる
- 15. AWS Lambdaのマルチアカウントデプロイ
- 16. AWS CDK + SAMでローカル実行しているLambdaにattachしてデバッグ実行したメモ
- 17. Lambda関数を作成する開発者に必要な権限を考えてみた
- 18. API Gateway + Lambda Authorizer + Lambdaプロキシ統合 + AWS SAM CLIを組み合わせたときのCORS設定
- 19. Lambda関数から別アカウントのDynamoDBに接続
- 20. Lambda + Goでネストされたアプリケーションを構築
RDSの自動起動と自動停止スクリプト
RDSは起動しっぱなしだとお金がかかる。
しかし、停止しても7日後に再度起動してしまう。
特に検証用とかで使用しない間が多い場合、いちいち起動したら停止するという運用はかなり面倒。
そのため、検証時以外は、起動したらすぐ停止するというスクリプトを作成して、**無駄なコスト**がかからないようにする。
そこで使用するのが、AWSのLambdaを使う。
## Lambdaとは何?
Lambdaと聞いてもわからないので調べた。
AWSの「サーバレスコンピューティングとアプリケーション」と言われる。
これまではPHPやPythonをうごかすためのwebサーバーが必要だったが、Lambdaならサーバーレスのため、サーバーを準備しなくても環境が揃っていると言うことである。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/255267/1235389f-8f51-f11f-ea6b-dc23ef67432e.png)
**LambdaはJava、Node.js、C#、Pythonの
SAMでSlack通知Lambdaをデプロイ
## はじめに
[AWS Lambda Container Image Support](https://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/) や EventBridgeのcron設定、Secrets Managerからシークレット情報の取得を試してみたかったので、以下のような構成図で一気に試してみます。## 構成図
– SAMでSlackにメッセージを通知するLambdaをデプロイする
– Lambdaはイメージ化してECRで管理する
– LambdaはEventBridgeで定期実行する
– SlackのWebhook URLをSecrets Managerで管理する![sam.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/917499/eed96002-2bda-33c2-64bf-cfdac785faed.png)
## 手順
1. ECRにリポジトリを作成しておく
2. S
lambda + typescript + s3のリファクタリングをしてテストケースを書いたメモ
## 概要
[前回はS3をローカルで立ち上げた。](https://qiita.com/hibohiboo/items/e81573744466343aec2c)
今回は、[ローカル環境でLambda+S3のテストをする](https://qiita.com/billthelizard/items/22d2457f3d6386d21796)を参考に、リファクタリングをしてテストを行う。[ソースコード](https://github.com/hibohiboo/develop/tree/481815420c60a0933e51483ded6ed53d1da64c03/tutorial/lesson/aws/typescript/projects/cdk_sample)
## 構造
“`
src
– lambda
– handlers
– s3-sample.ts
– service
– s3-sample.ts
test
– fixture
– s3
– message.txt
– lambda
–
Slackへ勤怠連絡を入力するAlexaスキルを作ってみた
# 概要
弊社は出勤や休憩などの勤怠連絡をSlackのチャンネルへのメッセージ送信で行っています
毎日何度も行うことなので手入力は結構面倒です
そこで、最近我が家にやってきたAmazon Echo Showに話しかけて勤怠連絡を行えるAlexaスキルを作りました!
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/413932/9ec76584-08da-ed4f-8139-d3a2a473f531.png)ちなみに、Echo Showが無くてもスマホのAlexaアプリでAlexaスキルを実行することはできます
音声入力で色々なものを操作するのは魔法感があって楽しいのでAlexaスキル開発はおすすめです!# システム構成
![勤怠入力スキル構成図 (2).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/413932/0b8214ed-9921-5472-d822-715873c51e29.jpeg)
Lambda@Edge とは
## 勉強前イメージ
lambda関係してそうだけど、Edgeがわからん
## 調査
### Lambda@Edge とは
cloudfrontのエッジロケーションからコードを実行するLambda関数のことで、
ユーザに近い場所でコードが実行されるので高速なコンテンツ配信が可能になる仕組みです。
コードをLambdaにアップロードするだけで自動的にコードの実行やスケーリングが行われます。
ですので、Lambda@Edgeは Lambdaとcloudfrontから成り立ちます### メリット
– 低レイテンシーのコンテンツを配信
ユーザに近いロケーションからコードを実行するので
低レイテンシーの配信が出来ます– サーバ管理が不要
オリジンサーバを複数のロケーションでプロビジョニング・拡張・管理することもなく、自動的にスケールします。
オリジンで実行しているアプリケーションに何も変更を加えることなく追加できます。### 指定できるcloufrontイベント
cloudfrontには4つの流れがあり、
それぞれ1つのリクエストに対して一意のlambdaのコードを割
AWS SAM を用いて Hello World アプリケーションをデプロイしてみる
AWS SAM を使ってみたいので、API Gateway 経由で Hello World メッセージを表示する Lambda を呼び出すアプリケーションを SAM でデプロイしてみます。
# 前提条件
– AWS アカウントの作成
– Docker のインストール
– AWS SAM CLI のインストール
– “sam –version” と叩いてバージョンが表示されれば OK# サンプルアプリケーションのダウンロード
sam コマンド経由でサンプルとしてダウンロードできるアプリケーションがあるので、ダウンロードしていきます。
まずは下記のコマンドを入力します。“`
$ sam init
“`途中でテンプレートソース、パッケージタイム、ランタイムを選択していきます。
プロジェクト名は任意の名前で問題ありません。
ここでは「hello-sam」としています。“`
$ sam init
Which template source would you like to use?
1 – AWS Quick Start Te
Chalice で Lambda Layer を利用する
# 問題点
Chalice で1つの `app.py` 内に以下のようなコードを書いた場合、API Gateway用の Lambda関数 と 定期実行用の2つの Lambda 関数が作成される。 デフォルトの設定だと `requirements.txt` で指定するすべてのライブラリを各 Lambda 関数内に展開してアップロードするので、2つの Lambda のコードサイズが大きくなる。
“`python:app.py
@app.route(‘/’)
def index():
pass@app.schedule(‘rate(5 minutes)’)
def cron(event):
pass
“`こういった場合には共通ライブラリの配置場所として Lambda Layer を利用できるのだが、昔ドキュメントを読んだときに読み落としていたのか chalice ではまだサポートされていないと思い込んでいた。 改めて調べると、ちゃんと Layer を使うことができたので、そのやり方を示す。
# 対象コードとバージョン
今回は以下のような cryptog
AWS Lambdaで関数作ってAPIGatewayで公開するまでの学習
# 本記事でやること
![スクリーンショット_2021-03-28_17_22_37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/113504/ea799a62-b7d4-6169-cea7-f51db4cba365.png)
適当なJSONを返す
# 前提
[AWSのアカウント作成後のAdminのIAMユーザー作成](https://qiita.com/Teach/items/8212c06dc9f4a2546800)# Lambdaのスタート
## Lambdaとは?
サーバー管理せずにコードが実行できるサービス## コスト
コード実行していない間は無料
https://aws.amazon.com/jp/lambda/pricing/永久無料枠アリ
## イベント
S3、DynamoDBの変更をトリガーにして発火できる## 学び方
https://docs.aws.amazon.com/lambda/latest/dg/welcome.html#welcome-first
EC2のプロセス監視と自動再起動
EC2で稼働しているプロセスがダウンした時に、自動起動する仕組みを作っていきたいと思います
今回は、dockerプロセスがダウンした場合を例とします# 前提条件
* Amazon Linux2
* amazon-ssm-agentインストール済み
* cloudwatch-agentインストール済み
* dockerインストール済み
* EC2のIAMロールにAmazonSSMFullAccessのポリシーがアタッチ済み# プロセスの監視を設定します
## Systems Manager パラメータストアの設定
CloudWatchのメトリクスに入れるための定義を作成します
AWSマネジメントコンソールからSystem Manager、パラメータストアをたどり、「パラメータを作成」を実行します
タイプはString、データ型はtextで、以下を値に設定します“`json:値
{
“metrics”: {
“append_dimensions”: {
“ImageId”: “${aws:ImageId}”,
localstack + aws cdk でAWS S3をローカル環境に立ち上げてLambdaでアクセスするメモ
## 概要
[前回はローカルでデバッグ実行をできるようにした。](https://qiita.com/hibohiboo/items/fa76084a207e5a3d5955)
今回はS3をローカルで実行する。
リファクタリングは[次回](https://qiita.com/hibohiboo/items/4e5fd8c723e0f70c12b1)。[ソースコード](https://github.com/hibohiboo/develop/tree/2dca5633f60621882e853598463da20d547e07e8/tutorial/lesson/aws/typescript/projects/cdk_sample)
## 環境
* windows 10
* Docker version 20.10.5, build 55c4c88
* aws-cdk 1.95.1
* aws-cdk-local 1.65.4
* aws-cli/2.1.29 Python/3.8.8 Windows/10 exe/AMD64 prompt/off
* node v14.16.0
AWS CDKでAPIGateway+Lambdaを作る
cdkの入門として、シンプルにAPIGateway+Lambdaを作っていく流れを書きます
## はじめに
* Ubuntu 18.04.4 LTS (WSL利用)
* VSCode
* aws-cdk 1.94.1
* typescript## AWS CDKをインストール
“`bash
$ npm install -g aws-cdk
$ cdk –version
“`## AWS CDKのプロジェクト作成
“`bash
# プロジェクトディレクトリを作成
$ mkdir cdk-api-lambda# 移動
$ cd cdk-api-lambda/# プロジェクト作成
$ cdk init app –language=typescript
“`## パッケージインストール
“`bash
$ npm install @aws-cdk/aws-lambda @aws-cdk/aws-apigateway
“`## lambdaコードを格納するフォルダを作成
“`bash
$ mkdir lib/lambda/
“`
## lambdaコー
TerraformでHTTPS静的サイト(Route53 + ACM + S3 + CloudFront + Lambda@EdgeによるBasic認証)を作ってみた
# 概要
Terraformでvueなどで作られた静的サイトを独自ドメインでHTTPS配信するためのインフラを構築していきます。
サンプルソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。## サンプルリポジトリ
サンプルとなるソースをリポジトリにまとめてみたのでこれを参考に紹介していきます。https://github.com/grasswake/terraform_aws_static_site
※本記事の内容と基本的に一緒ですが、一気に作るのでなくRoute53とACM、CloudFrontの3ディレクトリに分けてます。
その為remote stateを使用した構成になっています。因みにaccess_keyなどの扱いが雑ですので使ってみる場合は使いやすい形に直してください。# 前提
– 独自ドメインでのアクセスを行うために、お名前.comなどでドメインを購入してください。この記事ではお名前.comで`example.com`というドメインを購入していると想定でいます
– アクセスURLは`example.com`になります。`www.example.
SSM・CloudWatch Agentの自動更新とエラー発生時のメール配信
クマ松です。
皆さん、AWS Systems Managerはお使いでしょうか。
AWS Systems ManagerはAWS環境のEC2やオンプレのサーバを効率よく運用することが出来るサービスです。
サーバ構成のインベントリをコンソールから確認したり、決められた時間にパッチを適用したり等、よくある定型作業の自動化を実現してくれます。今回はこのSystems Managerの機能の1つである「State Manager」を用いて、EC2にインストールしたSystems Manager AgentとCloudWatch Agentを定期的にアップデートしてくれる構成を作ろうと思います。
![アラートメール配信アーキテクト.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/307047/78dd37f5-0a5d-52cf-22d3-09e12469605f.jpeg)
#前提知識
##State Managerについて
###Black Beltの説明
AWSのBlack Beltの文言を借りる
AWS Lambdaと開発環境(Eclipse)とでRDSの日時の値が異なる
# 背景
AWS Lambda処理内で、RDSのデータを読み書きする機能を開発していました。
プログラム上で日時を生成してテーブルに格納するのですが、実行環境(ローカル or AWS Lambda)によって日時の値が異なってしまっていました。# 環境・前提
– Java8
– Eclipse(2020-12 M3)
– RDS(MySQL 8.0)
– AWS Lambdaローカルで開発中は Eclipse で JUnit を実行し、ローカルから RDS の読み書きを行います。
AWS Lambda へプログラムのデプロイ後は、AWS Lambda を実行し、 RDS の読み書きを行います。# 検証
## ① ローカル(Eclipse)から、RDSへ
| プログラム上の日時(UTC)[^1] | RDS上の日時 |
| —————————– | —————– |
| 2021/3/25 12:00:00 | 2021/3/25 3:00:00 |[^1]: `Times
AWS Lambdaのマルチアカウントデプロイ
クマ松です。
「テスト用/本番用とで環境毎にAWSアカウントを分けてはいるけれども、利用しているLambdaは同じ」
という場合、テストしたLambdaをコピペして本番環境にデプロイをしたくはないですよね。ですので、**テスト環境のCodeCommitへのマージイベント**をトリガーに**本番環境にLambdaをデプロイする**構成のCodePipelineを作りました。
ほぼ全てCloudFormationで実現していますので、お手元のAWSアカウントで試してみてください。## 想定する環境
– テスト環境用AWSアカウントが1つ
– 本番環境用AWSアカウントが複数
– テスト環境と本番環境とで同じLambdaを使っている## 実現したいこと
– テスト環境のLambdaを本番環境にもデプロイしたい
– テスト環境のマージイベントをトリガーに、本番環境のCodePipelineを起動したい## ブログ
設計方針やCloudFormationのテンプレートはブログに掲載しています。
[Lambdaのマルチアカウントデプロイ 設計編](https://cloud
AWS CDK + SAMでローカル実行しているLambdaにattachしてデバッグ実行したメモ
## 概要
[前回はローカルでMongoを動かした。](https://qiita.com/hibohiboo/items/15db5256624c7a8e8b8c)
今回はローカルで実行しているlambdaにデバッグ実行を試してみる。
[ソースコード](https://github.com/hibohiboo/develop/tree/0466b37b367ea738564395fb82ac6a8dc1d31547/tutorial/lesson/aws/typescript/projects/cdk_sample)## 環境
* Windows 10
* aws-cdk 1.95.1
* SAM CLI. 1.20.0
* VSCode 1.54.3## やること
* attachしてデバッグ実行
* launch.jsonの自動生成## フォルダ階層
“`yaml
– .vscode
– launch.json # VSCodeのデバッガ設定
– cdk # cdk用の設定フォルダ
– lib
– s
Lambda関数を作成する開発者に必要な権限を考えてみた
## はじめに
日頃Lambda関数の構築において、都度インフラ管理者に依頼して、IAMポリシーとIAMロールを作成してもらうようにしていますが、後から必要な権限が出てきたりして、開発がなかなか進まないこともありますよね。
Lambda関数にアタッチするIAMポリシーとIAMロールを自分で作って試せると嬉しいなと思い、Lambda関数を構築する開発者に必要なIAM周りのIAMポリシーについて考えてみました。**先にお伝えすると、下記のポリシーだと穴があるので、ご使用はお控えください。**
別のアイデア大歓迎です!コメントください!## 前提条件
AWSの環境は次の通りとします。### Assume Roleを使う
Assume Roleを使っている場合、ユーザーに権限をつける際は下記のようなフローになります。**① IAMポリシーの作成**
必要な権限をつけたIAMポリシーを作成する。**② IAMロールの作成**
①で作成したポリシーをAssume用のロールにアタッチする。**③ IAMポリシーの作成**
②のIAMロールにAssumeできる権限をつけたIA
API Gateway + Lambda Authorizer + Lambdaプロキシ統合 + AWS SAM CLIを組み合わせたときのCORS設定
表題の通りです。苦しめられたので解決方法を共有します。
ポイントとしては、
* プリフライト用にOPTIONSメソッドを受け入れる必要がある (Access-Control系のヘッダーも返す)
* AWS::Serverless::ApiのCorsプロパティを定義すれば、自動的にOPTIONSメソッドが作成され設定したヘッダーが返されるようになる
* [CorsConfiguration \- AWS Serverless Application Model](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/sam-property-api-corsconfiguration.html)
* LambdaでAccess-Control系のヘッダーを返す
* 普通にレスポンスにヘッダーを含めればOK
* ↓「Lambda または HTTP プロキシ統合への CORS のサポートを有効にする」の項目を参照
* [REST AP
Lambda関数から別アカウントのDynamoDBに接続
## 記事を書いた経緯
– 初めてAWSを触った!記録取っておこう!
– Lamdba関数から他アカウントのDynamoDBにアクセスを経験!個人的に詰まったところもあったので、同じミスはしないように記録として残そう!
– ナレッジ化して共有できればいいなーって感じです。初投稿なので、「ん?」って思うところがあるかもしれないですが、参考になれば幸いです。
## 環境
– Typescript
– DynamoDB
– Lambda## まず驚いたこと
Lamdba関数からただ単に`aws-sdk`の`DynamoDB Client`を作ってアクセスをしたら`ResourceNotFoundException`になった。。。
なぜだ。。。### NGコード
“`typescript
import {DynamoDB} from “aws-sdk”const client = new DynamoDB.DocumentClient()
const param = {
TableName: “sample”,
Key: {
‘id’: 1
},
}
c
Lambda + Goでネストされたアプリケーションを構築
![1280px-Go_Logo_Aqua.svg.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/525769/2b8f3e0b-9e8b-1355-2e71-ffd3570f9337.png)
LambdaでGoを使ったAPIを作成したときの話
あるサービスでGoを採用し、Lambda上でapiを作成することになった、最初は小規模の認識で開発を行っていたが、仕様がどんどん膨らみ気づいた時にはエンドポイントが150を超え、そしてやってきたリソース制限“`
Template format error: Number of resources, 206, is greater than maximum allowed, 200
“`ネストさせることで回避できることを知り、ネストするも“`sam build“`できず、結局ネストされた各アプリケションを個別にビルドし、マージするシェルを書いて運用していた。
苦労した話を書こうと思い調べていると、いつの間にかネストされたアプリケーションのビルド