本記事は 2025 年 12 月 10 日 に公開された「 How to use Sustainability Insights Framework on AWS 」を翻訳したものです。 従来、組織は炭素排出量を追跡し、気候関連レポートを作成する際に、複雑で労働集約的、かつエラーが発生しやすい手動プロセスに直面してきました。このプロセスでは通常、従業員が公共料金の請求書、燃料消費記録、調達文書、出張領収書、施設運営ログなど、異なるソースから無数の時間をかけてデータを収集する必要がありました。大規模なチームは、このデータをスプレッドシートに手動で入力する必要があり、多くの場合、一貫性のない形式や単位を扱い、慎重な変換と検証が必要でした。このプロセスは、異なる地域基準、報告要件、排出係数を扱う多国籍組織にとって特に困難でした。スタッフは、スコープ 1 排出量（所有するソースからの直接排出）、スコープ 2 排出量（購入した電力からの間接排出）、さらに複雑なスコープ 3 排出量（バリューチェーン内のその他すべての間接排出）を手動で計算する必要がありました。各計算には適切な排出係数の慎重な適用が必要であり、これらの係数自体も基準の進化に伴って定期的に更新する必要がありました。 これらの懸念に対処するため、AWS は AWS Solutions Library に Sustainability Insights Framework (SIF) を導入しました。 これは、あらゆる規模の組織が AWS 上で炭素排出量を自動的に追跡し、気候関連レポートを作成するアプリケーションを構築するのに役立つ、柔軟でスケーラブルなソフトウェアプラットフォームです。計算、パイプライン処理、参照データセット用の特殊なコンポーネントを含むモジュラーアーキテクチャを通じて、SIF は組織が膨大な量のサステナビリティデータを処理しながら、すべての計算とレポート全体で精度と一貫性を維持できる高度なアプリケーションを作成することを可能にします。 フレームワークの有効性は最終的に入力データと推定方法の品質に依存し、すべての出力は規制遵守と公式開示のために独立した検証が必要ですが、SIF の自動化されたアプローチは 3 つの重要な利点を提供します：自動化されたデータ処理と計算を通じて人的エラーのリスクを劇的に削減し、増大する報告要件を処理するために動的にスケールし、進化するサステナビリティ基準と規制に容易に適応します。SIF には、それぞれ特定の目的を果たす複数のモジュールが含まれています。これらのモジュールは、アクセス管理、インパクト管理（排出係数管理）、参照データセット管理、計算、データパイプラインを処理します。 ​ SIF の主要機能 アカウント管理 – 組織の報告境界を設定します。フレームワーク内でユーザーアクセス、ロール、権限を制御します。 インパクト – GHG 排出係数などの活動インパクトのカタログを作成します。公開されたソースから排出係数を追加するか、独自のカスタム係数を作成します。 参照データセット – データパイプラインにカスタムデータセットを追加して、データ品質を向上させます。 計算 – ローコードアプローチを使用してカスタム計算を作成します。 メトリクス（KPI） – 処理された活動を自動的に集計するメトリクスを設定します。これらを組織の報告境界と期間に合わせます。 データ取り込みパイプライン – CSV ファイル、AWS Clean Rooms、または入力データコネクタフレームワークを使用した他のソースからデータをインポートします。計算を適用してデータを必要な出力に変換します。 監査可能性 – すべての計算と結果を完全な透明性で追跡および再現します。 マルチテナンシー – シングルテナントまたはマルチテナントモードで動作します。自社の排出量を計算したい組織と、SaaS オファリングを構築する組織をサポートします。必要に応じて、分離されたテナント間でデータを安全に共有します。たとえば、SaaS オファリングを構築する場合、トップティアのお客様は業界固有の数式などの事前定義された計算にアクセスできます。中央テナントは、集中管理のためにこれらの計算を保存します。トップティアテナントは、これらの計算にリモートでアクセスして使用する権限を取得します。 ソリューションアーキテクチャ SIF は、それぞれ特定の機能に焦点を当てた複数のモジュールで構成されています。以下のアーキテクチャ図は、これらのモジュールがどのように連携するかを示しています。 ​ SIFソリューションアーキテクチャモジュール ​ ユーザーは REST API を通じて SIF を操作します。 アクセス管理モジュール は、ユーザーと権限を管理し、グループごとにリソースを分離します。 インパクトモジュール は、データ処理計算中にインパクト係数などのリソースを管理するのに役立ちます。これらは計算モジュールとパイプラインモジュールから参照できます。 参照データセットモジュール は、ルックアップテーブルなどのデータセットを管理するのに役立ちます。これらのデータセットは、計算モジュールとパイプラインモジュールから参照できます。 計算モジュール は、方程式または関数を作成および管理するのに役立ちます。これらの計算は、データ処理計算のために他のモジュールで参照できます。 パイプラインモジュール は、計算用のデータ処理パイプラインを設定するのに役立ちます。 パイプラインプロセッサモジュール は、パイプラインを管理し、パイプライン集計を実行します。 計算機モジュール は、バックエンドコンポーネントとしてパイプライン内の操作を実行します。これには、算術演算とリソースルックアップが含まれます。 SIF は、AWS サービス上に構築されたモジュールのレイヤーとして機能します。各モジュールは特定の機能を処理します。各コンポーネントを見てみましょう： ​ アクセス管理モジュール アクセス管理モジュールは、ユーザーとグループを使用して SIF 内の権限を管理し、リソースを分離します。外部 REST API を通じてユーザーとグループを作成できます。他の SIF モジュールは、アクセス管理モジュールを呼び出して権限を確認します。各テナントは、独自のアクセス管理インフラストラクチャのコピーを取得します。 ​ SIF アクセス管理モジュール図 ​ インパクトモジュール インパクトモジュールは、インパクト関連のリソースを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのリソースを参照できます。インパクトの例としては、モバイルディーゼル燃料消費の二酸化炭素換算量（CO2e）があります。インパクトモジュールは、インパクトタスク API を通じて一度に多くのインパクトリソースを作成できます。すべてのインパクトには、透明性のためのバージョン追跡が含まれています。 ​ SIF インパクトモジュール図 ​ 参照データセットモジュール 参照データセットモジュールは、ルックアップテーブルなどのデータセットを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのデータセットを参照できます。参照データセットの例は、特定の場所の発電ミックス（石炭、原子力、風力）を示すテーブルです。すべての参照データセットには、透明性のためのバージョン追跡が含まれています。 ​ SIF 参照データセットモジュール ​ 計算モジュール 計算モジュールは、方程式または関数を作成および管理するのに役立ちます。排出量追跡などのデータ処理計算中に、他の計算モジュールまたはパイプラインモジュールでこれらの計算を参照できます。計算は、単純（単位変換など）または複雑（ビジネス固有の排出量計算など）にすることができます。すべての計算には、透明性のためのバージョン追跡が含まれています。 ​ SIF 計算モジュール ​ パイプラインモジュール パイプラインモジュールは、パイプライン構成を管理するのに役立ちます。これらの構成は、排出量追跡などの計算用のデータ処理パイプラインを設定します。パイプラインを構成して、実行全体で出力を結合し、メトリクスにグループ化できます。メトリクスは、時間の経過に伴う総排出量などの主要業績評価指標（KPI）を捕捉します。パイプライン構成のドライランをリクエストして、計算機を通じて処理し、作成前にエラーをチェックできます。すべてのパイプライン構成には、透明性のためのバージョン追跡が含まれています。 ​ SIF パイプラインモジュール ​ パイプラインプロセッサモジュール パイプラインプロセッサモジュールは、パイプライン操作を管理します。これには、入力ファイルを提供したときのパイプライン実行の開始と、パイプライン構成で定義された集計の実行が含まれます。パイプラインプロセッサモジュールは、パイプライン実行のステータスも表示します。 ​ パイプラインプロセッサモジュール ​ 計算機モジュール 計算機モジュールは、パイプラインで定義された操作を読み取って実行するバックエンドコンポーネントとして機能します。これには、算術演算と、参照データセットやインパクトなどのリソースのルックアップが含まれます。計算機は、入力値と実行で使用された各リソース（参照データセット、インパクト、計算）のバージョンを含む、すべてのパイプライン操作の監査ログも作成します。 ​ さまざまなモジュールの詳細については、こちらをご覧ください： Architecture diagrams for SIF on AWS ​ 米国環境保護庁（EPA）は、AWS と Sustainability Insights Framework（SIF）を使用して、サブパートW規制に基づく温室効果ガス排出量を管理および報告しています。SIFは、データ収集、分析、報告を容易にする包括的でスケーラブルかつ安全なプラットフォームを提供します。これにより、コンプライアンスが向上し、環境の持続可能性がサポートされます。このユースケースの詳細については、こちらをご覧ください： U.S. EPA Subpart W Greenhouse Gas Reporting with AWS and Sustainability Insights Framework ​ SIF 計算機モジュール ​ SIF の利点 SIF は以下の利点を提供します： 運用効率と自動化 ：データ収集から自動化された排出量計算と報告までの手動作業を削減します。 透明性と監査可能性 ：すべてのデータソース、計算式、結果がバージョン管理され、ログに記録されます。これにより、監査をサポートするトレーサビリティが作成されます。 標準化されたデータモデル ：データ統合と品質保証、さらにレポートの再利用性と高度なデータ分析を可能にします。 高い柔軟性とスケーラビリティ ：排出係数、ワークフロー、計算式を簡単に追加または変更できます。これにより、将来のニーズに柔軟に対応できます。 セキュリティと一貫性 ：データ暗号化や最小権限の原則を含む、AWS セキュリティのベストプラクティスに従います。 ガイダンスをデプロイする手順 SIF のソースコードは GitHub で見つけることができます： Guidance for AWS sustainability insights framework 。2 つのデプロイオプションがあります： CDK を使用して手動でデプロイする。 sif-cli を使用してデプロイする 。SIF コマンドラインインターフェース（sif-cli）は、コマンドラインコマンドを通じて SIF コンポーネントと対話するのに役立つオープンソースツールです。最小限のセットアップで、sif-cli は SIF の管理の多くの複雑さを簡素化します。また、デプロイされたバージョンと最新の SIF リリース間の互換性を確保する機能も含まれています。 デプロイを完了し、SIF を本番環境に移行したい場合は、 Considerations of running SIF in production を確認してください。 ​ カスタマイズガイダンス（さまざまなお客様向け） SIFは、多様なお客様要件を満たすために柔軟に適応します。 業界および地域別の排出係数のカスタマイズ ：製造や輸送などの業界、または米国や日本などの地域に応じて排出係数を管理します。 お客様固有の KPI とレポート形式の追加 ：SIF のカスタマイズ可能な計算式とレポートテンプレート機能を使用して、独自のメトリクスとカスタマイズされたレポート出力をサポートします。 既存のデータレイクとシステムとの統合 ：API と AWS サービス統合を通じて、SIFを既存のデータインフラストラクチャとシームレスに接続します。 組織構造とセキュリティ要件の最適化 ：SIF のマルチテナントアーキテクチャを使用して、複数の部門またはグループ会社間で操作を分離します。必要に応じて詳細なアクセス制御を設定します。 次のステップ SIF を始める準備はできましたか？以下をお勧めします： 初めてのユーザー向け： GitHub リポジトリを探索する – コードベースと要件を理解するために、AWS sustainability insights framework のガイダンスを確認してください。 開発環境をセットアップする – 必要な AWS CLI、CDK、および権限が構成されていることを確認してください。 パイロットデプロイから始める – 最もシンプルなセットアップエクスペリエンスのために、sif-cli ツールを使用して開発環境に SIF をデプロイします。 EPA ユースケースを確認する – 米国環境保護庁がサブパート W 報告のためにSIFをどのように実装したかを研究して、実際のアプリケーションを理解してください。 実装の準備ができている組織向け： データソースを評価する – SIF と統合する必要があるシステムとデータ形式を特定します。 排出係数を定義する – 構成する必要がある業界固有または地域固有の排出係数を決定します。 組織構造を計画する – 報告境界に基づいて、シングルテナントまたはマルチテナントアーキテクチャが必要かどうかを決定します。 本番環境の考慮事項を確認する – 本番環境にデプロイする前に、「 Considerations of running SIF in production 」のドキュメントを読んでください。 サポートを受ける： ベストプラクティスとピアサポートのために、AWS サステナビリティコミュニティに参加してください。 実装ガイダンスとカスタマイズサポートについては、AWS プロフェッショナルサービスをご検討ください。 SIF が使用する基盤となるサービスについては、AWS ドキュメントを確認してください。 パイロットプロジェクトから小規模に始めてアプローチを検証し、プラットフォームの経験を積むにつれてスケールアップしてください。 ​ 結論 AWS Sustainability Insights Framework（SIF）は、AWS上に構築された貴重なツールです。自動化された炭素排出量追跡のためのアプリケーションの設計と実装を加速する基盤となるソフトウェアコンポーネントを提供します。SIF は、自動化、カスタマイズの柔軟性、スケーラビリティ、コスト効率、セキュリティなどの利点を提供するために連携する、さまざまな独立したモジュールで構成されています。 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 Smita Srivastava Smita Srivastava は、Amazon Web Services のシニアソリューションアーキテクトで、デジタルネイティブ企業のイノベーション促進を支援しています。その経験を活かし、企業の成長を導き、AWS サービスを活用した AI/ML に重点を置きながら、アイデアを現実に変えるサポートをしています。AWS のお客様にサステナビリティソリューションを提案することに深い関心を持っています。仕事以外では、旅行好きで、読書家であり、食の探求者でもあります。

