目次

AWS Recycle Bin 完全ガイド v2.0

EBS スナップショット・AMI の誤削除防止・復元

AWS Recycle Bin は、誤って削除した EBS スナップショット・EBS バックアップ・AMI（Amazon Machine Image）・EC2 イメージを一定期間保持して復元できる Management & Governance サービス である。保持ルールを作成すると、削除されたリソースが自動的に Recycle Bin に移動し、期間内であれば復元（restore）できる。削除は許可しつつ、一定期間の回復猶予を提供する「柔軟な削除保護」を実現。CloudTrail で誤削除の監査証跡も完全記録。本ドキュメントは Recycle Bin の概念・対応リソース・保持ルール・復元・ベストプラクティスを体系的に解説。

ドキュメントの目的

本ガイドは以下を対象としています。

  • インフラエンジニア向け：EBS スナップショット・AMI の誤削除防止・復元パイプライン
  • DevOps エンジニア向け：自動化されたスナップショット管理・削除ポリシー
  • ストレージ管理者向け：複数 AWS アカウント・リージョンの保持ルール管理
  • セキュリティ・コンプライアンス向け：データ削除と復元の監査証跡
  • 意思決決者向け：AWS Backup・Azure Recovery Services との比較

2025-2026 年の Recycle Bin エコシステム

  • 自動保持ルールの推奨：AI が削除パターンを分析、最適な保持期間を提案
  • Organizations テンプレート拡大：全アカウント・全リージョンの統一保持ルール
  • API による細粒度制御：タグ・リソースタイプ・削除ユーザー別に異なるルール
  • Cost Analysis 統合：Recycle Bin 内リソースのストレージコスト可視化
  • EBS 直接スナップショット対応：EBS コンソール → Recycle Bin 操作の統合

目次

  1. 概要・課題・特徴
  2. Recycle Bin が解決する課題
  3. 主な特徴
  4. アーキテクチャ・リソースフロー
  5. 対応リソースと保持ルール
  6. コアコンポーネント詳細
  7. 主要ユースケース（10+）
  8. 設定・操作の具体例
  9. 類似サービス比較表
  10. ベストプラクティス
  11. トラブルシューティング
  12. 2025-2026 最新動向
  13. 学習リソース・参考文献
  14. 実装チェックリスト・導入ロードマップ
  15. まとめ

概要・課題・特徴

本質

AWS Recycle Bin は「削除されたリソースを一定期間保持し、期間内であれば復元できるサービス」。

AWS では通常、リソース削除は 即時永続削除 であり、復元手段がない。Recycle Bin を有効にすることで、以下を実現する。

  • 誤削除のセーフティネット：保持期間内（1 日～365 日）に復元可能
  • オペレーションミスの低減：本番スナップショット誤削除時に数秒で復旧
  • AWS Backup との補完：定期バックアップとは別に、「人的ミス」のセーフガード
  • コンプライアンス・監査：削除と復元の完全な操作履歴を CloudTrail に記録
  • 柔軟な削除保護：IAM / SCP で削除を完全ブロックするのではなく、削除後の回復猶予を提供

Recycle Bin が解決する課題

課題 Recycle Bin の解決策
本番 EBS スナップショットの誤削除 7 日以内に復元 → オペレーションダウンタイム最小化
AMI 更新作業中の旧バージョン誤削除 30 日以内に復元 → ロールバック可能
スナップショット自動削除スクリプトのバグ 一括誤削除から Recycle Bin で全件復元
データ削除要件との矛盾 削除は許可、でも回復の猶予を提供
Operations チームの属人的エラー セーフガード機構で防止、ルール化・自動化
クロスアカウント誤削除リスク Organizations テンプレートで全アカウントに統一ルール

主な特徴

1. 保持ルール（Retention Rule）

3 つの定義方法:

1. リソースタイプベース（Resource-Type Rule）
   すべての EBS スナップショット → 30 日保持
   すべての AMI → 60 日保持

2. タグベース（Tag-based Rule）
   tag:Environment=production → 90 日保持（本番のみ厳しく）
   tag:Environment=development → 7 日保持（開発は短く）

