AWS Secrets Manager 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Secrets Manager は、API キー・データベース認証情報・OAuth トークン・SSH キー・カスタムシークレットを安全に保存・取得・自動ローテーションする マネージドサービスです。2016 年にリリース後、暗号化・IAM 連携・自動ローテーション機能を通じて、シークレット管理のベストプラクティスを実現する業界標準ツールになりました。本ドキュメントは、Secrets Manager の概念・使い方・エコシステム・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

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

初心者向け： Secrets Manager とは何か、なぜ必要かを学びたい方
開発者向け： GetSecretValue API を使ってシークレットを取得したい方
DevOps / SRE 向け： Lambda ローテーション、KMS 統合、VPC エンドポイント設定したい方
セキュリティ向け： IAM Policy・ResourcePolicy・監査ログを活用したい方
意思決定者向け： Parameter Store との使い分け・投資判断

2025-2026 年の Secrets Manager エコシステム

AI Secret Scanning： CodeBuild / GitHub Actions での漏洩シークレット自動検出
Cross-Region Replication： DR 対応でのシークレット自動複製
Cost Optimization Batch API： 複数シークレット一括取得で API 料金削減
OpenID Connect（OIDC）Integration： GitHub Actions / GitLab CI / Terraform Cloud での認証
Hybrid Environment Support： オンプレミス Vault、HashiCorp との統合
RDS / Redshift 自動ローテーション拡張： DocumentDB、ElastiCache サポート追加

定義

AWS 公式による定義：

“Secrets Manager enables you to manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their lifecycle.”

暗号化・IAM ベースアクセス制御・自動ローテーション・CloudTrail 監査ログをあらゆるアプリケーション・インフラに提供します。

概要
Secrets Manager が解決する課題
主な特徴
アーキテクチャ
Secret タイプ
主要ユースケース
シークレットローテーション
RDS・Redshift・DocumentDB 自動ローテーション
バージョニング
レプリケーション（クロスリージョン）
VPC Endpoint（PrivateLink）
セキュリティ（KMS・IAM・ResourcePolicy）
ECS・EKS・Lambda 連携
Cost Optimization
Parameter Store vs Secrets Manager 使い分け
他の類似ツールとの比較
クライアント・エコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： Secrets Manager は「シークレットの銀行」のようなものです。パスワード・API キー・秘密鍵などを暗号化して安全に保管し、必要なアプリケーションだけに IAM ポリシーで認可後に GetSecretValue API で配布します。単なるストレージではなく、Lambda ローテーション関数で定期的にシークレットを自動更新し、CloudTrail で全アクセスを監査します。

Secrets Manager は、複雑なマルチクラウド・ハイブリッド環境において以下を実現します。

シークレットの一元管理：パスワード、API キー、証明書、OAuth トークンを統一されたインターフェースで保管・配布
自動ローテーション：Lambda 関数で定期的にシークレット更新、アプリ再起動なしで新認証情報に切り替わる
クロスアカウント・クロスリージョン共有：IAM Policy・Resource Policy・レプリケーションで複数環境をサポート
KMS 統合暗号化：カスタマーマネージドキー or AWS マネージドキーで保存時の暗号化
監査・コンプライアンス：全シークレットアクセスを CloudTrail でログ、PCI DSS・HIPAA 対応
VPC PrivateLink：インターネット経由なしの安全なアクセス

Secrets Manager の位置づけ

【図1】AWS セキュリティスタックにおける Secrets Manager の位置：

graph TD
    Apps[アプリケーション群<br/>EC2/Lambda/ECS/EKS]
    
    Apps -->|GetSecretValue| SM[AWS Secrets Manager]
    
    SM -->|KMS暗号化<br/>復号化| KMS[AWS KMS<br/>Customer Managed Key]
    SM -->|バージョニング| Ver[Version History<br/>AWSCURRENT/AWSPENDING]
    SM -->|自動ローテーション| Lambda[Lambda<br/>Rotation Function]
    SM -->|アクセス監査| CT[CloudTrail]
    SM -->|IAM権限管理| IAM[IAM Policy<br/>Resource Policy]
    SM -->|DR対応| Replica[Cross-Region<br/>Replication]
    
    Lambda -->|自動更新| DB[RDS/Redshift<br/>DocumentDB<br/>Aurora]
    Lambda -->|外部API| API[Third Party API<br/>Stripe/Twilio等]
    
    Apps -->|VPC Endpoint| VPCEndpoint[VPC PrivateLink<br/>no Internet]
    VPCEndpoint -->|Private| SM

Secrets Manager が解決する課題

課題	従来の方法の問題	Secrets Manager の解決
ハードコード化	ソースコードにパスワード埋め込み、git に commit	GetSecretValue API で動的取得、コード変更不要
認証情報の共有	環境変数・設定ファイルに平文保存、チーム間で共有困難	IAM Policy で細粒度アクセス制御、Resource Policy でクロスアカウント対応
DB パスワード管理	管理者が手動で作成・変更、セキュリティイベント時の対応遅延	Lambda 自動ローテーション、アプリ再起動なしで新パスワードへ切り替わり
API キーローテーション	定期ローテーション困難、漏洩リスク高い	スケジュールローテーション + バージョニングで段階的切り替え
複数環境管理	各環境で異なるシークレット管理方式、ツール乱立	統一フォーマット、IAM で権限分離、複数リージョン対応
コンプライアンス	誰がどのシークレットにアクセスしたか不明	CloudTrail でアクセス証跡、PCI DSS・HIPAA・SOC 2 対応
DR・災害復旧	別リージョンでシークレット手動複製	Cross-Region Replication で自動複製、フェイルオーバー容易
マイクロサービス連携	各サービスが独立したシークレット管理	Secrets Manager + OIDC で統一認証、Service-to-Service 連携

主な特徴

特徴	説明
KMS 暗号化	AWS KMS カスタマーマネージドキーで保存時の暗号化（FIPS 140-2 対応）
自動ローテーション	Lambda ローテーター関数で定期的に自動更新、アプリ再起動不要
RDS・Redshift・DocumentDB ネイティブ対応	AWS が提供するローテーター Lambda で DB ユーザーパスワード自動更新
バージョニング	AWSCURRENT（現在）/ AWSPENDING（待機）/ AWSPREVIOUS（前）のバージョン管理
クロスリージョンレプリケーション	シークレットを自動複製、DR・障害時のフェイルオーバー対応
IAM ベースアクセス制御	IAM Policy + Resource Policy で最小権限の原則を実装
CloudTrail 監査ログ	全シークレット GetSecretValue アクセスをログ、コンプライアンス対応
VPC Endpoint（PrivateLink）	プライベートサブネットから Secrets Manager へ、インターネット経由なし
複数データ型対応	RDS 認証情報、API キー、OAuth トークン、SSH キー、カスタム JSON 対応
RESTful API / CLI / SDK	自動化・統合が容易、複数言語対応（Python、Java、Go、Node.js 等）

