DEV Community: Yoshiyuki Watanabe

AWS DevOps Agent Hands-on: Isolating the Cause of ALB Target 5xx Between ECS and Aurora

Yoshiyuki Watanabe — Sat, 24 Oct 2026 11:12:21 +0000

Introduction

A 5xx alarm that goes off in the middle of the night is a good test for AWS DevOps Agent: how much of the work of isolating the cause can it take over? In this hands-on article, I use an ALB HTTPCode_Target_5XX_Count alarm to find out.

The question to isolate is whether the cause is in the backend (the app on ECS) or in the database (Aurora).

Traditionally, the person who receives the alarm moves back and forth between ALB metrics, application logs, and Aurora metrics and Performance Insights to find the cause. I check how much of this work can be handed to AWS DevOps Agent, using two failure scenarios whose causes sit in different layers.

Test Environment and Scenarios

Environment

I assume that an Agent Space for DevOps Agent has already been created. For the steps, see the official documentation Creating an Agent Space.

The settings used in this article are as follows.

Agent Space Name: alb-5xx-demo
Agent response language: English (US)
Configure primary account role: Auto-create a new DevOps Agent role (DevOpsAgentRole-AgentSpace-* is created)
Enable web app > Configure current account role: Auto-create a new DevOps Agent role (DevOpsAgentRole-WebappAdmin-* is created)
Everything else: default values

The environment assumes an e-commerce site and is built as follows.

The ALB forwards requests to a Flask app on ECS Fargate
The app reads the products table (3 million rows) in Aurora MySQL
The ALB health check path /health does not look at the state of the DB; it returns 200 as long as the app can respond
The app writes JSON logs to CloudWatch Logs. Aurora has Performance Insights enabled and also outputs the slow query log (long_query_time set to 2 seconds)
The HTTPCode_Target_5XX_Count alarm is passed to the DevOps Agent CreateBacklogTask API through EventBridge and Lambda, which starts an investigation automatically

Telling Where a 5xx Comes From

ALB 5xx responses fall into two kinds: those returned by the ALB itself (HTTPCode_ELB_5XX_Count) and those returned by a target and relayed by the ALB (HTTPCode_Target_5XX_Count). This article covers the latter.

The main causes of 5xx responses returned by the ALB itself are summarized in the AWS documentation "Troubleshoot your Application Load Balancers".

docs.aws.amazon.com

Scenarios

Scenario A: the cause is in the backend (a latent application bug)

Root cause: a product with no price (NULL) is registered, and the function that calculates the sale price (sale_price()) has no guard for NULL, so the price calculation on the top page raises a TypeError
A recent deployment is not the cause
The conclusions I expect from DevOps Agent are to identify the stack trace and the ID of the product whose price is NULL (product_id), to find that a recent deployment is not the cause, and to find that the Aurora metrics are normal

Scenario B: the cause is in the DB (a full scan by a search query)

Root cause: the product search query LIKE '%keyword%' ORDER BY created_at DESC cannot use an index and scans all 3 million rows, which pins Aurora CPU
The conclusions I expect from DevOps Agent are to confirm the CPU spike, to identify the top SQL, and to point out the missing index

Starting a DevOps Agent Investigation Automatically from an Alarm

When the alarm goes into ALARM, an EventBridge rule calls Lambda. Lambda then creates an investigation task (INVESTIGATION) through the DevOps Agent CreateBacklogTask API.

docs.aws.amazon.com

I chose this approach based on an AWS re:Post article. The reasons are that it authenticates with an IAM role, so no long-lived secret is needed, and that it is simpler than a webhook.

Automating AWS DevOps Agent investigation from Incident Detection and Response alarms | AWS re:Post

Learn how to route AWS Incident Detection and Response alarms to AWS DevOps Agent for instant, autonomous investigation when an alarm activates.

repost.aws

A configuration that uses a webhook (HMAC signature) also exists, and the official AWS blogs introduce it more often. A webhook suits cases where an investigation is started from an external monitoring tool or a system outside AWS.

docs.aws.amazon.com

How to Read Investigation Results

The results of a DevOps Agent investigation are viewed in a dedicated web app. In the Agent Spaces list, I chose Launch via IAM for the target Agent Space, and the web app opened.

The list of investigations appears under Incidents in the left navigation of the web app.

When you select an investigation, you can check the results in five tabs: Summary, Investigation timeline, Root cause, Mitigation plan, and Review.

The tabs show the following.

Summary: a summary of the cause and the mitigation
Investigation timeline: a record of the steps the Agent took in the investigation
Root cause: the impact, the root causes, and the key findings
Mitigation plan: the steps of the mitigation
Review: a quality evaluation of a completed investigation

When you run Review with Run review, you get a verdict on whether the investigation was helpful and a result for each criterion. The five criteria are Scope Alignment, Evidence Grounding, Investigation Completeness, Environment Impact, and Investigation Accuracy.

Scenario A: A Latent Application Bug

I reproduce a situation where a product is registered without entering its price.

# Register a product without a price (simulating a missed input at registration)
curl -s -X POST "$APP/admin/products" \
  -H "X-Admin-Token: $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"【新作】防水ワイヤレスイヤホン","discount_rate":0.1}'

This product appears in "New arrivals" on the top page, which shows the 10 newest products by id, so only the top page returns 500. Product detail pages keep returning 200. To simulate user traffic, I sent random requests, about 30% to the top page and about 70% to product detail pages.

for i in $(seq 1 300); do
  if [ $((RANDOM % 10)) -lt 3 ]; then
    path="/"
  else
    path="/products/$((RANDOM % 1000 + 1))"
  fi
  curl -s -o /dev/null -w "%{http_code} " "$APP$path"
  sleep "0.$((RANDOM % 4 + 1))"
done; echo

After a while, the 5xx alarm went off and a DevOps Agent investigation started. The investigation finished in about 10 minutes 30 seconds.

Summary

Incident, Cause, and Mitigation are gathered on one screen. None of them appeared to contain errors.

Incident: all the 5xx responses came from the backend, and there were zero 5xx responses from the ALB itself. The problem has already subsided
Cause: the root cause is the combination of a product whose price is NULL (product_id is 3932101) and the missing NULL guard in sale_price(). ECS and Aurora are ruled out as causes
Mitigation: the immediate action is to fix the NULL price, and the permanent action is a NULL fix in sale_price() plus a check at registration

The scale of the failure is shown with number cards and a graph. Peak 5xx/min is 89, and Aurora status is available. The graph also shows that 2xx responses were returned at the same time as the 5xx responses.

Investigation timeline

You can see DevOps Agent having sub-agents investigate in parallel. They look at the following.

The application logs
The Aurora metrics (including Performance Insights), the Aurora error log, and the slow query log
The ECS task metrics

ECS CPU peaked at about 10% and memory at about 7%, so a lack of ECS resources was ruled out at this point. I found no errors in this part.

Root cause

The Root cause tab is organized into four parts. The root cause was identified correctly. The explanation of the trigger, however, was inaccurate.

Impact: the ALB targets returned 5xx and crossed the alarm threshold
Root causes: the combination of "a product has a NULL price (a data defect)" and "sale_price() has no NULL guard (a code defect)"
Key findings: Aurora was judged not to be the cause
Investigation gaps: how the NULL price got in. It could not be traced because no code repository or data pipeline is connected

Across the whole investigation, the Agent went as far as the following.

From the stack trace in the application log, it identified the TypeError, product ID 3932101, sale_price() at /app/app.py:50, and the top page handler. It also showed that the 5xx count and the application error count match 1:1 minute by minute
It judged that the most recent deployment, which finished about 1.5 hours earlier, was not the trigger of this failure
It judged that Aurora was not the cause, based on many indicators, including connection count, db.load.avg, CPU, latency, buffer cache hit ratio, and the error log and slow query log
It also explained why 200 and 500 alternate: requests that do not include product 3932101 in the new arrivals return 200

The trigger was explained as "a traffic burst ... exposed the latent defect". The actual trigger was the registration of a product without a price.

Also, there is no sign that DevOps Agent queried the DB directly. The conclusion that "a product has a NULL price" was an inference from the TypeError message and the logs. The conclusion was correct.

Mitigation plan

The SQL to repair the data and the risk warnings are written in stages (pre-check, apply, post-check, rollback). It proposed repairing the rows with a NULL price and handling NULL in sale_price(), with an execution plan, and the approach was sound. The column name in the SQL, however, was wrong.

The top of the plan has an overview. The approach is to repair the NULL price and add a NULL guard to sale_price(). It also says that, because the data and code defects remain, the same error will recur in the next burst, and that rollback does not apply because there has been only one deployment.

The apply step (Step 2: Apply) shows SQL that updates the NULL price inside a transaction. It comes with warnings: do not enter an arbitrary price but use a price confirmed by the product owner, and check that exactly one row is updated before COMMIT.

The column name in the repair SQL was wrong. It said WHERE product_id = 3932101, but the primary key of the actual table is id. When I actually ran it, it failed with ERROR 1054 (42S22): Unknown column 'product_id' in 'where clause'. In the application log, the product ID is output as a field named product_id. The Agent probably used that field name as the column name as it was. A person needs to check the SQL before running it.

Scenario A Result

All three conclusions I expected (identifying the stack trace and the product ID, finding that a recent deployment is not the cause, and finding that Aurora is normal) were obtained. The errors were in the explanation of the trigger and in the column name of the SQL.

Scenario B: A Full Scan by a Search Query

I put parallel load on product search (/search) to pin the Aurora CPU. The search uses name LIKE '%keyword%', which starts with a wildcard, so an index cannot be used and it scans all 3 million rows.

hey -z 5m -c 30 "$APP/search?q=%E3%82%B1%E3%83%BC%E3%82%B9"

As in Scenario A, after a while the 5xx alarm went off and a DevOps Agent investigation started. The investigation finished in about 15 minutes 11 seconds.

Summary

Incident, Cause, and Mitigation contain the following. The root cause and the mitigation were correct, but the summary included a misidentification: it treated the Lambda that starts investigations as the source of the load.

Incident: it says 5xx bursts repeated on a cycle of about 20 minutes. The peak was about 5,330 per minute, and about 97% of the failures were 1040 (connection refused) and about 3% were 2013 (read timeout). Between bursts, the targets recover on their own
Cause: the root cause is a full scan of about 3 million rows by a LIKE that starts with a wildcard. This one statement accounts for 100% of the DB load and causes CPU saturation and connection exhaustion at the same time
Mitigation: the permanent fix is to make /search index-friendly, a connection pool and a concurrency cap, and a server-side timeout. The stopgap is to add a FULLTEXT index and scale up

At the end of Cause, it says that an "intentional demo load generator Lambda" is the source of the load that caused the 5xx. This is wrong.