3. リージョンレベル（Regional Rule）
   ap-northeast-1（東京）→ 全リソース 30 日保持
   ap-northeast-2（大阪）→ 全リソース 14 日保持

2. 対応リソース

✅ EBS Snapshot（EBS スナップショット）
   → 手動削除時に Recycle Bin に移動
   → 最大保持：365 日

✅ AMI（Amazon Machine Image）
   → イメージ削除時に Recycle Bin に移動
   → 関連スナップショットも保持対象

✅ EBS-backed AMI
   → AMI 削除時、関連 EBS スナップショットも保持

❌ EBS Volume（EBS ボリューム）
   → Recycle Bin 非対応
   → Snapshot 取得で間接的に保護

❌ Instance Store-backed AMI
   → Recycle Bin 非対応

3. CloudTrail 統合

記録される操作:

削除時:
  - 削除実行ユーザー
  - リソース ID
  - 削除タイムスタンプ
  - IAM ロール / コンソール実行

復元時:
  - 復元実行ユーザー
  - 復元リソース ID
  - 復元タイムスタンプ
  → 完全な監査証跡

Recycle Bin が解決する課題

ビジネス課題

  1. 本番環境の予期しないダウンタイム

    • 開発者が誤ってスナップショット削除
    • 復旧手段なし → 数時間のサービス停止
    • Recycle Bin で数分で復復元 → SLA 維持

  2. IaC（Infrastructure as Code）バグでの大量削除

    • Terraform destroy が想定外に実行
    • 数百のスナップショットが一度に削除
    • Recycle Bin で全件復元可能

  3. リリース・ロールバック時の AMI 復旧

    • 旧 AMI を誤削除してしまった
    • Recycle Bin で 30 日以内なら復旧可能
    • ロールバックに対応

  4. 複数チーム間の削除ルール不統一

    • 開発チーム = 即時削除
    • 本番チーム = 90 日保持
    • Organizations テンプレートで統一

技術課題

  1. スナップショット整理スクリプトのバグ

    # 誤ったロジック
aws ec2 describe-snapshots --query 'Snapshots[].SnapshotId' \
  | xargs aws ec2 delete-snapshot  # 全スナップショット削除！

→ Recycle Bin がセーフガード

  2. 本番・開発の誤操作

    • 本番環境と思ったら開発環境だった（その逆）
    • スナップショット削除後に気付く
    • Recycle Bin で即座に復元

  3. 削除権限と回復権限の分離

    • IAM ポリシー：削除は許可
    • 但し、誤削除は Recycle Bin で回復
    • 削除完全ブロック（SCP）より運用的

主な特徴

Recycle Bin リソースライフサイクル

graph LR
    A["EBS Snapshot / AMI"] --> B["削除"]
    B --> |"Rule Match"| C["Recycle Bin移動<br/>Pending Deletion"]
    
    C --> |"復元実行<br/>（期間内）"| D["復元完了<br/>使用可能"]
    C --> |"保持期間経過"| E["完全削除<br/>復元不可"]
    
    D --> F["ダッシュボード<br/>通常運用に復帰"]
    
    style A fill:#ccccff
    style C fill:#ffcccc
    style D fill:#ccffcc
    style E fill:#ff9999

ルール適用フロー

Step 1: 保持ルール作成
  リソースタイプ: EBS Snapshot
  保持期間: 30 日
  ルール ID: rule-12345

Step 2: リソース削除実行
  aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0

Step 3: 削除 → ルールチェック
  Recycle Bin が自動的にマッチングルール確認
  → EBS Snapshot タイプ＆該当ルール存在
  → Recycle Bin に移動

Step 4: 期間内の復元（オプション）
  aws rbin restore-resource \
    --resource-id snap-0123456789abcdef0 \
    --resource-type EBS_SNAPSHOT

  状態: Recycle Bin → 通常のスナップショット

Step 5: 保持期間経過後（30 日）
  自動削除 → 復元不可

対応リソースと保持ルール

対応リソース詳細