アーキテクチャ

初心者向けメモ： Secrets Manager は 4 層構造です。アプリケーションが IAM 権限を持つ場合、GetSecretValue API でシークレットを取得→KMS が復号化→アプリへ返却。ローテーション時は Lambda が DB パスワードを更新→Secrets Manager に新値を保存。「Secrets Manager が管理するのはシークレット本体とアクセス権、実際の使用方法はアプリ次第」というのが重要です。

【図2】Secrets Manager の多層アーキテクチャ：

graph TD
    subgraph Apps["アプリケーション層"]
        EC2["EC2/On-Prem"]
        Lambda["Lambda"]
        ECS["ECS/Fargate"]
        EKS["Kubernetes/EKS"]
    end
    
    subgraph Access["アクセス制御層"]
        IAMPolicy["IAM Policy<br/>GetSecretValue"]
        ResourcePolicy["Resource Policy<br/>Cross-Account"]
        VPCEndpoint["VPC Endpoint<br/>PrivateLink"]
    end
    
    subgraph Core["Secrets Manager コア"]
        Storage["Secret Storage<br/>暗号化保存"]
        Versioning["Version Manager<br/>AWSCURRENT/PENDING"]
        Rotation["Rotation Engine<br/>Lambda Trigger"]
    end
    
    subgraph Encryption["暗号化・監査層"]
        KMS["AWS KMS<br/>Customer Managed Key"]
        CloudTrail["CloudTrail<br/>Access Audit"]
    end
    
    subgraph Replica["DR・レプリケーション"]
        Primary["Primary Region"]
        Secondary["Secondary Region<br/>Read-Only Replica"]
    end
    
    Apps -->|GetSecretValue| Access
    Access -->|認可確認| Core
    Core -->|暗号化/復号化| KMS
    Core -->|ログ記録| CloudTrail
    Core -->|自動ローテーション| Rotation
    Rotation -->|RDS更新| DB[(RDS/Redshift<br/>Database)]
    Primary -->|自動複製| Secondary

アーキテクチャの主要コンポーネント

1. Secret Storage（シークレット保管）

Secrets Manager はマネージドサービスで、AWS インフラ上で暗号化して保管。ユーザーは直接ストレージにアクセスしない。

保存形式：

JSON キーバリュー： RDS 認証情報、API キー等を JSON で保存
文字列： カスタムシークレット、SSH キー、トークン等

サイズ制限：

最大 65,536 バイト / シークレット
十分に大きく、証明書チェーン・プライベートキー等を保存可能

2. Encryption（暗号化）

AWS KMS 統合：

Secrets Manager が KMS にデータを送信
  ↓
KMS が Data Key を生成・管理
  ↓
シークレットを暗号化して保存
  ↓
GetSecretValue API → KMS で復号化 → アプリへ返却

キーの選択：

AWS Managed Key： alias/aws/secretsmanager（デフォルト、無料）
Customer Managed Key： 独自ポリシーで制御（推奨・本番環境）

3. Versioning（バージョニング）

新しいシークレット作成
  ↓
AWSPENDING（待機状態）
  ↓
テスト・検証
  ↓
AWSCURRENT に昇格（現在の値）
  ↓
AWSPREVIOUS（前のバージョン・ロールバック用）

用途：

ローテーション時の段階的切り替え
問題発生時のロールバック
バージョン履歴の追跡

4. Rotation（自動ローテーション）

1. createSecret：新しいシークレット生成（AWSPENDING）
  ↓
2. setSecret：DB/外部サービスに新シークレット適用
  ↓
3. testSecret：新シークレットで接続テスト
  ↓
4. finishSecret：AWSPENDING → AWSCURRENT 昇格

ローテータ Lambda が実行

AWS 提供ローテーター：RDS、Redshift、DocumentDB、MongoDB Atlas
カスタムローテーター：API キー、外部 DB（PostgreSQL on EC2 等）

Secret タイプ

1. RDS Database Credentials（RDS 認証情報）

対応 DB エンジン：

MySQL
PostgreSQL
MariaDB
Oracle
SQL Server
Aurora（MySQL / PostgreSQL）

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "mysql",
  "host": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com",
  "port": 3306,
  "dbname": "mydb",
  "dbClusterIdentifier": "mydb-cluster"
}

自動ローテーション： ✅ AWS が提供する Lambda ローテーター使用

用途： EC2 アプリ、Lambda、ECS から RDS へのアクセス

2. Redshift Credentials（Redshift 認証情報）

対応バージョン： Redshift Serverless を含む全バージョン

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "redshift",
  "host": "mycluster.xxxx.redshift.amazonaws.com",
  "port": 5439,
  "dbname": "dev"
}

自動ローテーション： ✅ AWS 提供ローテーター使用

3. DocumentDB Credentials（DocumentDB 認証情報）

対応バージョン： DocumentDB（MongoDB 互換）

保存フォーマット：

{
  "username": "admin",
  "password": "GeneratedPassword123!",
  "engine": "docdb",
  "host": "mydb-cluster.xxxx.docdb.amazonaws.com",
  "port": 27017,
  "dbname": "mydb"
}

自動ローテーション： ✅ AWS 提供ローテーター使用

4. API Key / OAuth Token（API キー・OAuth トークン）

一般的なサービス：

Stripe API Key
Twilio Token
Slack Bot Token
GitHub Personal Access Token
汎用 HTTP API キー

保存フォーマット（JSON）：

{
  "api_key": "sk-abc123defghi...",
  "api_endpoint": "https://api.stripe.com",
  "api_version": "2024-04-01",
  "expiry_date": "2026-12-31"
}

保存フォーマット（文字列）：

sk-abc123defghi…

自動ローテーション： ❌ カスタム Lambda ローテーター必須（API が rotate/revoke メソッドをサポートしている場合）

5. SSH Key（SSH 秘密鍵）

用途：

EC2 インスタンスへの SSH キー
GitHub Deploy Key
外部サーバーへのアクセスキー

保存フォーマット：

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA2a2rwplBCc…
…
-----END RSA PRIVATE KEY-----

自動ローテーション： ❌ キーローテーション時には新キーペア生成が必要

6. Custom Secrets（カスタムシークレット）

自由形式のシークレット。任意の JSON または文字列を保存可能。

例：

{
  "db_password": "xxx",
  "api_token": "yyy",
  "encryption_key": "zzz",
  "certificate": "-----BEGIN CERTIFICATE-----..."
}

自動ローテーション： ❌ カスタム Lambda ローテーター実装

主要ユースケース

初心者向けメモ： Secrets Manager は「データベース認証情報管理」のイメージが強いですが、API キー・OAuth トークン・SSH キー・カスタムシークレットなど幅広い用途があります。ここでは実務でよくある 10+ のユースケースを整理します。

1. RDS Database Credentials（最も典型）

EC2 / Lambda / ECS アプリケーションが RDS に接続する際のパスワード管理。

パターン：

