DEV Community: ほうき星

I Built a CLI Tool to Delete Default VPCs Across All AWS Regions

ほうき星 — Thu, 04 Jun 2026 12:39:47 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

AWS 全リージョンのデフォルト VPC を一括削除する CLI ツールを作った #Python - Qiita

はじめにこんにちは、ほうき星 @H0ukiStar です。 AWS アカウントを作成すると、デフォルト VPC と呼ばれる VPC が各リージョンに 1 つずつ作成されます。このデフォルト VPC はパブリックサブネットのみで構成されており、これらのサブネットでは E...

qiita.com

Introduction

Hello, I’m @H0ukiStar.

When you create an AWS account, a VPC called the default VPC is automatically created in each region.

This default VPC consists only of public subnets, and the default subnets are configured to automatically assign public IP addresses when launching EC2 instances. When launching an EC2 instance from the AWS Management Console, this default VPC is also selected by default, which can lead to resources being created with unintended network configurations depending on your environment.

For this reason, if the default VPC is not needed in your organization’s network design, some teams choose to delete it in advance as part of their operational baseline.

In this article, I’ll introduce a CLI tool I created to delete default VPCs across all available regions in an AWS account.

CLI Tool for Deleting Default VPCs: aws-default-vpc-cleaner

The tool is available in the following repository:

H0ukiStar / aws-default-vpc-cleaner

A tool to delete default VPCs and related resources across all AWS regions.

AWS Default VPC Cleaner

A tool to delete default VPCs and related resources across all AWS regions.

AWSアカウント上のすべてのリージョンに存在するデフォルトVPCと関連リソースを削除するツール。

Features / 機能

Multi-Region Support / 複数リージョン対応: Delete default VPCs across all AWS regions or specific regions / すべてのAWSリージョンまたは特定のリージョンのデフォルトVPCを削除
Dry Run Mode / ドライランモード: List resources without deleting them / 削除せずにリソースをリスト表示
Safe Deletion / 安全な削除: Deletes resources in the correct order to avoid dependency issues / 依存関係の問題を回避するために正しい順序でリソースを削除
Multi-Language / 多言語対応: Supports English and Japanese output / 英語と日本語の出力をサポート
Verbose Mode / 詳細モード: Detailed logging of operations / 操作の詳細なログ出力

Deleted Resources / 削除されるリソース

The tool deletes the following resources in order: ツールは以下のリソースを順番に削除します:

Internet Gateways (detached then deleted) / インターネットゲートウェイ（デタッチ後に削除）
Subnets / サブネット
Route Tables (excluding main route table) / ルートテーブル（メインルートテーブルを除く）
Security Groups (excluding default security group) / セキュリティグループ（デフォルトセキュリティグループを除く）
Network ACLs (excluding default ACL) / ネットワークACL（デフォルトACLを除く）
VPC / VPC

Installation / インストール

Prerequisites / 前提条件

Python 3.10 or higher /…

View on GitHub

Installing the Tool

Build artifacts for both Linux and Windows are available in the Releases section.

Below is an installation example on CloudShell (Amazon Linux 2023).

$ wget https://github.com/H0ukiStar/aws-default-vpc-cleaner/releases/download/v1.0.0/aws-default-vpc-cleaner-v1.0.0-linux-x64
～omitted～
2026-05-21 14:35:22 (29.2 MB/s) - ‘aws-default-vpc-cleaner-v1.0.0-linux-x64’ saved [34495320/34495320]
$ chmod +x aws-default-vpc-cleaner-v1.0.0-linux-x64 
$ 
$ ./aws-default-vpc-cleaner-v1.0.0-linux-x64 --help
usage: aws-default-vpc-cleaner [-h] [--regions REGION [REGION ...]] [--dry-run] [--yes] [--lang {en,ja}] [--verbose] [--version]

Delete default VPCs and related resources across AWS regions

options:
  -h, --help            show this help message and exit
  --regions REGION [REGION ...]
                        Specify target regions (default: all regions)
  --dry-run             List resources without deleting them
  --yes, -y             Skip confirmation prompts
  --lang {en,ja}        Language for output (en/ja)
  --verbose, -v         Enable verbose output
  --version             show program's version number and exit

Examples / 使用例:
  # Delete default VPCs in all regions (with confirmation)
  # 全リージョンのデフォルトVPCを削除 (確認あり)
  aws-default-vpc-cleaner

  # Delete default VPCs in specific regions
  # 特定リージョンのデフォルトVPCを削除
  aws-default-vpc-cleaner --regions us-east-1 us-west-2

  # List default VPCs without deleting (dry-run)
  # 削除せずにデフォルトVPCをリストアップ (ドライラン)
  aws-default-vpc-cleaner --dry-run

  # Delete without confirmation
  # 確認なしで削除
  aws-default-vpc-cleaner --yes

  # Use Japanese language output
  # 日本語出力を使用
  aws-default-vpc-cleaner --lang ja

  # Verbose output
  # 詳細出力
  aws-default-vpc-cleaner --verbose

Deleting Default VPCs with the Tool

Before deleting default VPCs, it’s a good idea to first use the --dry-run option to check what resources will be affected.

As shown below, the tool lists default VPCs in all available regions, along with related resources such as internet gateways and subnets.