┌─────────────────────┬──────────────────┬─────────────────┬─────────────┐
│ リソース種別        │ 対応状況         │ 最大保持期間    │ 保持単位    │
├─────────────────────┼──────────────────┼─────────────────┼─────────────┤
│ EBS Snapshot        │ ✅ 対応          │ 365 日          │ Snapshot    │
│ AMI                 │ ✅ 対応          │ 365 日          │ Image       │
│ EBS-backed AMI      │ ✅ 対応          │ 365 日          │ Image + Snap│
│ EBS Volume          │ ❌ 非対応        │ -               │ -           │
│ Instance Store AMI  │ ❌ 非対応        │ -               │ -           │
│ EBS Backup（AWS    │ ✅ 対応          │ 365 日          │ Backup      │
│  Backup 経由）      │                  │                 │             │
└─────────────────────┴──────────────────┴─────────────────┴─────────────┘

保持ルールの設定

ルール定義の 3 要素:

1. Resource Type
   - EBS_SNAPSHOT: EBS スナップショット
   - AMI: Amazon Machine Image

2. Scope（ルール適用範囲）
   - ALL: 全リソース（フィルタなし）
   - RESOURCE_TAGS: 特定タグのみ
     例：tag:Environment=production

3. Retention Period
   - 最小：1 日
   - 最大：365 日（1 年）
   - デフォルト推奨：30 日

タグベースルール設定例

{
  "RuleName": "production-ebs-snapshots-90days",
  "Description": "本番 EBS スナップショット 90 日保持",
  "ResourceType": "EBS_SNAPSHOT",
  "RetentionPeriodValue": 90,
  "RetentionPeriodUnit": "DAYS",
  "ResourceTags": [
    {
      "Key": "Environment",
      "Value": "production"
    },
    {
      "Key": "Criticality",
      "Value": "high"
    }
  ]
}

コアコンポーネント詳細

1. Recycle Bin コンソール

機能:

Recycle Bin Dashboard
  → 現在 Bin に入っているリソース一覧
  → リソースタイプ別フィルター
  → 削除日時・復元可能日時表示

Retention Rules
  → 設定済みルール一覧
  → ルールの有効 / 無効切り替え
  → ルール編集・削除

Resource Details
  → 削除されたリソースの詳細情報
  → 元のタグ・スナップショット ID・サイズ
  → 復元ボタン（期間内のみ有効）

2. Recycle Bin API

主要オペレーション:

CreateRule
  → 新規保持ルール作成

DeleteRule
  → ルール削除（既に Bin 内のリソースは影響なし）

ListResources
  → Recycle Bin 内のリソース一覧取得

RestoreResource
  → 削除されたリソースを復元
  → リソースタイプ・リソース ID 指定

UpdateRule
  → ルール修正（保持期間など）

3. CloudTrail 統合

Recycle Bin に記録されるイベント:

DeleteSnapshot
  - 削除実行ユーザー
  - スナップショット ID
  - 削除タイムスタンプ
  - Recycle Bin 移動確認

RestoreResource
  - 復元実行ユーザー
  - リソース ID
  - 復元タイムスタンプ
  → コンプライアンス監査用に完全記録

4. Organizations 統合

管理アカウントでルール定義
  ↓
全メンバーアカウントに自動適用
  ↓
一元管理されたポリシー

例:
  本番環境（tag:Environment=production）
    → 全アカウント 90 日保持
  開発環境（tag:Environment=development）
    → 全アカウント 7 日保持

主要ユースケース

1. 本番 EBS スナップショットの誤削除復旧

シナリオ:
  本番データベース EBS ボリュームのスナップショットを誤削除

事象:
  AWS コンソール
    → EBS → Snapshots
    → snap-prod-db-20260401 を選択して「Delete」
    → 誤ったスナップショットを削除してしまった

従来（Recycle Bin なし）:
  → スナップショット消失 → 数時間のデータベース復旧作業
  → SLA breach → 顧客に謝罪