App 起動
  ↓
Secrets Manager から DB パスワード取得（IAM ロール認可）
  ↓
RDS に接続
  ↓
30 日ごとに自動ローテーション（アプリ再起動不要）

利点：

✅ ハードコード廃止
✅ 定期的な自動ローテーション
✅ パスワード漏洩時の迅速な対応
✅ CloudTrail でアクセス監査

2. API Key Management（API キー管理）

Third-party API（Stripe、Twilio、SendGrid など）のキー一元管理。

パターン：

複数の API キー
  ↓
Secrets Manager で一元保管
  ↓
IAM ロールでサービスごとのアクセス権制御
  ↓
ローテーション時にキー無効化・再生成

利点：

✅ キー漏洩リスク低減
✅ チームによるキー管理の一元化
✅ キー有効期限の管理

3. OAuth / JWT Token Management

GitHub、GitLab、OIDC、Okta などのシングルサインオン・フェデレーション認証の token 管理。

用途：

GitHub Actions での認証
Terraform Cloud との連携
Kubernetes クラスタの OIDC provider トークン
マイクロサービス間の Service-to-Service 認証

4. SSH Key Management

EC2 キーペア、GitHub Deploy Key、外部サーバーへのアクセスキー。

パターン：

EC2 インスタンスへの SSH キー
  ↓
Secrets Manager で一元保管
  ↓
Infrastructure as Code（Terraform 等）で自動配布
  ↓
キーローテーション時に新キー生成

利点：

✅ キーを環境変数・設定ファイルに保存しない
✅ 複数サーバーでの統一管理

5. CI/CD Secret Management（CodeBuild、GitHub Actions）

ビルド・デプロイパイプラインで必要なシークレット管理。

パターン：

GitHub Actions
  ↓
OIDC で AWS に認証
  ↓
IAM ロール経由で Secrets Manager にアクセス
  ↓
API キー・DB パスワード取得
  ↓
デプロイ実行

利点：

✅ GitHub Secrets に hardcode しない
✅ 複数リポジトリで統一管理
✅ OIDC で credential なし認証

6. Kubernetes（EKS）External Secrets Operator（ESO）

EKS ポッドから Secrets Manager のシークレットを自動マウント。

パターン：

K8s Pod
  ↓
External Secrets Operator
  ↓
Secrets Manager から取得
  ↓
K8s Secret として自動同期

利点：

✅ K8s Secret に hardcode しない
✅ 自動ローテーション対応
✅ 複数ポッドでの統一管理

7. IoT Certificate Management

IoT デバイスの X.509 証明書・秘密鍵保管。

用途：

AWS IoT Core デバイス認証
mTLS 通信のクライアント証明書

8. Lambda Environment Variable 代替

Lambda 環境変数に秘密情報を保存しない方法。

パターン：

Lambda 関数
  ↓
GetSecretValue で Secrets Manager からデータ取得
  ↓
環境変数を使わないゼロシークレット設計

利点：

✅ Lambda コンソール UI に秘密が表示されない
✅ コンテナイメージにシークレット埋め込まない

9. RDS Proxy Authentication

Amazon RDS Proxy（コネクションプーリング）のデータベース認証。

パターン：

アプリ
  ↓
RDS Proxy（IAM DB Auth またはパスワード）
  ↓
RDS Proxy が Secrets Manager からパスワード取得
  ↓
バックエンド RDS に接続

利点：

✅ アプリ側でパスワード管理不要
✅ RDS Proxy が自動ローテーション対応

10. ElastiCache、MemoryDB Credentials

Redis、Memcached のアクセス認証情報。

用途：

ElastiCache for Redis（AUTH パスワード）
MemoryDB for Redis（ユーザー認証）

11. Container Registry Authentication

Amazon ECR、Docker Hub、GitHub Container Registry のログイン認証。

用途：

ECS / Fargate でのイメージプル認証
CI/CD パイプラインでのイメージプッシュ

12. Third-Party SaaS Credentials

Datadog、New Relic、Sumo Logic、PagerDuty などのアカウント認証。

用途：

API キーの安全な保管
スクリプト・ラムダ関数からのプログラマティックアクセス

シークレットローテーション

ローテーションの目的

初心者向けメモ： シークレットローテーションは「定期的にパスワードやキーを更新し、漏洩リスクを低減する」セキュリティプラクティスです。Secrets Manager の自動ローテーション機能により、アプリケーション再起動なしに 新しい認証情報に切り替わります。

ローテーション実行の流れ：

ローテーションスケジュール（例：30 日）
  ↓
CloudWatch Events（EventBridge）が Secrets Manager トリガー
  ↓
Secrets Manager が Lambda ローテーター関数を呼び出し
  ↓
Lambda 処理：
    1. createSecret：新しいシークレット生成（AWSPENDING 状態）
    2. setSecret：DB/外部サービスに新シークレット適用
    3. testSecret：新シークレットで接続テスト
    4. finishSecret：AWSPENDING → AWSCURRENT 昇格
  ↓
アプリケーションは次回 GetSecretValue 呼び出し時に新値取得

AWS 提供ローテーター（RDS・Redshift・DocumentDB）

対応サービス：

✅ RDS（MySQL、PostgreSQL、Oracle、SQL Server、MariaDB、Aurora）
✅ Redshift
✅ DocumentDB（MongoDB 互換）

ローテーター Lambda 自動提供： AWS が提供する Lambda レイヤーにローテーション関数が含まれており、ユーザーは DB 接続設定とローテーション Lambda を Secrets Manager に登録するだけで動作。

設定例：

シークレット → Rotation タブ → Enable rotation
  ↓
Lambda function: SecretsManagerRDSMysqlRotation
  ↓
Rotation interval: 30 days
  ↓
VPC（DB にアクセス可能なセキュリティグループ）

カスタムローテーター（API キー・外部 DB）

API キーやサードパーティシステムのローテーション時には、カスタム Lambda 関数を実装。

実装例（Stripe API キーローテーション）：

import boto3
import json
import requests