$ ./aws-default-vpc-cleaner-v1.0.0-linux-x64 --dry-run
Starting AWS Default VPC Cleaner...
DRY RUN MODE - No resources will be deleted
Fetching available regions...
Found 17 regions
Default VPC found: vpc-0dfe2040fc98de87c
Default VPC found: vpc-0088a011ef4fd1a43
～omitted～
Processing region: ap-south-1
Would delete InternetGateway: igw-0d46d61ebaff6cb2d
Would delete Subnet: subnet-0c5d458b14c891426
Would delete Subnet: subnet-0f875743062c40fd8
Would delete Subnet: subnet-07a484491ecaaf387
Would delete VPC: vpc-0dfe2040fc98de87c
Region ap-south-1 completed
～omitted～

=== Summary ===
Regions processed: 17
VPCs deleted: 0
Resources deleted: 0
Errors: 0

Operation completed successfully

If the resources look correct, you can run the tool without --dry-run to actually delete them.

$ ./aws-default-vpc-cleaner-v1.0.0-linux-x64 --yes
Starting AWS Default VPC Cleaner...
Fetching available regions...
Found 17 regions
Default VPC found: vpc-0dfe2040fc98de87c
Default VPC found: vpc-0088a011ef4fd1a43
～omitted～
Processing region: ap-south-1
Deleted InternetGateway: igw-0d46d61ebaff6cb2d
Deleted Subnet: subnet-0c5d458b14c891426
Deleted Subnet: subnet-0f875743062c40fd8
Deleted Subnet: subnet-07a484491ecaaf387
Deleting VPC: vpc-0dfe2040fc98de87c
VPC deleted successfully: vpc-0dfe2040fc98de87c
Region ap-south-1 completed
～omitted～

=== Summary ===
Regions processed: 17
VPCs deleted: 17
Resources deleted: 89
Errors: 0

Operation completed successfully

Available Options

`--dry-run`

As shown in the example above, this option lists the default VPCs and related resources that would be deleted, but does not actually delete anything.

Instead of deleting resources immediately, it is recommended to review the list first and confirm that the targets are correct.

`--yes`

If --yes is not specified, the tool prompts for confirmation before deleting resources.

If --yes is specified, deletion proceeds without confirmation.

`--regions REGION [REGION ...]`

Specifies which regions to target for deleting default VPCs.

If not specified, the tool runs against all available regions.

`--lang {en,ja}`

Specifies the language used for the tool’s output.

`--verbose`

Enables verbose output during execution.

Conclusion

Default VPCs are a convenient feature automatically created when an AWS account is provisioned, but depending on your environment, they may not always be necessary. When multiple regions are involved, deleting them manually can also become tedious.

I created aws-default-vpc-cleaner as a CLI tool to make it easier to review and remove default VPCs across all available regions in one go.

I hope this tool and article are helpful for anyone facing the same challenge.

Trying AWS IoT Core's New GetConnection and ListSubscriptions APIs

ほうき星 — Fri, 29 May 2026 14:10:41 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

AWS IoT Core 単体で MQTT クライアントの接続状態を取得できるようになったので試す #awsIoT - Qiita

はじめにこんにちは、ほうき星 @H0ukiStar です。本日 AWS IoT Core に以下のようなアップデートがありました。 Posted on: May 28, 2026 Today, AWS IoT Core launches two new MQTT c...

qiita.com

Introduction

Hello, I'm @H0ukiStar.

Today, AWS IoT Core announced the following update.

Posted on: May 28, 2026
Today, AWS IoT Core launches two new MQTT connection management APIs, GetConnection and ListSubscriptions, enabling you to easily access MQTT client connection and subscription information for your Internet of Things (IoT) devices. These APIs help you troubleshoot connectivity issues, monitor client behavior, and audit connection patterns across your device fleet.

https://aws.amazon.com/about-aws/whats-new/2026/05/aws-iot-core-apis-mqtt/

Previously, checking device connection status required using Fleet Indexing or implementing your own state management with features such as Device Shadow. With this update, it is now possible to check device connection status directly using AWS IoT Core alone.

I previously introduced methods for checking connection status using Fleet Indexing and Device Shadow in the following article, so feel free to check it out as well.

AWS IoT Core でモノの接続状態をオンデマンドで取得する2つの方法 #lambda - Qiita

はじめにこんにちは、ほうき星です。皆さんは、AWS IoT Core に接続した自作 IoT デバイス（Raspberry Pi / ESP32 など）が「今オンラインなのか、それともオフラインなのか」を確認したいと思ったことはありませんか？私は自作した IoT ...

qiita.com

Trying It Out

Let's try the new APIs.

At the time of writing, these APIs do not appear to be available in the AWS SDK yet, so the API requests must be signed manually using SigV4.

This time, I used awscurl for signing. You can install it with the following command:

pip install awscurl

You can also retrieve the API endpoint using the AWS CLI as shown below.

aws iot describe-endpoint --endpoint-type iot:Data-ATS

{
    "endpointAddress": "abcd1234567890-ats.iot.ap-northeast-1.amazonaws.com"
}

GetConnection

This API allows you to retrieve information such as the connection status and Keep Alive configuration of a specified MQTT client.

docs.aws.amazon.com

Send the following request using awscurl.

awscurl \
  --service iotdevicegateway \
  --region ap-northeast-1 \
  "https://abcd1234567890-ats.iot.ap-northeast-1.amazonaws.com/connections/<clientId>"

[!WARNING]
For SigV4 signing, you must specify iotdevicegateway as the service name instead of iot.

You can retrieve information such as whether the client is currently connected and when the connection was established.

