AWS上でDell PowerProtectバックアップを運用する組織は、繰り返し発生する課題に直面しています。複数のアプライアンスエコシステム — PPDM（PowerProtect Data Manager）、DDVE（Data Domain Virtual Edition）、DDMC（Data Domain Management Center）— の慎重で順序立てられたプロビジョニングは、リージョンやアカウント間で一貫した再現が困難です。
本記事では、インフラストラクチャのプロビジョニングにTerraformを、展開後のオーケストレーションにAWS Step Functionsを使用した、AWS上でのDell PowerProtect導入の自動化アプローチを紹介します。ここで説明するパターンは、DellバックアップアプライアンスをAWS上で運用し、手動または半自動の導入から、完全にコード化された再現可能なフレームワークへの移行を目指すあらゆる企業に適用可能です。
AWS上でDellバックアップを自動化する理由
Dell PowerProtectコンポーネントは、通常、マーケットプレイスAMIからEC2インスタンスとしてAWS上に展開されます。展開自体はシンプルですが、課題は展開後の作業にあります。
- DDMC では対話型の初回ログインワizard（EULAの承諾、パスワード変更、ファイルシステムのセットアップ）が必要です
- PPDM ではREST APIによる設定（ライセンス付与、NTP、認証情報の設定、ポリシー作成）が必要です
- DDVE はPPDMとDDMCの両方に、連携したAPIコールで登録する必要があります
- DNS解決 では、双方向レコード（前方・逆引き）が必要です — PPDMは統合パートナーを受け入れる前に双方向のDNSを検証します
- 認証情報 は初日から安全な保管とローテーションが必要です
手動で行うと、設定のドリフトや文書化されない暗黙知が生まれ、スケールしません。Infrastructure as Codeはこれらのリスクを排除します。
リファレンスアーキテクチャ
AWS上の本番グレードのDell PowerProtect自動化フレームワークは、4つのレイヤーで構成されます。
┌─────────────────────────────────────────────────────────────────────┐
│ Layer 1: Terraform - Infrastructure │
│ VPC / Subnets / Security Groups / Route53 / IAM / KMS / Secrets │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 2: Terraform - Appliance Deployment │
│ PPDM EC2 Instance / DDVE EC2 Instance / DDMC EC2 Instance │
│ EBS Volumes / Network Interfaces / Instance Profiles │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 3: Step Functions - Configuration │
│ Lambda: Configure DDMC (SSH) │
│ Lambda: Configure PPDM (REST API) │
│ Lambda: Integrate DDVE ↔ PPDM/DDMC (REST API) │
│ Lambda: Credential Rotation (Secrets Manager) │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 4: Operational Monitoring │
│ EventBridge → Monitor Lambda → DynamoDB → ITSM Integration │
└─────────────────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode
各レイヤーには明確な責任境界があり、あるレイヤーの変更が他のレイヤーに予測不能な影響を与えることはありません。
レイヤー1：ネットワークとセキュリティの基盤
VPCとサブネットの設計
Dellバックアップアプライアンスは特定のポート（Data Domainプロトコル用2051、2052、3009、管理API用443）で通信します。ネットワークモジュールでは以下をプロビジョニングする必要があります。
- バックアップアプライアンス専用のVPC（または既存VPC内のサブネット範囲）
- 耐障害性向上のため複数AZにまたがるプライベートサブネット
- Dellプロトコルポートに限定した粒度の細かいセキュリティグループのingress/egressルール
- マーケットプレイスライセンス検証とアップデートのためのNAT Gatewayアクセス
DNS：見落とされがちな要件
PPDMの一般的な導入失敗原因は、DNS解決の問題による統合拒否です。PPDMは双方向のDNS検証を行います。DDVEホスト名をIPに解決し、そのIPを逆引きしてホスト名に戻し、両者が一致することを期待します。
両方の自動化が必要です。
- Route53プライベートホストゾーンでの前方DNS（Aレコード）
- 逆引きルックアップゾーン（例：
10.in-addr.arpa）での逆引きDNS（PTRレコード）
PTRレコードがない場合、PPDMは「Network validation has failed」や「Unable to resolve FQDN/IP address.」といったエラーで失敗します。これは文書化が不十分で、多くのチームが気づかないままです。
# Terraform reverse DNS zone and PTR record
resource "aws_route53_zone" "reverse" {
name = "10.168.192.in-addr.arpa"
vpc {
vpc_id = aws_vpc.backup.id
}
}
resource "aws_route53_record" "ppdm_ptr" {
zone_id = aws_route53_zone.reverse.zone_id
name = "15.10.168.192.in-addr.arpa"
type = "PTR"
ttl = 300
records = ["ppdm.backup.internal"]
}
Enter fullscreen mode Exit fullscreen mode
IAMとシークレット管理
各アプライアンスロールは最小権限の原則に従う必要があります。
- PPDMインスタンスロール：Secrets Manager（自らの認証情報）、S3（バックアップターゲット）、SSM（エージェント展開）へのアクセス
- DDVEインスタンスロール：暗号化ボリューム用のKMS復号、Secrets Manager（ローテーション用）
- DDMCインスタンスロール：パラメータ取得用のSSM、検出用のEC2 DescribeInstances
初回およびローテーション後の認証情報は、最初からAWS Secrets Managerに保存します。EC2ユーザーデータに認証情報を埋め込んだり、インスタンスIDをデフォルトパスワードとして使用したりすることは避けてください。
レイヤー2：Terraformによるアプライアンス展開
各Dellアプライアンスは、マーケットプレイスAMIからプロビジョニングされるEC2インスタンスです。主要な考慮事項は以下のとおりです。
PPDMの展開
- インスタンスタイプ：
m5.xlarge以上（最小4 vCPU、16 GB RAM） - ルートボリューム：100 GB gp3
- カタログサイズに応じた追加データボリューム
- DNSの一貫性確保のためのElastic IPまたは安定したプライベートIP
DDVEの展開
- インスタンスタイプ：ストレージ最適化（容量ティアに応じて
m5.2xlargeまたはr5.xlarge） - メタデータとデータ用の複数EBSボリューム（DDVEは特定のボリュームレイアウトを使用）
- 重複排除ワークロード向けの高IOPS設定
- 大規模展開向けのio2 Block Expressの検討
DDMCの展開
- インスタンスタイプ：
m5.large（管理プレーンとして軽量な要件） - 内部データベース用のデータボリューム
- 管理対象となる全DDVEインスタンスへのネットワークアクセス
# Parameterized appliance deployment
module "ppdm" {
source = "./modules/dell-appliance"
appliance_type = "ppdm"
ami_id = var.ppdm_ami_id
instance_type = var.ppdm_instance_type
subnet_id = module.network.private_subnet_ids[0]
security_groups = [module.network.ppdm_sg_id]
iam_profile = module.iam.ppdm_instance_profile
tags = {
Application = "dell-backup"
Component = "ppdm"
Environment = var.environment
}
}
Enter fullscreen mode Exit fullscreen mode
主要な原則：Terraformは「何を」（インフラストラクチャの状態）を扱い、「どのように」（アプライアンス内部の設定）を扱いません。後者はStep Functionsの役割です。
レイヤー3：Step Functionsによる展開後の設定
Terraform Provisionersを使わない理由
Terraform Provisioners（remote-exec、local-exec）は多段階のアプライアンス設定で魅力的ですが、問題があります。
- これらは
terraform apply時に実行され、独立して再試行できません - 待機条件を伴うシーケンシャルステップのための組み込みステートマシンがありません
- 失敗するとTerraformの状態が不整合な位置に残ります
- 宣言型モデルを破壊します — インフラストラクチャがランタイム動作と結合されます
AWS Step Functionsは、より適した選択肢です。再試行、タイムアウト、分岐、独立した実行が可能な可視化されたステートマシンを提供します。
設定用Lambda関数
DDMCの設定（SSHベース）
DDMCの初回ログインプロセスは対話型のSSHシェルウィザードです。Paramiko（Python SSHライブラリ）を使用するLambda関数でこれを自動化します。
- Secrets Managerから初期のデフォルト認証情報でDDMCにSSH接続
- 端末出力のパターンマッチングでEULAプロンプトを承諾
- sysadminパスワードを生成値に変更
- セットアップウィザードを完了（タイムゾーン、ホスト名、ネットワーク確認）
- 定義済みクォータでバックアップファイルシステムを作成
- 新しい認証情報をSecrets Managerに保存
主な課題： ウィザードのプロンプトテキストはDDMCファームウェアバージョンによって異なります。タイムアウトとフォールバック検出を備えた防御的なパターンマッチングを構築してください。
PPDMの設定（REST APIベース）
PPDMは起動後にポート443でREST APIを公開しますが、EC2が「running」状態になってからAPIが応答可能になるまで3〜8分かかります。Lambdaに必要な処理は以下のとおりです。
- 指数バックオフでPPDM APIヘルスエンドポイントをポーリング
- デフォルト認証情報で認証
- API経由でEULAを承諾
- 管理者パスワードを変更
- NTP設定を構成
- ライセンスをアクティベート
- デフォルトの保護ポリシーを作成
DDVE-PPDM-DDMC統合
統合Lambdaはアプライアンス間の登録をオーケストレーションします。
- PPDM APIで認証
- PPDMにDDVEをストレージターゲットとして追加（DDVE認証情報が必要）
- DDMC APIで認証
- DDMCにDDVEインスタンスを登録
- ステータスチェックで統合を検証
- エンドツーエンドの接続を確認するためのテストバックアップを実行
Step Functionの定義
{
"StartAt": "WaitForAppliances",
"States": {
"WaitForAppliances": {
"Type": "Wait",
"Seconds": 300,
"Next": "ConfigureDDMC"
},
"ConfigureDDMC": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:configure-ddmc",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 30,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"Next": "ConfigurePPDM"
},
"ConfigurePPDM": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:configure-ppdm",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 60,
"MaxAttempts": 5,
"BackoffRate": 2.0
}
],
"Next": "IntegrateDDVE"
},
"IntegrateDDVE": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:integrate-ddve",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 30,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"End": true
}
}
}
Enter fullscreen mode Exit fullscreen mode
レイヤー4：運用監視とITSM統合
展開後、Dellバックアップアプライアンスにはプロアクティブな監視が必要です。サーバーレス監視パターンが有効です。
監視アーキテクチャ
- EventBridge Scheduled Rule — 10分ごとに監視Lambdaをトリガー
- Monitor Lambda — DDMC REST APIで認証し、DDVEのヘルスステータスとアクティブアラートを取得
- DynamoDB Table — 現在のアラート状態を重複排除と追跡のために保存
- DynamoDB Streams — 新規または変更されたアラートでITSM Lambdaをトリガー
- ITSM Lambda — イベントをフォーマットし、インシデント管理システム（ServiceNow、Jira Service Managementなど）に転送
アラートイベントスキーマ
ダウンストリームの消費のためにイベント形式を標準化します。
{
"event_id": "unique-uuid",
"source": "dell-backup-monitor",
"severity": "critical",
"appliance": "ddve-01.backup.internal",
"alert_name": "Appliance Not Responding",
"timestamp": "2026-07-15T10:30:00Z",
"region": "eu-west-1",
"action_required": "Investigate DDVE connectivity"
}
Enter fullscreen mode Exit fullscreen mode
イベントのアーカイブ
監査とコンプライアンスのために、構造化されたパスで全イベントをS3にアーカイブします。
s3://backup-events/{service}/{account_id}/{region}/{date}/{event_id}-{severity}.json
Enter fullscreen mode Exit fullscreen mode
EC2バックアップの大規模オンボーディング
最後の自動化要素は、EC2インスタンスのDell Backup保護へのオンボーディングです。
-
タグベースのターゲティング —
Backup: enabledタグが付いたインスタンスが検出されます - SSM Automation — AWS Systems ManagerがSSHアクセスなしでPPDMエージェントをインストール
- エージェント登録 — エージェントは事前設定されたサーバーエンドポイントを使用してPPDMに登録
-
ポリシー割り当て — 保護ポリシーはワークロードタグ（例：
BackupPolicy: daily-30day-retention）に基づいて割り当てられます - ヘルス検証 — インストール後のチェックでPPDMへのエージェント接続を確認
バックアップオンボーディングは独立した自動化として維持し、一般的なEC2ライフサイクル管理と結合しないでください。バックアップポリシーはOSパッチ適用やスケーリングイベントとは独立して変更されます。
よくある落とし穴とその回避方法
| 落とし穴 | 影響 | 解決策 |
|---|---|---|
| PTRレコードの欠如 | PPDM統合がサイレントに失敗 | ネットワークモジュールで逆引きDNSを自動化 |
| デフォルトパスワードの放置 | セキュリティ脆弱性 | 初回起動時にローテーションし、Secrets Managerに保存 |
| 設定にTerraform Provisionersを使用 | 脆弱で再試行不可能な展開 | 代わりにStep Functions + Lambdaを使用 |
| ステップ間のヘルスチェックの欠如 | 準備ができていないアプライアンスでの統合試行 | 各Lambdaでバックオフ付きのポーリングを実装 |
| バックアップとOS管理の結合 | 一方の変更が他方を破壊 | Terraformモジュールとパイプラインを分離 |
| 監視の監視の欠如 | サイレントなアラート失敗 | Lambdaエラーメトリクスに対するCloudWatchアラーム |
まとめ
AWS上でのDell PowerProtectの自動化には、レイヤー思考が必要です。
- インフラストラクチャ用のTerraform — VPC、EC2、IAM、DNS（逆引きを含む）、KMS、Secrets Manager
- オーケストレーション用のStep Functions — Lambdaによるアプライアンスのシーケンシャルで再試行可能な設定
- 監視用のEventBridge + Lambda — ITSM統合を伴うプロアクティブなヘルスチェック
- オンボーディング用のSSM — SSHアクセスなしでの大規模なエージェント展開
このパターンは関心事を明確に分離します。Terraformは状態を、Step Functionsはワークフローを、Lambdaはアプライアンス固有のロジックを所有します。この分離により、各レイヤーは独立してテスト、更新、デバッグが可能になります。
現在AWS上でDellバックアップを手動で展開しているチームにとって、このレイヤード自動化アプローチを採用することで、設定のドリフトを排除し、セキュリティ体制を改善し、追加のエンジニアリング作業なしにリージョン間でスケールできます。
Alpesh Kumbhareは、Atos businessのクラウドアーキテクトであり、AWSインフラストラクチャ自動化とエンタープライズデータ保護ソリューションを専門としています。LinkedInでつながることができます。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.