AWSを使った開発では、

ちょっとした修正でもdev環境へデプロイが必要
S3イベントを試したいだけなのに時間がかかる
Lambdaとの連携を気軽に確認したい

という場面がよくあります。

そんなときに便利だったのが LocalStack でした。

この記事では、実際によくある

S3 → Lambda

の構成をローカルで動かす手順を紹介します。

LocalStackを使う理由

通常の開発フローはこんな感じです。

コード修正
    ↓
AWSへデプロイ
    ↓
動作確認

ちょっとした修正でも数分待つことがあり、繰り返していると意外と時間を使います。

LocalStackを使うと、

コード修正
    ↓
ローカルで動作確認

という流れになるため、試行錯誤のサイクルをかなり短縮できます。

個人的には次のようなケースで特に便利だと感じました。

S3イベント
Lambda実行
SQS連携
Parameter Store（SSM）を使った検証

LocalStackを起動する

まずはDocker ComposeでLocalStackを起動します。

version: "3.8"

services:
  localstack:
    image: localstack/localstack:latest
    container_name: localstack
    ports:
      - "4566:4566"
    environment:
      - SERVICES=s3,lambda
      - DEBUG=1
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

起動します。

docker compose up -d

LocalStackへ入る

公式イメージには awslocal が入っているので、そのまま利用できます。

docker exec -it localstack bash

以降の操作はコンテナ内で行います。

S3バケットを作成する

awslocal s3 mb s3://my-bucket

確認します。

awslocal s3 ls

Lambdaを作成する

今回は動作確認用にシンプルなLambdaを用意します。

exports.handler = async (event) => {
  console.log("Event:", JSON.stringify(event));

  return {
    statusCode: 200,
  };
};

ZIP化します。

zip function.zip index.js

続いてLambdaを登録します。

awslocal lambda create-function \
  --function-name my-function \
  --runtime nodejs18.x \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::000000000000:role/lambda-role

S3イベントを設定する

S3へファイルがアップロードされたらLambdaを呼び出すよう設定します。

awslocal s3api put-bucket-notification-configuration \
  --bucket my-bucket \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "arn:aws:lambda:us-east-1:000000000000:function:my-function",
      "Events": ["s3:ObjectCreated:*"]
    }]
  }'

動作確認

適当なファイルをアップロードします。

echo "test" > test.txt

awslocal s3 cp test.txt s3://my-bucket/

ログを確認します。

awslocal logs describe-log-groups

イベントが正しく設定されていれば、Lambdaが実行されます。

Laravelから接続する場合

.env

AWS_ACCESS_KEY_ID=test
AWS_SECRET_ACCESS_KEY=test
AWS_DEFAULT_REGION=ap-northeast-1
AWS_BUCKET=my-bucket
AWS_ENDPOINT=http://localstack:4566
AWS_USE_PATH_STYLE_ENDPOINT=true

config/filesystems.php

's3' => [
    'driver' => 's3',
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'region' => env('AWS_DEFAULT_REGION'),
    'bucket' => env('AWS_BUCKET'),
    'endpoint' => env('AWS_ENDPOINT'),
    'use_path_style_endpoint' => true,
],

use_path_style_endpoint はLocalStackを利用する場合に設定しておくと安心です。

ハマりやすかった点

endpointを指定し忘れる

AWS SDKやAWS CLIでエンドポイントを指定しないと、本物のAWSへ接続してしまいます。

LocalStackを利用する場合は、エンドポイントの指定を忘れないようにします。

localhost問題

Dockerコンテナ同士で通信する場合は

http://localstack:4566

を利用します。

コンテナ内から localhost を指定しても接続できません。

IAMの挙動が本番と異なる

LocalStackは便利ですが、IAMの検証は実AWSほど厳密ではありません。

ローカルでは問題なく動いても、本番AWSでは権限不足になるケースもあります。

そのため、最終確認は実際のAWS環境で行うようにしています。

LocalStackを使って感じたこと

LocalStackは「AWSを完全に再現するツール」というより、

AWSを使った開発を効率化するためのツール

という印象でした。

ローカルで何度も試行錯誤できるため、実装スピードはかなり上がります。

一方で、本番との差異がゼロではないため、最後は実AWSで確認する運用が安心です。

私の中では、

ローカル：LocalStack
CI・検証環境：実AWS

という使い分けが一番しっくりきています。

まとめ

LocalStackを使うことで、

S3
Lambda
SQS
Parameter Store

などの連携をローカルで素早く確認できるようになります。

毎回AWSへデプロイして動作確認していると、少しずつ待ち時間が積み重なります。

ローカルで完結できる部分はLocalStackを活用し、最終確認だけ実AWSで行うようにすると、開発効率を上げつつ安全性も確保しやすいと感じました。