Recycle Bin あり:
  Step 1: 誤削除に気付く（削除から 1 分後）

  Step 2: Recycle Bin コンソールで確認
    Recycle Bin → Resources
    → snap-prod-db-20260401 が Pending Deletion で表示

  Step 3: 復元実行
    AWS CLI:
      aws rbin restore-resource \
        --resource-type EBS_SNAPSHOT \
        --resource-id snap-prod-db-20260401 \
        --region ap-northeast-1

  Step 4: 復元完了（数秒）
    スナップショット復元 → 通常のスナップショット一覧に戻る

結果: ダウンタイム 0（～ 1 分の軽微な影響のみ）

2. Infrastructure as Code（IaC）バグからの復旧

シナリオ:
  Terraform コードバグで 500+ スナップショットが削除された

原因:
  Terraform destroy が想定外に実行
  または
  Terraform code に バグで全リソース削除ルール記載

影響:
  500 個のスナップショット一括削除

従来:
  → 手動で 1 つ 1 つ復旧？（不可能）
  → バックアップから復旧（数時間〜数日）

Recycle Bin あり:
  Step 1: バグを検出（削除から 10 分後）

  Step 2: 影響スナップショット一覧確認
    aws rbin list-resources \
      --resource-type EBS_SNAPSHOT \
      --region ap-northeast-1 \
      --query 'Resources[].{ResourceId: ResourceId, CreationTime: CreationTime}' \
      | grep "deletion-time recent"

  Step 3: Lambda で一括復元
    def restore_all_snapshots():
        client = boto3.client('rbin')
        resources = client.list_resources(
            ResourceType='EBS_SNAPSHOT'
        )
        
        for resource in resources['Resources']:
            client.restore_resource(
                ResourceType='EBS_SNAPSHOT',
                ResourceId=resource['ResourceId']
            )
        
        return len(resources['Resources'])

  Step 4: 全スナップショット復元完了（5 分）

結果: 500+ スナップショップを一括復旧、数分で復帰

3. AMI 管理 with ロールバック対応

シナリオ:
  AMI バージョン更新中に旧 AMI を誤削除

進行:
  AMI v1.0（現在）
    ↓ 更新作業開始
  AMI v2.0（新規作成）
    ↓ テスト中
  旧 AMI v1.0 削除命令（誤実行）
    ↓ ロールバック必要に！

従来:
  → ロールバック不可 → AMI v1.0 から再構築（数時間）
  → EC2 インスタンス停止

Recycle Bin:
  Step 1: 削除検出

  Step 2: Recycle Bin から復元
    aws rbin restore-resource \
      --resource-type AMI \
      --resource-id ami-v1-old-20260401

  Step 3: EC2 インスタンス停止 → v1.0 から再起動

結果: 5 分でロールバック完了

4. Organizations での統一保持ポリシー

シナリオ:
  5 つの AWS アカウント（Dev・Test・Prod-East・Prod-West）
  で異なる保持ルール → 一元管理へ

目標:
  本番（Prod）: 90 日保持（厳しく）
  ステージング: 30 日保持（中程度）
  開発（Dev）: 7 日保持（短く）

Management Account での実装:

  Step 1: Rules 作成（タグベース）

  production-retention-rule:
    ResourceType: EBS_SNAPSHOT
    RetentionPeriod: 90 days
    ResourceTags: [Environment=production]

  development-retention-rule:
    ResourceType: EBS_SNAPSHOT
    RetentionPeriod: 7 days
    ResourceTags: [Environment=development]

  Step 2: Organizations に適用
    aws rbin put-rule-into-template \
      --rule-id rule-prod-90 \
      → 全メンバーアカウントに自動適用

結果: 全アカウント・全リージョンで統一ポリシー

5. セキュリティ・コンプライアンス監査

シナリオ:
  SOC 2 Type II 監査で
  「EBS スナップショット削除の記録」確認要求