{
    "connected": true,
    "cleanSession": true,
    "clientId": "clientId",
    "thingName": "thingName",
    "keepAliveDuration": 15,
    "connectedSince": 1780061470032
}

You can also retrieve socket information by adding includeSocketInformation=true.

awscurl \
  --service iotdevicegateway \
  --region ap-northeast-1 \
  "https://abcd1234567890-ats.iot.ap-northeast-1.amazonaws.com/connections/<clientId>?includeSocketInformation=true"

{
    "connected": true,
    "cleanSession": true,
    "clientId": "clientId",
    "thingName": "thingName",
    "sourceIp": "sourceIp",
    "sourcePort": sourcePort,
    "targetIp": "targetIp",
    "targetPort": 8883,
    "keepAliveDuration": 15,
    "connectedSince": 1780061470032
}

ListSubscriptions

This API allows you to retrieve the topics subscribed to by a specified client.

docs.aws.amazon.com

Send the following request using awscurl.

awscurl \
  --service iotdevicegateway \
  --region ap-northeast-1 \
  "https://abcd1234567890-ats.iot.ap-northeast-1.amazonaws.com/connections/<clientId>/subscriptions"

[!WARNING]
For SigV4 signing, you must specify iotdevicegateway as the service name instead of iot.

You can retrieve the topics currently subscribed to by the specified client as shown below.

{
    "nextToken": "",
    "subscriptions": [
        {
            "topicFilter": "$aws/things/<thingName>/shadow/update/delta",
            "qos": 0
        }
    ]
}

Conclusion

With the newly introduced GetConnection and ListSubscriptions APIs, it is now possible to retrieve MQTT client connection status and subscription information directly from AWS IoT Core.

Previously, checking connection status often required custom implementations using Fleet Indexing, Device Shadow, or Lifecycle Events. With these new APIs, monitoring client state should become much simpler.

Although the APIs do not yet appear to be available in the AWS SDK, they can already be used today by manually signing requests with SigV4.

If you're interested, give them a try.

Automatically Healing CloudFormation Drift with Durable Functions

ほうき星 — Sun, 17 May 2026 02:34:59 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

Durable Functions を用いて CloudFormation のドリフトを自動修復する #AWS - Qiita

はじめにこんにちは、ほうき星 @H0ukiStar です。皆さんは昨年(2025年)の11月に CloudFormation がアップデートされ、ドリフト状態の修正に利用可能なドリフト認識変更セットが追加されたことをご存じでしょうか？本機能の登場以前は、ドリフ...

qiita.com

Introduction

Hello, I’m @H0ukiStar.

Did you know that in November 2025, AWS introduced a new CloudFormation feature called drift-aware change sets?

https://aws.amazon.com/about-aws/whats-new/2025/11/configuration-drift-enhanced-cloudformation-sets/

Before this feature was introduced, repairing drift typically required making a temporary dummy change to the stack, updating the stack, and then reverting the change afterward.

Now, by specifying --deployment-mode REVERT_DRIFT when creating a change set, CloudFormation can recognize differences between the IaC definition and the actual infrastructure, and automatically generate a change set specifically for drift remediation.

In this article, I’ll show how I implemented a Configuration Healing mechanism using Durable Functions that:

Detects CloudFormation stack drift
Automatically creates a drift-aware change set
Repairs the drift automatically

Trying Drift-Aware Change Sets

Deploying a Sample Stack

First, let’s see how drift-aware change sets work.

I deployed the following CloudFormation template with the stack name test.

AWSTemplateFormatVersion: 2010-09-09
Description: Stack for testing drift-aware change sets

Resources:
  TestParameter:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /drift-test/sample
      Type: String
      Value: initial-value
      Description: Parameter for drift testing

Immediately after deployment, the stack is not drifted.

[!WARNING]
The stack was deployed using a dedicated CloudFormation execution role.

The IAM role template is omitted here for brevity.
Please refer to the following GitHub repository for the complete template definition.

sample-aws-cfn-configuration-healing

Introducing Drift

Next, I intentionally introduced drift by modifying the SSM parameter value with the following command.

aws ssm put-parameter \
  --name /drift-test/sample \
  --value updated-value \
  --overwrite

You can confirm from the CloudFormation drift detection screen that the stack is now drifted.

Repairing Drift with a Drift-Aware Change Set

On the CloudFormation drift screen, CloudFormation displays guidance indicating that the drift can be repaired using a drift-aware change set.

Select Create change set.

Make sure the change set type is set to Drift-aware change set, then follow the instructions to create it.

If you review the generated change set, you can see that CloudFormation correctly detects the drifted resource and prepares the remediation changes automatically.

After executing the change set, the drift is resolved.

Configuration Healing with Durable Functions

CloudFormation drift detection and change set creation are asynchronous operations, which means polling is required until completion.

Implementing this behavior using only standard Lambda functions can quickly become complicated due to retry handling, wait control, and state management.

This time, I used Durable Functions to simplify these wait operations and state transitions.

Durable Functions are designed for long-running workflows, making them a great fit for asynchronous APIs like CloudFormation.

Especially for workflows like:

Start operation
Wait for completion
Check status
Proceed to the next step

Durable Functions make the orchestration logic much easier to implement and maintain.

Workflow

The implementation follows the workflow below to detect and repair CloudFormation stack drift.

Durable Functions make it straightforward to implement waiting logic for both drift detection and change set creation.

