AWS関連のことを調べてみた

LocalStack v2 で AWS CLI コマンドを使う

## 前説など

– https://qiita.com/outerlet/items/8199c2f4eb7cbc678f16 と同じ目的で書きました
– こちらは LocalStack v3 にも使えるかも知れませんが、裏付けをとっておらず現時点ではv2対応としておきます

## コンテナの LocalStack に対しAWS CLIコマンドを発行する方法

1. コンテナの外から `aws` コマンドを使う
2. コンテナに入って `awslocal` コマンドを使う

## （事前準備） LocalStack 用のプロファイルを定義

– `aws` コマンドの `–profile` に与える LocalStack 用のプロファイルを用意しておく
– 中身は適当でよいが、存在するAWS環境に有効なプロファイルを使うと LocalStack の方でエラーにしてしまうはず

#### （例） ~/.aws/config

“`plaintext
[profile localstack]
region = ap-northeast-1 # この値は AWS_DEFAULT_RE

LocalStack v2 のセットアップ（Docker Compose使用）

## 前説など

– 好き勝手に使えるAWS環境をローカルにエミュレートできるとのことで、色々試したときの記録を残しておきたかったのと、しばらく違う仕事をしてたので復習しておきたかったという次第です
– とはいえ既に[LocalStack v3が使えるらしい](https://blog.localstack.cloud/2023-11-16-announcing-localstack-30-general-availability/)ので、v2関連のネタにどこまで需要があるかは不明ですが（汗）
– 公式の説明は[こちら](https://docs.localstack.cloud/getting-started/installation/#docker-compose “https://docs.localstack.cloud/getting-started/installation/#docker-compose”)をご覧ください
– `docker run` を叩いて [localstack/localstack を起動する](https://docs.localstac

AWS SAMを用いてRemixアプリケーションをLambdaへデプロイする

## はじめに

[aws-lambda-web-adapter](https://github.com/awslabs/aws-lambda-web-adapter)を使って、とても簡単にRemixで作られたアプリケーションをLambdaにデプロイできたのでその手順をまとめました。

完成品はこちらのリポジトリにあります。

https://github.com/monjara/remix-sam-lambda-example

## 必要なもの
– SAM CLI
– Node.js
– Docker

## 階層構造

以下のような階層でプロジェクトを作成します。

“`sh
.
├── remix-app/ # Remixのアプリケーション
│   ├── (Remixのファイル群)
│   ├── Dockerfile # buildしたアプリケーションを実行するためのDockerfile
│   └── run.sh # remix-serveを実行するスクリプト
└── template.yaml # SAMのテンプレートファイル
“`

## Remixプロジェクト

Lambdaの実行中に、追加データを送ってみる

# この記事について

よくあるLambdaは次の図のような動きをします。
リクエストを投げるとLambdaの処理が始まって、処理が完了すると結果が返ります。


この記事では、次の図のようなことをする方法を紹介します。
実行中のLambdaに対して、追加のデータを送信します。


# 利用する環境

Lambdaの実装言語: TypeScript
ランタイム: Node.js 18.x

# 何が嬉しいのか

双方向通信をするだけならAPI Gatewa

（Amazon Linux 2023）AWS EC2にデプロイする① インスタンス起動〜Elastic IP（固定IP）を関連付ける

## はじめに
はじめてEC2にデプロイをしたため、備忘録も兼ねて、デプロイ手順を記事にしたいと思います。
記事が長くなりそうだったので、分割して投稿していきます。今回はAWSでEC2インスタンスを起動し、Elastic IP（固定IP）を関連付けるまでです。

## 前提
* インスタンス作成時にAmazon マシンイメージ (AMI)でAmazon Linux 2023を選択された方向けです
* Amazon Linux2を選択された方も手順は同じですが、Linuxコマンドが異なります
* AMIの調べ方は、EC2サーバーにSSH接続をし、下記のコマンドを入力すると確認できます
“`
cat /etc/os-release
“`

### 環境
* PHP 8.2
* Laravel 11
* mariaDB 10.5.23
* Nginx 1.24.0
* GitHub

## おおまかな流れについて
おおまかな流れは下記のとおりです。
1. AWSでEC2のインスタンスを起動する
1. 起動したインスタンスにElastic IP（固定IP）を関連付ける
1. EC2サーバの

AWS CloudFormationの最近の変更点 その2

## その２．ちょっと便利になった変更
[前回](/a-shiosalt/items/573086bfcf3b6347e639)の「三大変更点」ほかに引き続き、CloudFormationの変更点を記録しておきます。

前回は[Gitと同期](/a-shiosalt/items/573086bfcf3b6347e639#1-git%E3%81%A8%E5%90%8C%E6%9C%9Fgit-sync-202311)など新規追加機能を説明しました。
今回は、基本変わらないけどもちょっと便利になった変更箇所です。

1. [「根本原因を検出」ボタン追加](#1%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E3%82%92%E6%A4%9C%E5%87%BA%E3%83%9C%E3%82%BF%E3%83%B3%E8%BF%BD%E5%8A%A0-202311) (2023/11)
2. [AWS CloudTrail 統合](#2-aws-cloudtrail-%E7%B5%B1%E5%90%88202405) (2024/05)
3. [変更セットで変更の

Amazon Lookout for Metricsを構築してみました

## はじめに
Lookout for Metricsというサービスを触ってみる機会がありましたので学んだことを記載します。
## サービスの概要
Lookout for Metricsとは、AWSが提供する機械学習を利用した異常検出サービスになります。
ビジネスデータや運用データの中から異常を検出(異常検知)し、その原因を迅速に特定するのに役立つサービスになります。

https://aws.amazon.com/jp/lookout-for-metrics/
## 前提
・AWSアカウントがあること
・Lookout for Metricsとのデータ連携にはS3を利用
・データ形式はCSV
※後述しますが、状況によって多額の費用が発生するため、設定する値については十分注意してください。
## やること
・異常検知させるデータを作成する
・S3のバケットを作成し、データをアップする
・BacktestモードでLookout for Metricsを設定する

## データの作成
使用するデータについてはAWSの公式でもサンプルがあります。
以下のサイトからloyalty.csvをダウ

Public IPv4を持たないデュアルスタック構成でWebサーバー環境をTerraformで構築してみた

# はじめに
こんにちは、こんばんは、どうもamaebiと申します。
今回は、Public IPv4を持たないデュアルスタック構成でWebサーバー環境をTerraformで構築しました。
本ブログの想定読者として、「Public IPv4が有料化したし、Public IPv4を使用しない構成をぱぱっと作りたい」という方向けになっておりますので、必要に応じてカスタマイズしていただけますと幸いです。

https://aws.amazon.com/jp/blogs/news/new-aws-public-ipv4-address-charge-public-ip-insights/

# 考慮していない点
本ブログで以下の内容は考慮しておりません。
こちらは、後日ブログにする予定です。

– バックアップ設定
– ログ情報 の保存
– 運用・保守 (CloudWatch等)

# 構成図
![lamp構成.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3765414/73345a04-bd1a-8d17-3

AWS Lambda にPythonウェブサーバーを立てる最小のDockerfileを書いた

関数URLにアクセスすれば

これが動くなら言語、フレームワーク問わずどんなウェブサーバーも動かせそうですね
“`Dockerfile
FROM public.ecr.aws/lambda/python:3.12
COPY –from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.3 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=8080
RUN printf “\n\
import os, http.server, socketserver\n\
class MyHandler(http.server.SimpleHTTPRequestHandler):\n\
def do_GET(self):\n\
se