Recycle Bin + CloudTrail:

  CloudTrail ログで完全記録:
    {
      "eventName": "DeleteSnapshot",
      "sourceIPAddress": "192.168.1.1",
      "userAgent": "console.aws.amazon.com",
      "eventTime": "2026-04-26T10:30:00Z",
      "requestParameters": {
        "snapshotId": "snap-0123456789abcdef0"
      },
      "responseElements": {
        "resourceId": "snap-0123456789abcdef0"
      }
    }
    
    ↓ RestoreResource イベント
    
    {
      "eventName": "RestoreResource",
      "requestParameters": {
        "resourceId": "snap-0123456789abcdef0",
        "resourceType": "EBS_SNAPSHOT"
      }
    }

監査ダッシュボード:
  → 削除・復元の完全な時系列
  → 実行者・実行タイムスタンプ
  → 意図的な削除か誤削除かの判定可能

結果: コンプライアンス要件を満たす

6. マルチリージョン スナップショット管理

シナリオ:
  東京・シンガポール・シドニーの 3 リージョンで
  統一された保持ルール

実装:

  各リージョンで同じ ルール適用:
    ap-northeast-1（東京）: 30 日保持
    ap-southeast-1（シンガポール）: 30 日保持
    ap-southeast-2（シドニー）: 30 日保持

  API で各リージョンを並列管理:
    def apply_multiregion_rules():
        regions = ['ap-northeast-1', 'ap-southeast-1', 'ap-southeast-2']
        
        for region in regions:
            client = boto3.client('rbin', region_name=region)
            client.create_rule(
                RuleName='global-snapshot-retention',
                ResourceType='EBS_SNAPSHOT',
                RetentionPeriodValue=30,
                RetentionPeriodUnit='DAYS'
            )

結果: 全リージョンで統一ポリシー適用

7. ストレージコスト最適化

シナリオ:
  Recycle Bin に大量の古いスナップショットが溜まっている
  ストレージコスト増加

問題:
  保持期間 90 日で設定
  → 90 日目に自動削除される前に、手動削除可能

最適化:
  Step 1: Recycle Bin 内の容量確認
    aws rbin list-resources \
      --resource-type EBS_SNAPSHOT \
      --query 'Resources[*].{ResourceId: ResourceId, Size: Size}'

  Step 2: 古いスナップショットを確認
    CreationTime < 60 days ago
    → もう不要なら、早期削除して容量圧縮

  Step 3: Cost Analysis で効果測定
    削除前: $500/月（Recycle Bin スナップショット）
    削除後: $200/月（ 60% 削減）

結果: ストレージコスト最適化

8. スナップショット削除 IAM ポリシー運用

シナリオ:
  開発チームに削除権限は与えたいが、
  誤削除保護が必要

IAM ポリシー:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:DeleteSnapshot",
          "ec2:DeleteImage"
        ],
        "Resource": "*"
      }
    ]
  }

セーフガード:

  Recycle Bin Rule:
    タグ: Environment=development
    保持期間: 7 日
    → 削除は許可、でも 7 日は復可能

効果:
  権限は与えているが、
  誤削除のリスクを低減（7 日の回復猶予）

9. 本番環境の定期バックアップ

シナリオ:
  AWS Backup で定期バックアップ
  + Recycle Bin で人的ミス対策の 2 層防御

構成:

Layer 1: AWS Backup
  スケジュール: 日次 02:00 JST
  保持期間: 30 日
  用途: 計画的な復旧、定期バックアップ

Layer 2: Recycle Bin
  ルール: 全 EBS Snapshot を 30 日保持
  用途: 誤削除時の緊急復旧

効果:
  → AWS Backup のバックアップ
  → Recycle Bin でも別途保持
  → 多層防御で高い耐障害性

10. API ドリブン自動化

シナリオ:
  CI/CD パイプラインで
  スナップショット作成 → テスト → 削除を自動化
  失敗時は Recycle Bin から復元

Pipeline:

  Step 1: スナップショット作成
    aws ec2 create-snapshot \
      --volume-id vol-xxx \
      --description "test-snapshot"

  Step 2: テスト実行
    # 各種検証

  Step 3: テスト失敗時の復旧
    try:
        run_tests()
    except TestFailure:
        # スナップショット削除
        delete_snapshot()
        
        # Recycle Bin から復復元
        client = boto3.client('rbin')
        resources = client.list_resources(
            ResourceType='EBS_SNAPSHOT'
        )
        for resource in resources['Resources']:
            if resource['ResourceId'] == snapshot_id:
                client.restore_resource(
                    ResourceType='EBS_SNAPSHOT',
                    ResourceId=snapshot_id
                )
        
        print("Snapshot restored from Recycle Bin")