In addition, by passing CreateChangeSetOnly: true in the Lambda event payload, the workflow can stop after creating the change set without executing it automatically.

Durable Functions Implementation Example

The Durable Functions implementation follows the workflow shown above.

The full source code, including the SAM template, is available in the following repository.

H0ukiStar / sample-aws-cfn-configuration-healing

Sample implementation of an AWS Lambda function to detect and automatically heal CloudFormation stack configuration drift.

CloudFormation Configuration Healing with Durable Functions

Automatic detection and healing of CloudFormation stack drift using AWS Lambda with Durable Functions.

This sample demonstrates how to automatically detect configuration drift in CloudFormation stacks and heal them by creating and executing change sets using the AWS Durable Execution SDK for Python.

Features

Automatic Drift Detection: Detects configuration drift in CloudFormation stacks
Automatic Healing: Creates and executes change sets to restore the stack to its desired state
Durable Functions: Uses AWS Lambda Durable Execution SDK to handle long-running operations reliably
SNS Notifications: Sends notifications about drift detection and healing operations
Error Handling: Comprehensive error handling for drift detection and change set operations

Installation

Deploy using the AWS SAM CLI with the following commands:

cd configuration-healing
sam build
sam deploy --guided

During the guided deployment, you will be prompted to provide:

SNS Topic ARN: The ARN of an…

View on GitHub

# The complete implementation is available in the GitHub repository above.
# The code is omitted here for brevity.

Verification

Next, I intentionally modified the value of the SSM Parameter created in the test stack to introduce drift, then executed the deployed Lambda function.

aws lambda invoke \
  --function-name arn:aws:lambda:<region>:<account-id>:function:cfn-drift-healing:Alias \
  --invocation-type Event \
  --cli-binary-format raw-in-base64-out \
  --payload '{"StackName": "test"}' \
  response.json

From the logs, you can confirm that the automatic remediation proceeds as follows:

Start drift detection
Detect stack drift
Create a drift-aware change set
Execute the change set
Resolve the drift

You can also confirm the remediation completion through SNS notifications.

You can also stop the workflow after creating the change set by passing CreateChangeSetOnly: true in the event payload.

This allows a human operator to review and execute the change set manually.

aws lambda invoke \
  --function-name arn:aws:lambda:<region>:<account-id>:function:cfn-drift-healing:Alias \
  --invocation-type Event \
  --cli-binary-format raw-in-base64-out \
  --payload '{"StackName": "test", "CreateChangeSetOnly": true}' \
  response.json

Conclusion

CloudFormation drift-aware change sets make it much safer and easier to repair configuration drift than before.

In this article, I implemented a Configuration Healing mechanism using Durable Functions that automatically detects and repairs CloudFormation drift.

Even when using IaC, long-running environments inevitably experience unintended configuration changes over time.

By combining this workflow with services like EventBridge Scheduler for periodic execution, you can continuously and automatically remediate drift caused by:

Unintended manual changes
Temporary fixes that were never reverted
Configuration updates forgotten over time

This helps maintain infrastructure consistency and improve long-term IaC governance.

If fully automated remediation feels too risky for production environments, you can instead stop after creating the change set and require human review before execution, as demonstrated earlier in this article.

I hope this article serves as a useful example of implementing Configuration Healing with CloudFormation.

How to Create an EventBridge Scheduler with ActionAfterCompletion in CloudFormation

ほうき星 — Sun, 26 Apr 2026 09:09:56 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

CloudFormation で未対応の ActionAfterCompletion を指定した EventBridge Scheduler を作成する #AWS - Qiita

はじめにこんにちは、ほうき星 @H0ukiStar です。皆さんは CloudFormation で ActionAfterCompletion を指定した EventBridge Schedulder を作成したいと思ったことはありませんか？私はあります。 Eve...

qiita.com

Introduction

Hi, I'm @H0ukiStar.

Have you ever wanted to create an EventBridge Scheduler with ActionAfterCompletion specified in CloudFormation?

I have.

The CloudFormation resource for creating EventBridge Scheduler schedules, AWS::Scheduler::Schedule, does not currently support the ActionAfterCompletion property, as shown in the official documentation below:

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-scheduler-schedule.html

My assumption is that this limitation exists because when ActionAfterCompletion is set to DELETE, the schedule resource is automatically deleted after execution completes. If CloudFormation allowed this property, the resource would disappear outside of CloudFormation’s control, potentially causing drift.

However, there are cases where it is useful to create a schedule with ActionAfterCompletion from CloudFormation. For example, if you repeatedly deploy one-time schedules through CloudFormation, being able to specify ActionAfterCompletion: DELETE allows the schedule to clean itself up automatically after execution.

In this article, I will show how to achieve this by using a CloudFormation custom resource.

What is a CloudFormation Custom Resource (`AWS::CloudFormation::CustomResource`)?

A CloudFormation custom resource allows you to create resources or execute APIs that are not natively supported by CloudFormation.

It can invoke an SNS topic or a Lambda function, and the invoked function can perform tasks such as:

Creating AWS resources not supported by native CloudFormation resources
Integrating with external services through APIs
Automating initialization or registration processes

https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-cloudformation-customresource.html

In this article, we will use a custom resource backed by AWS Lambda to create an EventBridge Scheduler schedule with ActionAfterCompletion.

Sample Lambda Function for Creating a Schedule Resource with `ActionAfterCompletion`

A CloudFormation custom resource has a ServiceToken property, which is used to specify the ARN of the Lambda function that handles the resource lifecycle.