【Amplify Gen2】Amplifyの導入手順をまとめてみた

2024年5月にAmplify Gen2が一般提供となり、これを機に始める方もいると思います。
ドキュメントがまだ充実していないので、Amplifyについて書こうと思います。

## Amplify導入手順
### ①AWSアカウントを作成する
・以下よりサインアップできます。手順に従ってください。

https://portal.aws.amazon.com/billing/signup

### ②AWS CLIをインストール・セットアップする
・AWS CLIをインストールする

macOS

“`
curl “https://awscli.amazonaws.com/AWSCLIV2.pkg” -o “AWSCLIV2.pkg”
sudo installer -pkg AWSCLIV2.pkg -target
“`
AWS CLIのインストールを確認

“`
aws –version
“`

Windows

“`
msiexec.e

RDS Blue/Green DeploymentsでMySQL 5.7->8 へアップグレードした話

## 背景

Webサービスを運用していくにあたり、RDBのアップグレードに迫られる場合があります。ありますよね？

弊社のあるプロダクトのバックエンドについても Aurora MySQL 2.11.1(MySQL 5.7系) で稼働しておりましたが、Aurora MySQL v2系は 2024/10/31 を以って標準サポートが終了します。

Aurora MySQL v3 で現時点で利用可能な最新LTSバージョンは 3.04.2 (MySQL 8.0.28) になるため、MySQL 5.7 から MySQL8へのアップグレードが必要になってしまいました。

今回はそんなDBアップグレードを「RDS Blue/Green Deployments」でやってみた、という記事になります。

## RDS Blue/Green Deploymentsって？

以下はAWSの公式Docです

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html

ざっく

AthenaでSimple Notification Serviceの送信ログを読み込めるようにした

## S3上にあるログファイルをいい具合に取得したい

最初に、個人的なメモの側面もあるのでご容赦してほしい。

やりたかったことは、送信ログを解析したり、月々の送信数を把握したかった、それだけです。
その為に、s3上のログをいい具合に取り込んで上げる必要があった。参考にしたのは下記のページ。

https://zenn.dev/gomi_ningen/scraps/f2a340b1f2651e

https://staff-blog.faith-sol-tech.com/%E3%80%90%E5%88%9D%E5%BF%83%E8%80%85%E5%90%91%E3%81%91%E3%80%91amazon-athena%E3%81%AE%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A8%E3%81%AF/

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/partition-projection-setting-up.html

下記ク

AWSキーペアにED25519形式のpemファイルを作成してTerraformで公開鍵を登録する

AWSキーペアに登録するキーペアの作成方法をよく失念するので、一連の流れを備忘録として整理。

1. AWSキーペアに登録するためのキーペア(ED25519、PEM)を作成する
個人的には強度の強いED25519を使っています
“`shell
ssh-keygen -t ed25519 -C “公開鍵に記載されるコメント” -m PEM
“`
保存先のパスとパスフレーズ(確認も含め)を入力すると、秘密鍵と公開鍵が作成されます。
1. tfファイルでaws_key_pairリソースを作成する

“`terraform
resource “aws_key_pair” “sample” {
key_name = “sample”
public_key = “ssh-ed25519XXXXXXXXXXXXX”
}
“`
publik_keyには1で作成された公開鍵(.pub)の値をコピーする

1. Terraformでplanしてみて意図したものになっているか確認する

AWS RDS MySQL 標準サポート終了に伴う対応

### はじめに
このドキュメントは、AWS RDS MySQL 5.7の標準サポート終了に伴い、MySQL 8.0へのアップグレードを実施するための手順をまとめたものです。
MySQLのバージョンアップに際して、事前準備から実行手順、検証、そして万が一のロールバック手順までを網羅しています。
特に、Railsを使用しているプロジェクトにおいて、互換性の確認や必要な設定変更についても触れています。MySQL 8.0への移行は、セキュリティの向上や新機能の利用など、多くのメリットがありますが、慎重な準備と計画が必要です。

### 事前準備
1. **バックアップの取得**
– 現在のAuroraクラスタのバックアップを取得します。アップグレード中に問題が発生した場合に備えて、データを保護するために必須のステップです。
“`shell
aws rds create-db-cluster-snapshot –db-cluster-identifier –db-cluster-snapshot-identifier