効果: 自動化処理の安全性向上

設定・操作の具体例

CLI 例

# ルール作成（全 EBS スナップショット 30 日保持）
aws rbin create-rule \
  --resource-type EBS_SNAPSHOT \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --description "Retain all EBS snapshots for 30 days" \
  --region ap-northeast-1

# ルール作成（タグベース：本番のみ 90 日）
aws rbin create-rule \
  --resource-type EBS_SNAPSHOT \
  --retention-period RetentionPeriodValue=90,RetentionPeriodUnit=DAYS \
  --resource-tags Key=Environment,Value=production \
  --description "Retain production snapshots for 90 days" \
  --region ap-northeast-1

# Recycle Bin 内のリソース一覧
aws rbin list-resources \
  --resource-type EBS_SNAPSHOT \
  --region ap-northeast-1 \
  --query 'Resources[*].[ResourceId,ResourceArn,CreationTime,RetentionPeriod]'

# 削除されたスナップショットの詳細確認
aws rbin list-resources \
  --resource-type EBS_SNAPSHOT \
  --region ap-northeast-1 \
  --query "Resources[?ResourceId=='snap-0123456789abcdef0']"

# リソース復元
aws rbin restore-resource \
  --resource-type EBS_SNAPSHOT \
  --resource-id snap-0123456789abcdef0 \
  --region ap-northeast-1

# ルール一覧確認
aws rbin list-rules \
  --resource-type EBS_SNAPSHOT \
  --region ap-northeast-1 \
  --query 'Rules[*].[RuleId,ResourceType,RetentionPeriod,Description]'

# ルール更新（保持期間を 30 日から 60 日に変更）
aws rbin update-rule \
  --rule-id rule-12345 \
  --retention-period RetentionPeriodValue=60,RetentionPeriodUnit=DAYS \
  --region ap-northeast-1

# ルール削除
aws rbin delete-rule \
  --rule-id rule-12345 \
  --region ap-northeast-1

SDK 例（Python）

import boto3
from datetime import datetime, timedelta

def setup_recycle_bin_rules():
    """Recycle Bin ルール設定"""
    rbin = boto3.client('rbin', region_name='ap-northeast-1')
    
    # ルール 1: 全 EBS スナップショット 30 日保持
    response1 = rbin.create_rule(
        ResourceType='EBS_SNAPSHOT',
        RetentionPeriod={
            'RetentionPeriodValue': 30,
            'RetentionPeriodUnit': 'DAYS'
        },
        Description='Retain all EBS snapshots for 30 days'
    )
    print(f"Rule 1 created: {response1['RuleId']}")
    
    # ルール 2: 本番タグ付きスナップショット 90 日保持
    response2 = rbin.create_rule(
        ResourceType='EBS_SNAPSHOT',
        RetentionPeriod={
            'RetentionPeriodValue': 90,
            'RetentionPeriodUnit': 'DAYS'
        },
        ResourceTags=[
            {
                'Key': 'Environment',
                'Value': 'production'
            }
        ],
        Description='Retain production snapshots for 90 days'
    )
    print(f"Rule 2 created: {response2['RuleId']}")

def list_recycle_bin_resources():
    """Recycle Bin 内のリソース一覧表示"""
    rbin = boto3.client('rbin', region_name='ap-northeast-1')
    
    response = rbin.list_resources(
        ResourceType='EBS_SNAPSHOT'
    )
    
    print("Resources in Recycle Bin:")
    for resource in response['Resources']:
        print(f"  ID: {resource['ResourceId']}")
        print(f"    Created: {resource['CreationTime']}")
        print(f"    Retention: {resource['RetentionPeriod']}")
        print(f"    Status: {resource.get('Status', 'PENDING_DELETION')}")