def lambda_handler(event, context):
    secrets_manager = boto3.client('secretsmanager')
    secret_id = event['ClientRequestToken']
    
    metadata = secrets_manager.describe_secret(SecretId=secret_id)
    
    if not metadata['RotationEnabled']:
        raise ValueError("Secret rotation is not enabled")
    
    # 1. createSecret：新キー生成
    if event['Step'] == 'createSecret':
        # Stripe API で新キー生成（仮想例）
        new_key = generate_new_stripe_key()
        secrets_manager.put_secret_value(
            SecretId=secret_id,
            ClientRequestToken=event['ClientRequestToken'],
            SecretString=json.dumps({'api_key': new_key}),
            VersionStages=['AWSPENDING']
        )
    
    # 2. setSecret：新キーを本番環境に適用
    elif event['Step'] == 'setSecret':
        pending_secret = secrets_manager.get_secret_value(
            SecretId=secret_id,
            VersionId=event['ClientRequestToken'],
            VersionStage='AWSPENDING'
        )
        new_key = json.loads(pending_secret['SecretString'])['api_key']
        update_environment_variable('STRIPE_API_KEY', new_key)
    
    # 3. testSecret：新キーで接続テスト
    elif event['Step'] == 'testSecret':
        pending_secret = secrets_manager.get_secret_value(
            SecretId=secret_id,
            VersionId=event['ClientRequestToken'],
            VersionStage='AWSPENDING'
        )
        new_key = json.loads(pending_secret['SecretString'])['api_key']
        response = requests.post(
            'https://api.stripe.com/v1/account',
            auth=('', new_key)
        )
        if response.status_code != 200:
            raise Exception("New API key test failed")
    
    # 4. finishSecret：AWSPENDING → AWSCURRENT
    elif event['Step'] == 'finishSecret':
        secrets_manager.update_secret_version_stage(
            SecretId=secret_id,
            VersionStage='AWSCURRENT',
            MoveToVersionId=event['ClientRequestToken'],
            RemoveFromVersionId=metadata['VersionIdsToStages'].keys()[0]
        )

RDS・Redshift・DocumentDB 自動ローテーション

RDS 自動ローテーション（最も一般的）

対応 DB エンジン：

MySQL 5.7, 8.0+
PostgreSQL 9.6+
MariaDB 10.1+
Oracle 12c+
SQL Server 2016+
Aurora（MySQL/PostgreSQL 互換）

ローテーション動作：

1. DB 管理者ユーザーで新パスワード生成
2. RDS API で DB ユーザーパスワード更新（ALTER USER...）
3. 新パスワードを AWSPENDING として保存
4. 接続テスト実行
5. AWSCURRENT に昇格

アプリケーションへの影響：

❌ アプリ再起動不要
✅ アクティブな DB 接続：ローテーション後に自動切断
✅ コネクションプール：次の接続時に新パスワードで再接続

Redshift 自動ローテーション

Redshift クラスタ管理者ユーザーで新パスワード生成
ALTER USER で Redshift ユーザーパスワード更新
テスト接続確認
AWSCURRENT に昇格

注意点：

✅ Redshift Serverless 対応
❌ Redshift 復旧時はマスターユーザーのみローテーション対応

DocumentDB 自動ローテーション

DocumentDB クラスタマスターユーザーで新パスワード生成
db.updateUser() で DocumentDB ユーザーパスワード更新
MongoDB 互換接続テスト
AWSCURRENT に昇格

バージョニング

初心者向けメモ： Secrets Manager のバージョニングは「シークレットの履歴管理と段階的ローテーション」を実現します。AWSCURRENT（現在使用）、AWSPENDING（待機中）、AWSPREVIOUS（前版）の 3 つの状態があります。

バージョンステージ

ステージ	説明	用途
AWSCURRENT	現在アプリが使用しているシークレット	GetSecretValue で取得される値
AWSPENDING	ローテーション待機中の新シークレット	ローテーション中の段階確認
AWSPREVIOUS	前のシークレット（ロールバック用）	問題発生時の復旧
Custom	ユーザー定義ステージ	複数バージョン同時利用時

ローテーション時のバージョン遷移

初期状態：
  v1 → AWSCURRENT（アプリ使用中）
  v2 → AWSPREVIOUS（前版）

ローテーション開始：
  v1 → AWSCURRENT（アプリ使用中）
  v2 → AWSPREVIOUS
  v3 → AWSPENDING（新バージョン、ローテーション中）

テスト実行中：
  v3 を新しい設定で検証
  DB パスワード確認、接続テスト実行

ローテーション完了：
  v1 → AWSPREVIOUS（ロールバック用）
  v3 → AWSCURRENT（新規使用）
  v2 → （削除されます）

ロールバック

問題が発生した場合、前のバージョンに戻す：

# AWS CLI で手動ロールバック
aws secretsmanager update-secret-version-stage \
  --secret-id MyDatabaseSecret \
  --version-stage AWSCURRENT \
  --move-to-version-id <PREVIOUS_VERSION_ID> \
  --remove-from-version-id <CURRENT_VERSION_ID>

レプリケーション（クロスリージョン）

目的

Secrets Manager のシークレットを複数リージョンに自動複製。災害復旧（DR）、高可用性、グローバル展開に対応。

パターン：

Primary Region（us-east-1）
  └─ シークレット作成・管理
      ↓ 自動複製
  
Replica Region 1（eu-west-1）
  └─ Read-only replica
      
Replica Region 2（ap-northeast-1）
  └─ Read-only replica

レプリケーション設定

# プライマリでレプリケーション有効化
aws secretsmanager replicate-secret-to-regions \
  --secret-id MySecret \
  --add-replica-regions RegionCode=eu-west-1 RegionCode=ap-northeast-1

フェイルオーバー

Primary リージョンが障害時、Replica リージョンを昇格：

# Replica を新プライマリに昇格
aws secretsmanager update-secret \
  --secret-id MySecret \
  --replica-region-primary RegionCode=eu-west-1

利点

✅ DR：別リージョンでシークレット即座利用可能
✅ レイテンシ削減：ローカルリージョンから GetSecretValue
✅ 自動同期：新ローテーション時に全リージョンへ自動複製
✅ コスト最適化：Replica は読み取り専用で低コスト

VPC Endpoint（PrivateLink）

目的

プライベートサブネットの EC2 / Lambda / ECS から、インターネット経由なしで Secrets Manager にアクセス。

従来（インターネット経由）：

Private Subnet EC2
↓ Internet Gateway（VPN/NAT）
Secrets Manager（API Gateway）

VPC Endpoint（推奨）：

Private Subnet EC2
↓ VPC Endpoint（PrivateLink）
Secrets Manager（AWS ネットワーク内）

VPC Endpoint 設定

# Interface Endpoint 作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-northeast-1.secretsmanager \
  --subnet-ids subnet-xxxxx subnet-yyyyy \
  --security-group-ids sg-xxxxx

セキュリティグループ設定

Inbound Rule:
Protocol: TCP
Port: 443
Source: Private Subnet CIDR（10.0.0.0/16）

利点

✅ インターネット経由なし（より安全）
✅ AWS ネットワーク内で低レイテンシ
✅ NAT Gateway コスト削減
✅ FIPS 140-2 環境対応

セキュリティ（KMS・IAM・ResourcePolicy）

1. KMS 暗号化

デフォルト設定：

AWS Managed Key（alias/aws/secretsmanager）
無料・AWS が鍵ローテーション管理

本番推奨：

Customer Managed Key（ユーザー作成）
カスタム Policy で暗号化キーへのアクセス制御
監査ログ細粒度管理

設定例：

# Customer Managed Key 作成
aws kms create-key \
  --description "Secrets Manager encryption key" \
  --key-policy <POLICY_JSON>

# シークレット作成時に CMK 指定
aws secretsmanager create-secret \
  --name MySecret \
  --secret-string '{"password":"secret"}' \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx

2. IAM Policy（アクセス制御）

ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx"
    }
  ]
}

ベストプラクティス：

✅ Resource ARN にワイルドカード（secret:MyDbSecret-*）で複数バージョン対応
✅ KMS Decrypt アクションをセットで許可
✅ 最小権限：必要なシークレットのみアクセス許可

3. Resource Policy（クロスアカウント）

複数の AWS アカウント間でシークレット共有。

ポリシー例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999999:role/AppRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

用途：

マイクロサービスアーキテクチャ（別 AWS アカウント）での統一 DB 認証情報共有
マルチアカウント環境での API キー一元管理

4. CloudTrail 監査ログ

ログに記録されるイベント：

CreateSecret
DeleteSecret
UpdateSecret
GetSecretValue ← 重要：誰がいつシークレットを取得したか
RotateSecret
ReplicateSecretToRegions

CloudTrail 設定確認：

# CloudTrail でシークレット API ログ確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=AWS::SecretsManager::Secret \
  --max-results 50

コンプライアンス対応：

✅ PCI DSS：全シークレットアクセスをログに記録
✅ HIPAA：Protected Health Information（PHI）アクセス監査
✅ SOC 2：アクセス制御・監査ログ要件満たし

ECS・EKS・Lambda 連携

1. ECS Task（Fargate）でのシークレット利用

パターン：

ECS Task Definition
  ↓
Environment Variables：Secrets Manager の ARN 指定
  ↓
ECS Agent が GetSecretValue でシークレット取得
  ↓
コンテナに環境変数として注入

Task Definition 設定例：

{
  "family": "my-app",
  "containerDefinitions": [
    {
      "name": "app-container",
      "image": "myapp:latest",
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-xxxxx:password::"
        }
      ],
      "environment": [
        {
          "name": "DB_HOST",
          "value": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"
        }
      ]
    }
  ],
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}

IAM ロール権限：

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
}

2. Kubernetes（EKS）External Secrets Operator

EKS ポッドから Secrets Manager のシークレットを自動同期。

インストール：

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets -n external-secrets-system --create-namespace

SecretStore 定義：

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets-manager
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-northeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa

ExternalSecret 定義：

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-secret-k8s
    creationPolicy: Owner
  data:
  - secretKey: password
    remoteRef:
      key: MyDatabaseSecret
      property: password

Pod での利用：

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  serviceAccountName: app-sa
  containers:
  - name: app
    image: myapp:latest
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret-k8s
          key: password

3. Lambda 関数での GetSecretValue

Python 例：

import boto3
import json

secrets_client = boto3.client('secretsmanager', region_name='ap-northeast-1')

def lambda_handler(event, context):
    try:
        # Secrets Manager からシークレット取得
        response = secrets_client.get_secret_value(
            SecretId='MyDatabaseSecret'
        )
        
        # JSON パース（RDS 認証情報の場合）
        if 'SecretString' in response:
            secret = json.loads(response['SecretString'])
            username = secret['username']
            password = secret['password']
            host = secret['host']
        
        # DB 接続
        import pymysql
        conn = pymysql.connect(
            host=host,
            user=username,
            password=password,
            database='mydb'
        )
        
        return {'statusCode': 200, 'body': 'Connected'}
    
    except Exception as e:
        return {'statusCode': 500, 'body': str(e)}

Lambda IAM ロール権限：

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*"
}

4. Lambda キャッシングライブラリ

GetSecretValue API は遅延・コスト発生。キャッシング推奨。

AWS Secrets Manager キャッシュライブラリ（公式）：

from aws_secretsmanager_caching import SecretCache

cache = SecretCache()

def lambda_handler(event, context):
    # キャッシュから取得（初回は API、以降はメモリ）
    secret = cache.get_secret_string('MyDatabaseSecret')
    
    # パスワード利用
    import json
    creds = json.loads(secret)
    return {'password': creds['password']}

メリット：

✅ API 呼び出し削減（コスト削減）
✅ レイテンシ低減
✅ TTL キャッシュで自動ローテーション対応

Cost Optimization

1. 価格体系

項目	価格
シークレット保管	$0.40 / シークレット / 月
API 呼び出し	$0.05 / 10,000 呼び出し
レプリケーション	$0.40 / レプリカ / 月

例：

シークレット 10 個 × $0.40 = $4.00 / 月
API 呼び出し 100 万回 × $0.05 / 10,000 = $5.00 / 月
Total: 月 $9.00

2. コスト削減戦略

A. Batch GetSecretValue API（2024 年新機能）

複数シークレットを1つの API 呼び出しで取得。

import boto3

client = boto3.client('secretsmanager')

# 複数シークレット一括取得
response = client.batch_get_secret_value(
    SecretIds=['Secret1', 'Secret2', 'Secret3']
)

for secret in response['Secrets']:
    print(secret['Name'], secret['SecretString'])

コスト削減効果：

従来：3 つのシークレット取得 → 3 × $0.05 / 10,000 = $0.00015 / 回
Batch：1 回で 3 つ取得 → 1 × $0.05 / 10,000 = $0.000050 / 回
削減：66% コスト削減

B. Lambda キャッシング

GetSecretValue のキャッシュで API 削減。

100 万回呼び出し
  ↓
キャッシュ 95%
  ↓
実際の API：50,000 回
  ↓
コスト：$0.25 / 月（従来 $5.00）

C. Parameter Store との使い分け

DB 認証情報・API キー → Secrets Manager
（自動ローテーション、KMS 標準）
設定値・ARN・環境値 → Parameter Store
（低コスト、小さいデータ）

3. 一般的なコスト

スタートアップ（シークレット 5～10 個、API 100k/月）
  → 月 $2～3

中規模組織（シークレット 50 個、API 1M/月、レプリケーション 2 リージョン）
  → 月 $30～40

エンタープライズ（シークレット 500 個、API 10M/月、レプリケーション 5 リージョン）
  → 月 $300～500

Parameter Store vs Secrets Manager 使い分け

初心者向けメモ： AWS には 2 つのシークレット管理サービスがあります。DB パスワード・API キーは Secrets Manager、設定値・ARN は Parameter Store が最適です。

観点	Secrets Manager	Parameter Store
目的	秘密情報・認証情報	設定値・パラメータ
自動ローテーション	✅（Lambda 関数）	❌（手動、スケジュール困難）
RDS・Redshift 対応	✅（ネイティブ）	❌（手動実装必要）
暗号化	✅（KMS デフォルト）	✅（SecureString で可）
最大サイズ	65,536 バイト	8 KB（Standard）/ 4 KB（Advanced）
バージョニング	✅（AWSCURRENT / PENDING）	✅（手動管理）
クロスアカウント	✅（Resource Policy）	❌（限定的）
価格	`0.40/シークレット/月 + API 課金	無料（Standard）/ `0.05/月（Advanced SecureString）
用途例	DB password, API key, OAuth token	App version, Deployment region, Feature flag