This Lambda starts investigations and does not generate any load. The actual source was hey on my own machine
The Agent's role could not read the Lambda's configuration, and it appears to have mistaken the cadence of CreateBacklogTask in CloudTrail for the cadence of the load
The "recurring ~20-min bursts" in Incident are also, in reality, the result of me running hey repeatedly

Investigation timeline

The tab shows, in chronological order, what DevOps Agent checked and in what order. It corrected a wrong early assessment on its own, but the misidentification of the Lambda remains in the final summary.

In the first 4 minutes or so, the Agent verifies the alarm and organizes the situation. It confirmed three things.

ECS is replacing tasks because of health check failures
RequestCount is almost the same as the 5xx count, and 2xx is almost 0
Aurora CPU reaches 99 to 100% in every burst

It then raises a question: "why does Aurora hit 100% CPU at only ~50-80 req/s and <20 connections?" It has three sub-agents investigate in parallel: the application logs (app-logs), the DB internals (aurora-db-analysis), and infrastructure changes (infra-changes).

The assessment at this point was "CPU saturation, not connection/memory exhaustion", because the maximum of DatabaseConnections was only 16 to 19. This assessment is corrected later.

At 4 minutes 26 seconds, the Agent is running four jobs in parallel (app-logs, aurora-db-analysis, infra-changes, and propose-mitigation).

For aurora-db-analysis, it had the sub-agent look at the slow query log, the Performance Insights top SQL, and the instance size. At 5 minutes 26 seconds, the following results came back.

There is one full-scan query, and the ratio of Rows_examined to Rows_sent is extremely large
A single execution takes 16 to 114 seconds
This one statement accounts for 100% of the DB load (the peak of average active sessions is about 90.9)
The dominant wait is wait/io/table/sql/handler, so CPU is the bottleneck because of in-memory row scanning
The error log also supports this cause

Around the 8-minute mark, there is a hypothesis and its reconciliation. The application logs contained a large number of 1040 Too many connections (refused because the connection limit was reached). On the other hand, the DB-side sub-agent had concluded that there was no problem with connections, and the two conclusions conflicted.

The Agent formed a hypothesis that max_connections was low and checked it, but the parameter lookup came back empty, so it recorded the hypothesis as unresolved. It then reconciled the conflict between the two sub-agents on its own. The judgment was as follows.

MySQL doesn't log 1040 rejections, and rejected connections never register in DatabaseConnections
The DB-side sub-agent's conclusion was based on signals that are blind to this failure mode, and it over-concluded

It also organizes the flow from the full-scan query to the 5xx in four steps.

The full-scan query accounts for all of the DB load
As a result, CPU saturation and connection exhaustion happen at the same time
Requests that were refused a connection (1040) and requests that timed out after 10 seconds (2013) both become 5xx, and the alarm fires
Because the load arrives intermittently, the bursts repeat. Between bursts, CPU drops and the targets recover on their own

When I actually checked DatabaseConnections in CloudWatch, the maximum was only about 10 as a 5-minute average. Meanwhile, the application logs contain a large number of 1040 Too many connections. Looking at this metric alone, the connections appear to have plenty of headroom, so the Agent's point was confirmed on screen as well.

At about 10 minutes, the final summary appears. The following are gathered in one place.

The root cause
The two failure mechanisms that occurred together (CPU saturation and connection exhaustion)
The causes that were ruled out (deployment or configuration changes, memory, deadlocks, disk I/O)
An unrelated observation (a remnant of the Scenario A failure)
What could not be investigated

On the other hand, the Trigger (Inputs) paragraph also contains the misidentification that treats the Lambda which starts investigations as the source of the load.

From the screen, you can read an approach close to how human SREs handle a failure as a team: dividing roles and investigating in parallel, correcting an early assessment, and reconciling conflicting conclusions from team members.

Root cause

The Root cause tab is organized into three parts. The root cause was identified correctly, but the judgment about the Lambda in Investigation gaps was wrong.

