EventBridge SchedulerでDynamoDBの古いデータを自動削除してみた

2025.09.11
 はじめにこんにちは、八亀です。

皆さん、DynamoDB のデータ削除と聞いて真っ先に思い浮かべるのは TTL（Time To Live） 機能ではないでしょうか。

TTL はシンプルに「一定時間経過したレコードを自動削除」できて便利ですが、実際の運用要件ではそれだけでは不十分なケースもあるかと思います。例えば、「最終アクセス日時から30日が経過したら削除したい」といったシナリオは TTL の仕組みでは直接実現できません。

そこで今回は、Amazon EventBridge Scheduler + AWS Lambda を組み合わせて  「30日以上アクセスされていないデータを自動削除する仕組み」  を構築し、TTL ではカバーできない運用シナリオを試してみます。
 今回作るもの本記事では、DynamoDB に保存されたデータのうち「30日以上アクセスされていない項目」を自動で削除する仕組みを構築します。

具体的には、EventBridge Scheduler で定期的に Lambda を起動し、DynamoDB の lastAccessAt 属性をチェックして削除対象を判定します。削除処理の結果は CloudWatch Logs に出力されるため、実行状況を簡単に確認できます。

以下が本システムの構成図です。
 Step1 DynamoDB の準備まずは削除対象となるデータを保存するための DynamoDB テーブル を作成します。

テーブル作成はマネジメントコンソールから行いました。
このテーブルには「ユーザーID」と「最終アクセス日時」を属性として持たせ、

後続の Lambda + EventBridge Scheduler で「30日以上アクセスされていないデータを削除する」ことができるように設計します。
 テーブルの作成以下の構成でテーブルを作成します
テーブル名: TestTable_yakame （任意のテーブル名）
パーティションキー: userId (String)
その他の属性: lastAccessAt (Number)
秒単位の Unix タイムスタンプを格納
「最後にアクセスした日時」を表すため、この値を基準に「30日以上前かどうか」を判定します



 項目の追加本来のシナリオでは、アプリケーションから データにアクセスされるたびに lastAccessAt を更新 する仕組みが必要です。

これにより、「最終アクセスから一定期間が経過したデータ」を正しく判定できます。
ただし今回は検証用ですので、テストデータとして以下の3件を手動で追加しました。
約90日前のアクセス時刻を持つデータ（削除対象になる想定）
約30日前のアクセス時刻を持つデータ（削除対象になる想定）
現在時刻を持つデータ（削除対象外の想定）
以下は JSON 形式で項目を投入している様子と、追加後のテーブル画面です。


 Step2 Lambda 関数の作成次に、DynamoDB の古いデータを削除するための Lambda 関数 を作成します。

この関数は EventBridge Scheduler から定期的に呼ばれ、テーブルから 30 日以上前のデータを探し出して削除します。
 Lambda 関数の作成AWS Management Console から Lambda を開きます。
「関数の作成」をクリックし、以下の内容で作成します。
関数名: dynamodb-cleanup-yakame (任意の関数名）
ランタイム: Python 3.13
アーキテクチャ: x86_64
実行ロール: 新しいロールを作成（後でポリシーを追加します）
作成後、設定タブ → 環境変数 に以下を追加してください。
キー: TABLE_NAME
値: TestTable_yakame（DynamoDBテーブル名）

 IAMロールの権限付与Lambda が DynamoDB を操作できるように、作成された IAM ロールに次のポリシーを追加します。
付与するポリシー
					
			{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:Scan",
        "dynamodb:DeleteItem"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:<アカウントID>:table/<テーブル名>"
    }
  ]
}

		
		
 Lambda のコード追加作成した Lambda 関数に、DynamoDB の項目を削除する処理を追加します。

コードタブを開き、以下の Python コードを貼り付けてください。

編集後は「デプロイ」ボタンを押すと変更が反映されます。
Python コード
					
			import boto3
import os
import time