決定フロー：

シークレット？
  ├─ Yes（DB password、API key、OAuth token）
  │   └─ Secrets Manager
  │       （自動ローテーション機能あり）
  │
  └─ No（設定値、ARN、リージョン情報）
      └─ Parameter Store
          （コスト最適、小さいデータ）

他の類似ツールとの比較

Secrets Manager vs HashiCorp Vault

項目	AWS Secrets Manager	HashiCorp Vault
デプロイ形態	フルマネージド（SaaS）	Self-hosted / Vault Cloud
セットアップ複雑度	低（AWS コンソール）	高（インフラ構築、HA 構成等）
自動ローテーション	✅（Lambda ベース）	✅（Vault Agent）
動的シークレット	❌（Database のみ）	✅（Database、Cloud IAM、SSH）
PKI・CA	❌	✅（完全対応）
マルチテナント	❌	✅（Enterprise Namespace）
マルチクラウド	❌（AWS のみ）	✅（Any cloud）
エコシステム	AWS ネイティブ（IAM、KMS、CloudTrail）	HashiCorp スタック（Terraform、Boundary）
推奨	AWS 完結、シンプル構成	マルチクラウド、高度な要件

Secrets Manager vs Azure Key Vault

項目	AWS Secrets Manager	Azure Key Vault
プロバイダ	Amazon	Microsoft
マネージド方式	✅ フルマネージド	✅ フルマネージド
自動ローテーション	✅	✅
キー管理	KMS（基盤）	Key Vault（専門）
証明書	❌	✅（Let’s Encrypt 統合）
マルチテナント	❌	❌
クロスリージョン	✅（Replication）	✅（Geo-redundancy）
推奨	AWS メインクラウド	Azure メインクラウド

Secrets Manager vs GCP Secret Manager

項目	AWS Secrets Manager	GCP Secret Manager
マネージド方式	✅	✅
自動ローテーション	✅（Lambda）	❌（Cloud Functions で実装必要）
暗号化	KMS	Cloud KMS
レプリケーション	✅	✅（自動）
IAM 統合	✅	✅
推奨	AWS 環境	GCP 環境

Secrets Manager vs 1Password / Doppler

項目	AWS Secrets Manager	1Password / Doppler
用途	アプリケーション・インフラ	チーム・開発者シークレット
UI	AWS コンソール（管理向け）	Web UI（開発者向け）
ローテーション	✅（自動）	△（限定的）
企業向け	✅（エンタープライズ）	△（スタートアップ向け）
推奨	本番環境・大規模組織	小規模チーム・開発環境

クライアント・エコシステム

1. AWS CLI

# シークレット取得
aws secretsmanager get-secret-value \
  --secret-id MyDatabaseSecret \
  --region ap-northeast-1

# シークレット作成
aws secretsmanager create-secret \
  --name MyAPIKey \
  --secret-string '{"api_key":"sk-abc123..."}' \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx

# ローテーション有効化
aws secretsmanager rotate-secret \
  --secret-id MyDatabaseSecret \
  --rotation-lambda-arn arn:aws:lambda:ap-northeast-1:123456789012:function:SecretsManagerRDSMysqlRotation \
  --rotation-rules DurationSeconds=2592000

2. AWS SDK（複数言語）

Python（boto3）：

import boto3

client = boto3.client('secretsmanager', region_name='ap-northeast-1')
response = client.get_secret_value(SecretId='MyDatabaseSecret')
print(response['SecretString'])

Node.js：

const AWS = require('aws-sdk');
const client = new AWS.SecretsManager({ region: 'ap-northeast-1' });

client.getSecretValue({ SecretId: 'MyDatabaseSecret' }, (err, data) => {
  if (err) console.log(err);
  else console.log(data.SecretString);
});

Java：

import software.amazon.awssdk.services.secretsmanager.SecretsManagerClient;
import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest;
import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueResponse;

SecretsManagerClient client = SecretsManagerClient.builder().region(Region.AP_NORTHEAST_1).build();
GetSecretValueResponse response = client.getSecretValue(
    GetSecretValueRequest.builder().secretId("MyDatabaseSecret").build()
);
System.out.println(response.secretString());

3. Terraform

# Secrets Manager シークレット作成
resource "aws_secretsmanager_secret" "db_secret" {
  name       = "mydb-secret"
  kms_key_id = aws_kms_key.secrets_key.id
}

# シークレット値設定
resource "aws_secretsmanager_secret_version" "db_secret_version" {
  secret_id = aws_secretsmanager_secret.db_secret.id
  secret_string = jsonencode({
    username = "admin"
    password = random_password.db_password.result
    engine   = "mysql"
    host     = aws_db_instance.mydb.endpoint
    port     = 3306
  })
}

# ローテーション設定
resource "aws_secretsmanager_secret_rotation" "db_rotation" {
  secret_id           = aws_secretsmanager_secret.db_secret.id
  rotation_enabled    = true
  rotation_lambda_arn = aws_lambda_function.rotation.arn
  rotation_rules {
    automatically_after_days = 30
  }
}

4. AWS CloudFormation

AWSTemplateFormatVersion: '2010-09-09'

Resources:
  MyDatabaseSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      Name: mydb-secret
      KmsKeyId: !GetAtt SecretsKey.Arn
      SecretString: |
        {
          "username": "admin",
          "password": "InitialPassword123!",
          "engine": "mysql",
          "host": "mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"
        }
  
  SecretRotation:
    Type: AWS::SecretsManager::RotationSchedule
    Properties:
      SecretId: !Ref MyDatabaseSecret
      RotationLambdaARN: arn:aws:lambda:ap-northeast-1:123456789012:function:SecretsManagerRDSMysqlRotation
      RotationRules:
        DurationSeconds: 7200
        Frequency:
          Duration: 30
          Unit: DAYS

5. External Secrets Operator（Kubernetes）

前述の「EKS 連携」セクション参照。

6. コンテナイメージ拡張

ECS / Fargate でのシークレット注入は、ECS Agent が自動実行。追加ライブラリ不要。

ベストプラクティス

1. 最小権限の原則

{
  "Effect": "Allow",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MyDatabaseSecret-*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "10.0.0.0/8"
    }
  }
}

✅ DO：

必要なシークレットのみアクセス許可
IP 制限・VPC エンドポイント経由に限定
IAM ロールは時間制限付き

❌ DON’T：

Root ユーザーに GetSecretValue 許可
全 ARN（*）に権限付与
Policy ポリシーで細粒度制御なし

2. 自動ローテーション戦略

高頻度（API キー）：7～30 日
  ↓
中頻度（DB パスワード）：30～90 日
  ↓
低頻度（SSH キー）：90～365 日

テスト環境：

ローテーション無効にして開発効率向上
本番移行時のみ有効化

3. ローテーション Lambda の VPC 設定

Lambda が以下にアクセス可能か確認：
✅ RDS / Redshift（DB セキュリティグループ）
✅ Secrets Manager（VPC Endpoint または NAT Gateway）