本記事は、2025 年 6 月 20 日に公開された Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments を翻訳したものです。翻訳は Cloud Support Engineer の野島 正就が担当しました。 Amazon Aurora PostgreSQL 互換エディション は、高いパフォーマンスと可用性を実現するために設計されたフルマネージドのリレーショナルデータベースエンジンで、更新時のダウンタイムの削減とリスクの最小化を支援する マネージドなブルー/グリーンデプロイ をサポートしています。ブルー/グリーンデプロイは、論理レプリケーションを使用してフルマネージドのステージング環境を作成し、本番環境の変更を安全にデプロイおよびテストできるようにします。ブルー環境は現在の本番データベースです。グリーン環境には必要な更新や変更が含まれていますが、アプリケーションエンドポイントを変更する必要はありません。このアプローチにより、エンジンバージョンのアップグレードやシステムパッチなどの更新に伴うリスクとダウンタイムを最小限に抑えることができます。検証が完了したら、アプリケーションエンドポイントの変更なしにグリーン環境をシームレスに本番環境に昇格させることができます。 非本番環境で入念に計画とテストを行ったとしても、バージョンアップグレード後に予期しない問題が発生することがあります。例えば、新しいスキーマ変更がステージング環境では完璧に動作しても、本番環境では実際のデータパターンの違いやテスト中に実行されなかったアプリケーションクエリが原因でエラーが発生する場合があります。また、実際のトラフィックやワークロードによってパフォーマンスが低下することもあります。このような場合、サービスの安定性を迅速に復旧するためにロールバック計画を用意しておくことが不可欠です。ブルー/グリーンデプロイ機能には現在組み込みのロールバック機能はありませんが、バージョン管理のための代替ソリューションを実装することができます。 この記事では、Amazon RDS ブルー/グリーンデプロイの切り替え後に、セルフマネージドな論理レプリケーションを使用してロールバッククラスターを手動でセットアップし、新しいバージョンとの同期を維持する方法を紹介します。ロールバッククラスターは、元のバージョンに戻す必要がある場合のバックアップオプションとして機能します。 ソリューションの概要 次の図は、このソリューションの高レベルなワークフローを示しています。 スイッチオーバーの前には、2 つのクラスターがあります: ブルークラスター – 既存の本番データベースクラスター グリーンクラスター – ブルークラスターからミラーリングおよび同期されたステージング環境 スイッチオーバー後、3 つのクラスターが存在します: 旧ブルークラスター – 元の本番クラスター (以前のブルークラスター) 新ブルークラスター – 本番クラスターの新バージョンで、ワークロードが実行される場所 (以前のグリーンクラスター) ブループライマリ (ロールバック) クラスター – 旧ブルークラスターのクローンで、新ブルークラスターのデータと同期されたもの (ロールバッククラスターとして使用されます) ワークフローのステップは以下のとおりです: ブルー/グリーンデプロイを作成 します ブルークラスターへのトラフィックを停止し グリーンクラスターへのスイッチオーバーを実行 します ブルー/グリーンデプロイを削除 します 旧ブルークラスターを クローン して、ブループライマリ (ロールバック) クラスターを作成します 新しいブルークラスターからブループライマリ (ロールバック) クラスターへの論理レプリケーションを設定します 新しいブルークラスターへのトラフィックを開始します この記事では、 Amazon Aurora PostgreSQL 互換エディション のメジャーバージョンアップグレード (バージョン 15.10 から 16.6 へ) をシミュレーションします。 制限事項 Aurora ブルー/グリーンデプロイは DDL、シーケンス、マテリアライズドビューのリフレッシュ、ラージオブジェクトの作成や変更、プライマリキーのないテーブルでのデータの更新や削除をレプリケートしません。詳細については、 Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項 を参照してください。 Aurora ブルー/グリーンデプロイはスイッチオーバー後にプライマリクラスターエンドポイントを自動的に管理しますが、以前のバージョンへのロールバックが必要な場合は、アプリケーションまたは DNS レベルでエンドポイントの変更を処理する必要があります。 ロールバッククラスターのセットアップには追加のダウンタイムが発生します。 前提条件 このソリューションを実装するには、以下のコンポーネントが必要です: ブルー/グリーンデプロイのサポート – 既存の Aurora クラスターのバージョンがブルー/グリーンデプロイをサポートしていることを確認します。詳細については、 データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する および New – Fully managed Blue/Green Deployment in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL を参照してください。 ソースデータベースクラスター (この記事では Aurora PostgreSQL v15) で論理レプリケーションを有効にします。 必要に応じてブルー/グリーンデプロイをサポートするバージョンへのインプレースマイナーバージョンアップグレードを 1 回実行します。 AWS CLI による操作。 注意: 論理レプリケーションパラメータを有効にするには、ライターインスタンスの再起動が必要です。詳細については、 Aurora PostgreSQL DB クラスターの論理レプリケーションの設定 を参照してください。 新しいバージョンのデータベース用のクラスターパラメータグループ : 新しいバージョンから古いバージョンへの論理レプリケーションを設定するため、新しいバージョン (Aurora PostgreSQL 16) で論理レプリケーションが有効になっていることを確認する必要があります。以下の AWS CLI コマンドでクラスターパラメータグループを作成し、論理レプリケーションパラメータを有効にします。 aws rds create-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --db-parameter-group-family aurora-postgresql16 \ --description "Parameter group that contains logical replication settings for Aurora PG 16" aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot" Aurora のクローン機能については Amazon Aurora DB クラスターのボリュームのクローン作成 を参照してください。 ブルー/グリーンデプロイの作成 Amazon RDS ブルー/グリーンデプロイは AWS によって管理されます。内部的には、ブルー環境からグリーン環境にリソースを作成してミラーリングし、ネイティブの論理レプリケーションを使用してブルー環境からグリーン環境に DML の変更をレプリケートします。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで RDS ブルー/グリーンデプロイを作成できます。ここで source は本番データベースの Amazon Resource Name (ARN) です。以下の RDS コンソールのスクリーンショットは、論理レプリケーションが有効になっている既存のクラスター (ブルークラスター) を示しています。 以下のコマンドを使用して、Amazon Aurora PostgreSQL バージョン 16 のグリーンクラスターを持つブルー/グリーンデプロイを作成します。グリーンクラスターには、事前に作成した論理レプリケーション用の適切なパラメータグループをアタッチする必要があります。 aws rds create-blue-green-deployment \ --blue-green-deployment-name my-blue-green-deployment \ --source arn:aws:rds: {REGION} : {ACCOUNT_NUMBER} :cluster: {CLUSTER_ID} \ --target-engine-version 16.6 \ --target-db-cluster-parameter-group-name pg16-blue-green すべてのインスタンスが利用可能になると、ブルークラスターとグリーンクラスターの両方がアタッチされたブルー/グリーンデプロイが完成します。 トラフィックの停止とスイッチオーバーの実行 グリーンクラスターを昇格させるには、 スイッチオーバー アクションを開始する必要があります。スイッチオーバーを開始する前に、ブループライマリの作成中のデータ整合性を確保するために、ブルークラスターのデータベーストラフィックを停止してください。VPC セキュリティグループを使用して、インバウンドおよびアウトバウンドのデータベーストラフィックをブロックできます。スイッチオーバーが完了したら、RDS ブルー/グリーンデプロイの更新されたラベルを確認してください。 aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --switchover-timeout "300" ブルー/グリーンデプロイの削除 ブループライマリ (ロールバック) クラスターを設定する前に、ブルー/グリーンデプロイを削除する必要があります。RDS ブルー/グリーンデプロイを削除すると、マネージド環境からクラスターが解放され、Amazon RDS ブルー/グリーンデプロイによって生成されたレプリケーションスロット、パブリケーション、サブスクリプション、論理レプリケーションコンポーネントなどのオブジェクトがクリーンアップされます。 aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --no-delete-target 次のスクリーンショットに示すように、apg-blue-green-demo (v16.6) と apg-blue-green-demo-old1 (v15.10) の 2 つの独立したクラスターが作成されました。 新しいブルークラスターをクローンしてブループライマリ (ロールバック) クラスターを作成 コンプライアンスや監査の目的で、元のブルークラスターを保持する必要がある場合があります。ロールバッククラスターをセットアップするには: 元のブルークラスターをクローンしてセルフマネージドのブループライマリ (ロールバック) クラスターを作成します 利用可能になったら、クローンしたクラスターで簡単な読み取り専用クエリを実行して、クラスターとデータへのアクセスを確認します ロールバックが必要になった場合に備えて、DNS またはアプリケーションのエンドポイント更新用にブループライマリ (ロールバック) クラスターのエンドポイントを記録します aws rds restore-db-cluster-to-point-in-time \ --db-cluster-identifier "apg15-blue-prime" \ --restore-type copy-on-write \ --use-latest-restorable-time \ --source-db-cluster-identifier "apg-blue-green-demo-old1" \ --db-subnet-group-name " {DB_SUBNET} " \ --vpc-security-group-ids " {VPC_SECUITY_GROUP} " \ --db-cluster-parameter-group-name " pg15-blue-green " aws rds create-db-instance \ --db-instance-identifier "apg15-blue-prime" \ --db-instance-class "db.r6g.large" \ --db-cluster-identifier "apg15-blue-prime" \ --engine "aurora-postgresql" \ --engine-version "15.10" 次のスクリーンショットに示すように、ロールバック先となる新しい復元クラスター「apg15-blue-prime」を作成しました。 ブループライマリ (ロールバック) クラスターのセットアップ ブループライマリのクローンが完了したら、新しいブルークラスター (パブリッシャー) からブループライマリクラスター (サブスクライバー) へのセルフマネージドな論理レプリケーションを設定します。データ同期の問題を防ぐため、書き込みアクティビティやスキーマ変更が行われないようにしてください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントを使用してデータベースに接続し、新しいパブリケーションを作成します: CREATE PUBLICATION publication_name FOR ALL TABLES ; 重要 : 各テーブルにレプリケーションアイデンティティ (プライマリキーやユニークキーなど) があることを確認してください。同じクラスターに複数のデータベースがある場合は、新しく昇格した本番クラスター (新しいブルークラスター) の各データベースに対して以下の手順を繰り返してください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントに接続し、以下のコマンドを使用して ‘pgoutput’ プラグインを使用したレプリケーションスロットを作成します: SELECT pg_create_logical_replication_slot(' replication_slot_name ', 'pgoutput'); ブループライマリクラスター (サブスクライバー) で、以下のコマンドを使用して、データのコピーや新しいスロットの作成を行わずに新しいサブスクリプションを作成します: CREATE SUBSCRIPTION subscription_name CONNECTION 'postgres:// admin_user_name : admin_user_password @ source_instance_URL / database ' PUBLICATION publication_name WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = ' replication_slot_name '); このコードには以下のパラメータが必要です: subscription_name – サブスクリプションの名前 admin_user_name – rds_superuser 権限を持つ管理ユーザーの名前 admin_user_password – 管理ユーザーに関連付けられたパスワード source_instance_URL – パブリケーションサーバーインスタンスの URL database – サブスクリプションサーバーが接続するデータベース publication_name – パブリケーションサーバーの名前 replication_slot_name – ステップ 2 で作成したレプリケーションスロットの名前 重要 : ブループライマリクラスター上のすべてのパブリケーション (ステップ 1) に対して、この作業を繰り返す必要があります。 ブループライマリクラスターで、以下のコマンドを使用してサブスクリプションを有効にします: ALTER SUBSCRIPTION subscription_name ENABLE ; 重要 : ブループライマリクラスター上のすべてのサブスクリプションに対して、この作業を繰り返す必要があります。 論理レプリケーションのセットアップが完了し、新しいブルークラスターからブループライマリクラスターへのデータフローを確認した後、既存のクラスターエンドポイントを使用して新しいブルークラスターへのトラフィックを再開できます。Amazon RDS ブルー/グリーンデプロイが DNS の変更を自動的に処理するため、アプリケーションは同じエンドポイントを引き続き使用できます。 ブループライマリクラスターへのロールバック ブループライマリクラスター (元のバージョン) にロールバックする必要がある場合は、以下の手順に従ってください。 移行中のデータ整合性を維持するためにアプリケーショントラフィックを停止します (Amazon Aurora VPC セキュリティグループを使用して受信トラフィックをブロックできます) アプリケーションまたは DNS レコードを更新して、ブループライマリクラスターのエンドポイントを指すようにします ブループライマリクラスターのサブスクリプションを削除します 該当する場合はシーケンス値を手動で更新します この切り替えは自動ではありません。ブループライマリクラスターはマネージドサービスの管理下にないためです。実行時のエラーを最小限に抑えるために、ロールバック手順のランブックまたは自動化スクリプトを作成することをお勧めします。 この戦略はロールバックオプションを提供しますが、ブループライマリクラスターのセットアップ時に追加のダウンタイムが発生します。このアプローチを実装する際に考慮すべきトレードオフであり、本番環境に移行する前にステージング環境で十分にテストすることを推奨します。 クリーンアップ 本番環境では、すべてのアプリケーションが正常に移行されたことを検証する間、新しいブループライマリクラスターを維持する必要があります。両方の環境を同時に稼働させておくことで、新しいインフラストラクチャで何か不整合や予期しない動作が発生した場合にロールバックできることが保証されます。コンプライアンス目的で旧ブルークラスターをバックアップした後、コスト削減のためにクラスターを削除できます。すべてのクラスターは削除されるまで課金されます。 テスト目的でこれらのリソースを作成した場合は、追加料金が発生しないように、すべてのクラスター (ブルー、グリーン、ブループライマリ) を削除する必要があります。データベースクラスターをクリーンアップするには、以下の手順を実行してください。 リードレプリカインスタンスがあれば、 それぞれを削除します。 プライマリインスタンスを削除します。 データベースクラスターを削除します。 まとめ この記事では、Amazon RDS ブルー/グリーンデプロイを使用してデータベースバージョンのアップグレードを行う際のロールバック戦略の作成方法を紹介しました。安全性を高めるために、ロールバック戦略として論理レプリケーションを設定しました。ブルー/グリーンデプロイは、ミラーリングされた同期済みのデータベースステージングバージョンの作成、ガードレールチェックの実行、スイッチオーバーの実施、DNS 変更の自動化など、多くの複雑なタスクを自動的に処理します。しかし、本番データベースの変更には、アプリケーションの非互換性などのリスクが伴う可能性があります。ロールバッククラスターを設定しておくことで、アップグレード後に問題が発生した場合に迅速にフォールバックできる追加の安全策が得られます。問題が解決されるまで、以前の本番バージョンに戻すことができます。 本番ワークロードを切り替える前に、本番レベルの負荷をかけた状態で新しいデータベースバージョンに対してアプリケーションを十分にテストしてください。アプリケーションが完全に互換性があり、パフォーマンスが安定していることを確認してください。これにより、ブルー/グリーンデプロイの切り替え後にアプリケーションの問題やパフォーマンス低下が発生する可能性を大幅に減らすことができます。このロールバック戦略を実装する前に、 RDS ブルー/グリーンデプロイ の仕組みと機能について確認することから始めることをお勧めします。 Chirag Dave Chirag は マネージドな PostgreSQL を専門とする Amazon Web Services のプリンシパルソリューションアーキテクトです。セキュリティ、コスト、パフォーマンス、信頼性、効率的なオペレーション、アーキテクチャについてのベストプラクティスを通じてお客様と技術的な関係を構築しています。 Kovan Chandra Kovan は PostgreSQL データベースを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協業し、クラウドにおけるカスタマージャーニー、セキュリティ、レジリエンシー、コスト削減、およびオペレーショナルエクセレンスの改善に取り組んでいます。 Daxeshkumar Patel Daxeshkumar は Amazon Web Services (AWS) のソリューションアーキテクトであり、主要なクラウド案件においてお客様やパートナーと密接に連携しています。概念実証（PoC）プロジェクトの設計・提供、実装支援、および AWS サービスを活用したアプリケーションの構築・移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。 Kamal Singh Kamal は Amazon Web Services (AWS) のシニアデリバリーコンサルタントです。データベースの移行およびモダナイゼーションプログラムに重点を置き、お客様やパートナーの AWS クラウドへの移行を支援しています。 Jinesh Shah Jinesh は Amazon Web Services (AWS) のデリバリーコンサルタントです。レガシーデータベースおよびアプリケーションのモダンな AWS プラットフォームへの移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。