def restore_snapshot(snapshot_id):
    """スナップショット復元"""
    rbin = boto3.client('rbin', region_name='ap-northeast-1')
    
    response = rbin.restore_resource(
        ResourceType='EBS_SNAPSHOT',
        ResourceId=snapshot_id
    )
    
    print(f"Snapshot {snapshot_id} restored successfully")
    print(f"Resource ARN: {response['ResourceArn']}")

def bulk_restore_by_date(days_old_threshold=5):
    """指定日数より古いスナップショット一括復元"""
    rbin = boto3.client('rbin', region_name='ap-northeast-1')
    
    response = rbin.list_resources(
        ResourceType='EBS_SNAPSHOT'
    )
    
    threshold = datetime.now(tz=None) - timedelta(days=days_old_threshold)
    restored_count = 0
    
    for resource in response['Resources']:
        creation_time = resource['CreationTime'].replace(tzinfo=None)
        
        if creation_time < threshold:
            try:
                rbin.restore_resource(
                    ResourceType='EBS_SNAPSHOT',
                    ResourceId=resource['ResourceId']
                )
                restored_count += 1
                print(f"Restored: {resource['ResourceId']}")
            except Exception as e:
                print(f"Failed to restore {resource['ResourceId']}: {e}")
    
    print(f"Total restored: {restored_count}")

def monitor_recycle_bin_cost():
    """Recycle Bin ストレージコスト監視"""
    rbin = boto3.client('rbin', region_name='ap-northeast-1')
    ec2 = boto3.client('ec2', region_name='ap-northeast-1')
    
    response = rbin.list_resources(
        ResourceType='EBS_SNAPSHOT'
    )
    
    total_size_gb = 0
    for resource in response['Resources']:
        # リソース ID から EBS スナップショット詳細取得
        snapshot_details = ec2.describe_snapshots(
            SnapshotIds=[resource['ResourceId']]
        )
        
        if snapshot_details['Snapshots']:
            size = snapshot_details['Snapshots'][0]['VolumeSize']
            total_size_gb += size
    
    # EBS スナップショット価格：$0.05 per GB-month
    monthly_cost = total_size_gb * 0.05
    
    print(f"Recycle Bin Statistics:")
    print(f"  Total Size: {total_size_gb} GB")
    print(f"  Estimated Monthly Cost: ${monthly_cost:.2f}")

if __name__ == '__main__':
    setup_recycle_bin_rules()
    list_recycle_bin_resources()
    monitor_recycle_bin_cost()

類似サービス比較表

┌──────────────────────┬──────────────────┬──────────────────┬──────────────────┐
│ 観点                 │ Recycle Bin      │ AWS Backup       │ Azure Recovery   │
│                      │                  │                  │ Services         │
├──────────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 対象リソース         │ EBS Snap / AMI   │ EC2/RDS/DynamoDB │ VM / DB backup   │
│ 保持期間             │ 1-365 日         │ 設定値            │ 設定値           │
│ 自動保持             │ ✅ ルール基      │ ✅ ポリシー基    │ ✅ ポリシー基   │
│ 誤削除復旧           │ ✅ セーフガード  │ ⚠️ 別途テープ    │ ✅ Soft delete   │
│ Organizations 統合  │ ✅ テンプレート  │ ✅ 一元管理       │ ✅ Tenant        │
│ CloudTrail 記録     │ ✅ 完全記録      │ ⚠️ バックアップ  │ ✅ 監査ログ      │
│ コスト               │ スナップ料金    │ バックアップ料金 │ Recovery 料金    │
│ タグベース管理       │ ✅ 対応          │ ✅ 対応          │ ⚠️ 限定的        │
└──────────────────────┴──────────────────┴──────────────────┴──────────────────┘

ベストプラクティス

ルール設計

✅ DO

  1. 環境別に異なる保持期間

    production: 90 日（厳しく）
staging: 30 日（中程度）
development: 7 日（短く）

  2. タグベースルールで柔軟性確保

    tag:Criticality=high → 180 日保持