The Lambda function referenced by ServiceToken can either be defined inline in the CloudFormation template or deployed in advance and referenced externally.

In this example, I prepared the Lambda function beforehand and deployed it using AWS SAM.

The complete source code, including the SAM template, is available in the following repository:

https://github.com/H0ukiStar/sample-aws-cfn-schedule-with-action-after-completion

# lambda_function.py
from __future__ import print_function
import re
import json
from typing import Optional
from datetime import datetime

import boto3
import urllib3
from pydantic import BaseModel, ValidationError


class FlexibleTimeWindowProperty(BaseModel):
    """
    Flexible time window configuration for EventBridge Scheduler.
    """
    MaximumWindowInMinutes: Optional[int] = None
    Mode: Optional[str] = None


class TargetProperty(BaseModel):
    """
    Target configuration for EventBridge Scheduler.
    """
    class DeadLetterConfigProperty(BaseModel):
        """
        Dead letter queue configuration.
        """
        Arn: Optional[str] = None

    class EventBridgeParametersProperty(BaseModel):
        """
        EventBridge event parameters.
        """
        DetailType: Optional[str] = None
        Source: Optional[str] = None

    class KinesisParametersProperty(BaseModel):
        """
        Kinesis stream parameters.
        """
        PartitionKey: Optional[str] = None

    class RetryPolicyProperty(BaseModel):
        """
        Retry policy configuration.
        """
        MaximumEventAgeInSeconds: Optional[int] = None
        MaximumRetryAttempts: Optional[int] = None

    class SageMakerPipelineParametersProperty(BaseModel):
        """
        SageMaker Pipeline parameters.
        """
        class PipelineParameterListItemProperty(BaseModel):
            """
            Individual pipeline parameter.
            """
            Name: Optional[str] = None
            Value: Optional[str] = None

        PipelineParameterList: Optional[list[PipelineParameterListItemProperty]] = None

    class SqsParametersProperty(BaseModel):
        """
        SQS queue parameters.
        """
        MessageGroupId: Optional[str] = None

    Arn: Optional[str] = None
    DeadLetterConfig: Optional[DeadLetterConfigProperty] = None
    # EcsParameters: Optional[dict] = None
    EventBridgeParameters: Optional[EventBridgeParametersProperty] = None
    Input: Optional[str] = None
    KinesisParameters: Optional[KinesisParametersProperty] = None
    RetryPolicy: Optional[RetryPolicyProperty] = None
    RoleArn: Optional[str] = None
    SageMakerPipelineParameters: Optional[SageMakerPipelineParametersProperty] = None
    SqsParameters: Optional[SqsParametersProperty] = None


class ScheduleProperty(BaseModel):
    """
    EventBridge Scheduler schedule configuration.
    """
    ActionAfterCompletion: Optional[str] = None
    Description: Optional[str] = None
    EndDate: Optional[datetime] = None
    FlexibleTimeWindow: Optional[FlexibleTimeWindowProperty] = None
    GroupName: Optional[str] = None
    KmsKeyArn: Optional[str] = None
    Name: str
    ScheduleExpression: Optional[str] = None
    ScheduleExpressionTimezone: Optional[str] = None
    StartDate: Optional[datetime] = None
    State: Optional[str] = None
    Target: Optional[TargetProperty] = None


def lambda_handler(event: dict, context: object) -> None:
    """
    AWS Lambda handler for CloudFormation custom resource managing EventBridge Scheduler schedules.

    Handles Create, Update, and Delete operations for EventBridge Scheduler schedules
    as a CloudFormation custom resource. Supports ActionAfterCompletion property to enable
    automatic schedule actions (e.g., deletion) after completion.

    Parameters
    ----------
    event : dict
        Lambda event object containing CloudFormation request details.
    context : object
        Lambda context object containing runtime information.

    Returns
    -------
    None
        Sends response to CloudFormation via HTTP callback.

    Notes
    -----
    - For Create: Creates a new schedule and returns its ARN
    - For Update: Updates existing schedule or creates new one if Name changed
    - For Delete: Deletes the schedule unless it failed during creation/update
    """
    print(f"{event['ResourceProperties']=}")

    try:
        schedule_property: ScheduleProperty = ScheduleProperty(
            **event["ResourceProperties"]
        )
    except ValidationError as e:
        send(event, context, "FAILED", {}, reason=f"Resource properties pre validation failed: {e.errors()}")
        return

    scheduler_client = boto3.client("scheduler")
    request_type: str = event["RequestType"]
    print(f"{request_type=}")

    if request_type == "Create":
        try:
            response: dict = scheduler_client.create_schedule(
                **schedule_property.model_dump(exclude_none=True)
            )
            send(event, context, "SUCCESS", {"Arn": response["ScheduleArn"]}, physicalResourceId=schedule_property.Name)
        except Exception as e:
            send(event, context, "FAILED", {}, reason=f"{e}", physicalResourceId="CREATE_FAILED")
        return
    elif request_type == "Update":
        try:
            old_schedule_property: ScheduleProperty = ScheduleProperty(
                **event["OldResourceProperties"]
            )
        except ValidationError as e:
            send(event, context, "FAILED", {}, reason=f"Old resource properties pre validation failed: {e.errors()}")
            return

        physical_resource_id: str = event["PhysicalResourceId"]

        # Create a new schedule if Name has changed
        if old_schedule_property.Name != schedule_property.Name:
            try:
                # CloudFormation will automatically delete the old schedule when the physical ID changes, so no explicit deletion is needed in Update.
                response: dict = scheduler_client.create_schedule(
                    **schedule_property.model_dump(exclude_none=True)
                )
                send(event, context, "SUCCESS", {"Arn": response["ScheduleArn"]}, physicalResourceId=schedule_property.Name)
            except Exception as e:
                send(event, context, "FAILED", {}, reason=f"{e}", physicalResourceId="UPDATE_FAILED")
            return

        # Update the schedule if Name is the same
        try:
            existing_schedule: dict = scheduler_client.get_schedule(Name=physical_resource_id)
            existing_schedule_property: ScheduleProperty = ScheduleProperty(**existing_schedule)

            update_params: dict = existing_schedule_property.model_dump(exclude_none=True)
            new_params: dict = schedule_property.model_dump(exclude_none=True)
            update_params.update(new_params)

            response: dict = scheduler_client.update_schedule(**update_params)
            send(event, context, "SUCCESS", {"Arn": response["ScheduleArn"]}, physicalResourceId=schedule_property.Name)
        except Exception as e:
            send(event, context, "FAILED", {}, reason=f"{e}", physicalResourceId=physical_resource_id)
        return
    elif request_type == "Delete":
        physical_resource_id: str = event["PhysicalResourceId"]

        # Skip deletion and return success if CREATE_FAILED (schedule does not exist) or UPDATE_FAILED (should not delete)
        if physical_resource_id == "CREATE_FAILED" or physical_resource_id == "UPDATE_FAILED":
            send(event, context, "SUCCESS", {})
            return

        try:
            scheduler_client.delete_schedule(Name=physical_resource_id)
            send(event, context, "SUCCESS", {})
        except scheduler_client.exceptions.ResourceNotFoundException:
            # If the schedule is already deleted, consider it a success
            send(event, context, "SUCCESS", {})
        except Exception as e:
            send(event, context, "FAILED", {}, reason=f"{e}")
        return
    send(event, context, "FAILED", {}, reason=f"Unsupported request type: {request_type}")
    return


# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
http = urllib3.PoolManager()


def send(event, context, responseStatus, responseData, physicalResourceId=None, noEcho=False, reason=None):
    responseUrl = event['ResponseURL']

    responseBody = {
        'Status': responseStatus,
        'Reason': reason or "See the details in CloudWatch Log Stream: {}".format(context.log_stream_name),
        'PhysicalResourceId': physicalResourceId or context.log_stream_name,
        'StackId': event['StackId'],
        'RequestId': event['RequestId'],
        'LogicalResourceId': event['LogicalResourceId'],
        'NoEcho': noEcho,
        'Data': responseData
    }

    json_responseBody = json.dumps(responseBody)

    print("Response body:")
    print(json_responseBody)

    headers = {
        'content-type': '',
        'content-length': str(len(json_responseBody))
    }

    try:
        response = http.request('PUT', responseUrl, headers=headers, body=json_responseBody)
        print("Status code:", response.status)

    except Exception as e:
        print("send(..) failed executing http.request(..):", mask_credentials_and_signature(e))


def mask_credentials_and_signature(message):
    """
    Mask AWS credentials and signatures in error messages.

    Redacts sensitive AWS credential and signature information from messages
    before logging to prevent credential exposure.

    Parameters
    ----------
    message : str
        Error message or string that may contain AWS credentials.

    Returns
    -------
    str
        Message with credentials and signatures masked.

    Notes
    -----
    Masks the following AWS authentication parameters:
    - X-Amz-Credential
    - X-Amz-Signature
    """
    message = re.sub(r'X-Amz-Credential=[^&\s]+', 'X-Amz-Credential=*****', message, flags=re.IGNORECASE)
    return re.sub(r'X-Amz-Signature=[^&\s]+', 'X-Amz-Signature=*****', message, flags=re.IGNORECASE)

Note

Pydantic validation in this sample is mainly used to convert values such as datetime and int. Validation for allowed strings or numeric ranges is left to the EventBridge Scheduler API through boto3.

Warning

EcsParameters is not implemented in this sample.

Verification

The following sample CloudFormation template creates an EventBridge Scheduler schedule with ActionAfterCompletion enabled:

AWSTemplateFormatVersion: 2010-09-09
Description: Sample template for managing EventBridge Scheduler with ActionAfterCompletion using a CloudFormation custom resource

Resources:
  CustomScheduleWithActionAfterCompletion:
    Type: Custom::ScheduleWithActionAfterCompletion
    Properties:
      ServiceTimeout: 30
      # Replace with the ARN of the deployed custom resource Lambda function
      ServiceToken: arn:aws:lambda:ap-northeast-1:123456789012:function:cfn-custom-resource-schedule-with-aac

      Name: schedule-with-aac
      ActionAfterCompletion: DELETE

      FlexibleTimeWindow:
        Mode: OFF

      # Replace with the desired schedule expression
      ScheduleExpression: at(2026-04-30T00:00:00)

      ScheduleExpressionTimezone: Asia/Tokyo

      Target:
        # Replace with the ARN of the target resource to invoke
        Arn: arn:aws:lambda:ap-northeast-1:123456789012:function:example-function

        # Replace with the ARN of the IAM role that EventBridge Scheduler assumes
        RoleArn: arn:aws:iam::123456789012:role/example-scheduler-role

Warning