みなさん、こんにちは。ソリューションアーキテクトの田村です。 サイバー攻撃の脅威は質的に変化しています。AI の進展により高度な技術を持たない攻撃者でも大規模な攻撃を実行できるようになり、攻撃の参入障壁が大きく下がっています。サプライチェーン攻撃も急拡大しており、正規の開発プロセスそのものが攻撃経路として悪用されるケースが増えています。（参考：「 サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から 」「 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと 」） こうした状況を受け、AWS Japan パブリックセクター技術統括本部では2026年4月よりセキュリティワークショップを月次で開催してきました。4月・5月は特に「ランサムウェア対策」をテーマとしました。ランサムウェアは侵入後に長期間潜伏し、業務データだけでなくバックアップ自体も暗号化する高度な攻撃が増加しており、多くの組織にとって喫緊の課題であるためです。第1回は脅威検知、第2回は統合セキュリティ管理にフォーカスしました。 さらに直近では、Claude Mythos に代表されるフロンティア AI モデルの登場を背景に、これを悪用したサイバー攻撃への対策が急速にクローズアップされています。金融庁は2026年5月22日に「 フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応 」を発出し金融機関に対応を要請、厚生労働省も同日に医療機関を含む重要インフラへの AI を活用したサイバー攻撃について 対策強化の議論を開始 しています。こうした状況を踏まえ、6月12日（金）開催予定の第3回では急遽「Claude Mythos の登場で変化する脅威への対応」をテーマとし、生成 AI 時代の脅威動向を座学で解説するとともに、ハンズオンではアプリケーションの脆弱性管理を体験いただきます。 本記事では第1回・第2回の開催レポートと、今後の取り組みについてご紹介します。 ワークショップの概要 本ワークショップは「ランサムウェア対策」を共通テーマとし、第1回と第2回で異なる AWS セキュリティサービスにフォーカスした内容となっています。講師はシニア セキュリティ ソリューションアーキテクトの中島 章博が務め、前半の座学で近年の脅威動向やセキュリティ対策の考え方を解説し、後半はハンズオン形式で実際に AWS のセキュリティサービスを体験していただきました。 ランサムウェア対策を考える上では、NIST Cybersecurity Framework（CSF）の識別・防御・検知・対応・復旧という各段階に沿って対策を整理することが有効です。 AWS にはこれらの各段階で活用できるセキュリティサービスがあります。 本ワークショップでは「検知」を担う Amazon GuardDuty と、「識別」「検知」を担う AWS Security Hub にフォーカスしました。 以下、各回の内容をご紹介します。 第1回: Amazon GuardDuty で実現する脅威検知（2026年4月10日） Amazon GuardDuty とは Amazon GuardDuty は、AI と ML に AWS と主要なサードパーティーが提供する統合脅威インテリジェンスを組み合わせて使用し、AWS アカウント、ワークロード、およびデータを脅威から保護します。ランサムウェア、バックドア、暗号通貨マイナー、トロイの木馬などのマルウェアを検出することもできます。 ハンズオン概要 参加者一人ひとりにワークショップ専用の AWS サンドボックス環境が払い出されます。この環境にはあらかじめ悪意のあるアクティビティを模したシナリオが構築されており、GuardDuty が実際に検出結果（Findings）を生成した状態になっています。参加者はセキュリティ担当者の立場で、攻撃（Attack）→ 検知（Detect）→ 調査・対応（Respond）の一連の流れを体験します。 ハンズオンは「基礎・設定」「脅威対応シナリオ」の2パートで構成されています。 前半の基礎・設定パートでは、GuardDuty の有効化と検出結果の読み方、自社固有の脅威 IP リストを GuardDuty に登録するカスタム脅威リストの構築、Amazon Simple Storage Service (Amazon S3) にアップロードされたマルウェアを自動検知する Malware Protection for Amazon S3、Amazon Elastic Compute Cloud (Amazon EC2) などのランタイムアクティビティを監視する Runtime Monitoring の設定、Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を組み合わせた脅威通知の仕組みづくりを行います。 後半の脅威対応シナリオでは、ランサムウェア攻撃を模した「攻撃シーケンス検出結果への対応」がメインシナリオです。このシナリオでは、攻撃者が AWS Identity and Access Management (IAM) 認証情報を窃取し、Amazon S3 バケットのポリシーを変更してデータを流出させた後、証拠隠滅のためにログを無効化しバケットを削除する、という多段階の攻撃が再現されています。GuardDuty はこれらの個々のシグナルを相関分析し、「攻撃シーケンス」として一つの重大な検出結果にまとめます。参加者は MITRE ATT&CK の戦術マッピングを手がかりに攻撃の全体像を把握し、AWS CloudTrail で攻撃者の行動を時系列で追跡した上で、IAM 認証情報の無効化や Amazon S3 バケットポリシーの修正といった封じ込めを実践します。 このほか、侵害された Amazon S3 バケットへの対応、IAM 認証情報が流出した場合の対応、Amazon EC2 上で Runtime Monitoring が検出した不正プロセスへの対応、Amazon Elastic Block Store (Amazon EBS) ボリュームのマルウェアスキャンと対応など、実際のインシデントで遭遇する代表的なシナリオに取り組みます。 「GuardDuty をオンにしてはいるが、検出結果が出たときに何を見ればいいのかわからない」「インシデント発生時にどこから調査を始めればよいかわからない」という方にとって、実践的なインシデント対応を安全な環境で体験できる内容です。ワークショップ教材は「 Amazon GuardDuty & Amazon Detective ワークショップ 」として公開しています。 第2回: AWS Security Hub で実現する統合セキュリティ管理（2026年5月15日） AWS Security Hub とは AWS Security Hub は、お客様の重大なセキュリティ問題に優先順位を付け、規模に応じた対応を支援して環境を保護します。クラウド環境全体の可視性を一元化することで、セキュリティ運用を統合します。シグナルを相互に関連付け、実用的なインサイトへと充実させることで重大な問題を検出し、効率的な対応を可能にします。ランサムウェア対策の「予防」の観点から、自環境の弱点を事前に把握し改善しておく上で重要な役割を果たします。 ハンズオン概要 第2回のハンズオンでは、Security Hub が複数のセキュリティサービスの検出結果を相関分析して検出する「露出（Exposure）」の概念を中心に、セキュリティポスチャの改善サイクルを体験しました。 ハンズオンの前半では、Security Hub の概要と露出の仕組みを学びます。露出とは、設定ミス（Misconfiguration）、ネットワーク到達可能性（Reachability）、ソフトウェア脆弱性（Vulnerability）、機密データの存在（Sensitive Data）といった複数の特性を Security Hub が自動的に相関分析し、「このリソースは攻撃者に悪用される可能性が高い」と判断した検出結果です。参加者は実際に露出の検出結果を確認し、潜在的な攻撃パスを視覚的に把握した上で、以下のような修復作業を実践しました。 ネットワークアクセスの制限 : セキュリティグループで不要なポート（Telnet など）を閉じ、SSH アクセスを Amazon Virtual Private Cloud (Amazon VPC) 内に限定する ソフトウェア脆弱性へのパッチ適用 : Amazon Inspector が検出した既知の CVE に対し、AWS Systems Manager Session Manager 経由でパッチを適用する IAM 権限の最小化 : 過度に広範な権限を持つインスタンスプロファイルを特定し、IAM Access Analyzer を活用した最小権限への道筋を確認する 構成の改善 : IMDSv2 の強制適用により、SSRF 攻撃による認証情報窃取のリスクを排除する 後半では、Security Hub の自動化ルール（検出結果に対するアクションの自動実行）、Automated Security Response ソリューションによる修復の自動化、Security Hub と Slack を連携した通知の仕組みなど、運用に直結する内容に取り組みました。 「Security Hub を有効にしたものの、大量の検出結果をどう優先順位付けすればよいかわからない」という方にとって、露出を起点に最もリスクの高い問題から対処していくアプローチを実感いただける内容です。ワークショップ教材は「 Security Hub ワークショップ 」として公開しています。 参加者からのフィードバック 両回とも多くの方にご参加いただき、ご好評をいただきました。 「実際に手を動かすことで理解が深まった」「自組織での活用イメージが湧いた」「普段から利用しているサービスだが、何を見ればいいのか理解できるようになった」など、日々の運用に直結する学びを得られたというフィードバックをいただきました。 まとめと今後の取り組み 本ワークショップシリーズは、皆様のご要望に応じて今後も継続的に開催予定です。次回（2026年6月12日）は「Claude Mythos 時代の脅威と対応」をテーマに、フロンティア AI の普及により変化しつつある脅威動向を座学で扱い、ハンズオンではアプリケーションセキュリティワークショップとして Amazon Inspector を用いた脆弱性管理を体験いただきます。さらに 7月2日（木）には第4回として、お客様自身がフロンティア AI を使って攻撃者より先に脆弱性を検出して対策ができる  AWS Security Agent をテーマに開催予定です。ご関心ある方は担当営業にご連絡ください。 ワークショップで学んだ内容を次のアクションにつなげるために、AWS では以下のようなセキュリティ支援を提供しています。 AWS セキュリティ成熟度モデル : 組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするフレームワークです。脅威検知やポスチャ管理が自組織ではどの段階にあるのか、確認してみてはいかがでしょうか。 Security Health Improvement Program (SHIP) : データ主導でセキュリティ改善を進めるための無償プログラムです。 脅威モデリングワークショップ : 設計段階からセキュリティを組み込みたい方に向けて、サンプルシステムを対象としたワークショップ形式のほか、実際のワークロードを対象とした個別支援も実施しています。 上記の支援にご興味がある方は、担当の AWS アカウントチームまでお気軽にお声がけください。 著者 田村 健祐 (Kensuke Tamura) — AWS Japan, Public Sector, Solutions Architect 梅田 昌太 (Shota Umeda) — AWS Japan, Public Sector, Sr Solutions Architect