セキュリティグループ設定：

ローテーション Lambda SG：
Outbound → RDS SG Port 3306（MySQL）
Outbound → NAT Gateway または VPC Endpoint

4. クロスアカウント設定

マイクロサービスがシークレット共有時：

Account A（Secrets Manager 管理）
  └─ Resource Policy で Account B のロール許可

Account B（アプリケーション実行）
  └─ IAM Policy で Account A のシークレット GetSecretValue

5. KMS キーポリシー

{
  "Sid": "AllowSecretsManagerToUse",
  "Effect": "Allow",
  "Principal": {
    "Service": "secretsmanager.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

6. バージョン管理・GitOps

Terraform + Git でシークレット管理：

# git では encrypted 値のみコミット
resource "aws_secretsmanager_secret" "example" {
  name = "myapp-secret"
}

# 実際の値は terraform.tfvars（.gitignore）または Vault で管理
resource "aws_secretsmanager_secret_version" "example" {
  secret_id     = aws_secretsmanager_secret.example.id
  secret_string = var.secret_value  # 環境変数から注入
}

7. 監査・コンプライアンス

# CloudTrail で GetSecretValue ログ確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
  --max-results 100 \
  --output json | jq '.Events[] | {EventTime, Username, EventName, Resources}'

CloudWatch ログ集約：

CloudTrail → CloudWatch Logs → Athena で SQL クエリ

トラブルシューティング

よくある問題と解決策

1. AccessDeniedException: User is not authorized

原因： IAM Policy に GetSecretValue 権限がない

解決：

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:MySecret-*"
}

2. InvalidParameterException: Resource policy is not valid JSON

原因： Resource Policy の JSON 構文エラー

解決：

# JSON バリデーション
aws secretsmanager get-resource-policy --secret-id MySecret | jq .

3. ローテーション失敗：Lambda が DB にアクセスできない

原因： Lambda セキュリティグループが RDS へのアウトバウンドトラフィックをブロック

解決：

Lambda SG：
Outbound rule → RDS SG Port 3306

4. テスト接続失敗：新パスワードが古い設定で利用中

原因： ローテーション中にアプリがまだ古いパスワードを使用

解決：

Lambda キャッシュ TTL を短縮
GetSecretValue を定期呼び出し
コネクションプールを再起動

5. クロスリージョンレプリケーション遅延

原因： Primary リージョンでの更新がレプリカリージョンに数秒遅延

解決：

強力な整合性が必要な場合は Primary リージョンのみアクセス
読み取り専用レプリカは参照用のみ

2025-2026 最新動向

1. AI Secret Scanning（自動検出）

CodeBuild / GitHub Actions でコードの漏洩シークレット自動検出・隔離。

実装例（GitHub Actions）：

- name: AWS Secret Detection
  uses: aws-actions/configure-aws-credentials@v2
  with:
    aws-region: ap-northeast-1
    
- name: Scan for secrets
  run: |
    aws codeartifact list-repositories --domain myco

2. OpenID Connect（OIDC）Integration

GitHub Actions、GitLab CI、Terraform Cloud での認証。

name: Deploy
on: push

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
        aws-region: ap-northeast-1
    
    - name: Get secret
      run: aws secretsmanager get-secret-value --secret-id MySecret

3. Hybrid Environment Support

オンプレミス Vault、HashiCorp との統合。

Hybrid Secret Sync：
AWS Secrets Manager ← → HashiCorp Vault
（クロスプラットフォームローテーション）

4. Cost Optimization Features

Batch GetSecretValue：複数シークレット一括取得で 66% API コスト削減
キャッシング強化：Lambda レイヤーでのディープキャッシング

5. RDS Auto Minor Version Upgrade 連携

RDS 自動パッチ時のローテーション自動調整。

6. DynamoDB・DocumentDB・ElastiCache 拡張

DocumentDB、ElastiCache（Redis・Memcached）のネイティブローテーション対応予定。

学習リソース

公式ドキュメント・リファレンス

実装サンプル

オンライン学習

AWS Skills Builder：Secrets Manager コース
Pluralsight / Udemy：AWS セキュリティ認定向け講座

コミュニティ

実装例・活用シーン

シーン 1：RDS + Lambda + Secrets Manager

import boto3
import json
import pymysql

def lambda_handler(event, context):
    secrets_client = boto3.client('secretsmanager')
    
    # Secrets Manager からシークレット取得
    response = secrets_client.get_secret_value(SecretId='mydb-secret')
    secret = json.loads(response['SecretString'])
    
    # RDS に接続・クエリ実行
    conn = pymysql.connect(
        host=secret['host'],
        user=secret['username'],
        password=secret['password'],
        database=secret['dbname']
    )
    
    cursor = conn.cursor()
    cursor.execute('SELECT * FROM users LIMIT 10')
    result = cursor.fetchall()
    
    conn.close()
    
    return {'statusCode': 200, 'data': result}

シーン 2：ECS Fargate + Secrets Manager

{
  "family": "myapp-task",
  "containerDefinitions": [
    {
      "name": "myapp",
      "image": "myapp:latest",
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:mydb-secret-xxxxx:password::"
        },
        {
          "name": "API_KEY",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:stripe-api-key-xxxxx:api_key::"
        }
      ]
    }
  ],
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}

シーン 3：GitHub Actions + OIDC + Secrets Manager

name: Deploy to AWS

on: push

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    
    - uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
        aws-region: ap-northeast-1
    
    - name: Get deployment secret
      run: |
        SECRET=$(aws secretsmanager get-secret-value --secret-id deploy-key --query SecretString --output text)
        echo "::add-mask::$SECRET"
        echo "DEPLOY_KEY=$SECRET" >> $GITHUB_ENV
    
    - name: Deploy
      run: ./deploy.sh
      env:
        DEPLOY_KEY: ${{ env.DEPLOY_KEY }}

シーン 4：Kubernetes（EKS）+ External Secrets Operator

前述「EKS 連携」セクション参照。

導入ロードマップ

Phase 1：計画・評価（1～2 月）

[ ] セキュリティ要件・コンプライアンス要件確認
[ ] 既存シークレット管理方式の棚卸し
[ ] Secrets Manager vs Parameter Store の用途分類
[ ] PoC 環境構築
[ ] KMS キーポリシー設計
[ ] コスト試算

Phase 2：開発環境構築（2～4 月）

[ ] AWS Secrets Manager 権限設計（IAM ロール）
[ ] 開発用 KMS キー作成
[ ] シークレット作成テンプレート整備
[ ] Lambda ローテーター関数開発（RDS / 外部 DB）
[ ] Local テスト環境でのシークレット取得テスト
[ ] CloudTrail ログ設定

Phase 3：Staging 環境（4～6 月）