Terraformを使ったLambda関数のコンテナイメージ構築

# はじめに

AWS Lambdaは、サーバーレスでイベント駆動型のコンピューティングサービスです。従来のLambda関数ではzipファイルでコードをアップロードしていましたが、コンテナイメージを使用することで、より柔軟で強力な開発・デプロイが可能になります。
本記事では、Infrastructure as CodeツールであるTerraformを用いて、Lambda関数として実行するコンテナイメージを構築し、AWS環境へデプロイする手順を解説します。

制作したレポジトリはこちらです。

https://github.com/sugiyama404/practice_lambda_docker

参考にしたサイト

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/python-image.html#python-image-instructions

# 目的

Lambda関数をコンテナイメージで実行することにより、柔軟性とパフォーマンスを向上させることを目指します。

# インフラ構成

![aws.png](https:/

Next.jsを使用して成果物をS3にデプロイし、CloudFront経由で公開する方法

CloudFrontを使ったページ公開時に詰まった経験のある方、これからページ公開をやりたい方はぜひみていただけると幸いです。

## 使用するAWSサービス

– S3
– CloudFront
– (Route53)

## 0. HTMLを生成
Next.jsのプロジェクトでは、ページを生成する方法としてSPA（シングルページアプリケーション）、SSG（静的サイト生成）、SSR（サーバーサイドレンダリング）の3つの選択肢があります。今回はSSG（静的サイト生成）を対象に手順を説明します。なお、SPAの設定も大きくは変わりませんが、SSRはLambdaなどサーバーが必要になるため、別記事で詳しく説明します。

手順:
`next.config.mjs` に以下を設定します

“`ts
/** @type {import(‘next’).NextConfig} */
const nextConfig = {
output: ‘export’
};

export default nextConfig;
“`

これにより、静的なHTMLファイルが、outディレクトリに生成され

AWS NAT ゲートウェイ を理解した上で起動＆停止 Lambda を用意する

# 実現したいこと
既存のAWSのバックエンドシステムにおいて、コスト削減のため開発環境とステージング環境のNATゲートウェイ（NAT Gateway）を夜間と休日の間は停止させるべく、NATゲートウェイを起動・停止させるLambdaを作成します。

# 待て、まだコードを書こうとするな
「NATゲートウェイ　自動　停止」とかで検索すると少ないながらもいくつか記事が出てきますが、理解せずにそれをまるまるコピペして実行させるだけではうまくいかないことが多いですし、望まないNAT削除をしてしまう可能性があります。
NATゲートウェイ、ルートテーブル、Elastic IPなどが自分の開発しているシステムではどのように設定されていて、どのリソースを操作すれば良いかをちゃんと理解する必要がありました。

こちらは開発していたシステムの構成図を、NATゲートウェイ周りだけを抽出して描いたものです。
手描きでごめんなさい。（手で描いた方が頭に残ると思って。）
これを基にNATゲートウェイ周りを説明します。

![IMG_0214.jpg](https://qiita-image-store.s3.a

脱初心者！「社内向けAWS実践提案道場」参加感想

# 参加前

AWSからパートナー企業向けに提供されているAWS実践道場がありますが、今まで参加した経験がないのでずっと行きたいと思っていました。

今回、社内で似たようなイベントが開催され、どうしても参加したかったので部署内で調整してもらい、行かせてもらいました。
（機会を譲ってくださったPJリーダーのAさん、本当にありがとうございます！）

私が所属している部署にはAWSの黒帯のベテランがたくさんいるので、参加前は自分自身が大丈夫か？足を引っ張ったらどうしよう？といった不安がありました。

しかし、チャレンジしないと人間は成長しないので、最後は平常心で臨みました。

# イベント内容

弊社の先輩方のブログをご参照ください～

https://www.beex-inc.com/blog/aws_practicedojo

# 印象的なところ①
「みなさんはなぜEC2を使わないのか？」と講評者さんがイベントの最後におっしゃった言葉が非常に印象的でした。

「確かに。。。」と思いました。

いつの間にか、「クラウドを使う＝脱オンプレミス＝サーバーレス」という固定概念が心の中にできて

Node.jsでS3の署名付きURL取得

node.jsで署名付きURL取得するコードサンプルを書きました。
aws-sdk v3を使用しています。

“`javascript
import { S3Client, PutObjectCommand, GetObjectCommand } from “@aws-sdk/client-s3”;
import { getSignedUrl } from ‘@aws-sdk/s3-request-presigner’;

const s3 = new S3Client({ region: process.env.AWS_REGION });
// 環境変数にあらかじめBUCKET_NAMEを登録しておく
const BUCKET_NAME = process.env.BUCKET_NAME;
const KEY = “hoge”

export const handler = async (event) => {
const { filename, contentType } = JSON.parse(event.body);
console.log(“body”,

AWSサービスメニュー開発をしていてAWSを好きだ！と感じた瞬間

# 勉強会
JAWS-UG#59で発表させて頂きました。

https://jawsug-asa.connpass.com/event/291919/

# 内容
社内でAWSのサービスメニュー開発を行いました。AWSを利用して何かアプリケーションを構築したわけではなくAWSの構築や運用をシステムインテグレーターとして提供するサービスです。


実施の背景としてはクラウド関連の案件の需要が増加する中、AWS案件は実施しているものの、まだまだオンプレミス対応案件に比べ、クラウド案件の対応割合が低いためです。

![スライド5.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/4558d662-f008-c5d0-9dd6-58683e08d19c.pn