# DynamoDB リソースを初期化
dynamodb = boto3.resource("dynamodb")
TABLE_NAME = os.environ["TABLE_NAME"]
table = dynamodb.Table(TABLE_NAME)

def lambda_handler(event, context):
    # 現在時刻（UnixTime, 秒）
    now = int(time.time())
    # 現在から30日前のしきい値を計算
    threshold = now - (30 * 24 * 60 * 60)

    print(f"Current time: {now}, Threshold: {threshold}")

    # DynamoDB テーブルをスキャン（全件取得）
    response = table.scan()
    items = response.get("Items", [])

    deleted_count = 0

    for item in items:
        last_access = int(item.get("lastAccessAt", 0))
        user_id = item.get("userId")

        # 30日前より古ければ削除
        if last_access < threshold:
            print(f"Deleting item: userId={user_id}, lastAccessAt={last_access}")
            table.delete_item(Key={"userId": user_id})
            deleted_count += 1

    print(f"Deleted {deleted_count} items older than 30 days")

    return {
        "statusCode": 200,
        "deletedCount": deleted_count
    }

		
		
 Step3 EventBridge Scheduler の設定Lambda 関数が準備できたら、次は Amazon EventBridge Scheduler を使って定期的に実行されるようスケジュールを設定します。

これによりデータ削除処理が自動化され、放置しても古いデータが溜まらなくなります。
 スケジュールの作成AWS Management Console から EventBridge を開きます。
左のメニューから Scheduler を選び、「スケジュールの作成」をクリックします。
以下の内容を入力します。
スケジュール名: daily-dynamodb-cleanup
説明: DynamoDB cleanup Lambda test
スケジュールグループ: default のままでOK
 スケジュールのパターン頻度: 定期的なスケジュール
タイムゾーン: (UTC+09:00) Asia/Tokyo`
スケジュールの種類: rate ベースのスケジュール
rate式: 5 minutes
フレックスタイムウィンドウ: オフ
ここでは検証用に「5分ごとに実行」するように設定します。
本番想定で cron 式を使い、毎日決まった時刻に設定しても構いません
 ターゲットの指定ターゲットタイプ: AWS Lambda 関数
API: Invoke
ターゲット: Step2で作成した関数を指定
ペイロード: {}（空 JSON で十分）
実行ロールはスケジュール作成時に新規ロールが自動作成されます。ロール名はそのままでも変更しても構いません。
 その他の設定上記以外は基本的に デフォルトのままでOK です。

これで、指定した間隔で自動的に Lambda が呼び出され、DynamoDB の古いデータが削除されるようになります。
 確認してみたそれでは、実際に削除処理が行われたかを確認してみます。
まずは DynamoDB コンソール を開き、テーブルの内容を確認しました。

結果、user-001 と user-002 が削除され、最新の user-003 のみが残っている ことを確認できました。
次に CloudWatch Logs を確認します。

Lambda の実行ログには、削除対象となった項目と削除件数が出力されていました。
このように、古い 2 件が削除され、最新のデータのみが残ることを確認できました。
 おわりにEventBridge Scheduler + Lambda を使うことで、

TTL では実現できない「最終アクセスから一定期間でのデータ削除」をシンプルに実装できました。

この仕組みはセッション情報やアクセスログなど、「使われなくなったら定期的に掃除したいデータ」に応用可能だと思います。
一方で、今回はあくまで検証のための簡易構成です。
アプリケーションからのアクセス時刻（lastAccessAt）の自動更新は未対応
検証用に投入した Item 数が少ない
実行頻度やエラーハンドリングも最小限
といった制限があるため、本番導入を検討する際には、より現実に即した検証や負荷テストを行うことをおすすめします。
 参考資料ステップ 1: DynamoDB にテーブルを作成する - Amazon DynamoDB
Time to Live (TTL) - Amazon DynamoDB
Table - Boto3 1.40.27 documentation
EventBridge スケジューラの開始方法 - EventBridge スケジューラ
 アノテーション株式会社についてアノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。