Impact: it says 5xx repeated in bursts on a cycle of about 20 minutes
Root causes: only one full-scan query. The Agent wrote that "This single query is 100% of DB load", that fixing the query "stops recurrence", and that "The undersized burstable instance is a secondary amplifier only"
Investigation gaps: it could not read the configuration of the Lambda that starts investigations (the Agent's role lacks the lambda:GetFunction permission). Based on the cadence of CreateBacklogTask in CloudTrail, it judged that Lambda to be the "scheduled traffic generator". As described above, this judgment is wrong

Across the whole investigation, the Agent went as far as the following.

It organized the two symptoms, CPU saturation and connection exhaustion, as results of one root cause (the full-scan query)
Based on the Performance Insights top SQL, it showed that this one statement accounts for 100% of the DB load (the peak of average active sessions is about 90.9)
It showed that Rows_examined is about 3,000,021 against about 20 for Rows_sent, and that a single execution takes 16 to 114 seconds
It did not stop at the surface symptom Too many connections, and explained the causal chain in which the slow query holds each per-request connection for a long time and exhausts the connections

Mitigation plan

The mitigation is written in stages (record the current state, pre-check, apply, post-check, rollback), with commands and risks. The summary at the top separates a stopgap action from a permanent action. The content was mostly sound, but the explanation of the health check proposal was inaccurate.

Stopgap: add an ngram FULLTEXT index on products.name. Scale the writer up from db.t4g.medium to db.r6g.large
Permanent (application redeploy): rewrite /search into an index-friendly form (MATCH ... AGAINST, or a prefix match). Add a connection pool and a concurrency cap. Add a composite index that supports ORDER BY created_at DESC and a server-side statement timeout. Decouple the health check from the processing that uses the DB

The apply stage (Step 3: Apply) consists of two commands: ALTER TABLE products ADD FULLTEXT INDEX ft_products_name (name) WITH PARSER ngram; and aws rds modify-db-instance ... --db-instance-class db.r6g.large --apply-immediately. The Agent itself wrote the risks for each.

Creating the FULLTEXT index on a table of about 3 million rows consumes CPU and I/O. Run it after the resize or in a low-traffic window. The index alone does not change behavior until the application query is rewritten to MATCH ... AGAINST
--apply-immediately reboots the writer, and writes stop for about 1 to 2 minutes. The cluster is a single instance with no reader, so there is no failover target. The instance class is more expensive
Even if the connection limit goes up, without fixing the query, more concurrent 3-million-row scans can run and deepen CPU saturation. The Agent wrote that this is "a cushion, not a fix"

The permanent fix is organized in Agent-ready spec at the bottom of the screen as Change requirements (three requirements). Each comes with acceptance criteria.

Make the product-name search index-friendly (EXPLAIN no longer shows type=ALL and shows an index being used. Rows_examined drops from about 3,000,021 to roughly the number of matched rows. In Performance Insights, the statement no longer dominates DB load. The index is defined in a schema migration or IaC). This is the primary fix, and it says "fast queries release DB connections immediately, which also resolves the errno 1040 pileup"
Introduce a bounded connection pool and a request concurrency cap, so that a slow dependency fails fast instead of exhausting DB connections
An index that supports ORDER BY created_at DESC LIMIT 20, a server-side statement timeout (so the DB does not keep running orphaned queries after the client disconnects), and decoupling the health check from the processing that uses the DB

The permanent fix was sound. The stopgap scale-up does not fix the full scan itself, and the Agent itself wrote that "a larger instance alone still saturates at higher traffic". A person still needs to check the plan before running it.

The Agent also proposed decoupling /health from the processing that uses the DB. In this app, /health does not look at the DB in the code. During the load, however, ECS replaced tasks because of health check failures (replaced ... due to an unhealthy status). The worker threads were probably filled by slow /search requests, so /health could not respond in time. The Agent's wording was inaccurate, but the symptom it pointed to was correct.

Scenario B Result

All three conclusions I expected (confirming the CPU spike, identifying the top SQL, and pointing out the missing index) were obtained. The errors were the judgment that the Lambda starting investigations was the source of the load, and the explanation of the /health proposal.

Comparison with Investigating by Hand

Traditionally, the person who received the alarm investigated with the following steps.

Use ALB metrics to check whether the 5xx comes from the ALB or from the targets
Check the state of the ECS tasks and the application logs (CloudWatch Logs) for exceptions and connection errors
Check the Aurora metrics (CPU, connection count) and, if needed, connect to Aurora and look at the running queries
Check the Performance Insights top SQL and the slow query log

The differences with DevOps Agent are as follows.

Switching screens: a person moves between ALB, ECS, CloudWatch Logs, Aurora, and Performance Insights. DevOps Agent puts the conclusion, the evidence, and the mitigation in one place in the web app
How the investigation proceeds: a person investigates alone, one thing at a time. DevOps Agent splits the application logs, the DB internals, and infrastructure changes across sub-agents, investigates in parallel, and reconciles conflicting conclusions
Speed of start: it took about 2 seconds from the alarm firing to the start of the investigation. Even if the alarm goes off at night, the investigation result and a mitigation proposal are ready by the time a person wakes up
Duration of an investigation: about 10 minutes for Scenario A and about 15 minutes for Scenario B. The time varies with the complexity of the failure (other investigations varied from about 3 to 18 minutes)
How evidence is presented: the conclusion comes with numerical evidence (Rows_examined, average active sessions, the breakdown of errors), the flow of the investigation, and what could not be investigated. This makes it easy for a person to verify afterwards

On the other hand, DevOps Agent is not a replacement for people. Even in this test, there were several places where a person needed to check.

It misidentified the Lambda that starts investigations as the source of the traffic (Scenario B)
The column name in the mitigation SQL was wrong (Scenario A)
The time notation in the summary (UTC) did not match what operations expects by default

I felt that the division of labor is quite realistic: DevOps Agent does the first-pass investigation, and a person verifies the conclusion and the evidence and then carries out the mitigation.

A Refinement: Reporting Investigation Results in Japan Standard Time

DevOps Agent seems to use UTC for times by default. The summary of the first investigation also reported the alarm time in UTC, as 22:19:58 UTC.

The Lambda that starts investigations puts the contents of the alarm into the description of CreateBacklogTask and passes it to DevOps Agent. The contents are the alarm name, the reason for the state change, the time, and so on. The time in the alarm event arrives in UTC.

A Japanese operations team reads times more easily in Japan Standard Time, so I tried the following, in order, on the Lambda side and in the DevOps Agent settings.

The Lambda put both JST and UTC in the time it writes to description (Time: 2026-10-24 07:19:58 JST (2026-10-23T22:19:58.489+0000 UTC))
I removed the UTC and used only JST
I wrote a rule for reporting times in Global instructions (AGENTS.md)

The third one worked. From the Agents tab of the web app, open the details page of any of the Managed agents (the Agent Definition tab), and you will find an input field for Global instructions (AGENTS.md). It is labeled Shared across all agents, so it applies to all Agents. I wrote the following two lines there and pressed Save.

Report all times in Japan Standard Time (JST, UTC+9). When a source returns a UTC timestamp, convert it and show the JST value first, with the UTC value in parentheses.
This instruction takes priority over any built-in formatting or timezone convention, including when they conflict.

When I ran the same test after the change, the summary showed JST first and UTC in parentheses (2026-10-24 07:40:03 JST (2026-10-23 22:40:03 UTC)).

Summary

In this article, I used an ALB HTTPCode_Target_5XX_Count alarm as the subject and tested how far AWS DevOps Agent can take the work of isolating the cause (backend or DB).

Scenario A (a latent application bug): it identified why a product with a NULL price caused an exception, down to the file, the line, and the product ID, and ruled out Aurora as the cause
Scenario B (a full scan by a search query): based on the Performance Insights top SQL, it identified the query that was the root cause, and organized the causal chain down to connection exhaustion

Investigating a failure sometimes requires knowing both the application and the infrastructure. I do not have much knowledge on the application side, and investigating from the application's point of view was hard for me. DevOps Agent investigates both the application and the infrastructure, so I think it can help reduce the dependence of incident response on specific people.

On the other hand, there were mistakes, such as misidentifying the Lambda that starts investigations as the source of the load. A person needs to check the conclusion and the mitigation before running them.

Thank you for reading this far!

Let Anthropic's claude-code-setup Recommend Hooks and Skills for a Repo with Almost No Claude Code Config

Yoshiyuki Watanabe — Sat, 17 Oct 2026 03:52:15 +0000

Introduction

I tried Anthropic's official plugin claude-code-setup on netflix-intro-skipper, a Chrome extension I built myself.

Claude Code Setup | Claude by Anthropic

Analyze codebases and recommend tailored Claude Code automations such as hooks, skills, MCP servers, and subagents.

claude.com

This article walks through installing the plugin and the recommendations it actually produced.

What is Claude Code Setup?

claude-code-setup is a plugin that analyzes your codebase and recommends Claude Code automation settings that fit the project. It is provided by Anthropic and is shown as Anthropic-verified on the marketplace.

The recommendation categories are Hooks, Subagents, Skills, MCP Servers, and Plugins
It is read-only and never creates or modifies files
It usually limits recommendations to 1-2 per category, and increases that to 3-5 when you ask for a specific category
It reads files such as package.json and the directory structure to determine the tech stack

The Target Project

The target is netflix-intro-skipper, introduced above.

yowatanabe / netflix-intro-skipper

NetflixのイントロをスキップするChrome拡張機能

Netflix Intro Skipper

Netflix のイントロを自動的にスキップする Chrome 拡張機能です。

🎯 機能

✅ Netflix の「イントロをスキップ」ボタンを自動検出・クリック
✅ 自動スキップ機能のオン/オフ切り替え
✅ 世界各国の Netflix ドメインに対応
✅ 軽量で非侵入的な設計
✅ 多言語対応（日本語、英語、その他）
✅ セッション管理で複数動画に対応
✅ 堅牢なエラーハンドリング

🚀 インストール方法

注意: このツールは個人利用のために作成されたもので、現時点では Chrome ウェブストアで公開する予定はありません。以下の手順で手動インストールしてください。

このプロジェクトのファイルをダウンロード
Chrome を開き、chrome://extensions/ にアクセス
右上の「デベロッパーモード」を有効にする
「パッケージ化されていない拡張機能を読み込む」をクリック
拡張機能のディレクトリを選択
拡張機能がインストールされ、使用準備完了

📖 使用方法

Netflix にアクセスして動画の視聴を開始
イントロが表示されると、拡張機能が自動的にスキップ
拡張機能のポップアップで自動スキップのオン/オフを切り替え可能
設定はブラウザセッション間で保存されます

🛠️ 開発

開発者向け（コードを修正・テストする場合）

拡張機能のコードを修正したり、テストを実行したい場合のみ以下が必要です：

環境セットアップ

# 依存関係をインストール（開発・テスト用）
npm install

# すべてのテストを実行
npm test

# 特定のテストを実行
npm test -- integration.test.js

# テストをウォッチモードで実行
npm run test:watch

# テストカバレッジを確認
npm run test:coverage

開発ワークフロー

ソースコード: src/ フォルダ内のファイルを編集
テスト: tests/ フォルダ内でテストを作成・実行
アイコン: assets/icons/ でアイコンファイルを管理
拡張機能テスト: Chrome で chrome://extensions/ から再読み込み

リリースバージョン管理

リリースバージョンを更新したい場合は以下のコマンドを実行するとpackage.jsonとmanifest.jsonのversionが更新されます

# パッチバージョンアップ（バグ修正: 1.0.1 → 1.0.2）
npm run version:patch

# マイナーバージョンアップ（新機能: 1.0.1 → 1.1.0）
npm run version:minor

# メジャーバージョンアップ（破壊的変更: 1.0.1 → 2.0.0）
npm run version:major

Dry Run（事前確認）:

# 実行前に何が行われるかを確認
npm run version:dry-run:patch
npm run version:dry-run:minor
npm run version:dry-run:major

実行例:

$ npm run version:patch
> netflix-intro-skipper@1.0.1 version:patch

…

View on GitHub

It supports Manifest V3 and automatically skips Netflix intros
It is plain JavaScript with no build step
Tests use Jest and fast-check, with 13 test files
There is no CLAUDE.md, and .claude/ contains only settings.local.json

Since the project has almost no Claude Code configuration, I thought it was a good fit for seeing what this plugin recommends.

Trying It Out

Step 1: Install the plugin

Launch Claude Code in the target repository and install the plugin from the marketplace.

/plugin install claude-code-setup@claude-plugins-official

After installation, you can confirm that claude-code-setup was added in the Installed tab of /plugins.

Step 2: Ask for recommendations

After installing, I entered the following prompt in English.

Analyze this project and recommend Claude Code automations (hooks, skills, MCP servers, subagents, plugins) that fit it.

Step 3: Review the recommendations

This is the output the plugin produced.

## Claude Code Automation Recommendations

### Codebase Profile
- **Type**: Chrome extension (Manifest V3) that automatically skips Netflix intros
- **Language/tooling**: Plain JavaScript, no build step
- **Testing**: Jest (jsdom) and fast-check (property-based testing), with 13 test files and about 6,000 lines of tests
- **Versioning**: `scripts/release-version.js` keeps the version in `package.json`, `manifest.json`, and `src/version.js` in sync
- **Size**: `src/content.js` is 2,720 lines and by far the largest file
- **Claude config**: No `CLAUDE.md`. `.claude/` contains only `settings.local.json`
- **Other**: Specs live in `.kiro/specs/`. No CI was found

---

### ⚡ Hooks

#### 1. Run related tests automatically after edits (PostToolUse)
**Why**: The project has a large test suite, and small changes to a big file like `content.js` can easily cause regressions. Running `npx jest --findRelatedTests <file>` after each `src/` edit catches problems right away.
**Where**: `.claude/settings.json`
```json
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command",
        "command": "jq -r '.tool_input.file_path' | grep -E '/src/.*\\.js$' | xargs -r npx jest --findRelatedTests --passWithNoTests" }]
    }]
  }
}
```

#### 2. Block direct edits to version-managed files (PreToolUse)
**Why**: Versions are meant to be bumped through `npm run version:*`, which syncs three files. Hand-editing the version in `manifest.json` or `src/version.js` would desynchronize them. You could also block `package-lock.json` and `coverage/` in the same hook.

---

### 🎯 Skills

#### 1. `release` (user-only)
**Why**: A release spans several steps: `version:dry-run`, then `version:*`, then commit, then tag. It has side effects, so it is safer to invoke manually.
**Create**: `.claude/skills/release/SKILL.md`
```yaml
---
name: release
description: Verify with a dry run, then bump the version and prepare the release
disable-model-invocation: true
---
```

#### 2. `netflix-dom-check` (Claude-only background knowledge)
**Why**: Changes to Netflix's DOM selectors are the most common way an extension like this breaks. A skill that collects the selector list, the requirements in `.kiro/specs`, and the tests to check after an update makes `content.js` changes faster and more accurate.
**Create**: `.claude/skills/netflix-dom-check/SKILL.md` (with `user-invocable: false`)

---

### 🤖 Subagents

#### 1. `extension-security-reviewer`
**Why**: This MV3 extension has many `host_permissions`. A periodic review is worthwhile for excessive permissions, XSS risks from DOM manipulation in `content.js`, and missing validation on message passing.
**Where**: `.claude/agents/extension-security-reviewer.md`

#### 2. `service-worker-reviewer`
**Why**: You previously fixed a Service Worker problem after PC sleep (PR #1). A reviewer focused on state persistence, alarms, and restart resilience would help prevent a recurrence when `background.js` changes.
**Where**: `.claude/agents/service-worker-reviewer.md`

---

### 🔌 MCP Servers

#### 1. Playwright MCP
**Why**: Verifying behavior in a real browser matters for an extension. Jest runs on jsdom, so it can't check the real popup UI or content-script behavior.
**Install**: `claude mcp add playwright npx @playwright/mcp@latest`

#### 2. context7
**Why**: It gives you up-to-date docs for the Chrome Extension APIs (`chrome.storage`, `chrome.alarms`, and others) and for Jest and fast-check.
**Install**: `claude mcp add context7 -- npx -y @upstash/context7-mcp`

---

### 📦 Plugins
- **commit-commands**: Streamlines commits and PR creation. It fits well because this repo uses a PR workflow (feature branch, then merge).
- **frontend-design**: Useful when improving `popup.html` and `popup.js`. Lower priority.

---

### Notes
- I'd start by **creating a `CLAUDE.md`**. Just documenting how to run `npm test`, the version-sync rules, and the role of `.kiro/specs` goes a long way. `/init` can generate a draft.
- Check that `coverage/` and `node_modules/` are both listed in `.gitignore`.

If you want more options in a specific category, or help implementing any of these, let me know.

Key Takeaways from the Recommendations

Most of the recommendations were based on the specifics of the repository.

Because src/content.js is large at 2,720 lines, it recommends a hook that runs only the related tests after each edit
Because scripts/release-version.js keeps the version in three files in sync, it recommends a hook that blocks direct edits to version-related files, plus a release skill that bundles the release steps
It even picked up the Service Worker fix from PR #1 and recommends a dedicated reviewer subagent for background.js

All of these are grounded in what is actually in the repository: file size, scripts, and PR history.

The plugin only prints recommendations and does not create any files. To apply them, either place the suggested settings yourself or ask Claude Code separately to create them.

The first recommendation was to create a CLAUDE.md. /init can generate a draft, so that looks like a good place to start.

Summary

For a repository with almost no configuration, claude-code-setup produced recommendations that took into account the version-sync script and past fix history. It is a good starting point for a project where you are not sure what to add first.

Because it is read-only and has no side effects, it is easy to try even on an existing repository. Give it a try on your own project.

Thank you for reading this far!

References

Trying MiniStack and StackPort

Yoshiyuki Watanabe — Tue, 13 Oct 2026 21:52:57 +0000

Introduction

I tried MiniStack, a free local AWS emulator, and StackPort, a browser-based viewer for its resources.

ministackorg / ministack

Ministack: Free, open-source local AWS emulator - 60+ services, Terraform compatible, real databases. Free forever. MIT licensed.

MiniStack

Free, open-source local AWS emulator. Free forever.

60+ AWS services on a single port · Multi-account & multi-region · Terraform compatible · Real databases · MIT licensed

Ministack.org · Docker Hub · LinkedIn

Why MiniStack?

LocalStack recently moved its core services behind a paid plan. If you relied on LocalStack Community for local development and CI/CD pipelines, MiniStack is your free alternative.

60+ AWS services emulated on a single port (4566)
Drop-in compatible — works with boto3, AWS CLI, Terraform, CDK, Pulumi, any SDK
Multi-account & multi-region — a 12-digit access key becomes the account, the SigV4 region scopes the state; isolated tenants and regions on one endpoint, like real AWS
Amazon Bedrock locally — Converse / InvokeModel with AWS-exact wire shapes; point MINISTACK_BEDROCK_PROXY_URL at Ollama, llama.cpp, or vLLM and get real completions through the Bedrock API
Real infrastructure — RDS spins up actual Postgres/MySQL containers, ElastiCache spins…

View on GitHub

DaviReisVieira / stackport

Open-source universal AWS resource browser for MiniStack, Floci, LocalStack, Moto, and real AWS

StackPort

Universal AWS resource browser for local emulators and real AWS accounts.

Browse, inspect, and manage resources across 35 AWS services with dedicated UIs for S3, DynamoDB, Lambda, SQS, IAM, EC2, CloudWatch Logs, and Secrets Manager.

Screenshots

Dashboard — Service overview with resource counts and health status

Lambda Browser — Function list with config, aliases, versions, event sources, and invocation panel

S3 Browser — File browser with upload, download, folder navigation, and tagging

Features

Browse and inspect resources across 35 AWS services
8 dedicated service UIs for S3, DynamoDB, Lambda, SQS, IAM, EC2, CloudWatch Logs, and Secrets Manager
Write operations — upload/delete S3 objects, query DynamoDB, invoke Lambda, send/receive SQS messages
Real AWS support — connect to real AWS accounts with read-only mode by default
Per-endpoint authentication — default credentials, AWS profiles (SSO/AssumeRole), or static keys per endpoint
Guided lessons — hands-on AWS tutorials that run inside the console and…

View on GitHub

This article builds the following pipeline:

EventBridge Scheduler invokes a Lambda function on a schedule
The Lambda function calls an API and publishes the result to SNS
SNS triggers a second Lambda function, which posts to a Slack Incoming Webhook
The API key and the Webhook URL are stored as SecureString parameters in SSM Parameter Store

What Are MiniStack and StackPort?

MiniStack

MiniStack is a local AWS emulator under the MIT license. You can use more than 60 AWS services directly from the AWS CLI, boto3, Terraform, and CDK.

MiniStack — The Best AWS Emulator | Free Open-Source LocalStack Alternative

The best AWS emulator and the best alternative to LocalStack. 60+ AWS services free forever — real Postgres, Redis, Docker containers, full Terraform / CDK / Pulumi support. MIT licensed.

ministack.org

StackPort

StackPort is a tool for browsing the resources of local emulators and real AWS accounts in a browser. It connects to emulators other than MiniStack (such as LocalStack) and to real AWS accounts.

StackPort: open-source web console for AWS emulators

StackPort is a free, open-source web console for MiniStack, Floci, LocalStack, Moto and real AWS. Browse 35 services, use 13 dedicated views, and learn AWS with guided lessons. One Docker image.

stackport.cloud

StackPort lets you browse the resources of 35 services.

Eight of them have dedicated screens: S3, DynamoDB, Lambda, SQS, IAM, EC2, CloudWatch Logs, and Secrets Manager. For example, CloudWatch Logs lets you drill down from log groups to log streams to log events.

The other services (such as SSM in this article) are shown as a searchable resource table with a JSON detail view.

Note that StackPort does not support EventBridge Scheduler. The events service only shows EventBridge rules and event buses, so I check the schedule with the CLI.

Architecture

Locally, I run a mock server (mock-api) in place of the external API. For Slack, I use a real Incoming Webhook, with separate channels for the local and AWS environments.

Two things differ between the local environment and real AWS:

External API: mock-api locally, API Gateway (MOCK integration) on real AWS. Both return GET /v1/status
Slack destination: #notify-demo-local locally, #notify-demo-aws on real AWS

The directory structure is as follows. Terraform is split into a shared module (modules/notify) and one directory per environment (environments/local and environments/aws). Each environment has its own state.

code/
├── lambda/                          # Shared: the same code runs locally and on real AWS
│   ├── fetch_status/
│   │   └── app.py
│   └── notify_slack/
│       └── app.py
├── mock-api/                        # Local only: mock server standing in for the external API
│   ├── Dockerfile
│   └── server.py
├── scripts/
│   ├── put-parameters-aws.sh        # AWS only: registers parameters in the real SSM
│   └── put-parameters.sh            # Local only: registers parameters in MiniStack's SSM
├── terraform/
│   ├── environments/
│   │   ├── aws/                     # For real AWS: points at real AWS
│   │   │   ├── main.tf
│   │   │   ├── outputs.tf
│   │   │   ├── providers.tf
│   │   │   ├── terraform.tfvars
│   │   │   ├── terraform.tfvars.example
│   │   │   └── variables.tf
│   │   └── local/                   # For local: points at MiniStack
│   │       ├── main.tf
│   │       ├── outputs.tf
│   │       ├── providers.tf
│   │       ├── terraform.tfvars
│   │       ├── terraform.tfvars.example
│   │       └── variables.tf
│   └── modules/
│       └── notify/                  # Shared: Lambda, SNS, Scheduler, IAM, and more
│           ├── main.tf
│           ├── outputs.tf
│           ├── variables.tf
│           └── versions.tf
└── docker-compose.yml               # Local only: starts MiniStack, StackPort, and mock-api

Building the Local Environment

You need Docker (Docker Desktop, OrbStack, and so on), Terraform, and the AWS CLI.

Step 1: Start MiniStack, StackPort, and the Mock Server

Start three containers with docker-compose.yml.

services:
  ministack:
    image: ministackorg/ministack:latest
    ports:
      - "4566:4566"
    environment:
      - MINISTACK_REGION=ap-northeast-1
    healthcheck:
      test:
        [
          "CMD",
          "python",
          "-c",
          "import urllib.request; urllib.request.urlopen('http://localhost:4566/_ministack/health')",
        ]
      interval: 5s
      timeout: 3s
      retries: 5

  stackport:
    image: davireis/stackport:latest
    ports:
      - "8080:8080"
    environment:
      - AWS_ENDPOINT_URL=http://ministack:4566
      - AWS_REGION=ap-northeast-1
      - AWS_ACCESS_KEY_ID=test
      - AWS_SECRET_ACCESS_KEY=test
    healthcheck:
      test:
        [
          "CMD",
          "python",
          "-c",
          "import urllib.request; urllib.request.urlopen('http://localhost:8080/api/health')",
        ]
      interval: 10s
      timeout: 3s
      retries: 3
    restart: unless-stopped
    depends_on:
      ministack:
        condition: service_healthy

  # Mock server standing in for the external API
  mock-api:
    build: ./mock-api
    ports:
      - "8000:8000"
    environment:
      - EXPECTED_API_KEY=local-dummy-api-key

The three containers are:

ministack: the local AWS emulator. It accepts AWS API calls on port 4566
stackport: a web UI for browsing MiniStack's resources. It opens on port 8080
mock-api: a mock server standing in for the external API. It runs on port 8000

mock-api is written with only the Python standard library. It has one endpoint that validates the x-api-key header and returns a status.

    def do_GET(self):
        if self.path == "/v1/status":
            if self.headers.get("x-api-key") != EXPECTED_API_KEY:
                return self._send(403, {"message": "Forbidden"})
            return self._send(200, {"status": "ok"})
        return self._send(404, {"message": "not found"})

Start the containers.

cd code
docker compose up -d --build

Open http://localhost:8080 in a browser to see the StackPort dashboard.

Step 2: Register SecureString Parameters in SSM Parameter Store

I register the API key and the Webhook URL outside Terraform.

If you create them as aws_ssm_parameter resources in Terraform, the values remain in the state file in plain text. Write-only arguments (value_wo) in Terraform 1.11 and later keep them out of the state, but I don't use them here.

I prepared a script (scripts/put-parameters.sh) to register them.

#!/usr/bin/env bash
set -euo pipefail

: "${SLACK_WEBHOOK_URL:?Set SLACK_WEBHOOK_URL}"

export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test
export AWS_DEFAULT_REGION=ap-northeast-1
ENDPOINT=http://localhost:4566

aws --endpoint-url="$ENDPOINT" ssm put-parameter \
  --name /notify-demo/api-key \
  --type SecureString \
  --value local-dummy-api-key \
  --overwrite

aws --endpoint-url="$ENDPOINT" ssm put-parameter \
  --name /notify-demo/slack-webhook-url \
  --type SecureString \
  --value "$SLACK_WEBHOOK_URL" \
  --overwrite

For the Webhook URL, I use an Incoming Webhook issued for a Slack channel dedicated to local testing (#notify-demo-local).

SLACK_WEBHOOK_URL=<Webhook URL of the local channel> ./scripts/put-parameters.sh

Running the script adds the parameters.

The displayed value is ENCRYPTED: followed by a base64 string. It is not encrypted with KMS, and anyone can decode it back to the original value, so be careful when sharing screenshots.

Step 3: Write the Lambda Code

This is the Lambda function that calls the API (fetch_status). It gets the API key from SSM and publishes the API response to SNS.

import json
import os
import urllib.request

import boto3

ssm = boto3.client("ssm")
sns = boto3.client("sns")

API_BASE_URL = os.environ["API_BASE_URL"]
API_KEY_PARAM = os.environ["API_KEY_PARAM"]
RESULT_TOPIC_ARN = os.environ["RESULT_TOPIC_ARN"]

_api_key = None


def get_api_key():
    # Fetch from SSM only on a cold start; use the cache afterwards
    global _api_key
    if _api_key is None:
        res = ssm.get_parameter(Name=API_KEY_PARAM, WithDecryption=True)
        _api_key = res["Parameter"]["Value"]
    return _api_key


def handler(event, context):
    req = urllib.request.Request(
        f"{API_BASE_URL}/v1/status",
        headers={"x-api-key": get_api_key()},
    )
    # 4xx/5xx raise HTTPError, which makes the Lambda invocation fail
    with urllib.request.urlopen(req, timeout=10) as res:
        result = json.loads(res.read())
    print(f"API status: {result['status']}")

    sns.publish(
        TopicArn=RESULT_TOPIC_ARN,
        Subject="API status check",
        Message=json.dumps(result, ensure_ascii=False),
    )
    return result

This is the Lambda function for Slack notifications (notify_slack). It extracts the SNS message and posts it to the Webhook.

def handler(event, context):
    for record in event["Records"]:
        result = json.loads(record["Sns"]["Message"])
        now = datetime.now().astimezone().strftime("%Y-%m-%d %H:%M:%S %Z")
        text = f":white_check_mark: API status: {result['status']} ({now})"

        req = urllib.request.Request(
            get_webhook_url(),
            data=json.dumps({"text": text}).encode(),
            headers={"Content-Type": "application/json"},
            method="POST",
        )
        with urllib.request.urlopen(req, timeout=10):
            pass
        print(text)

Neither piece of code contains any MiniStack-specific endpoint configuration. MiniStack injects AWS_ENDPOINT_URL into the Lambda execution environment, so boto3 automatically points at MiniStack. The same code can be deployed to real AWS as is.

Step 4: Create the Resources with Terraform

The resources live in the shared module (terraform/modules/notify/main.tf). I don't show every resource. Instead, I excerpt the points I designed to work on both MiniStack and real AWS.

The external API URL is passed through the module variable api_base_url.

resource "aws_lambda_function" "fetch_status" {
  function_name    = local.fetch_name
  role             = aws_iam_role.fetch_status.arn
  runtime          = "python3.14"
  handler          = "app.handler"
  filename         = data.archive_file.fetch_status.output_path
  source_code_hash = data.archive_file.fetch_status.output_base64sha256
  timeout          = 30

  environment {
    variables = {
      API_BASE_URL     = var.api_base_url
      API_KEY_PARAM    = local.api_key_param
      RESULT_TOPIC_ARN = aws_sns_topic.result.arn
    }
  }

  depends_on = [aws_cloudwatch_log_group.fetch_status]
}

terraform/environments/ contains one directory per environment (local and aws). Each has a main.tf that calls the shared module and its own environment-specific settings.

The only differences are providers.tf, which decides the connection target, and terraform.tfvars, which decides the external API URL.

Because the directories are separate, the state is also separate for each environment.

In terraform/environments/local/providers.tf, the provider points only the services I use at MiniStack.

provider "aws" {
  access_key                  = "test"
  secret_key                  = "test"
  region                      = "ap-northeast-1"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    iam       = "http://localhost:4566"
    lambda    = "http://localhost:4566"
    logs      = "http://localhost:4566"
    scheduler = "http://localhost:4566"
    sns       = "http://localhost:4566"
    ssm       = "http://localhost:4566"
    sts       = "http://localhost:4566"
  }
}

These are the settings that make it work with MiniStack:

access_key, secret_key: dummy values (test)
region: the region to deploy to
skip_credentials_validation: skips validating credentials through the STS API
skip_metadata_api_check: skips the check against the AWS metadata API
skip_requesting_account_id: skips retrieving the account ID
endpoints: points each service at MiniStack. Specify only the services you use

The local directory (terraform/environments/local/main.tf) calls the module. The external API URL is passed through the variable api_base_url.

module "notify" {
  source = "../../modules/notify"

  region       = "ap-northeast-1"
  api_base_url = var.api_base_url
}

The variable's value goes in terraform/environments/local/terraform.tfvars. Because this file is not managed in Git, create it by copying the template (terraform.tfvars.example). The Lambda function runs inside the MiniStack container, so it reaches mock-api by its Compose service name.

api_base_url = "http://mock-api:8000"

Apply it.

cd terraform/environments/local
cp terraform.tfvars.example terraform.tfvars
# Edit terraform.tfvars if needed
terraform init
terraform apply

Here is the result. The resources are created in MiniStack's default account ID (000000000000).

$ terraform apply
module.notify.data.archive_file.notify_slack: Reading...
module.notify.data.archive_file.fetch_status: Reading...
module.notify.data.archive_file.notify_slack: Read complete after 0s [id=68fb7c506afbeeab169fb65494efc63dd8acba90]
module.notify.data.archive_file.fetch_status: Read complete after 0s [id=013b111cb8285884b651e501fd6f84ad373f787a]
module.notify.data.aws_iam_policy_document.lambda_assume: Reading...
module.notify.data.aws_caller_identity.current: Reading...
module.notify.data.aws_iam_policy_document.lambda_assume: Read complete after 0s [id=2690255455]
module.notify.data.aws_caller_identity.current: Read complete after 0s [id=000000000000]
module.notify.data.aws_iam_policy_document.scheduler_assume: Reading...
module.notify.data.aws_iam_policy_document.notify_slack: Reading...
module.notify.data.aws_iam_policy_document.scheduler_assume: Read complete after 0s [id=644537899]
module.notify.data.aws_iam_policy_document.notify_slack: Read complete after 0s [id=2364181876]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # module.notify.data.aws_iam_policy_document.fetch_status will be read during apply
  # (config refers to values not yet known)
 <= data "aws_iam_policy_document" "fetch_status" {
      + id            = (known after apply)
      + json          = (known after apply)
      + minified_json = (known after apply)

      + statement {
          + actions   = [
              + "ssm:GetParameter",
            ]
          + resources = [
              + "arn:aws:ssm:ap-northeast-1:000000000000:parameter/notify-demo/api-key",
            ]
        }
      + statement {
          + actions   = [
              + "sns:Publish",
            ]
          + resources = [
              + (known after apply),
            ]
        }
    }

  # module.notify.data.aws_iam_policy_document.scheduler will be read during apply
  # (config refers to values not yet known)
 <= data "aws_iam_policy_document" "scheduler" {
      + id            = (known after apply)
      + json          = (known after apply)
      + minified_json = (known after apply)

      + statement {
          + actions   = [
              + "lambda:InvokeFunction",
            ]
          + resources = [
              + (known after apply),
            ]
        }
    }

  # module.notify.aws_cloudwatch_log_group.fetch_status will be created
  + resource "aws_cloudwatch_log_group" "fetch_status" {
      + arn                         = (known after apply)
      + deletion_protection_enabled = (known after apply)
      + id                          = (known after apply)
      + log_group_class             = (known after apply)
      + name                        = "/aws/lambda/notify-demo-fetch-status"
      + name_prefix                 = (known after apply)
      + region                      = "ap-northeast-1"
      + retention_in_days           = 7
      + skip_destroy                = false
      + tags_all                    = (known after apply)
    }

  # module.notify.aws_cloudwatch_log_group.notify_slack will be created
  + resource "aws_cloudwatch_log_group" "notify_slack" {
      + arn                         = (known after apply)
      + deletion_protection_enabled = (known after apply)
      + id                          = (known after apply)
      + log_group_class             = (known after apply)
      + name                        = "/aws/lambda/notify-demo-notify-slack"
      + name_prefix                 = (known after apply)
      + region                      = "ap-northeast-1"
      + retention_in_days           = 7
      + skip_destroy                = false
      + tags_all                    = (known after apply)
    }

  # module.notify.aws_iam_role.fetch_status will be created
  + resource "aws_iam_role" "fetch_status" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "lambda.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-fetch-status-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role.notify_slack will be created
  + resource "aws_iam_role" "notify_slack" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "lambda.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-notify-slack-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role.scheduler will be created
  + resource "aws_iam_role" "scheduler" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Condition = {
                          + StringEquals = {
                              + "aws:SourceAccount" = "000000000000"
                            }
                        }
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "scheduler.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-scheduler-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role_policy.fetch_status will be created
  + resource "aws_iam_role_policy" "fetch_status" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = (known after apply)
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy.notify_slack will be created
  + resource "aws_iam_role_policy" "notify_slack" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = jsonencode(
            {
              + Statement = [
                  + {
                      + Action   = "ssm:GetParameter"
                      + Effect   = "Allow"
                      + Resource = "arn:aws:ssm:ap-northeast-1:000000000000:parameter/notify-demo/slack-webhook-url"
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy.scheduler will be created
  + resource "aws_iam_role_policy" "scheduler" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = (known after apply)
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy_attachment.fetch_status_logs will be created
  + resource "aws_iam_role_policy_attachment" "fetch_status_logs" {
      + id         = (known after apply)
      + policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
      + role       = "notify-demo-fetch-status-role"
    }

  # module.notify.aws_iam_role_policy_attachment.notify_slack_logs will be created
  + resource "aws_iam_role_policy_attachment" "notify_slack_logs" {
      + id         = (known after apply)
      + policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
      + role       = "notify-demo-notify-slack-role"
    }

  # module.notify.aws_lambda_function.fetch_status will be created
  + resource "aws_lambda_function" "fetch_status" {
      + architectures                  = (known after apply)
      + arn                            = (known after apply)
      + code_sha256                    = (known after apply)
      + filename                       = "./build/fetch_status.zip"
      + function_name                  = "notify-demo-fetch-status"
      + handler                        = "app.handler"
      + id                             = (known after apply)
      + invoke_arn                     = (known after apply)
      + last_modified                  = (known after apply)
      + memory_size                    = 128
      + package_type                   = "Zip"
      + publish                        = false
      + qualified_arn                  = (known after apply)
      + qualified_invoke_arn           = (known after apply)
      + region                         = "ap-northeast-1"
      + reserved_concurrent_executions = -1
      + response_streaming_invoke_arn  = (known after apply)
      + role                           = (known after apply)
      + runtime                        = "python3.14"
      + signing_job_arn                = (known after apply)
      + signing_profile_version_arn    = (known after apply)
      + skip_destroy                   = false
      + source_code_hash               = "So5oKi3b/bEDekVIzzKxoKwo1aO2n/JdG+Ioj2nhtVw="
      + source_code_size               = (known after apply)
      + tags_all                       = (known after apply)
      + timeout                        = 30
      + version                        = (known after apply)

      + environment {
          + variables = (known after apply)
        }

      + ephemeral_storage (known after apply)

      + logging_config (known after apply)

      + tracing_config (known after apply)
    }

  # module.notify.aws_lambda_function.notify_slack will be created
  + resource "aws_lambda_function" "notify_slack" {
      + architectures                  = (known after apply)
      + arn                            = (known after apply)
      + code_sha256                    = (known after apply)
      + filename                       = "./build/notify_slack.zip"
      + function_name                  = "notify-demo-notify-slack"
      + handler                        = "app.handler"
      + id                             = (known after apply)
      + invoke_arn                     = (known after apply)
      + last_modified                  = (known after apply)
      + memory_size                    = 128
      + package_type                   = "Zip"
      + publish                        = false
      + qualified_arn                  = (known after apply)
      + qualified_invoke_arn           = (known after apply)
      + region                         = "ap-northeast-1"
      + reserved_concurrent_executions = -1
      + response_streaming_invoke_arn  = (known after apply)
      + role                           = (known after apply)
      + runtime                        = "python3.14"
      + signing_job_arn                = (known after apply)
      + signing_profile_version_arn    = (known after apply)
      + skip_destroy                   = false
      + source_code_hash               = "M+ENHhkFRJqThFhPFiREbrEpiqqEf0cJLzdvTNzrMUY="
      + source_code_size               = (known after apply)
      + tags_all                       = (known after apply)
      + timeout                        = 30
      + version                        = (known after apply)

      + environment {
          + variables = {
              + "TZ"                = "Asia/Tokyo"
              + "WEBHOOK_URL_PARAM" = "/notify-demo/slack-webhook-url"
            }
        }

      + ephemeral_storage (known after apply)

      + logging_config (known after apply)

      + tracing_config (known after apply)
    }

  # module.notify.aws_lambda_permission.notify_slack_from_sns will be created
  + resource "aws_lambda_permission" "notify_slack_from_sns" {
      + action              = "lambda:InvokeFunction"
      + function_name       = "notify-demo-notify-slack"
      + id                  = (known after apply)
      + principal           = "sns.amazonaws.com"
      + region              = "ap-northeast-1"
      + source_arn          = (known after apply)
      + statement_id        = "AllowExecutionFromSNS"
      + statement_id_prefix = (known after apply)
    }

  # module.notify.aws_scheduler_schedule.fetch_status will be created
  + resource "aws_scheduler_schedule" "fetch_status" {
      + action_after_completion      = (known after apply)
      + arn                          = (known after apply)
      + group_name                   = (known after apply)
      + id                           = (known after apply)
      + name                         = "notify-demo-fetch-status"
      + name_prefix                  = (known after apply)
      + region                       = "ap-northeast-1"
      + schedule_expression          = "rate(1 minute)"
      + schedule_expression_timezone = "UTC"
      + state                        = "ENABLED"

      + flexible_time_window {
          + mode = "OFF"
        }

      + target {
          + arn      = (known after apply)
          + input    = jsonencode(
                {
                  + source = "scheduler"
                }
            )
          + role_arn = (known after apply)
        }
    }

  # module.notify.aws_sns_topic.result will be created
  + resource "aws_sns_topic" "result" {
      + arn                         = (known after apply)
      + beginning_archive_time      = (known after apply)
      + content_based_deduplication = false
      + fifo_throughput_scope       = (known after apply)
      + fifo_topic                  = false
      + id                          = (known after apply)
      + maximum_message_size        = (known after apply)
      + name                        = "notify-demo-result"
      + name_prefix                 = (known after apply)
      + owner                       = (known after apply)
      + policy                      = (known after apply)
      + region                      = "ap-northeast-1"
      + signature_version           = (known after apply)
      + tags_all                    = (known after apply)
      + tracing_config              = (known after apply)
    }

  # module.notify.aws_sns_topic_subscription.result_to_notify_slack will be created
  + resource "aws_sns_topic_subscription" "result_to_notify_slack" {
      + arn                             = (known after apply)
      + confirmation_timeout_in_minutes = 1
      + confirmation_was_authenticated  = (known after apply)
      + endpoint                        = (known after apply)
      + endpoint_auto_confirms          = false
      + filter_policy_scope             = (known after apply)
      + id                              = (known after apply)
      + owner_id                        = (known after apply)
      + pending_confirmation            = (known after apply)
      + protocol                        = "lambda"
      + raw_message_delivery            = false
      + region                          = "ap-northeast-1"
      + topic_arn                       = (known after apply)
    }

Plan: 16 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + fetch_status_function_name = "notify-demo-fetch-status"

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.notify.aws_cloudwatch_log_group.notify_slack: Creating...
module.notify.aws_cloudwatch_log_group.fetch_status: Creating...
module.notify.aws_iam_role.fetch_status: Creating...
module.notify.aws_iam_role.scheduler: Creating...
module.notify.aws_sns_topic.result: Creating...
module.notify.aws_iam_role.notify_slack: Creating...
module.notify.aws_iam_role.fetch_status: Creation complete after 0s [id=notify-demo-fetch-status-role]
module.notify.aws_iam_role.scheduler: Creation complete after 0s [id=notify-demo-scheduler-role]
module.notify.aws_iam_role.notify_slack: Creation complete after 0s [id=notify-demo-notify-slack-role]
module.notify.aws_cloudwatch_log_group.fetch_status: Creation complete after 0s [id=/aws/lambda/notify-demo-fetch-status]
module.notify.aws_cloudwatch_log_group.notify_slack: Creation complete after 0s [id=/aws/lambda/notify-demo-notify-slack]
module.notify.aws_sns_topic.result: Creation complete after 0s [id=arn:aws:sns:ap-northeast-1:000000000000:notify-demo-result]
module.notify.aws_iam_role_policy_attachment.fetch_status_logs: Creating...
module.notify.data.aws_iam_policy_document.fetch_status: Reading...
module.notify.aws_iam_role_policy_attachment.notify_slack_logs: Creating...
module.notify.aws_iam_role_policy.notify_slack: Creating...
module.notify.data.aws_iam_policy_document.fetch_status: Read complete after 0s [id=193309822]
module.notify.aws_lambda_function.notify_slack: Creating...
module.notify.aws_lambda_function.fetch_status: Creating...
module.notify.aws_iam_role_policy_attachment.fetch_status_logs: Creation complete after 0s [id=notify-demo-fetch-status-role/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole]
module.notify.aws_iam_role_policy.notify_slack: Creation complete after 0s [id=notify-demo-notify-slack-role:terraform-0c334b43e9f77ddf68c66755f5]
module.notify.aws_iam_role_policy_attachment.notify_slack_logs: Creation complete after 0s [id=notify-demo-notify-slack-role/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole]
module.notify.aws_iam_role_policy.fetch_status: Creating...
module.notify.aws_iam_role_policy.fetch_status: Creation complete after 0s [id=notify-demo-fetch-status-role:terraform-5e557969d0acd65274a217f306]
module.notify.aws_lambda_function.notify_slack: Creation complete after 5s [id=notify-demo-notify-slack]
module.notify.aws_lambda_permission.notify_slack_from_sns: Creating...
module.notify.aws_lambda_permission.notify_slack_from_sns: Creation complete after 0s [id=AllowExecutionFromSNS]
module.notify.aws_sns_topic_subscription.result_to_notify_slack: Creating...
module.notify.aws_sns_topic_subscription.result_to_notify_slack: Creation complete after 0s [id=arn:aws:sns:ap-northeast-1:000000000000:notify-demo-result:8876cdbc-24f6-49f7-b09e-14fb507ff76e]
module.notify.aws_lambda_function.fetch_status: Still creating... [00m10s elapsed]
module.notify.aws_lambda_function.fetch_status: Creation complete after 10s [id=notify-demo-fetch-status]
module.notify.data.aws_iam_policy_document.scheduler: Reading...
module.notify.data.aws_iam_policy_document.scheduler: Read complete after 0s [id=1455079044]
module.notify.aws_scheduler_schedule.fetch_status: Creating...
module.notify.aws_iam_role_policy.scheduler: Creating...
module.notify.aws_scheduler_schedule.fetch_status: Creation complete after 0s [id=default/notify-demo-fetch-status]
module.notify.aws_iam_role_policy.scheduler: Creation complete after 0s [id=notify-demo-scheduler-role:terraform-db943e5a1f8c21b3a1a29f7c69]

Apply complete! Resources: 16 added, 0 changed, 0 destroyed.

Outputs:

fetch_status_function_name = "notify-demo-fetch-status"

Two functions appear on the StackPort Lambda screen.

StackPort does not show schedules, so I check them with the CLI.

$ aws --endpoint-url=http://localhost:4566 --region ap-northeast-1 \
>   scheduler list-schedules
{
    "Schedules": [
        {
            "Arn": "arn:aws:scheduler:ap-northeast-1:000000000000:schedule/default/notify-demo-fetch-status",
            "CreationDate": "2026-10-12T09:56:36.343454+09:00",
            "GroupName": "default",
            "LastModificationDate": "2026-10-12T09:56:36.343454+09:00",
            "Name": "notify-demo-fetch-status",
            "State": "ENABLED",
            "Target": {
                "Arn": "arn:aws:lambda:ap-northeast-1:000000000000:function:notify-demo-fetch-status"
            }
        }
    ]
}

Step 5: Verify the Behavior

After a short wait, API status: ok is posted to #notify-demo-local.

You can check the Lambda execution logs on the StackPort CloudWatch Logs screen. First, the log group list shows /aws/lambda/notify-demo-notify-slack and /aws/lambda/notify-demo-fetch-status.

Opening /aws/lambda/notify-demo-notify-slack shows a list of log streams, one per execution.

Opening a log stream shows START, END, and REPORT, plus what the Lambda function printed: the same API status: ok (…) that went to Slack.

Deploying to Real AWS and Verifying the Same Behavior

I deploy the pipeline I verified locally to a real AWS account and check that it behaves the same way.

The Lambda code and the Terraform module are shared with the local environment. Only the environment directory (environments/aws) and the values registered in SSM change.

The thick red borders show what differs from the local environment. An API Gateway created in advance stands in for the external API, and Slack notifications go to the AWS channel (#notify-demo-aws).

Step 1: Register the SSM Parameters

The API key was generated by the API Gateway. I retrieve its value and register it in SSM as a SecureString, together with the Incoming Webhook URL of the AWS channel.

Apart from retrieving the API key, the script is the same as the local one, so I omit its contents.

API_KEY_ID=<API key ID> SLACK_WEBHOOK_URL=<Webhook URL of the AWS channel> ./scripts/put-parameters-aws.sh

This is the Parameter Store in the AWS console after registration.

Opening a parameter shows its SecureString value as ********. Turn on "Show decrypted value" to see the value.

Step 2: Deploy

terraform/environments/aws/providers.tf has no MiniStack-specific settings.

provider "aws" {
  region = "ap-northeast-1"
}

The module call (terraform/environments/aws/main.tf) is the same as the local one.

module "notify" {
  source = "../../modules/notify"

  region       = "ap-northeast-1"
  api_base_url = var.api_base_url
}

Only the external API URL changes, in terraform/environments/aws/terraform.tfvars. This file is not managed in Git either, so create it by copying the template (terraform.tfvars.example) and rewrite it with the URL of the API Gateway you created in advance.

api_base_url = "https://<API ID>.execute-api.ap-northeast-1.amazonaws.com/prod"

Apply it.

cd terraform/environments/aws
cp terraform.tfvars.example terraform.tfvars
# Rewrite <API ID> in terraform.tfvars
terraform init
terraform apply

For comparison with the apply against MiniStack, here is the result. The account ID is masked.

$ terraform apply
module.notify.data.archive_file.fetch_status: Reading...
module.notify.data.archive_file.notify_slack: Reading...
module.notify.data.archive_file.notify_slack: Read complete after 0s [id=68fb7c506afbeeab169fb65494efc63dd8acba90]
module.notify.data.archive_file.fetch_status: Read complete after 0s [id=013b111cb8285884b651e501fd6f84ad373f787a]
module.notify.data.aws_iam_policy_document.lambda_assume: Reading...
module.notify.data.aws_caller_identity.current: Reading...
module.notify.data.aws_iam_policy_document.lambda_assume: Read complete after 0s [id=2690255455]
module.notify.data.aws_caller_identity.current: Read complete after 0s [id=123456789012]
module.notify.data.aws_iam_policy_document.scheduler_assume: Reading...
module.notify.data.aws_iam_policy_document.notify_slack: Reading...
module.notify.data.aws_iam_policy_document.notify_slack: Read complete after 0s [id=3754217979]
module.notify.data.aws_iam_policy_document.scheduler_assume: Read complete after 0s [id=991516426]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # module.notify.data.aws_iam_policy_document.fetch_status will be read during apply
  # (config refers to values not yet known)
 <= data "aws_iam_policy_document" "fetch_status" {
      + id            = (known after apply)
      + json          = (known after apply)
      + minified_json = (known after apply)

      + statement {
          + actions   = [
              + "ssm:GetParameter",
            ]
          + resources = [
              + "arn:aws:ssm:ap-northeast-1:123456789012:parameter/notify-demo/api-key",
            ]
        }
      + statement {
          + actions   = [
              + "sns:Publish",
            ]
          + resources = [
              + (known after apply),
            ]
        }
    }

  # module.notify.data.aws_iam_policy_document.scheduler will be read during apply
  # (config refers to values not yet known)
 <= data "aws_iam_policy_document" "scheduler" {
      + id            = (known after apply)
      + json          = (known after apply)
      + minified_json = (known after apply)

      + statement {
          + actions   = [
              + "lambda:InvokeFunction",
            ]
          + resources = [
              + (known after apply),
            ]
        }
    }

  # module.notify.aws_cloudwatch_log_group.fetch_status will be created
  + resource "aws_cloudwatch_log_group" "fetch_status" {
      + arn                         = (known after apply)
      + deletion_protection_enabled = (known after apply)
      + id                          = (known after apply)
      + log_group_class             = (known after apply)
      + name                        = "/aws/lambda/notify-demo-fetch-status"
      + name_prefix                 = (known after apply)
      + region                      = "ap-northeast-1"
      + retention_in_days           = 7
      + skip_destroy                = false
      + tags_all                    = (known after apply)
    }

  # module.notify.aws_cloudwatch_log_group.notify_slack will be created
  + resource "aws_cloudwatch_log_group" "notify_slack" {
      + arn                         = (known after apply)
      + deletion_protection_enabled = (known after apply)
      + id                          = (known after apply)
      + log_group_class             = (known after apply)
      + name                        = "/aws/lambda/notify-demo-notify-slack"
      + name_prefix                 = (known after apply)
      + region                      = "ap-northeast-1"
      + retention_in_days           = 7
      + skip_destroy                = false
      + tags_all                    = (known after apply)
    }

  # module.notify.aws_iam_role.fetch_status will be created
  + resource "aws_iam_role" "fetch_status" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "lambda.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-fetch-status-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role.notify_slack will be created
  + resource "aws_iam_role" "notify_slack" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "lambda.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-notify-slack-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role.scheduler will be created
  + resource "aws_iam_role" "scheduler" {
      + arn                   = (known after apply)
      + assume_role_policy    = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "sts:AssumeRole"
                      + Condition = {
                          + StringEquals = {
                              + "aws:SourceAccount" = "123456789012"
                            }
                        }
                      + Effect    = "Allow"
                      + Principal = {
                          + Service = "scheduler.amazonaws.com"
                        }
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + create_date           = (known after apply)
      + force_detach_policies = false
      + id                    = (known after apply)
      + managed_policy_arns   = (known after apply)
      + max_session_duration  = 3600
      + name                  = "notify-demo-scheduler-role"
      + name_prefix           = (known after apply)
      + path                  = "/"
      + tags_all              = (known after apply)
      + unique_id             = (known after apply)

      + inline_policy (known after apply)
    }

  # module.notify.aws_iam_role_policy.fetch_status will be created
  + resource "aws_iam_role_policy" "fetch_status" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = (known after apply)
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy.notify_slack will be created
  + resource "aws_iam_role_policy" "notify_slack" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = jsonencode(
            {
              + Statement = [
                  + {
                      + Action   = "ssm:GetParameter"
                      + Effect   = "Allow"
                      + Resource = "arn:aws:ssm:ap-northeast-1:123456789012:parameter/notify-demo/slack-webhook-url"
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy.scheduler will be created
  + resource "aws_iam_role_policy" "scheduler" {
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = (known after apply)
      + policy      = (known after apply)
      + role        = (known after apply)
    }

  # module.notify.aws_iam_role_policy_attachment.fetch_status_logs will be created
  + resource "aws_iam_role_policy_attachment" "fetch_status_logs" {
      + id         = (known after apply)
      + policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
      + role       = "notify-demo-fetch-status-role"
    }

  # module.notify.aws_iam_role_policy_attachment.notify_slack_logs will be created
  + resource "aws_iam_role_policy_attachment" "notify_slack_logs" {
      + id         = (known after apply)
      + policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
      + role       = "notify-demo-notify-slack-role"
    }

  # module.notify.aws_lambda_function.fetch_status will be created
  + resource "aws_lambda_function" "fetch_status" {
      + architectures                  = (known after apply)
      + arn                            = (known after apply)
      + code_sha256                    = (known after apply)
      + filename                       = "./build/fetch_status.zip"
      + function_name                  = "notify-demo-fetch-status"
      + handler                        = "app.handler"
      + id                             = (known after apply)
      + invoke_arn                     = (known after apply)
      + last_modified                  = (known after apply)
      + memory_size                    = 128
      + package_type                   = "Zip"
      + publish                        = false
      + qualified_arn                  = (known after apply)
      + qualified_invoke_arn           = (known after apply)
      + region                         = "ap-northeast-1"
      + reserved_concurrent_executions = -1
      + response_streaming_invoke_arn  = (known after apply)
      + role                           = (known after apply)
      + runtime                        = "python3.14"
      + signing_job_arn                = (known after apply)
      + signing_profile_version_arn    = (known after apply)
      + skip_destroy                   = false
      + source_code_hash               = "So5oKi3b/bEDekVIzzKxoKwo1aO2n/JdG+Ioj2nhtVw="
      + source_code_size               = (known after apply)
      + tags_all                       = (known after apply)
      + timeout                        = 30
      + version                        = (known after apply)

      + environment {
          + variables = (known after apply)
        }

      + ephemeral_storage (known after apply)

      + logging_config (known after apply)

      + tracing_config (known after apply)
    }

  # module.notify.aws_lambda_function.notify_slack will be created
  + resource "aws_lambda_function" "notify_slack" {
      + architectures                  = (known after apply)
      + arn                            = (known after apply)
      + code_sha256                    = (known after apply)
      + filename                       = "./build/notify_slack.zip"
      + function_name                  = "notify-demo-notify-slack"
      + handler                        = "app.handler"
      + id                             = (known after apply)
      + invoke_arn                     = (known after apply)
      + last_modified                  = (known after apply)
      + memory_size                    = 128
      + package_type                   = "Zip"
      + publish                        = false
      + qualified_arn                  = (known after apply)
      + qualified_invoke_arn           = (known after apply)
      + region                         = "ap-northeast-1"
      + reserved_concurrent_executions = -1
      + response_streaming_invoke_arn  = (known after apply)
      + role                           = (known after apply)
      + runtime                        = "python3.14"
      + signing_job_arn                = (known after apply)
      + signing_profile_version_arn    = (known after apply)
      + skip_destroy                   = false
      + source_code_hash               = "M+ENHhkFRJqThFhPFiREbrEpiqqEf0cJLzdvTNzrMUY="
      + source_code_size               = (known after apply)
      + tags_all                       = (known after apply)
      + timeout                        = 30
      + version                        = (known after apply)

      + environment {
          + variables = {
              + "TZ"                = "Asia/Tokyo"
              + "WEBHOOK_URL_PARAM" = "/notify-demo/slack-webhook-url"
            }
        }

      + ephemeral_storage (known after apply)

      + logging_config (known after apply)

      + tracing_config (known after apply)
    }

  # module.notify.aws_lambda_permission.notify_slack_from_sns will be created
  + resource "aws_lambda_permission" "notify_slack_from_sns" {
      + action              = "lambda:InvokeFunction"
      + function_name       = "notify-demo-notify-slack"
      + id                  = (known after apply)
      + principal           = "sns.amazonaws.com"
      + region              = "ap-northeast-1"
      + source_arn          = (known after apply)
      + statement_id        = "AllowExecutionFromSNS"
      + statement_id_prefix = (known after apply)
    }

  # module.notify.aws_scheduler_schedule.fetch_status will be created
  + resource "aws_scheduler_schedule" "fetch_status" {
      + action_after_completion      = (known after apply)
      + arn                          = (known after apply)
      + group_name                   = (known after apply)
      + id                           = (known after apply)
      + name                         = "notify-demo-fetch-status"
      + name_prefix                  = (known after apply)
      + region                       = "ap-northeast-1"
      + schedule_expression          = "rate(1 minute)"
      + schedule_expression_timezone = "UTC"
      + state                        = "ENABLED"

      + flexible_time_window {
          + mode = "OFF"
        }

      + target {
          + arn      = (known after apply)
          + input    = jsonencode(
                {
                  + source = "scheduler"
                }
            )
          + role_arn = (known after apply)
        }
    }

  # module.notify.aws_sns_topic.result will be created
  + resource "aws_sns_topic" "result" {
      + arn                         = (known after apply)
      + beginning_archive_time      = (known after apply)
      + content_based_deduplication = false
      + fifo_throughput_scope       = (known after apply)
      + fifo_topic                  = false
      + id                          = (known after apply)
      + maximum_message_size        = (known after apply)
      + name                        = "notify-demo-result"
      + name_prefix                 = (known after apply)
      + owner                       = (known after apply)
      + policy                      = (known after apply)
      + region                      = "ap-northeast-1"
      + signature_version           = (known after apply)
      + tags_all                    = (known after apply)
      + tracing_config              = (known after apply)
    }

  # module.notify.aws_sns_topic_subscription.result_to_notify_slack will be created
  + resource "aws_sns_topic_subscription" "result_to_notify_slack" {
      + arn                             = (known after apply)
      + confirmation_timeout_in_minutes = 1
      + confirmation_was_authenticated  = (known after apply)
      + endpoint                        = (known after apply)
      + endpoint_auto_confirms          = false
      + filter_policy_scope             = (known after apply)
      + id                              = (known after apply)
      + owner_id                        = (known after apply)
      + pending_confirmation            = (known after apply)
      + protocol                        = "lambda"
      + raw_message_delivery            = false
      + region                          = "ap-northeast-1"
      + topic_arn                       = (known after apply)
    }

Plan: 16 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + fetch_status_function_name = "notify-demo-fetch-status"

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

module.notify.aws_cloudwatch_log_group.fetch_status: Creating...
module.notify.aws_iam_role.fetch_status: Creating...
module.notify.aws_iam_role.notify_slack: Creating...
module.notify.aws_cloudwatch_log_group.notify_slack: Creating...
module.notify.aws_sns_topic.result: Creating...
module.notify.aws_iam_role.scheduler: Creating...
module.notify.aws_cloudwatch_log_group.fetch_status: Creation complete after 0s [id=/aws/lambda/notify-demo-fetch-status]
module.notify.aws_cloudwatch_log_group.notify_slack: Creation complete after 0s [id=/aws/lambda/notify-demo-notify-slack]
module.notify.aws_sns_topic.result: Creation complete after 0s [id=arn:aws:sns:ap-northeast-1:123456789012:notify-demo-result]
module.notify.data.aws_iam_policy_document.fetch_status: Reading...
module.notify.data.aws_iam_policy_document.fetch_status: Read complete after 0s [id=3535791877]
module.notify.aws_iam_role.notify_slack: Creation complete after 1s [id=notify-demo-notify-slack-role]
module.notify.aws_iam_role.scheduler: Creation complete after 1s [id=notify-demo-scheduler-role]
module.notify.aws_iam_role_policy_attachment.notify_slack_logs: Creating...
module.notify.aws_iam_role_policy.notify_slack: Creating...
module.notify.aws_lambda_function.notify_slack: Creating...
module.notify.aws_iam_role.fetch_status: Creation complete after 1s [id=notify-demo-fetch-status-role]
module.notify.aws_iam_role_policy_attachment.fetch_status_logs: Creating...
module.notify.aws_iam_role_policy.fetch_status: Creating...
module.notify.aws_lambda_function.fetch_status: Creating...
module.notify.aws_iam_role_policy_attachment.notify_slack_logs: Creation complete after 1s [id=notify-demo-notify-slack-role/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole]
module.notify.aws_iam_role_policy_attachment.fetch_status_logs: Creation complete after 1s [id=notify-demo-fetch-status-role/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole]
module.notify.aws_iam_role_policy.notify_slack: Creation complete after 1s [id=notify-demo-notify-slack-role:terraform-22dd2cc9194bee349a41b83b49]
module.notify.aws_iam_role_policy.fetch_status: Creation complete after 1s [id=notify-demo-fetch-status-role:terraform-70ee3cf4543eabb9406936afc3]
module.notify.aws_lambda_function.notify_slack: Still creating... [00m10s elapsed]
module.notify.aws_lambda_function.fetch_status: Still creating... [00m10s elapsed]
module.notify.aws_lambda_function.notify_slack: Creation complete after 15s [id=notify-demo-notify-slack]
module.notify.aws_lambda_permission.notify_slack_from_sns: Creating...
module.notify.aws_lambda_permission.notify_slack_from_sns: Creation complete after 0s [id=AllowExecutionFromSNS]
module.notify.aws_sns_topic_subscription.result_to_notify_slack: Creating...
module.notify.aws_sns_topic_subscription.result_to_notify_slack: Creation complete after 0s [id=arn:aws:sns:ap-northeast-1:123456789012:notify-demo-result:c13350e2-427f-446b-b1ff-341576727510]
module.notify.aws_lambda_function.fetch_status: Still creating... [00m20s elapsed]
module.notify.aws_lambda_function.fetch_status: Creation complete after 21s [id=notify-demo-fetch-status]
module.notify.data.aws_iam_policy_document.scheduler: Reading...
module.notify.data.aws_iam_policy_document.scheduler: Read complete after 0s [id=2990400390]
module.notify.aws_scheduler_schedule.fetch_status: Creating...
module.notify.aws_iam_role_policy.scheduler: Creating...
module.notify.aws_scheduler_schedule.fetch_status: Creation complete after 0s [id=default/notify-demo-fetch-status]
module.notify.aws_iam_role_policy.scheduler: Creation complete after 0s [id=notify-demo-scheduler-role:terraform-229c8ea50921716c957135f6a7]

Apply complete! Resources: 16 added, 0 changed, 0 destroyed.

Outputs:

fetch_status_function_name = "notify-demo-fetch-status"

I check the schedule with the CLI, as I did locally. The account ID is masked.

$ aws --region ap-northeast-1 scheduler list-schedules
{
    "Schedules": [
        {
            "Arn": "arn:aws:scheduler:ap-northeast-1:123456789012:schedule/default/notify-demo-fetch-status",
            "CreationDate": "2026-10-12T10:28:05.265000+09:00",
            "GroupName": "default",
            "LastModificationDate": "2026-10-12T10:28:05.265000+09:00",
            "Name": "notify-demo-fetch-status",
            "State": "ENABLED",
            "Target": {
                "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:notify-demo-fetch-status"
            }
        }
    ]
}

Step 3: Verify the Behavior

After waiting about a minute from the first invocation, API status: ok is posted to #notify-demo-aws.

You can check the Lambda logs in CloudWatch Logs. In the console, open the log group, the log stream, and the log events in that order.

Summary

I built the pipeline from Scheduler through Lambda and SNS to Slack notifications locally with MiniStack. The Lambda code is shared with real AWS, and Terraform uses a shared module with one directory per environment, so the pipeline could be deployed to real AWS just by switching directories.
With StackPort, you can follow Lambda logs and SSM parameters on screen, which makes it easier to see what is going on than with the CLI alone.
That said, MiniStack and StackPort do not simulate AWS completely. For example, SecureString values are not encrypted, and StackPort cannot display Scheduler. I recommend understanding what you can test locally, and then verifying on real AWS as well.

Thank you for reading this far!

Why S3 list-buckets Returns a CreationDate That Doesn't Match the Actual Bucket Creation Date

Yoshiyuki Watanabe — Sat, 08 Aug 2026 00:18:03 +0000

Introduction

I manage multiple AWS accounts, and while taking inventory of S3 buckets and their creation dates across accounts with list-buckets, I noticed that the CreationDate returned by aws s3api list-buckets didn't match the actual bucket creation date shown in the S3 console.

I asked about this on AWS re:Post and got solid answers from the community.

Why does ListBuckets return incorrect CreationDate when called from a non-us-east-1 endpoint? | AWS re:Post

When I call `aws s3api list-buckets` from a regional endpoint other than `us-east-1` (e.g., `ap-northeast-1`), the `CreationDate` field returns an incorrect date that does not match the actual buck...

repost.aws

Digging further, I found a GitHub Issue on aws-cli with information about this exact issue.

This article cross-references the re:Post answers with that Issue to lay out the cause and the workaround.

The Symptom: CreationDate Changes When Called from a Non-us-east-1 Region

Calling list-buckets against the same bucket returns a different CreationDate depending on which regional endpoint you use.

# Called via the ap-northeast-1 endpoint
aws s3api list-buckets --region ap-northeast-1 \
  --query 'Buckets[?Name==`my-bucket`].CreationDate' --output text
# 2026-06-04T02:48:47+00:00

# Called via the us-east-1 endpoint
aws s3api list-buckets --region us-east-1 \
  --query 'Buckets[?Name==`my-bucket`].CreationDate' --output text
# 2023-07-05T08:39:18+00:00

This bucket was created in ap-northeast-1, and the S3 console shows its creation date as July 5, 2023, 17:39:18 (UTC+09:00).

In other words, the us-east-1 result matches the console, while only the ap-northeast-1 result is off from the actual creation date.

The Cause: CreationDate Isn't the "Creation Date" — It's the "Last Replication Time in That Region"

The investigation revealed that the meaning of the CreationDate returned by list-buckets depends on which regional endpoint you call it from.

All S3 bucket creation operations appear to be mastered in us-east-1 and then replicated globally.

When you call list-buckets against an endpoint other than us-east-1, the CreationDate you get back isn't the actual creation date — it's the last replication time for that region (i.e., the timestamp of the most recent sync, such as a bucket policy change).

Only when you call the us-east-1 endpoint do you get the original creation date registered at the master. The S3 console also reads from the us-east-1 data, which is why the console date always matches the us-east-1 endpoint's result.

The aws-cli GitHub Issue includes the following explanation:

All bucket creations are mastered in us-east-1, then replicated on a global scale - the resulting difference is that there are no "replication" events to the us-east-1 region.

When using an endpoint other than us-east-1, the CreationDate you receive is actually the last modified time according to the bucket's last replication time in this region. This date can change when making changes to your bucket, such as editing its bucket policy.

Source: aws/aws-cli#3597

The official AWS documentation for the Bucket data type's CreationDate field also includes this line:

Date the bucket was created. This date can change when making changes to your bucket, such as editing its bucket policy.

Source: Amazon S3 API Reference - Bucket

However, this sentence alone doesn't make it clear that the behavior varies by region — it's an easy detail for many users to miss.

I confirmed this myself: after editing a bucket policy, only the CreationDate returned via the ap-northeast-1 endpoint changed. Changing Block public access produced the same result.

It seems any bucket-level configuration change — not just bucket policy edits — can trigger this replication timestamp update.

# After the configuration change
aws s3api list-buckets --region ap-northeast-1 \
  --query 'Buckets[?Name==`my-bucket`].CreationDate' --output text
# 2026-08-06T21:20:49+00:00

aws s3api list-buckets --region us-east-1 \
  --query 'Buckets[?Name==`my-bucket`].CreationDate' --output text
# 2023-07-05T08:39:18+00:00

The Workaround: Explicitly Specify the us-east-1 Endpoint

To get the accurate creation date, explicitly call the API with --region us-east-1.

aws s3api list-buckets --region us-east-1 \
  --query 'Buckets[?Name==`my-bucket`].CreationDate' --output text

This result matches the creation date shown in the S3 console.

Conclusion

The CreationDate returned by list-buckets has a quirk: calling it from any endpoint other than us-east-1 returns the last replication time for that region, not the actual bucket creation date.

If you need the accurate creation date, explicitly specify --region us-east-1.

I lost some time myself before figuring this out. I hope this article saves someone else from the same trap.

Thank you for reading this far!