tag:Criticality=medium → 30 日保持
tag:Criticality=low → 7 日保持

  3. Organizations テンプレートで統一

    全アカウント・全リージョンで同一ルール
→ 管理効率化・一貫性確保

❌ DON’T

  • すべてのリソースで最大 365 日保持 → ストレージコスト増加
  • ルール設定後、放置 → 定期レビュー（月 1 回）

オペレーション

✅ DO

  1. Recycle Bin 復復元の権限分離

    削除権限: 一般開発者
復復元権限: SRE・管理者のみ
→ 誤操作による大量復復元防止

  2. CloudTrail で削除・復復元アクションを監視

    削除数が多い → スクリプトバグ疑い
復復元頻度 → オペミス頻度の可視化

  3. Recycle Bin の定期クリーンアップ

    月 1 回、Recycle Bin 内リソースの確認
明らかに不要 → 早期削除でコスト削減

❌ DON’T

  • 削除スクリプト改修なし → Recycle Bin への依存化
  • 復復元権限なしで削除を許可 → リスク管理不十分

セキュリティ

✅ DO

  1. SCP で Recycle Bin ルール削除を禁止

    Organization 管理者のみ、ルール削除可能
一般ユーザー：復復種は許可、ルール削除は禁止

  2. CloudTrail 監査

    誰がどのリソースを削除・復復種したか記録
→ コンプライアンス要件対応

トラブルシューティング

症状 原因 解決策
復復種ボタンが無効 保持期間経過 復復種期限内に実行必須
ルール作成できない リージョン未対応 Recycle Bin は全リージョン対応（確認）
Recycle Bin にリソースがない ルール未適用 リソース削除時にルール重合確認
タグベースルール機能しない タグが一致していない** リソースのタグキー・値を正確に確認
復復種時に権限エラー IAM 権限不足 rbin:RestoreResource 権限追加

2025-2026 最新動向

EBS ボリュームサポート（検討中）

現在は EBS スナップショット・AMI のみですが、EBS ボリューム直接対応がロードマップに記載。

Cost Analyzer との統合

Recycle Bin 内リソースのストレージコストを Cost Analyzer で可視化予定。

API 機能拡張

LongID（リソースロング ID）対応・バッチ削除など、自動化向け API 拡張予定。

学習リソース・参考文献

公式リソース

  1. AWS 公式ドキュメント

  2. ブログ・記事

実装チェックリスト・導入ロードマップ

導入前チェック

  • [ ] 現在の EBS スナップショット・AMI 削除頻度を把握
  • [ ] 環境別（本番・開発）の保持期間要件を整理
  • [ ] IAM 権限設定（削除 vs 復復種）を計画
  • [ ] Organizations 使用の確認

Phase 1: 設定（1 週間）

  1. 基本ルール作成（全リソース 30 日保持）
  2. Recycle Bin コンソール・API の動作確認
  3. テスト環境で誤削除 → 復復種を検証

Phase 2: 本番運用（2 週間）

  1. タグベースルール適用（環境別）
  2. IAM 権限設定（削除・復復種の分離）
  3. Organizations テンプレート化（マルチアカウント）

Phase 3: 最適化（継続）

  1. CloudTrail 監視ダッシュボード構築
  2. Recycle Bin コスト監視
  3. 月 1 回のルール見直し

まとめ

AWS Recycle Bin は「削除されたリソースを一定期間保持し、期間内なら復復種できるセーフティネットサービス」。

強み

  • 無料（ストレージコスト除く）
  • 誤削除対策として非常に有効
  • 削除は許可しながらセーフガード提供
  • CloudTrail で完全な監査証跡

弱み

  • EBS ボリューム直接対応なし（スナップショット経由）
  • 保持期間中はストレージコスト発生
  • Instance Store AMI 非対応

採用判断

Recycle Bin は本番 EBS スナップショット・AMI の 必須 セーフガード。

✅ 本番データベース / アプリケーション向け EBS スナップショット ✅ 定期更新する AMI・EC2 イメージ ✅ Organizations マルチアカウント運用 ✅ コンプライアンス・監査ログ要件あり

最終更新：2026-04-26 バージョン：v2.0