- 1. 個人ブログのバックエンドを EC2 から Lambda に移行した
- 2. 【お手軽エラー監視】AWS CloudWatchからSNSでメール通知する
- 3. 【AWS】Lambda + API Gateway + DynamoDBで酒豪判定アプリを開発してみる【前編】
- 4. LambdaからFargateへの切り替える際にNode.jsアプリのタスクスペックをどう決めたか？
- 5. ECS schedule taskの多重起動を防ぐ
- 6. AWS Lambda, CloudWatch, SNS, SSMを活用したApache Webサーバーの監視と自動再起動の技術検証
- 7. AWS EventBridgeとSSMのRun Commandを活用したEC2インスタンスのApache自動起動
- 8. AWS EventBridgeでEC2インスタンスの起動を検知し、LambdaとSSMを連携して自動化する方法
- 9. SQSとLambdaの「部分的なバッチレスポンス」を試す
- 10. Lambda で awscli を利用する
- 11. AWS CloudTrailのJSON確認とEventBridgeを活用した詳細なイベントキャプチャ手法
- 12. AWS LambdaとSSMを使用したEC2インスタンスの状態監視とALBの動的切り替え②
- 13. AWS LambdaとSSMを使用したEC2インスタンスの状態監視とALBの動的切り替え①
- 14. NestJSでログフォーマットを変更してリクエスト単位のIDを共通でログに記録する方法
- 15. 個人的な備忘録：Lambda関数でのいろいろな処理について
- 16. Lambda（python）でS3からファイルを取得し、ファイルのマジックナンバーとMIMEを判定する
- 17. Lex Bot の slots の値をLambdaで取得してみる
- 18. AWSのインフラ構築におけるベストプラクティスと代表サービスのご紹介
- 19. AWS LambdaとAPI Gatewayを使用したGETリクエスト対応のサーバーレスアーキテクチャ構築
- 20. AWS LambdaとAPI Gatewayを使用したPOSTリクエスト対応のサーバーレスアーキテクチャ構築
個人ブログのバックエンドを EC2 から Lambda に移行した
# はじめに
EC2 & ALB はコストが高すぎた。1 円にもならない個人ブログのために 1 か月 $40 という大金が消えていた。そのうち移行しよう、なんて甘い考えだったが、マネジメントコンソールのコストを見ていたら居ても立っても居られなくなった。
なぜだかわからないがとても不安になった。
そこで急遽移行を始めた。
# Lambda 関数の作成
幸いバックエンドは複雑なコードではなく、index.js という 1 つのファイルだけだった。ChatGPT にどのようにデプロイしたらよいか聞いた。
> AWS Lambdaは、ファイルシステムへの長期的なアクセスや常駐プロセスの保持を前提としていないため、標準的なExpressサーバーのコードをそのままLambdaにデプロイすることはできません。ただし、AWS LambdaでExpressアプリケーションを実行するために、aws-serverless-expressなどのライブラリを使用してHTTPリクエストを処理する形に変換することが一般的です。
`aws-serverless-express` を使うらしい。コ
【お手軽エラー監視】AWS CloudWatchからSNSでメール通知する
## はじめに
アラート監視体制は、小規模なサービスや開発初期でも信頼性向上や障害発生時の迅速な対応のために無くてはならないものです。
ただ、人数やスケジュールが限られているとどうしても後回しにしがちな部分でもあります。
そこで、今回はAWSで普段使用するであろうCloudWatchに対して、特別な設定なくLambdaとSNSを組み合わせることで簡単にアラートのメール送信を実現できたので、その際使用した方法を載せます。まずは簡単なとこらからでも、少しずつ少しずつ積み重ねることでプロダクトの信頼性は着実に向上していきます！
## アラートを送信するLambda関数の作成
今回はPythonを使って関数を作成します。
AWSコンソールで`Lambda > 関数 > 関数の作成`を選択し、関数を作ります。
ランタイムはPythonで任意のバージョンを選択すればOKです。**コード例**
“`python
import base64
import json
import zlib
import os
import boto3def lambda_handler(event, c
【AWS】Lambda + API Gateway + DynamoDBで酒豪判定アプリを開発してみる【前編】
## はじめに
叡智に富んだ読者の皆様、御機嫌よう。
フルスタックエンジニアにメガ進化したいすぎちゃんです！ぶっちゃけ、リアルすぎちゃんの懐事情は険しくなってきつつありますw（仕事しろ）
そんな爪に火を灯すような生活を送る中でWeb開発を試みると、
どうしてもコスパとタイパを気にせざるを得ません。先月、AWSの[Aurora Serverless](https://aws.amazon.com/jp/rds/aurora/serverless/)をDBとしてポートフォリオを作ろうと試みたのですが、何もしなくても月に2500円もぶっ飛んじゃうので泣く泣く閉鎖することになりました 😥 （お金に余裕があればまた公開するかも）
https://aws.amazon.com/jp/rds/aurora/serverless/
さて、今回の記事ではコスパとタイパの両立ができる**サーバレスアーキテクチャ**を元にアプリケーションの作り方をレクチャーしたいと思います！
:::note info
**「サーバレス」とは**
サーバー周りの構築・運用を一切気にする必要がな
LambdaからFargateへの切り替える際にNode.jsアプリのタスクスペックをどう決めたか？
最近、LambdaからFargateに移行して、Node.js(NestJS)アプリの動作を最適化するためにタスクスペック(CPUやメモリの割り当て)についていろいろ試行錯誤しました。この経験を踏まえて、最適な設定を見つけるまでの流れを共有します。
## Lambdaとの違い
最初はLambdaを使っていたんですが、リクエストごとに新しい環境が立ち上がり、リソースの競合がなくて快適でした。短い処理ならLambdaが効率的で、オートスケーリングも自動的に対応してくれていました。でも、長時間稼働するバッチ処理や大量データの処理になると、Lambdaではコールドスタートやタイムアウト(30 s)が気になってきました。そこで、より柔軟なリソース管理ができるFargateに移行することに決めました。
## Fargateに移行してみて: タスクスペックの試行錯誤
Fargateの強みは、CPUやメモリなどのリソースを自分で細かく設定できるところですが、これが逆に難しくもあります。Node.jsはシングルスレッドで動くので、どのくらいのリソースが最適なのかを見極める必要がありました。#
ECS schedule taskの多重起動を防ぐ
## はじめに
ECS schedule taskなどで動かしているバッチ処理はアプリケーションの方で冪等性を
担保していることが多いと思います。ただ、今回はアプリケーションの変更が
難しい際に、タスクの多重起動を防ぐことによって、問題を解消するアプローチ方法について書きます！## 構成
StepFunctionsからECS taskとLambdaは起動可能なので
ECS taskとEventBridgeの間にStepFunctionsを挟み、そこで、Lambdaを
呼び出し、すでに起動しているタスク(ステートマシン)がないかを確認するという処理を行います。
## StepFunctionsのフロー
ステートマシンは以下のように定義していきます！
“`
{
“StartAt”: “get execution id”,
“Sta
AWS Lambda, CloudWatch, SNS, SSMを活用したApache Webサーバーの監視と自動再起動の技術検証
## はじめに
この記事は、前回の記事に続き、AWS Lambdaを活用したApache Webサーバーの監視・自動再起動設定について解説します。前回の記事の内容をもとに、Lambda関数を使ったさらなる自動化の手順を紹介します。
https://qiita.com/free-honda/items/d7eb9e39cfc95ac6e91b
今回の記事では、Lambda関数を使ってApacheサービスを自動再起動する手順を追加し、その設定方法を詳しく説明します。
## 知識整理
:::note warn
[前回の記事](https://qiita.com/free-honda/items/d7eb9e39cfc95ac6e91b)では、以下の内容について説明しました。**前提準備：AWS環境の準備**
**⓵Apacheのインストールと設定**
**⓶CloudWatchエージェントのインストール**
**⓷CloudWatchエージェントの設定ファイルの作成**
**⓸ApacheのHTTPポート監視**
**⓹CloudWatchアラームの作成**
:::これに
AWS EventBridgeとSSMのRun Commandを活用したEC2インスタンスのApache自動起動
## はじめに
AWS Systems Manager (SSM) の Run Command は、AWS環境内のEC2インスタンスなどをリモート操作できる強力なツールです。Run Commandの基本的な使い方については、前回の記事でも詳しく説明していますので、興味がある方はぜひご覧ください。
https://qiita.com/free-honda/items/f2a2e922a826c2b45a18
https://qiita.com/free-honda/items/071fc55d2c8f2aee57c3
この記事では、EventBridgeを使用してEC2インスタンスの起動を検知し、Lambda関数をトリガーとしてSSMコマンドを実行します。
さらに、指定のインスタンスにApacheのサービスを自動起動させる自動化の流れを解説します。
## 前提条件
この手順では、AWSの各種サービスを活用して、インスタンスの起動を動的に検知し、Apacheサービスの起動を自動化するフローを構築します。 の Run Command は、AWS環境内のEC2インスタンスなどをリモート操作できる強力なツールです。この記事では、EventBridgeを使用してEC2インスタンスの起動を検知し、Lambda関数をトリガーとしてSSMコマンドを実行し、指定のインスタンスにメッセージを出力する自動化の流れを解説します。
Run Commandの基本的な使い方については、前回の記事でも詳しく説明していますので、興味がある方はぜひご覧ください。
https://qiita.com/free-honda/items/f2a2e922a826c2b45a18
## 前提条件
この手順では、AWSの各種サービスを活用して、インスタンスの起動を動的に検知し、コマンド実行まで自動化するフローを構築します。
」がどのような仕組みなのかを理解するために実際に触って試した際の記録。
## 検証構成
SQS -> Lambda
## 検証
### SQS
あらかじめ適当な名前でSQSキューを作っておく。今回は標準キューを採用。
### Lambda
– SQSキューからバッチでメッセージをポーリングし、メッセージ本文をログ(CloudWatchLogs)に出力
– 部分的なバッチレスポンスの挙動を確認したいので、特定のメッセージのみ例外を発生させる(バッチで取得した最後の要素で例外を発生させる)
– 例外が発生したメッセージのIDをレスポンスに含める
– 部分的なバッチレスポンスによって、**
Lambda で awscli を利用する
# はじめに
Lambda でAWS のインスタンスを管理をさせたいとき awscli のインストールが必要になるので、これを利用できるようにする。# 概要
1. awscli を利用する EC2 のインスタンスと同じ OS を用意する (docker)
1. docker container でawscli をインストールして zip でかためる
1. zip にしたファイルを S3 に置く
1. S3 に置いたファイルをLambda のレイヤーで 指定する
1. Lamda の関数を用意して レイヤーを指定
1. bootstrap, hello.sh を用意(編集)# awscli を利用して EC2 に接続する Access キーを用意する
“`bash
# cat /var/lib/aws/aws_cli.key
アクセスキー
シークレットキー
ap-northeast-1 (ゾーン)
text
“`# awscli をインストールする環境 (docker コンテナ) の用意
Amazon Linux 2023 でawscli を動作させたいので、このOSの
AWS CloudTrailのJSON確認とEventBridgeを活用した詳細なイベントキャプチャ手法
# CloudTrailのJSON確認方法とEventBridgeでのイベントキャプチャ手法
EventBridgeは、AWSサービスやカスタムアプリケーションからのイベントを受け取り、指定したターゲットにルーティングするサービスです。CloudTrailと組み合わせることで、特定のイベントが発生した際に自動的に処理を行えます。
AWSリソースの変更やAPIコールをトリガーとしてEventBridgeで検出する場合、CloudTrailのJSONイベントを使用します。しかし、CloudTrailのコンソール画面での確認だけでは十分でないことがあります。
そこで、より詳細な条件でのイベントキャプチャ方法について解説します### 使用するリソース
1. CloudTrail
1. Eventbridge
1. Lambda
1. CloudWatch Logs## Lambdaの作成
Lambda関数内でイベントデータをログに出力することで、どのようなイベントがキャプチャされているかを確認できます。 のリスナールールを動的に変更する方法を紹介します。メンテナンスモードや通常モードへの切り替えを自動化することで、システムの可用性を高めることができます。
## 全体のコード
“`py
import boto3def lambda_handler(event, context):
ec2_client = boto3.client(‘ec2’)
ssm_client = boto3.client(‘ssm’)
elbv2_client = boto3.client(‘elbv2’)# 監視対象のEC2インスタンスIDリスト
instance_ids = [“i-0458be1d8c980e8ec”, “i-0b27db6a9b067f345”]# httpdサービスの状態を確認するためのSSM Run Command
AWS LambdaとSSMを使用したEC2インスタンスの状態監視とALBの動的切り替え①
## はじめに
AWS LambdaとAWS Systems Manager (SSM) を活用し、EC2インスタンスのhttpdサービスの状態を監視して、状態に応じてApplication Load Balancer (ALB) のリスナールールを変更する手法について解説します。具体的には、httpdサービスが停止している場合にメンテナンス用のSorryページを表示し、少なくとも1台のサービスが稼働している場合は通常のページを表示するように設定します。
## コード紹介
### 全体のコード
以下は、Lambda関数で実装されたコードです。SSM Run Commandを使用してhttpdサービスの状態を確認し、サービスの停止に応じてALBのルールを変更する処理を行います。“`py
import boto3
import timedef lambda_handler(event, context):
ssm_client = boto3.client(‘ssm’)
elbv2_client = boto3.client(‘elbv2’)#
NestJSでログフォーマットを変更してリクエスト単位のIDを共通でログに記録する方法
## ログの標準フォーマット
NestJSの標準で出力されるログは以下のような感じです
“`
[Nest] 227 – 10/09/2024, 2:47:17 PM LOG [NestFactory] Starting Nest application…
“`ただ、運用を考えると以下の点を変更できるようにしたく思いました。
– プロセスIDの前にある`[Nest]`がいらない
– プロセスIDよりリクエスト単位のIDが欲しい
– AWS Lambda上で実行するならAWSが割り振ったリクエストIDを使いたい
– 余計なスペースは削除したい
– 時間はミリ秒まで出して欲しい
– ログレベルのみでログ監視できるようにしたい## NestJSのログ拡張方法について
Loggerは一から`LoggerService`で定義されたインターフェースを実装する方法もありますが、基本的な動きは変更せずに処理を少し変更したいような場合は、`ConsoleLogger`クラスを継承して、変更したいメソッドをオーバーライドすることで対応が可能です。
外部ロガーを
個人的な備忘録：Lambda関数でのいろいろな処理について
## 全体コード
“`py
import boto3def lambda_handler(event, context):
ec2_client = boto3.client(‘ec2’)
elb_client = boto3.client(‘elbv2’)# 監視対象のEC2インスタンスのID
instance_ids = [‘i-0123456789abcdef0’, ‘i-0abcdef1234567890’]# インスタンスの状態を確認
response = ec2_client.describe_instances(InstanceIds=instance_ids)instances_stopped_count = sum(
1 for reservation in response[‘Reservations’]
for instance in reservation[‘Instances’]
if instance[‘State’][
Lambda（python）でS3からファイルを取得し、ファイルのマジックナンバーとMIMEを判定する
# やりたいこと
Lambda（python）で事前にS3バケットへアップロードしたファイルを取得し、ファイルの各メタデータであるマジックナンバーとMIMEを取り、ファイル形式を判定したい# 構築
・S3バケット
・Lambda
・IAMポリシー
・IAMロール# やり方
Lambda→S3のポリシー
“`
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “VisualEditor0”,
“Effect”: “Allow”,
“Action”: [
“s3:*”
],
“Resource”: “arn:aws:s3:::*”
}
]
}
“`Lambdaソース
“`
import boto3def lambda_handler(event, context):
# S3バケットとファイルキーを指定
Lex Bot の slots の値をLambdaで取得してみる
# はじめに
本記事では、Lexのslotに設定された値を `Code hooks` で呼ばれたLambdaで受け取る処理を実装していきます。# 環境
– Python：3.12
– Lex：v2# ゴール
Code hooksで呼ばれたLambdaでLexのslotに設定された値を受け取る# Lex
本記事では下記のようにslotが1つあるLex Botを想定してます。
何でもよいですが今回は日付入力を想定して、Slot typeを`AMAZON.Date`にしておきます。– SLots
– Name：get_date
– SLot type：AMAZON.Date
– Prompts：hoge
– Sample utterances
– {get_date}