[ ] Customer Managed KMS キー作成・Policy 設定
[ ] RDS / Redshift ローテーション設定
[ ] ECS / Lambda での GetSecretValue 実装
[ ] VPC Endpoint 設定
[ ] ローテーション動作確認
[ ] Resource Policy（クロスアカウント）設定・テスト

Phase 4：本番デプロイ（6～8 月）

[ ] 本番 Secrets Manager インスタンス起動
[ ] 既存シークレット段階的マイグレーション
[ ] 運用 Runbook 作成
[ ] 監視・アラート設定（CloudWatch / EventBridge）
[ ] 本番トラブルシューティング演習

Phase 5：最適化・継続運用（8 月以降）

[ ] CloudTrail ログ分析・アクセス監査
[ ] ローテーション失敗の自動復旧
[ ] コスト分析・Batch API 導入検討
[ ] レプリケーション戦略見直し
[ ] チーム教育・ドキュメント更新
[ ] セキュリティレビュー

実装チェックリスト

セットアップ・アクセス制御

[ ] Secrets Manager シークレット作成
[ ] AWS KMS Customer Managed Key 作成・設定
[ ] IAM Policy で GetSecretValue 権限付与
[ ] VPC Endpoint（PrivateLink）設定
[ ] Resource Policy でクロスアカウント権限設定

自動ローテーション

[ ] Lambda ローテーター関数デプロイ
[ ] ローテーションスケジュール設定（RDS: 30 日等）
[ ] ローテーション失敗時の Lambda Dead Letter Queue 設定
[ ] ローテーション Lambda の VPC セキュリティグループ設定

アプリケーション統合

[ ] Lambda / ECS での GetSecretValue 実装
[ ] EKS（External Secrets Operator）設定
[ ] Secrets Manager キャッシュライブラリ導入
[ ] Batch API 活用検討

監視・監査

[ ] CloudTrail で Secrets Manager ログ有効化
[ ] CloudWatch Logs グループ作成・集約
[ ] GetSecretValue 監視アラート設定
[ ] 定期的なアクセスログレビュー

セキュリティ・コンプライアンス

[ ] 最小権限 Policy 設計・監査
[ ] キーローテーション Policy 設定
[ ] PCI DSS / HIPAA コンプライアンス対応確認
[ ] 定期セキュリティレビュー

まとめ

AWS Secrets Manager は 「シークレットの保存・取得・自動ローテーションを統合管理する、AWS ネイティブなマネージドサービス」 です。

何ができるか

✅ RDS・Redshift・DocumentDB の自動ローテーション
✅ API キー・OAuth トークン・SSH キーの一元管理
✅ IAM + KMS による細粒度アクセス制御
✅ CloudTrail による監査ログ・コンプライアンス対応
✅ クロスリージョンレプリケーション（DR 対応）
✅ VPC PrivateLink でのセキュアアクセス
✅ ECS・EKS・Lambda と統合

導入のポイント

シークレット分類：DB パスワード（Secrets Manager） vs 設定値（Parameter Store）
自動ローテーション：30～90 日ごとに自動更新、ドリフト防止
KMS 統合：Customer Managed Key で暗号化・監査
IAM Policy：最小権限、Resource Policy でクロスアカウント対応
キャッシング：Lambda キャッシュで API コスト・レイテンシ最適化

2025-2026 の展望

OpenID Connect（OIDC）統合で GitHub Actions・Terraform Cloud 認証強化
AI Secret Scanning で漏洩シークレット自動検出
Batch GetSecretValue で API コスト 66% 削減
Hybrid Environment Support でオンプレミス Vault 連携

参考文献

公式ドキュメント

ツール・ライブラリ

ベストプラクティス・ブログ

2025-2026 最新参考文献

Cross-Region Replication in Secrets Manager - マルチリージョン対応
Automate Secrets Replication Across AWS Regions - DR対応
OpenID Connect Integration with Secrets Manager - GitHub Actions/Terraform Cloud認証
AI Secret Scanning for Developers - 漏洩検知（2026新機能）
Batch GetSecretValue API - コスト最適化
HashiCorp Vault Integration - ハイブリッド環境対応
External Secrets Operator (ESO) - Kubernetes連携
CSI Secrets Store Driver - Kubernetes Pod マウント

最終更新：2026-04-26

目次

AWS Secrets Manager 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2025-2026 年の Secrets Manager エコシステム

定義

目次

概要

Secrets Manager の位置づけ

Secrets Manager が解決する課題

主な特徴

アーキテクチャ

アーキテクチャの主要コンポーネント

1. Secret Storage（シークレット保管）

2. Encryption（暗号化）

3. Versioning（バージョニング）

4. Rotation（自動ローテーション）

Secret タイプ

1. RDS Database Credentials（RDS 認証情報）

2. Redshift Credentials（Redshift 認証情報）

3. DocumentDB Credentials（DocumentDB 認証情報）

4. API Key / OAuth Token（API キー・OAuth トークン）

5. SSH Key（SSH 秘密鍵）

6. Custom Secrets（カスタムシークレット）

主要ユースケース

1. RDS Database Credentials（最も典型）

2. API Key Management（API キー管理）

3. OAuth / JWT Token Management

4. SSH Key Management

5. CI/CD Secret Management（CodeBuild、GitHub Actions）

6. Kubernetes（EKS）External Secrets Operator（ESO）

7. IoT Certificate Management

8. Lambda Environment Variable 代替

9. RDS Proxy Authentication

10. ElastiCache、MemoryDB Credentials

11. Container Registry Authentication

12. Third-Party SaaS Credentials

シークレットローテーション

ローテーションの目的

AWS 提供ローテーター（RDS・Redshift・DocumentDB）

カスタムローテーター（API キー・外部 DB）

RDS・Redshift・DocumentDB 自動ローテーション

RDS 自動ローテーション（最も一般的）

Redshift 自動ローテーション

DocumentDB 自動ローテーション

バージョニング

バージョンステージ

ローテーション時のバージョン遷移

ロールバック

レプリケーション（クロスリージョン）

目的

レプリケーション設定

フェイルオーバー

利点

VPC Endpoint（PrivateLink）

目的

VPC Endpoint 設定

セキュリティグループ設定

利点

セキュリティ（KMS・IAM・ResourcePolicy）

1. KMS 暗号化

2. IAM Policy（アクセス制御）

3. Resource Policy（クロスアカウント）

4. CloudTrail 監査ログ

ECS・EKS・Lambda 連携

1. ECS Task（Fargate）でのシークレット利用

2. Kubernetes（EKS）External Secrets Operator

3. Lambda 関数での GetSecretValue

4. Lambda キャッシングライブラリ

Cost Optimization

1. 価格体系

2. コスト削減戦略

A. Batch GetSecretValue API（2024 年新機能）

B. Lambda キャッシング

C. Parameter Store との使い分け

3. 一般的なコスト

Parameter Store vs Secrets Manager 使い分け

他の類似ツールとの比較

Secrets Manager vs HashiCorp Vault

Secrets Manager vs Azure Key Vault

5. KMS キーポリシー