Replace ServiceToken with the ARN of the deployed Lambda function

Replace Target with the desired schedule target configuration

Deploy the above template with CloudFormation. If the schedule is created successfully with ActionAfterCompletion set, the custom resource is working as expected.

Notes

As mentioned earlier, when ActionAfterCompletion is set to DELETE, the schedule resource is automatically removed after execution.

CloudFormation custom resources do not support drift detection, so even if the schedule is deleted by EventBridge Scheduler, the CloudFormation stack will not be marked as drifted.

However, when deleting the CloudFormation stack, the custom resource Lambda function receives a Delete event. Therefore, it is a good idea to handle ResourceNotFoundException as SUCCESS:

try:
    scheduler_client.delete_schedule(Name=physical_resource_id)
    send(event, context, "SUCCESS", {})
except scheduler_client.exceptions.ResourceNotFoundException:
    send(event, context, "SUCCESS", {})
except Exception as e:
    send(event, context, "FAILED", {}, reason=f"{e}")

Conclusion

In this article, I showed how to create an EventBridge Scheduler schedule with ActionAfterCompletion using a CloudFormation custom resource.

There are many cases where AWS SDK APIs support features that CloudFormation does not yet expose as native resources or properties. The same custom resource pattern introduced here can be applied to those situations as well.

I hope this article helps someone facing the same challenge.

Why You Should Use context.logger in Lambda Durable Functions

ほうき星 — Thu, 19 Mar 2026 13:25:20 +0000

This article is a machine translation of the contents of the following URL, which I wrote in Japanese:

Lambda Durable Functions のロギングには context.logger を使用しよう #Python - Qiita

はじめにこんにちは、ほうき星 @H0ukiStar です。皆さんは Lambda Durable Functions を使っていますでしょうか？ Lambda Durable Functions は Lambda 関数単体で Step Functions のようなマル...

qiita.com

Introduction

Hi, I'm @H0ukiStar.

Have you tried using Lambda Durable Functions?

Lambda Durable Functions is a feature that allows you to implement multi-step workflows—similar to Step Functions—using only a single Lambda function.

When implementing logging in Lambda Durable Functions, it is recommended to use context.logger and step_context.logger. But why is that?

In this article, I’ll explain the reason based on actual behavior and implementation details.

Logging with the Standard Method

First, in a typical Lambda function (Python), logging is usually done using the built-in logging module, like this:

import logging

logger: logging.Logger = logging.getLogger()
logger.setLevel(logging.INFO)

logger.info("Loading lambda_function.py")

Below is a sample where logging is performed using the logging module inside both steps and the lambda_handler in Lambda Durable Functions:

import logging


from aws_durable_execution_sdk_python.config import Duration
from aws_durable_execution_sdk_python.execution import durable_execution
from aws_durable_execution_sdk_python.context import DurableContext, StepContext, durable_step


logger: logging.Logger = logging.getLogger()
logger.setLevel(logging.INFO)


@durable_step
def step_one(step_context: StepContext, arg: int) -> str:
    logger.info("Hello from step_one")
    return f"from step_one: {arg=}"


@durable_step
def step_two(step_context: StepContext, arg: int) -> str:
    logger.info("Hello from step_two")
    return f"from step_two: {arg=}"


@durable_step
def step_three(step_context: StepContext, arg: int) -> str:
    logger.info("Hello from step_three")
    return f"from step_three: {arg=}"


@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> None:
    msg_one: str = context.step(step_one(123))
    logger.info(msg_one)

    msg_two: str = context.step(step_two(456))
    logger.info(msg_two)

    context.wait(Duration.from_seconds(30))

    msg_three: str = context.step(step_three(789))
    logger.info(msg_three)

Execution Result

When you run this code and check the logs in CloudWatch, you will see output like this:

In summary, the logs behave as follows:

step_one() runs → "Hello from step_one" is logged
The return value "from step_one: arg=123" is logged (①)
step_two() runs → "Hello from step_two" is logged
The return value "from step_two: arg=456" is logged (②)
Execution pauses with context.wait()
After resuming, "from step_one: arg=123" is logged again (①')
"from step_two: arg=456" is logged again (②')
step_three() runs → "Hello from step_three" is logged
The return value "from step_three: arg=789" is logged
You can see that logs before and after context.wait() are duplicated.

Recommended Logging Method

As mentioned earlier, in Lambda Durable Functions:

Use context.logger in the handler
Use step_context.logger inside steps

Logging—I use context.logger for the main handler and step_context.logger inside steps. The context logger suppresses duplicate logs during replay.

Build multi-step applications and AI workflows with AWS Lambda durable functions | AWS News Blog

aws.amazon.com

Here is the updated version of the previous code using context.logger:

from aws_durable_execution_sdk_python.config import Duration
from aws_durable_execution_sdk_python.execution import durable_execution
from aws_durable_execution_sdk_python.context import DurableContext, StepContext, durable_step


@durable_step
def step_one(step_context: StepContext, arg: int) -> str:
    step_context.logger.info("Hello from step_one")
    return f"from step_one: {arg=}"


@durable_step
def step_two(step_context: StepContext, arg: int) -> str:
    step_context.logger.info("Hello from step_two")
    return f"from step_two: {arg=}"


@durable_step
def step_three(step_context: StepContext, arg: int) -> str:
    step_context.logger.info("Hello from step_three")
    return f"from step_three: {arg=}"


@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> None:
    msg_one: str = context.step(step_one(123))
    context.logger.info(msg_one)

    msg_two: str = context.step(step_two(456))
    context.logger.info(msg_two)

    context.wait(Duration.from_seconds(30))

    msg_three: str = context.step(step_three(789))
    context.logger.info(msg_three)

Execution Result

The output now looks like this:

Unlike the previous case, there are no duplicated logs before and after context.wait().

Why This Is Recommended

1. Logs in the handler are not duplicated

From the results above, logs written using context.logger are not duplicated.

This is because Lambda Durable Functions uses a mechanism called replay.

When execution resumes after context.wait(), the function does NOT continue from where it left off. Instead, the handler is executed again from the beginning.

During this process:

Completed steps are skipped using checkpoint logs
Their results are reused instead of re-executing the step

When your function resumes after a pause or interruption, the SDK performs replay:

Load checkpoint log: The SDK retrieves the checkpoint log for this execution from Lambda.

Run from beginning: The SDK invokes your handler function from the start, not from where it paused.

Skip completed durable operations: As your code calls durable operations, the SDK checks each against the checkpoint log. For completed durable operations, the SDK returns the stored result without executing the operation code.

docs.aws.amazon.com

As a result:

Step functions are skipped → no duplicate logs inside steps
But handler code runs again → duplicate logs when using logging

On the other hand, context.logger is implemented to suppress duplicate logs during replay:

https://github.com/aws/aws-durable-execution-sdk-python/blob/main/src/aws_durable_execution_sdk_python/logger.py#L118-L131

2. Logs can be viewed in the "Logger output" tab

You might think:

"If step functions are skipped anyway, why not just use logging?"

While that works for avoiding duplication, there is another benefit.

Logs written using context.logger or step_context.logger can be viewed in the "Logger output" tab in the Durable Execution management console.

This allows you to:

View logs per execution
See timestamps and messages in a structured way

Internally, this is just a CloudWatch Logs Insights query:

fields timestamp, message
    | filter executionArn like "arn:aws:lambda:{region}:{accountId}:function:{functionname}:{version or alias}/durable-execution/{executionId}/{invocationId}"

You could replicate this format manually, but it's much easier to just use step_context.logger.

Conclusion

In this article, we explored why context.logger and step_context.logger are recommended in Lambda Durable Functions, based on both behavior and SDK implementation.

Lambda Durable Functions is a powerful feature that enables multi-step workflows within a single Lambda function.

I hope this article helps you when implementing Durable Functions in your own projects.

DEV Community: ほうき星

I Built a CLI Tool to Delete Default VPCs Across All AWS Regions

AWS 全リージョンのデフォルト VPC を一括削除する CLI ツールを作った #Python - Qiita

Introduction

CLI Tool for Deleting Default VPCs: aws-default-vpc-cleaner

H0ukiStar / aws-default-vpc-cleaner

A tool to delete default VPCs and related resources across all AWS regions.

AWS Default VPC Cleaner

Features / 機能

Deleted Resources / 削除されるリソース

Installation / インストール

Prerequisites / 前提条件

Installing the Tool

Deleting Default VPCs with the Tool

Available Options

--dry-run

--yes

--regions REGION [REGION ...]

--lang {en,ja}

--verbose

Conclusion

Trying AWS IoT Core's New GetConnection and ListSubscriptions APIs

AWS IoT Core 単体で MQTT クライアントの接続状態を取得できるようになったので試す #awsIoT - Qiita

Introduction

AWS IoT Core でモノの接続状態をオンデマンドで取得する2つの方法 #lambda - Qiita

Trying It Out

GetConnection

ListSubscriptions

Conclusion

Automatically Healing CloudFormation Drift with Durable Functions

Durable Functions を用いて CloudFormation のドリフトを自動修復する #AWS - Qiita

Introduction

Trying Drift-Aware Change Sets

Deploying a Sample Stack

Introducing Drift

Repairing Drift with a Drift-Aware Change Set

Configuration Healing with Durable Functions

Workflow

Durable Functions Implementation Example

H0ukiStar / sample-aws-cfn-configuration-healing

Sample implementation of an AWS Lambda function to detect and automatically heal CloudFormation stack configuration drift.

CloudFormation Configuration Healing with Durable Functions

Features

Installation

Verification

Conclusion

How to Create an EventBridge Scheduler with ActionAfterCompletion in CloudFormation

CloudFormation で未対応の ActionAfterCompletion を指定した EventBridge Scheduler を作成する #AWS - Qiita

Introduction

What is a CloudFormation Custom Resource (AWS::CloudFormation::CustomResource)?

Sample Lambda Function for Creating a Schedule Resource with ActionAfterCompletion

Verification

Notes

Conclusion

Why You Should Use context.logger in Lambda Durable Functions

Lambda Durable Functions のロギングには context.logger を使用しよう #Python - Qiita

Introduction

Logging with the Standard Method

Execution Result

Recommended Logging Method

Build multi-step applications and AI workflows with AWS Lambda durable functions | AWS News Blog

Execution Result

Why This Is Recommended

1. Logs in the handler are not duplicated

2. Logs can be viewed in the "Logger output" tab

Conclusion

`--dry-run`

`--yes`

`--regions REGION [REGION ...]`

`--lang {en,ja}`

`--verbose`

What is a CloudFormation Custom Resource (`AWS::CloudFormation::CustomResource`)?

Sample Lambda Function for Creating a Schedule Resource with `ActionAfterCompletion`