2026年03月25日
[Documentdb] AWS Backup expands support for Amazon DocumentDB to 12 Regions
- 公開日: 2026-03-25 (JST)
- カテゴリ: Documentdb
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/03/aws-backup-amazon-documentdb-regions/
概要
AWS BackupがAmazon DocumentDBのサポートを12の追加リージョンに拡張しました。これにより、これらのリージョンにあるDocumentDBクラスタをAWS Backupのポリシーベースで保護・復元できるようになります。
変更内容・新機能の詳細
追加されたリージョンは、アジアパシフィック(マレーシア、タイ、大阪、香港、ジャカルタ、メルボルン)、ヨーロッパ(ストックホルム、スペイン、チューリッヒ)、アフリカ(ケープタウン)、イスラエル(テルアビブ)、メキシコ(中部)の12リージョンです。DocumentDBクラスタを既存のAWS Backupプランに追加するか、新規バックアッププランを作成してクラスタを紐付けることで、ポリシー(スケジュール、ライフサイクル、バックアップボールトなど)に基づくバックアップと復元の管理が可能になります。操作はAWS Backupコンソール、AWS CLI、またはAWS SDKから行えます。詳細な機能や価格、実装方法については製品ページやドキュメントを参照してください。
影響範囲・利用シーン
- 対象ユーザー: Amazon DocumentDBを使用しているアプリケーション開発者、データベース管理者、SRE/運用チーム
- 利用シーンまたは効果: 地域拠点で稼働するDocumentDBクラスタの一元的なバックアップ管理(スケジュール化、保持期間管理、復元)により、データ保護ポリシーの適用と迅速な復旧が可能
- 運用効果: バックアップ運用の自動化と標準化によりヒューマンエラーを削減し、DR(災害復旧)やコンプライアンス対応の効率が向上
- リージョン分散対応: これらのリージョンで稼働するワークロードがAWS Backupの管理下に入り、地域ごとのバックアップ戦略を統一しやすくなる
技術的な注意点
- IAM権限: AWS BackupでDocumentDBクラスタを管理するには、AWS Backupの操作(backup:StartBackupJob等)とDocumentDBのリソースに対する必要な読み取り権限が必要です。事前にロールとポリシーを確認してください。
- リージョン制限: サポート拡張は本文で列挙した12リージョンに対するものであり、リージョンごとに個別に設定が必要です。クロスリージョンのバックアップコピーやクロスアカウントの運用は追加設定や別途費用が発生する場合があります。
- コスト: バックアップストレージ、データ転送(特にクロスリージョンコピー)およびバックアップリクエストに対する料金が発生します。バックアップ保持期間やコピーポリシーがコストに影響しますので事前に見積もりを行ってください。
- 運用上の注意: クラスタをバックアップ対象に追加する前にクラスタ状態(スナップショットのサポート状況、暗号化設定、VPC設定など)を確認してください。バックアップ/復元の挙動やRTO/RPO要件は事前に検証することを推奨します。
- 互換性・差異: AWS Backupの一般機能(ライフサイクル、バックアップボールト、バックアッププラン等)は適用されますが、リージョンにより提供される機能や動作に差異がある可能性があるため、該当リージョンのドキュメントを参照してください。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/03/aws-backup-amazon-documentdb-regions/
- https://aws.amazon.com/backup/
- https://aws.amazon.com/backup/pricing/
- https://docs.aws.amazon.com/backup/latest/devguide/what-is-backup.html
- https://aws.amazon.com/documentdb/
[Transfer Family] AWS Transfer Family AS2 now supports receipts of MDNs asynchronously
- 公開日: 2026-03-25 (JST)
- カテゴリ: Transfer Family
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/03/aws-transfer-family-as2-mdns/
概要
AWS Transfer FamilyがAS2メッセージのMDN(Message Disposition Notification)を非同期で受信する機能をサポートしました。これにより、長時間処理や高レイテンシを持つ取引先とのAS2ワークフローをそのままTransfer Familyへ移行できます。
変更内容・新機能の詳細
AS2プロトコルでは、受信者がメッセージ受領や処理結果をMDNで応答します。これまでは同期(同一TLS/HTTP接続で即時に返す)MDNが一般的でしたが、取引先の処理が長時間かかる場合やネットワーク要件によっては非同期MDN(別のTLS接続/別送のHTTP POSTで後からMDNを返す)が必要になります。今回のアップデートにより、AWS Transfer Familyは送信側が非同期MDNを要求するケースで、別途確立されるTLS接続を介して後続のMDN受信を受け入れるようになりました。これにより、Transfer Family上で同期/非同期両方のMDN要求をサポートでき、取引先の処理時間や接続要件に応じた互換性を維持しつつAS2ワークフローをAWSへ移行できます。
実装上のポイント(詳細はユーザーガイド参照):
- 非同期MDNは別途確立されるHTTPS/TLS接続で送信されるため、受信用エンドポイント(URL)と証明書の設定が必要です。
- 取引先とのAS2ヘッダー(例: Disposition-Notification-To等)と合意された非同期MDNフローに従って構成する必要があります。
- Transfer Familyは同期MDNと非同期MDNの両方をサポートするため、パートナーごとの要件に応じた設定が可能です。
- 本機能はAWS Transfer Familyが提供されている大半のリージョンで利用可能ですが、対応状況はAWS Capabilitiesツールで確認してください。
影響範囲・利用シーン
- 対象ユーザー: AS2を使って取引先や規制機関とデータ交換を行う企業(ヘルスケア、ライフサイエンス、小売、製造、サプライチェーン等のデータ交換担当者/SRE/統合エンジニア)
- 利用シーン: 取引先の処理が長時間かかる、または高レイテンシ/再接続ポリシーがある相手とのAS2メッセージ送受信(非同期MDNで後続確認を受け取りたい場面)
- 運用効果: 取引先の処理特性に合わせて非同期MDNを受け取れるため、既存のパートナー統合を変更せずにTransfer Familyへ移行でき、接続失敗やタイムアウトによる処理中断を減らせる
技術的な注意点
- IAM権限: Transfer Familyサーバー管理やEndpoint/Certificate設定に関するIAM権限が必要。運用者は関連のIAMポリシーを確認してください。
- リージョン制限: 大半のリージョンで利用可能ですが、完全対応リージョンはAWS Capabilitiesツールで確認してください。
- 設定/相手先調整: 非同期MDNを使う場合、受信エンドポイント(MDN送信先URL)とTLS証明書の交換、AS2ヘッダーやMessage-ID/Dispositionの取り扱いについて取引先と事前合意が必要です。
- TLS/証明書: 非同期MDNは別接続のTLSで送信されるため、受信側の証明書管理(信頼済み証明書、ピア検証等)と期限管理を適切に行ってください。
- ログ/監査: MDNの受信は配信確認や否認の根拠になるため、Transfer Familyのログ(CloudWatch Logs等)や監査設定を整備しておくことを推奨します。
- メッセージ整合性と再試行: 非同期MDN到着までの間にメッセージIDやMIC(Message Integrity Check)のマッピングや再試行ポリシーを設計しておくと運用が安定します。
- コスト: 追加機能単体の料金アナウンスはないものの、Transfer Familyの標準利用料、データ転送費用、ログ記録(CloudWatch等)の費用が発生します。導入前にコスト影響を評価してください。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/03/aws-transfer-family-as2-mdns/
- https://docs.aws.amazon.com/transfer/latest/userguide/as2.html
- https://aws.amazon.com/transfer-family/
- https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/
[General] Amazon SageMaker HyperPod now supports continuous provisioning for Slurm-orchestrated clusters
- 公開日: 2026-03-25 (JST)
- カテゴリ: General
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sagemaker-hyperpod-continuous-provisioning/
概要
Amazon SageMaker HyperPodがSlurmオーケストレータを使うクラスターに対して継続的プロビジョニングをサポートしました。これにより、必要なノードが順次バックグラウンドで立ち上がるため、トレーニング開始の遅延や手動介入を減らせます。
変更内容・新機能の詳細
新機能では、SlurmベースのHyperPodクラスター作成/スケーリング時に NodeProvisioningMode を "Continuous" に設定すると、プロビジョニングが継続的(非ブロッキング)に行われます。優先度ベースのプロビジョニングによりまずSlurmコントローラノードを立ち上げ、その後ログインノードとワーカーノードを並列で起動してクラスターを早期に稼働状態にします。立ち上げに失敗したノードは非同期にリトライされ、利用可能になったノードは自動的にSlurmクラスターへ追加されます。また複数のインスタンスグループに対して同時に(ブロックせずに)スケーリング操作が可能になり、あるグループの容量不足が他グループのスケーリングを阻害しません。設定方法は CreateCluster API で NodeProvisioningMode を "Continuous" に指定するか、AWS CLI / SageMaker AI コンソールで新規クラスター作成時に有効化します。本機能は Slurm オーケストレータを使用する新規 HyperPod クラスターで利用可能で、HyperPodがサポートされる全リージョンで提供されます。
影響範囲・利用シーン
- 対象ユーザー: 大規模AI/MLトレーニングをSlurmで実行するデータサイエンティスト、MLエンジニア、SRE/運用チーム
- 利用シーン: トレーニングジョブの即時開始、クラスターの並行スケーリング、メンテナンス中も段階的に容量を確保したい場面
- 運用効果: クラスター作成/拡張でのロールバックや手動介入を削減し、time-to-trainingを短縮、リソース利用率を向上させる
技術的な注意点
- 設定方法: CreateCluster APIで NodeProvisioningMode="Continuous" を指定、またはAWS CLI / SageMaker AIコンソールで新規作成時に有効化
- 既存クラスター: 既存のHyperPodクラスターに対する切替は不可。継続的プロビジョニングを使うにはSlurmクラスターを新規作成する必要があります
- IAM権限: sagemaker:CreateCluster 等のSageMakerクラスター作成権限が必要。クラスター作成時に関連するEC2/EBS/Role作成の権限も必要になるため、実運用では必要なIAMポリシーを事前に確認してください
- リージョン制限: HyperPodがサポートされる全リージョンで有効。ただし利用可能リージョンは随時更新されるため、事前にドキュメントやコンソールで確認してください
- コスト: 背景で段階的にノードを起動するため、未使用のインスタンスが立ち上がっている期間は課金が発生します。期待するコスト/性能を確認のうえ設定してください
- 運用上の注意: 優先度に基づきコントローラが最優先で立ち上がる設計だが、ノード起動失敗時は非同期リトライに依存するため、根本原因(インスタンスタイプの一時的不足やサブネット制約など)を併せて調査する必要があります
- オーケストレータ対応: 現時点ではSlurm向けの機能拡張。その他オーケストレータは既存の挙動が継続されるため、対象オーケストレータを確認してください