このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 4 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明しました。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明しました。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに このブログ記事は、Windows Server のサポート終了への対応ブログシリーズの第 4 部です。この最後のブログ記事では、AWS Application Migration Service (AWS MGN) を使用して Windows Server のインプレースアップグレードを実行する方法について説明します。早速見ていきましょう。 AWS MGN を使用した Windows Server のインプレースアップグレードの実行 お使いの Windows 2012 または Windows 2012 R2 サーバーがまだオンプレミス環境で実行されている場合は、それらのサーバーを AWS MGN を使用して AWS に移行できます。移行の最後にサーバーを新しいバージョンの Windows にアップグレードするように AWS MGN を設定できます。AWS MGN を設定する手順については、この ブログ記事 (訳註：日本語でのAWS MGN 解説動画) をお読みください。AWS MGN で移行する手順を理解できます。 前提条件 1. AWS Identity and Access Management ( IAM ) ロール Windows Server のアップグレードを実行するための AWS MGN で移行後のテンプレートを準備する前に、以下のアクセス権限ポリシーを含む IAM ロール (図 1 参照) を作成する必要があります。 AmazonSSMManagedInstanceCore AWSApplicationMigrationFullAccess 図 1. ロールと権限を含む IAM 権限 2. サブネット ID 移行したインスタンスを実行するサブネット ID を書き留めておきます。サブネット ID は、AWS マネジメントコンソールの Amazon Virtual Private Cloud (Amazon VPC) サービス (図 2 参照) の [サブネット] にあります。 図 2. Amazon VPC とサブネット ID の選択 AWS MGN コンフィギュレーション AWS MGN では、Amazon Elastic Compute Cloud (Amazon EC2) の起動インスタンスで、あらかじめ定義されたさまざまな起動後のアクションを実行できます。組み込みの起動後テンプレートのいずれかを使用して、Windows Server のインプレースアップグレードを実行します。 このステップを開始するときは、ソースサーバーへの AWS MGN エージェントのインストールが既に完了していて、MGN コンソールに表示されている前提とします。 注意： この方法を使用して Windows Server 2008 R2 をアップグレードすることもできます。Windows Server 2008 R2 インスタンスを Windows Server 2016、2019、または 2022 にアップグレードするには、インプレースアップグレードを 2 回実行します。1 回目は Windows Server 2008 R2 から Windows Server 2012 R2 へ、その次は Windows Server 2012 R2 から Windows Server 2016、2019、または 2022 へのインプレースアップグレードです。 Windows Server 2008 R2 を Windows Server 2016、2019、または 2022 に直接アップグレードすることはサポートされていません。  AWS MGN で、 [ソースサーバー] に移動します (図 3 参照)。Windows アップグレードを実行するサーバーをクリックします。 図 3. Application Migration Service のアクティブソースサーバーページ  [起動後設定] を選択します (図 4 参照)。 図 4 Application Migration Service ダッシュボード   [起動後のアクションをアクティブ化する] が [はい] に設定されていることを確認します。それ以外の場合は、 [編集] をクリックします。 図 5. Application Migration Serviceの起動後のアクション   [起動後設定の編集] (図 5 参照) で、 [Systems Manager エージェントをインストールし、起動したサーバーでのアクションの実行を許可する] を有効にします (図 6 参照)。   [テストインスタンスとカットオーバーインスタンス (推奨)] を選択し、 [設定を保存] を選択します (図 6 参照)。 図 6. 起動後のアクションの詳細とデプロイ   [Windows upgrade] を選択し、 [編集] をクリックします (図 7 を参照)。 図 7. 起動後アクションの設定ページ   [アクションの編集] で、 [このアクションをアクティブ化する] をオンにします (図 8 参照)。 図 8. 起動後のアクションページでのアクションの編集 次の情報を入力します (図 9 参照)。 IamInstanceProfile : 前提条件ステップ 1 で作成したプロファイル SubnetId : サーバーをデプロイしたいサブネットを設定します。前提条件セクションのステップ 2 を参照してください TargetWindowVersion : アップグレードしたい Windows バージョンを選択します。 KeepPreUpgradeImageBackUp : 今回の手順では False 設定します。条件に応じて、設定してください。 RebootInstanceBeforeTakingImage : 今回の手順では False 設定します。条件に応じて、設定してください。 入力後、アクションを保存します。 図 9. アップグレード前のイメージを変更しないようにするためのアクションパラメータとオプション 最終的に、起動後の設定に「SSM agent」と「Windows upgrade」の 2 つのアクションが表示されます (図 10 参照)。 図 10. 起動後の設定ページでの SSM Agent と Windows アップグレードの選択  AWS MGN でカットオーバーを行うと、ステップ 9 で設定した 2 つの起動後のアクションによって SSM Agent のインストールと、新しいバージョンの Windows OS へのインプレースアップグレードが実行されます (図 11 参照)。 図 11. Application Migration Service のアクティブなソースサーバーのカットオーバーページ 起動後のアクションは、移行ダッシュボードの [起動後のアクション] でモニタリングできます (図 12 参照)。 図 12. 移行のモニタリング カットオーバーが正常に完了すると、Amazon EC2 コンソールに新しい Windows Server 2019 が表示されるはずです (図 13 参照)。 図 13. EC2 コンソールでの移行完了の検証 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。 まとめ このブログ記事では、AWS Application Migration Service を使用した Windows Server のアップグレード方法について説明しました。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部 : AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 3 部 : AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法  最後に、 この電子書籍 を読んで、NextGen Healthcare、Parsons Corporation、SeatGeek、アーカンソー州裁判所管理局などの組織が AWS を使用して Windows Server ワークロードを移行、最適化、およびモダナイズする方法を参考にしてください。 アップグレードについてご支援が必要な場合は、 こちら から AWS にお問い合わせください。お客様の EOS の状況やニーズへの対応を支援いたします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 Kyaw Soe Hlaing Kyaw Soe Hlaing は、インフラストラクチャ、プラットフォーム、ID 管理を専門とするシニアソリューションアーキテクトです。顧客の複雑なビジネス要件に対応するソリューションの提供やアーキテクチャ設計に情熱を注いでいます。15 年以上の経験を持つ Kyaw は、パートナーと協力して AWS のお客様がクラウド変革の道のりを進めるために支援しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 3 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明しました。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに Windows Server のサポート終了 (End of Support、EOS) への対応ブログシリーズの第 3 部へようこそ。Windows コンテナを使用した EOS のモダナイゼーション方法について順を追って説明します。 早速見ていきましょう。 レガシーな ASP.NET Web アプリケーションを Windows コンテナにリプラットフォーム お客様の EOS の課題解決を支援する中で、レガシーアプリケーションやモノリシックアプリケーションの管理を容易にする目的で Windows コンテナを使用する案件が増えているようです (図 1 を参照) 。ASP.NET Web アプリケーションでは、Windows コンテナが最適な実行方法です。コンテナはもともとポータブルで、スケーラブルで、信頼性があります。ASP.NET Web アプリケーションを Windows コンテナで実行することで、ソースコードの再設計やリファクタリングについて心配する必要がなくなります。EOS となるWindows OS に対応すること以外にも、Windows コンテナにリプラットフォームすることでアプリケーションのモダナイズを開始 (または継続) できます。 図 1. マイグレーションとモダナイゼーションのアプローチ：リホスト、リプラットフォーム、リファクタリング App2Container による.NET Framework アプリケーションのモダナイゼーション 前提条件 これらの前提条件の詳細については、 こちら のドキュメントをご覧ください。 アプリケーションに、新しいOSへの移行を妨げるような、OSとの依存関係や Windows API (例：COM 相互運用) が使われていないか確認します。 組織の要件に基づいてターゲット Windows OS を設定します。 注意 ： Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Kubernetes Service (Amazon EKS) は、Windows コンテナを実行するためにサポートされている 2 つのオーケストレーションプラットフォームです。Windows Server 2022 にアップグレードすることをお勧めしますが、一般的なコンピューティングオプションでは Windows Server 2019 と 2022 がサポートされます。Windows Server 2016 は ECS の Amazon Elastic Cloud Compute (Amazon EC2) 起動タイプでのみサポートされています。 アプリケーションが App2Container (A2C) でサポート されていることを確認してください。 どのオーケストレーションプラットフォームを使用するか決めてください。Amazon ECS と Amazon EKS は Windows コンテナと App2Container の成果物をサポートしているプラットフォームです。 オプションで、 Amazon Simple Storage Service (Amazon S3) バケットを指定すると成果物をバケットに出力することができます。 また、アプリケーションが完全に機能するテスト環境をセットアップして、App2Container CLI ツールでアプリケーションをターゲットにすることができます。セットアップしない場合は、アプリケーションの成果物は App2Container を実行しているサーバーのローカルに保存されます。 手順に従って、移行先の OS バージョン (Windows Server 2019 または 2022) を実行し、移行元のWindow Server 2012 のアプリケーションサーバーからアプリケーションの成果物を抽出するリモートワーカーマシンをセットアップします。 手順については、「 Modernize with AWS App2Container Workshop 」をご覧ください。その結果、図 2 に示すように、.NET ウェブアプリケーションを AWS でモダナイズします。 図 2. .NET の AWS へのモダナイゼーションの例 アプリケーションを発見して分析する。 アプリケーションサーバー上で実行されているすべてのインターネット インフォメーション サーバー (IIS) の Web サイトと Windows サービスを記録する App2Container の分析コマンドを実行します。 分析出力ファイルを確認し、必要に応じて、コンテナのベースイメージを所望の移行先 OS になるように調整します。(例：mcr.microsoft.com/dotnet/framework/runtime:4.8-windowsservercore-ltsc2022 — .NET Framework 4.8 Windows Server Core 2022 イメージ)。これは IIS と OS の構成の分析に基づいて自動的に設定されるはずです。 アプリケーションを抽出してコンテナ化する。 リモートワーカーマシンで extract コマンド を実行して、指定したアプリケーションのアプリケーションアーカイブを生成します。このアーカイブをワーカーマシンにコピーするか、Amazon S3 プレフィックスを指定することができます。 containerize コマンド を実行して Dockerfile を作成します。 コンテナ化されたアプリケーションをデプロイする。 Amazon ECS または Amazon EKS のアーティファクトを含むようにデプロイ設定を調整してください。次に、アプリケーションデプロイを実行してコンテナイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュし、アプリケーションを Amazon ECS または Amazon EKS にデプロイします。 アプリケーションが正常にコンテナ化され、パブリックアクセス向けに保護されたら、本番環境へのデプロイを計画する準備が整います。App2Containerは、アプリケーションのデプロイを容易にする継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインの作成をサポートします。App2Container は、CodePipeline、Jenkins、Microsoft Azure DevOps など、いくつかの CI/CD ツールをサポート しています。App2Container を使用した CI/CD パイプラインの段階的なデプロイについては、ブログ記事「 AWS App2Container を使用してコンテナ化された ASP.NET アプリケーション用の CI/CD パイプラインの生成 (英文) 」を参照してください。 本番環境にプッシュする。 Windows Server 2012 で実行されているレガシーアプリケーションから、デプロイしたコンテナ化されたアプリケーションの前段にある新しいロードバランサーへのパブリック URL のカットオーバーを計画します。 アプリケーションに OS の依存関係がない場合は、最新の Windows OS を使用して新しいビルドサーバーをデプロイし、アプリの Dockerfile の FROM 行を変更し (図 3 参照)、新しいコンテナイメージを構築し (図 4 参照)、 ローリング更新 を行うだけで、今後の OS バージョンのアップグレードは簡単にできます。 注意：本番環境に実装する前に、基盤となるOSに大幅な変更がないことを確認するための適切なテストが必要です。 EOS OS: 図 3. EOS OS コンテナベースイメージ New OS: 図 4. Dockerfile の新しい OS コンテナベースイメージ App2Container の使用手順を詳しく理解するには、 App2Container の公開ドキュメント を参照してください。Amazon Relational Database Service (Amazon RDS) for SQL Server にデータベースを移行するユースケースをさらに詳しく知りたい場合は、 AWS App2Container によるモダナイズワークショップ を参照してください。 リファクタリング — .NET Framework を最新バージョンの .NET へ 組織で.NET Framework コードを最新バージョンの .NET にリファクタリングする準備ができている場合は、 Porting Assistant for .NET と AWS Toolkit for .NET Refactoring を利用できます。.NET 6 もしくはそれ以降のバージョンに移行することで、.NET コードを Linux コンテナで実行できるようになります。 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。アップグレードの進め方をステップバイステップの手順で示しています。 まとめ このブログ記事では、AWS App2Container を活用して .NET ウェブアプリケーションをアップグレードおよびモダナイズする方法について説明しました。このブログシリーズの次のブログ記事では、AWS Application Migration Service を使用して Windows OS をアップグレードする方法を紹介します。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部 : AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 4 部 : AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 アップグレードについてご支援が必要な場合は、 こちら から AWS にお問い合わせください。お客様の EOS の状況やニーズへの対応を支援いたします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Bill Pfeiffer Bill Pfeiffer は、アマゾン ウェブ サービスのシニアソリューションアーキテクトです。Bill は、お客様が安全でコストを最適化したインフラストラクチャを設計、実装、発展できるよう支援することを主な活動としています。Bill は、お客様がビジネス上の課題を技術的ソリューションで解決できるよう支援することに情熱を注いでいます。仕事以外では、ビルは家族と一緒にRV車に乗ってアメリカを旅行したり、ウルトラマラソン距離のスパルタンレースに出場したりすることを楽しんでいます。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 2 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。 第 1 部 では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明しました。 第 2 部 では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明します。 第 3 部 では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。 第 4 部 では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 概要 AWS Systems Manager は、既存のインスタンスを最新バージョンの Windows Server にアップグレードするために利用できる選択肢の 1 つです。このブログ記事では、AWS Systems Manager を使用して Windows Server のインプレースアップグレードプロセスを自動化する方法を紹介します (図 1 参照)。このオプションの詳細を説明したビデオを公開しました。 AWS Online Tech Talks チャンネル にアクセスして (まだ登録していない場合は [チャンネル登録] をクリックしてください)、「 Navigate the Windows Server end of support challenge with AWS 」をチェックしてください。ソリューションが実際に動作していることを確認するには、 34:36 に早送りすることをお勧めします。 図 1. AWS SSM を使用したアップグレードプロセス 前提条件 注意 :この自動化プロセスは Windows Server 2008 R2、2012 R2、2016、2019 でのみ機能します。Windows Server 2008 R2 では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが最初に Windows Server 2012 にアップグレードされ、次に Windows Server 2016 または 2019 にアップグレードされます。 このアップグレードを完了するには、次の前提条件を満たす必要があります。 アップグレードが必要な Amazon EC2 インスタンス アップグレードする予定のインスタンスに SSM エージェントがインストールされ、動作している この自動化をインスタンスで機能させるために、TLS 1.2を有効にする アップグレードを正常に実行するために、ルートに少なくとも 20 GB の空き容量がある インスタンスが既存の Active Directory ドメインに参加している場合は、ホスト名の競合を避けるため、Active Directory に接続できないサブネット ID を指定することを推奨 「 パブリック IPv4 アドレスの自動割り当て 」が TRUE に設定されたパブリックサブネット。これは大きなブロッカーになる可能性があります。その場合は、このブログシリーズの第 1 部で説明した方法を使用してアップグレードすることを検討してください。 Amazon EC2 インスタンスが SSM と通信し、お客様に代わってアップグレードプロセスを実行できるようにする AWS Identity and Access Management (IAM) ロール。必要なロールを作成する方法については、 IAM ドキュメント を参照してください。 注意:この記事で説明されている自動化プロセスは、Windows Server 2008 R2、2012 R2、2016、および 2019 でのみ機能します。これを Windows Server 2008 R2 で実行する場合、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは最初に Windows Server 2012 にアップグレードされ、次に Windows Server 2016 または 2019 にアップグレードされます。また、自動化ドキュメントでは Windows Server のライセンス版や Bring Your Own License (BYOL) 版をアップグレードすることもできますが、BYOL を扱う際には追加の手順が必要であることを忘れないでください。詳細は こちらのドキュメント に記載されています。 制限事項 この自動化方法では、Windows ドメインコントローラー、クラスタ、または Windows デスクトップオペレーティングシステムのアップグレードはサポートされていません。さらに、以下のロールがインストールされている Windows Server 用の Amazon EC2 インスタンスはサポートされていません。 リモート デスクトップ セッション ホスト (RDSH) リモート デスクトップ接続ブローカー (RDCB) リモート デスクトップ仮想化ホスト (RDVH) リモート デスクトップ Web アクセス (RDWA) サポートされているアップグレードパス AWS Systems Manager オートメーションランブック AWSEC2-CloneInstanceAndUpgradeWindows では、以下のアップグレードパスをサポートしています。 Windows Server 2008 R2 から Windows Server 2012 R2 へ、Windows Server 2019 または 2022 へ Windows Server 2012 と 2012 R2 から Windows Server 2016 へ Windows Server 2012 R2 から Windows Server 2019 へ Windows Server 2016 から Windows Server 2019 へ Windows Server 2016 から Windows Server 2022 へ Windows Server 2019 から Windows Server 2022 へ Windows Server インスタンスのアップグレード オートメーションを使用してこのアップグレードを完了する手順を詳しく説明します。オートメーションに必要ないくつかの情報を記録するために、メモなどご用意ください。 OS のアップグレードを進める前に、次の点に注意しましょう。後で必要になります。   AWS マネジメントコンソール で、Windows 2012 のインスタンス ID を取得します (図 2 参照)。 図 2. AWS コンソールの Windows 2012 EC2 インスタンス EC2 インスタンスのネットワークプロパティを見て、パブリック サブネットID を書き留めておきます。 図 3. EC2 インスタンスのネットワークプロパティ AWS Identity IAM コンソールで、SSM にアクセス可能な作成した IAM ロールを選択します (図 4 参照)。以下は、ロールにアタッチする必要があり、インスタンスに関連付けられているポリシー名です。 図 4. IAM コンソールの SSM ポリシー 最後に、インスタンスのパスワードを入力します。 それでは、Windows Server 2012 インスタンスに RDP を実行してみましょう。図 5 に示すように、Windows Server 2012 R2 マシンには、いくつかのアプリケーションがデスクトップにロードされ、システムにインストールされています。アップグレードプロセスが完了したら、これを参考にします。 図 5. RDP セッションの Windows 2012 Windows Server 2012 R2 をアップグレードする準備ができました! AWS Systems Manager コンソールを開き、 [変更管理] セクションにある [オートメーション] (図 6 参照) を選択します。 図 6. AWS コンソールでの AWS Systems Manager Automation [オートメーションの実行] を選択します (図 7 参照)。 図 7. AWS コンソールでのオートメーションの実行 検索フィールドに 「clone」と入力してフィルターを作成します。一連のオートメーションドキュメントが表示されます (図 8 参照)。 「 AWSEC2-CloneInstanceAndUpgradeWindows 」という名前のドキュメントを選択します (図 8 に表示)。 図 8. AWS コンソールのオートメーションドキュメント ドキュメントを読み込んだら、 [オートメーションを実行する] を選択します (図 9 参照)。 図 9. AWS コンソールでのオートメーションの実行 次の画面で、アップグレードするインスタンスを選択します (図 10 参照)。インスタンスにわかりやすい名前がある場合は、その名前を使用してください。そうでない場合は、事前に取得したインスタンス ID を入力します。 図 10. AWS Systems Manager コンソールで EC2 インスタンスを選択 ドロップダウンメニューを使用して、以前に収集した情報を入力します (図 11 を参照)。 – IamInstanceProfile – SubnetId – TargetWindowVersion アップグレードしようとしているインスタンスが BYOL オプションを使用している場合は、「BYOLWindowsMediaSnapshotId」フィールドに Windows Server 2012 R2 インストールメディアの EBS ボリュームのスナップショット ID を入力する必要があります。このセクションを完了したら、ページの下部に移動して [実行] を選択します (図 11 参照)。 図 11. アップグレードパラメータの指定 この時点で、正しいオプションを選択すると、図 12 に示すように [実行の詳細] ページが表示されます。プロセス全体が完了するまでに2時間以上かかる場合がありますのでご注意ください。Windows Server 2008 R2 の場合、自動化によって最初にインスタンスが Windows Server 2012 R2 にアップグレードされ、続いて選択した Windows Server のターゲットバージョンがアップグレードされます。 図 12. システムマネージャーの実行詳細 イメージの作成が完了したので、Amazon EC2 コンソールに移動しましょう (図 13 参照)。左側のペインの [イメージ] で、 [AMI] を選択します。次に、 自己所有 の AMI を選択していることを確認してください。リストにはいくつかの AMI があるかもしれません。オートメーションを起動したときの作成日を確認してください。もう 1 つの手がかりは、 AMI 名: upgraded という属性を使用して検索することです。AMI を見つけたら、 [AMI からインスタンスを起動] を選択します。 図 13. EC2 コンソールに表示される AMI 図 14 に示すように、 [インスタンスを起動] 画面が開きます。起動するインスタンスタイプを選択します。これは、使用状況のメトリクスに基づいてインスタンスを適切なサイズにする機会です。インスタンスをデプロイする正しい VPC とそのサブネットを必ず選択してください。 注意 : Windows Server 2012 R2 システムを複製したときには、必ず元の Windows 2012 R2 システムから取得したパスワードを使用してください。キーペアは、必要に応じて後で新しいインスタンスに追加できます。完了したら、 [インスタンスを起動] を選択します。すべてが正常に完了すると、次の画面が表示されます (図 15 参照)。 図 14. アップグレードされたインスタンスの起動開始 すべてが正常に完了すると、次の画面が表示されます (図 15 参照)。 図 15. 新しいインスタンスの起動が正常に開始 新しくアップグレードしたインスタンスにアクセスできることを確認し、プロセスの前半でコピーした元のパスワードを使用してリモートデスクトッププロトコル (RDP) 経由で接続します。 Amazon EC2 コンソールで、新しくアップグレードしたインスタンスを選択し、 [接続] を選択します (図 16 を参照)。 図 16. AWS コンソールでアップグレードされた EC2 インスタンス [インスタンスに接続] ウィンドウ (図 17 参照) の [RDP クライアント] タブでは、RDP クライアントを使用してサーバーに接続するためのインスタンスのパブリック DNS 名を取得できます。 図 17. アップグレードしたインスタンスに RDP で接続 ログインすると、図 18 に示すように、サーバー上にアプリケーションが表示されます。この場合では、Windows Server 2012 R2 システムにあったアプリケーションと同じものなります。 図 18. RDP で接続したアップグレードされたインスタンス おめでとうございます。これで、 サーバーが Windows Server 2012 R2 から Windows Server 2019 に自動的にアップグレードされました! システムを本番環境に戻す前に、アプリケーションの機能を検証して検証し、互換性の問題がないことを確認する必要があることに注意してください。 クリーンアップ このブログ記事は手順の説明を目的としており、クリーンアップについては省略しています。ステップバイステップのアプローチでは、アップグレードを自動化する方法を正確に示しています。 まとめ このブログ記事では、AWS Systems Manager を使用して Windows Server 2012 を自動的にアップグレードする方法について、手順を追って説明しました。この方法は、より大規模で複雑な環境に最も適用できると考えています。 これは EOS に対処するために利用できる多くの選択肢のうちの 1 つであり、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 1 部: AWS で Microsoft Windows Server 2012 を手動でアップグレードする方法 第 3 部: AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法 第 4 部: AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 この記事で紹介した方法を確認するために AWS の支援を希望される場合は、 こちら からお問い合わせください。AWS は喜んでお客様とお客様のチームと面談し、お客様の EOS 状況に対処するための最適な選択肢を検討します。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 Kyaw Soe Hlaing Kyaw Soe Hlaing は、インフラストラクチャ、プラットフォーム、ID 管理を専門とするシニアソリューションアーキテクトです。顧客の複雑なビジネス要件に対応するソリューションの提供やアーキテクチャ設計に情熱を注いでいます。15 年以上の経験を持つ Kyaw は、パートナーと協力して AWS のお客様がクラウド変革の道のりを進めるために支援しています。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

このブログ記事は、Windows Server 2012 と 2012 R2 のアップグレード方法に関する 4 部構成のシリーズの第 1 部です。 このシリーズでは、2023年10月に予定されているサポート終了イベントに対応するための選択肢についてご説明します。第 1 部では、サポート終了のジレンマと、インプレースでの手動アップグレードの実行方法と、 Windows Server 向けサポート終了移行プログラム (EMP) の概要を説明します。第 2 部では、 Amazon Systems Manager (SSM) を使用してアップグレードを自動化する方法について説明します。 第 3 部では、 AWS App2Container などのモダナイゼーションツールを活用してアップグレードする方法を説明します。第 4 部では、 AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法を説明します。 はじめに Windows Server のサポート終了 (End of Support、EOS) の課題への対応に関する 4 部構成のブログシリーズの第 1 回へようこそ。このブログ記事では、まず EOS を取り巻く課題について説明し、次に AWS 上の Microsoft Windows Server 2012 R2 を Windows Server 2019 に手動でアップグレードする手順について説明します。 概要 Microsoft が 2023年10月10日に Windows Server 2012 のサポートを終了するため、多くの IT 関係者は、このイベントの準備が整っていないか、どのように進めるべきかわからない状態にあります。心配する必要はありません。ソフトウェアのアップグレードにはいくつかの選択肢があります。ただし、それらの選択肢がチームにとってどのように有効なのか理解するのは難しい場合があります。 Microsoft は、他のオペレーティングシステム（OS）やソフトウェアベンダーと同様に、自社製品の EOS の日程を定期的に発表しています。通常、リリースから10〜12年後です。最近の例としては、2020年1月に EOS となった Windows Server 2008 と 2008 R2 のほか、2022年7月に EOS となった SQL Server 2012 や 2012 R2 などのデータベースがあります。このブログでは、2023年10月10日に EOS となる予定の Windows Server 2012 と 2012 R2 を対象としています。 アマゾン ウェブ サービス (AWS) には、これら 2 つのオペレーティングシステムを使用する多くのお客様がいます。これから説明する方法とアプローチのいくつかは、一般的な EOS の懸念事項にも当てはまります。また、更新が必要な難しいアプリケーションに関して懸念がある場合でも、AWS が支援します（このブログ記事の後半の EMP セクションを参照してください）。 このブログ記事では、EOS に関する技術的な問題点と、AWS 上の Windows Server 2012 を手動でアップグレードする手順について説明します。このシリーズの他の記事では、アップグレードに関するその他の選択肢を紹介します。Windows Server 2012 EOS の問題をビジネスの観点からさらに詳しく見るには、次の記事をご覧ください。 Microsoft Windows Server 2012 のサポート終了に関する AWS オプションを知ろう（英文） 。 EOS の課題 最も明らかな課題は、EOS の期限を過ぎてもソフトウェアを使い続けると、セキュリティアップデート、セキュリティ以外のアップデート、バグ修正、テクニカルサポート、オンラインテクニカルコンテンツのアップデートを受けられなくなることです。唯一の例外は、お客様がソフトウェアプロバイダーから拡張セキュリティ更新プログラムを購入した場合です。しかし、このタイプの購入は（過去でも現在でも）大きな懸念には対処せず、問題を将来に先延ばしにしているだけです。 より多くのお金を使わざるを得なくなる可能性もあります。 その他の技術的問題には次のようなものがあります。 OS をアップグレードできない : 新しいバージョンの Windows Server とアプリケーションの互換性がないため、お客様は OS をアップグレードできません。 アプリケーションの非互換性 : 上記の点と同様に、EOS オペレーティングシステムで実行されている一部のアプリケーションはアップグレードできません。 知識や選択肢の欠如 : 多くのITプロフェッショナルは、EOS の問題に取り組むためにどのようなツールが利用できるかを知らないかもしれません。 セキュリティとコンプライアンスに関する懸念 : 多くの規制環境では、アプリケーションとオペレーティングシステムを最新の状態に保つ必要があります。パッチを適用できない古いオペレーティングシステムは、マルウェア、ランサムウェア攻撃、セキュリティ侵害に対して脆弱なままです。 EOS の問題に対処するための人材や資金の不足 : 多くの場合、EOS の日程はIT部門の主な関心事ではなく、優先リストの下位に押し下げられています。 一部のソリューションはコストがかかりすぎる : 一部の延長サポート製品、ソリューション、オファーは、IT部門にとって書類上は見栄えが良いものの、多くの場合、費用がかかり、タイムリーに採用されないことがあります。 新機能やイノベーションの欠如 : 古いオペレーティングシステムには、現在のソフトウェアに期待されるような新機能がありません。 EOS の重要な技術的課題がいくつか明らかになったところで、AWS がそれらの課題への対応にどのように役立つかを見てみましょう。今日のビジネス環境では、何もしないという選択肢はありません。 EOS に対する AWS の技術的ソリューション AWS とそのパートナーは、専用のプログラム、ツール、技術支援により、お客様の Windows Server ワークロードの移行、アップグレード、モダナイズを支援することに重点を置いています。環境を評価や、Microsoft のライセンスオプションの見直しを行う際には、AWS を頼りにして、全体を通してサポートすることができます。 次のセクションでは、Windows Server 2012 R2 の手動アップグレードプロセスについて説明します。この方法、および関連するブログ記事シリーズに記載されている方法は、Windows 2008 R2などの古い EOS オペレーティングシステムにも適用できることに注意してください。サポートされている Windows Server のアップグレードの概要については、 こちら をご覧ください。 始める前に、テストを行って、アップグレードした OS で実行されているアプリケーションが完全に機能することを確認することが重要です (このブログ記事やシリーズでは説明はしません) 。 前提条件 以前、「 Amazon EC2 Windows Server インスタンス の OS を新しいバージョンにアップグレードする方法を教えてください 」というタイトルのブログ記事を公開しました。 その記事では、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのサーバー移行を完了する方法についてのガイダンスを共有しました。このブログ記事は、このアップグレードに伴う参考資料となります。 アップグレードを開始する前に、 Amazon マシンイメージ (AMI) を作成するか、 Amazon Elastic Block Storage (EBS) ボリュームのスナップショットを作成します。このステップは、アップグレードプロセス中に問題が発生した場合の保護をさらに強化します。この方法をテストする前に、必ずバックアップを取っておくことをお勧めします。 Windows 用 EC2 ユーザーガイド では、パブリックインストールメディアを使用してインプレースアップグレードを実行することを推奨しています。BYOL バージョンの Windows Server をアップグレードする予定がある場合は、 独自のインストールメディアを作成する必要があること に注意してください。この ビデオ では、Windows Server 2012 R2 を実行している t2.large EC2 インスタンスをアップグレードする方法を示しています。インスタンスがいつデプロイされたかによって、開始前に実行する必要のある追加の手順があります。これには次のようなものがあります。 AWS マネジメントコンソール から、アップグレードする Windows Server のインスタンス ID を収集します。これは後で必要になります。  10 GB 以上の空きディスク容量があることを確認してください。 ユーザーガイドのリスト と比較して、インスタンスに最新の準仮想化 (PV) ドライバーがインストールされていることを確認してください。 古い世代のシステムには EC2ConfigService がインストールされている可能性があります。これは削除して、新しい EC2Launch サービスに置き換える必要があります。 Amazon Systems Manager (SSM) エージェント がインスタンスにもインストールされていることを確認してください。これにより、追加の自動化を実行し、今後インスタンスを管理できるようになります。 図 1 に示すように、Amazon EC2 コンソールにアクセスします。 [Elastic Block Store] セクションにある [スナップショット] を選択します。ドロップダウンで、 パブリックスナップショット を選択します。 図 1.「スナップショット」のリストを表示する Amazon EC2 コンソール 検索 (図 2 参照)に、「所有者エイリアス =「amazon」、説明:「Windows 2019 English Installation Media」というフィルターを含めます。 図 2. Amazon EC2 コンソールで Windows 2019 English Installation Media のフィルタを設定 図 3 に示すように、スナップショットを選択して確認します。次に [アクション] をクリックし、ドロップダウンから [スナップショットからボリュームを作成] を選択します。 図 3. Amazon EC2 コンソールでスナップショットリストと「スナップショットからボリュームを作成」アクションの表示 ボリュームを作成するときは (図 4 を参照)、インスタンスが配置されている正しいアベイラビリティーゾーンを選択し、最後までスクロールして、 [ボリュームの作成] を選択します。 図 4. ボリューム設定メニュー、インスタンスが正しいアベイラビリティーゾーンにあることを確認する方法、「ボリュームを作成」アクション ボリュームを作成したら、そのボリュームを選択して詳細を表示し、インスタンスにアタッチします (図 5 参照)。 図 5. ボリューム作成の成功 ボリュームをアタッチするには、 [アクション] を選択します。次に、ドロップダウンから [ボリュームのアタッチ] を選択します (図 6 参照)。 図 6.「ボリュームのアタッチ」画面 ボリュームのアタッチウィンドウで、アップグレードするインスタンスをリストから選択します。次に、 [ボリュームのアタッチ] を選択します (図 7 参照)。 図 7.「ボリュームのアタッチ」基本詳細画面 RDP または Amazon Fleet Manager を使用してインスタンスに接続します。次に、ディスクの管理を使用して Windows 2012 R2 マシンにボリュームをアタッチします。GUI を使用するか、PowerShell コンソールから diskmgmt.msc を実行できます。 ボリュームを右クリックして オンライン に設定します (図 8 参照)。 図 8. ディスクの管理を使用してボリュームを「オンライン」に設定 これでドライブがマウントされ、システムに d:\ ドライブとして接続されました (図 9 参照)。 図 9. ボリューム D: がシステムに接続 補足 ：マウントしたドライブのフォルダをご確認ください。インストールメディアによっては、ISOファイルの形式で保存されてる場合があります。その場合は、ISOファイルをマウントして、そちらで次の作業を進めてください。 いよいよアップグレードを開始します。PowerShell コンソールを開き、マウントしたばかりのドライブにディレクトリを変更して、次のコマンドを送信します。. /setup.exe /auto upgrade すべてが正しく完了したら、Windows Server 2019 セットアップのインストールウィンドウが表示されます。 Windows Server 2019 Datacenter エディション を選択します (図 10 を参照)。 図 10. Windows Powershell イメージ。Windows Server 2019 Datacenter (Desktop Experience) を選択 完了するまで画面の指示に従ってアップグレードを続行します。アップグレードプロセス中に、システムが数回再起動します。 OS のアップグレードが完了したら、システムを本番環境に戻す前にアプリケーションの機能を検証できます。 クリーンアップ アタッチしたインストールメディアのボリュームをデタッチしてください (図11を参照)。インストールメディア自体が不要となった場合は、EBS ボリュームを削除してください。 図 11. EBAボリュームのデタッチ AWS EMP AWS は、Windows Server 向けサポート終了移行プログラム (EMP) を使用して、レガシーな Windows Server アプリケーションを AWS 上の最新のサポート対象バージョンの Windows Server に移行するお手伝いをします。EMP には、レガシーアプリケーションを Windows Server 2003、2008、2012 から AWS でサポートされている新しいバージョンに移行するためのツールが含まれています。EMP ツールはセルフサービスオプションとして、または AWS パートナーまたは AWS プロフェッショナルサービスの支援を受けて自由に使用できます。 まとめ このブログ記事では、技術的な観点から見た Windows Server の EOS を取り巻く課題と、アップグレードに向けた対策が必要となる理由について説明しました。さらに、Windows Server 2012 と 2012 R2 の手動アップグレード方法についても説明しました。 この 4 部構成のブログシリーズでは、EOS に対処するためのさまざまな選択肢と、AWS のテクノロジー、ツール、エキスパートがこれらの問題への対処にどのように役立つか説明したことを覚えておいてください。 第 2 部 : AWS Systems Manager を使用して Microsoft Windows Server のアップグレードを自動化する方法 第 3 部 : AWS 上の Windows コンテナを使用して Microsoft Windows Server 2012 をアップグレードおよびモダナイズする方法 第 4 部 : AWS Application Migration Service を使用して Microsoft Windows Server 2012 をアップグレードする方法 ご支援が必要な場合は、 こちら からお問い合わせください。お客様の特定の EOS 状況について把握し、AWS でのアップグレードをお手伝いします。 AWS は、お客様がクラウドを最大限に活用する方法を評価するご支援をします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、これらお客様の仲間入りしてください。Windows Server または SQL Server のモダナイゼーションの詳細については、 Windows on AWS をご覧ください。今すぐ移行を開始するには、 こちら からお問い合わせください。 Mike Adams Mike Adams は AWS の世界的な市場開拓スペシャリストです。マイクロソフトのワークロードを AWS に移行し、運用効率とコスト効率を向上させる方法を顧客に示すことを主な活動としています。AWS に入社する前は、Mike は Ivanti、VMware、Symantec、VERITAS Software で製品マーケティングの役職を歴任していました。Mike のキャリアは、ギガ・インフォメーション・グループ (現在はフォレスター・リサーチのグループ) で業界アナリストとしてスタートしました。 Gianpaolo Albanese GianPaolo Albanese は、ニューヨーク地域に拠点を置くアマゾン ウェブ サービスのマイクロソフトスペシャリストソリューションアーキテクトです。GP は、お客様の Windows アーキテクチャ、AWS クラウドへの移行、最適化を支援することを主な活動としています。GP は、フィンテック業界で 30 年以上の経験を持つ IT プロフェッショナルであり、大規模インフラストラクチャ、移行、およびモダナイゼーション活動のマネジメントを専門としています。過去 2 年間、GP はお客様がサポート終了の課題に対処できるよう支援することに全力を注いできました。 この記事の翻訳はソリューションアーキテクトの平良允俊が担当しました。原文は こちら です。

こんにちは！アマゾン ウェブ サービス ジャパン合同会社（AWS Japan）のパブリックセクターチームです。 今回のブログでは、2023 年 6 月 13 日(火)・14 日(水) にカリフォルニア州 アナハイムで開催された「AWS re:Inforce 2023」における、梅谷 晃宏 氏（デジタル庁 エグゼクティブアドバイザー）、山本 教仁 氏（同 シニアエキスパート）の講演内容をダイジェストでご紹介します。 Amazon Web Services, Inc. (AWS) では、クラウドセキュリティとコンプライアンスのグローバルカンファレンスである「AWS re:Inforce」を毎年開催しています。今年の目玉の一つが、デジタル庁 梅谷氏、山本氏のBreakout sessionへの登壇です。 日本政府が進めているガバメントクラウドの取組や、AWSを活用した大規模なリスク管理のアプローチまで、全世界に向けた情報発信を頂きました。公共部門のみならず、規制の厳しい業種・業態においてクラウド活用を検討されている皆様には非常に参考になる内容となっています。是非ご一読ください。 「デジタル敗戦からの変革を目指して」 講演の序盤、コロナ禍を契機としたデジタル庁の設立当時の状況について、梅谷氏はこう振り返ります。 「過去 20 年の努力にも関わらず、新型コロナウイルスの流行という緊急事態に対して、政府の情報システムは有効に対応することができたとは言えないでしょう。平井卓也 初代デジタル大臣が“デジタル敗戦”（※）と表現した状況そのものです。」 （※出所：総務省 「 令和3年版　情報通信白書」 第１部 第３節 　） このコロナ禍において、梅谷氏はクラウドを活用した「ワクチン接種記録システム」のインフラ開発をリードしていきます。 「1700 を超える全国の自治体、そして 1 億 2000 万人の日本国民がエンドユーザーとなるシステムを二ヵ月という短期間で構築し、厳格なセキュリティ要件を遵守することは、極めて困難なことでした。ですが、IaC（Infrastructure as Code）によるベースラインの構築等、現代のクラウドサービスに実装されている最新のテクノロジーをフル活用することで、期日通りのサービス開始と、その後の継続的な改善を実現し、過去 2 年間の安定稼働を実現しています。」 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 この実務的に実証された成功をより共通的に政府、自治体で活用できるように標準化を進めたものが、政府共通のクラウドサービス環境である「ガバメントクラウド」と呼ばれるクラウドの利用環境です。 「マネージドサービスと自動化によって手作業を削減し、どのようなシステムであっても政府システムとして必要となるセキュリティやリスク要件をIaCテンプレートにコードで実装することで、一定水準以上のセキュアで均質な環境を用意し、システムオーナーはその上にアプリケーションを開発することに集中することで、全体の開発スピードと効率性、安全性を確保できるようになります。ガバメントクラウドでは、こうしたクラウドの特性を最大限活用し、迅速かつ柔軟に、安全でコスト効果の高いクラウド環境を提供することを目指しています。」 梅谷氏は、今後の展開とともに、ご自身のパートをこう締めくくります。 「ガバメントクラウドをベースに政府ITの構造や慣習をより良い物へと変革していくことになるでしょう。例えば、民間企業各社等とも連携をしながら、政府システムの SaaS 市場の拡大を図っていくといったことが考えられます。」 「ガバメントクラウドが挑む 5 つの課題」 そして、山本氏からは、ガバメントクラウドの発足時にどのような課題に直面したのか、またクラウドを活用することでそうした課題にどのように対応してきたのか、解説を頂きました。以下、5 つのカテゴリに整理されています。 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 データガバナンス（Data governance） 日本国内にデータが保持されるように、東京もしくは大阪のリージョンのみを許可。アカウントの所有権を国機関や地方公共団体にしてデータの所有権を明確にし、暗号化サービスやコンフィデンシャルコンピューティングを活用して、データの機密性を担保。 スケール（Scale） 13 の中央省庁や 1700 の地方自治体、そして準公共領域等の大規模システム環境の管理。AWS Control Tower を活用したマルチアカウント構成、AWS Security Hub によるガードレールの実装。 予算（Budgets） クラウド利用料の従量課金の実現（月額）や業務区分に応じた請求書＝Payer Account の分割。クラウド利用料の可視化によるトレンドの把握やコスト意識の醸成。 従来型セキュリティ（Traditional security） CI/CD パイプラインによる本番環境メンテナンスの自動化（ゼロタッチプロダクション）。マネージドサービス/IaC 主体のアーキテクチャによる OS 運用の廃止、一過性のテストに終わらない継続的なセキュリティ監視やアラート通知。 レガシーアーキテクチャ（Legacy architecture） 政府文書（「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」）における“クラウドスマート”の明記、ワクチン接種記録システムにおけるモダン化の実績、アプリケーションのモダン化に向けた2段階のアプローチ（R1：Replatform、R2：Rebuild）の定義。 AWS re:Inforce 2023 Youtube特設ページ より。登壇風景 その他、AWS の Greg Eppel （Cloud Operation Global Tech Leader）及び AWS Japan の大富部貴彦（パブリックセクター統括本部 官公庁事業本部長）から、政府機関のお客様に対する支援内容や、AWS セキュリティソリューション及びそれらを活用したリスク管理策について、ご紹介をしています。講演内容は こちら より是非ご覧ください。 Learn More AWS re:Inforce 2023 「Managing risk in a regulated environment, feat. Japan Digital Agency (GRC302)」 ─の講演内容は こちら 日本の公共部門の皆様へのご案内 AWS では、政府・公共部門、パブリックセクターの皆さまの各組織におけるミッション達成が早期に実現するよう、継続して支援して参ります。 今後とも AWS 公共部門ブログ で AWS の最新ニュース・公共事例をフォローいただき、国内外の公共部門の皆さまとの取り組みを多数紹介した 過去のブログ投稿 に関しても、ぜひご覧いただければ幸いです。お悩みの際には、お客様・パートナー各社様向けの相談の時間帯を随時設けておりますので、ぜひ AWS までご相談ください（ Contact Us ）。 ＊　＊　＊　＊ このブログは、アマゾン ウェブ サービス ジャパン合同会社のパブリックセクターチームが投稿しました。 ＊　＊　＊　＊

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 今週は Amazon RDSとAmazon AuroraのExtended Support開始をアナウンス しました。この機能は多くのお客様からご要望をいただいていたもので、あるバージョンのデータベースのサポート終了日が迫っているがバージョンアップの検証が間に合わないのでなんとかしてほしい、というケースに対応するものです。ソフトウェアのバージョンアップは避けて通れないものですが、いろいろな事情ですぐに着手できないケースは現実的に存在するので、そういった場合に新たな選択肢を提供できるサービスですね。 一方で、この機能は インスタンスのvCPUあたり1時間の費用が発生 します。長期間利用すればそれだけコストが増加することには注意してください。我々としては、今まで通りタイムリーなバージョンアップを強くお勧めしています。あくまでも「いざというときのプランB」としての選択肢が増えた、と捉えていただくのが良いのではないかなと思います。 それでは、8 月 28 日週のアップデートを振り返ってみましょう。 2023 年 8 月 28 日週の主要なアップデート 8/28(月) AWS Systems ManagerのPatch ManagerがLinux OSの新しいバージョンに対応 Patch ManagerはOSのパッチ管理を可能にするAWS Systems Managerの機能ですが、今回Linux OSの新しいバージョンをサポートし、新たにRed Hat Enterprise Linux(RHEL) 8.7, 9.0, 9.1, 9.2と、Rocky Linux 8.6, 8.7, 9.0, 9.1, 9.2と、Oracle Linux 8.6, 8.7, 9.0, 9.1, 9.2に対応しました。 AWS NeuronがLlama 2, GPT-NeoX, Stable Diffusion XLなどのモデルに対応 AWS Neuronは高性能で費用対効果の高いディープラーニング関係処理を可能にするSDKで、AWS InferentiaやAWS Traniumによるアクセラレーションを容易に実現します。今回 AWS Neuronバージョン2.13 で、新たに生成系AIアプリケーションで利用されるモデルであるLlama 2, GPT-NeoX, Stable Diffusion XL, CLIPに対応しました。Llama 2については学習と推論を、GPT-NeoXについては学習を、Stable Diffusion XLとCLIPについては推論をサポートしています。 8/29(火) Amazon VPC CNIプラグインがKubernetesのNetworkPolicyリソースに対応 Amazon VPC CNI(Container Networking Interface)プラグインを利用して、KubernetesのNetworkPolicyによるPod間の通信制御を行うことができるようになりました。この機能を利用するとPod間の通信を様々な要素に基づいて許可・拒否する設計を容易に実装に落とし込むことができます。 Amazon Connect Casesが日本語をはじめ9つの言語に対応 コンタクトセンターのサービスであるAmazon Connectには、一度の対応で完了しないようなお客様の課題解決のためにケース管理を行う機能として Amazon Connect Cases が用意されています。今回、Amazon Connect Casesが日本語をはじめとする9つの言語に対応し、日本国内のお客様向けの業務でも利用しやすくなりました。 8/30(水) Gateway Load Balancer Endpointを仮想プライベートゲートウェイとVPCサブネットの間に配置可能に AWS Direct ConnectやVPNを利用してオンプレミス環境とVPCを接続する場合に、オンプレミス側からの通信の出入口となるのが仮想プライベートゲートウェイ(Virtual Private Gateway)です。今回、仮想プライベートゲートウェイから流入するトラフィックがVPCサブネットに到達する前に、Gateway Load Balancer Endpointにルーティングする設定が可能になりました。これによって、オンプレミス側からのトラフィックをAWS Network Firewallやサードパーティソリューションで保護するように構成することが可能になります。 AWS Amplifyで多要素認証に時刻ベースのワンタイムパスワードをサポート AWS AmplifyのAndroid, Swift, Flutterライブラリで、多要素認証(MFA)の方式として時刻ベースのワンタイムパスワード(TOTP, Time-based One-Time Passwords)をサポートしました。詳細については ブログ記事 をご覧ください。 Amazon Kinesis Data Analytics改めAmazon Managed Service for Apache Flinkを発表 Apache Flinkを利用してストリーミングデータをリアルタイムで変換・分析するためのサービス、Amazon Kinesis Data Analyticsがサービス名を変更し、Amazon Managed Service for Apache Flinkとして再デビューしました。なお、名称変更に伴う機能の変更はありませんので、既存のアプリケーションは従来通り動作しますのでご安心ください。 Amazon S3がDNSクエリへの応答時に多値応答をサポート Amazon S3が、S3エンドポイントに関するDNSクエリに対する応答として多値応答(Multivalue answer)をサポートしました。この機能を利用するとDNSクエリに対して最大8つのIPアドレスを回答として受け取ることが可能になり、これによって複数のIPアドレスに対して同時接続することでスループットを向上させることが可能です。新しいバージョンのAWS SDKを利用している場合は、アプリケーションの変更なしにこのアップデートのメリットを活用することができます。 AWS Clean Roomsで分析結果の配信設定機能とApache Icebergサポートを発表 AWS Clean Roomsで2つの新機能が発表されました。ひとつは分析結果の配信設定機能で、AWS Clean Roomsを介して処理された分析結果を、分析者に自動的に送付するのではなく「結果を受領する権限をもつと設定されたメンバー」に限って送付することができます。これによって分析者と結果受領者を分離することが可能になり、複雑なデータ取り扱い要件がある場合にも対応できるようになります。ふたつめはApache Icebergテーブルのサポートで、こちらはプレビューの扱いです。 8/31(木) Amazon RDS Database Preview EnvironmentでPostgreSQL 16 Release Candidateが試用可能に BetaバージョンやRelease Candidateバージョンなどを先行して試用できる Amazon RDS Database Preview Environment で、Amazon RDSで稼働するPostgreSQL 16をプレリリース版として評価できるようになりました。 9/1(金) Amazon AuroraとAmazon RDSでMySQLとPostgreSQLのExenteded Supportを発表 MySQL 5.7やPostgreSQL 11とそれ以降のメジャーバージョンを実行するAmazon AuroraとAmazon RDSについて、Extended Supportを提供することを発表しました。2023 年 12 月以降、コンソールやCLI/APIを通じてExtended Supportにオプトインすることが可能になります。Extended Supportではオープンソースコミュニティがメジャーバージョンのサポート終了後に、重要なセキュリティとバグの修正を提供します。また、メジャーバージョンの標準サポート終了日から最大3年間にわたって特定バージョンのインスタンスを継続利用できます。この機能は新しいメジャーバージョンにアップグレードするための検証が間に合わない、といった場合に作業時間を確保することを目的として提供される有償サービスです。バージョンアップは随時実施すべきという考え方は変わりませんのでご注意を。 Amazon SageMaker Canvasで新たに8つのデータコネクタが利用可能に コード開発や機械学習の深い知識なしにデータに基づく予測を実現するAmazon SageMaker Canvasで、新たに8つのデータコネクタが利用可能になりました。Salesforce, Databricks, SQL Server, MySQL, PostgreSQL, MariaDB, Amazon RDS, Amazon Auroraに対応しています。また、Snowflakeからストレージを介しないデータの取り込みと、SalesforceとSnowflakeのOAuth 2.0接続もサポートされ、これまでよりも広範なデータソースからのデータを利用した予測が可能です。 Amazon Cognitoが大阪リージョンとイスラエルリージョンで利用可能に Amazon Cognitoがアジアパシフィック（大阪）リージョンと、イスラエル（テルアビブ）リージョンでご利用いただけるようになりました。 Amazon RDS for PostgreSQLのバージョン13と14でPL/Rustに対応 PostgreSQLのバージョン13と14を実行するAmazon RDSにおいて、新たなTrusted Procedural LanguageとしてRust言語をご利用いただけるようになりました。複雑な計算処理を実行するタイプのデータ処理に最適です。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

昨今、国内企業においても「生成系 AI 」をビジネスにおいて効果的に利用する動きが活発化してきています。 アマゾン ウェブ サービス （以下、AWS ） は、お客様がこの新しいテクノロジーの価値をフルに活かすために生成系 AI の専門家からなるチームを設置するとともに、柔軟性と費用対効果に優れた生成系 AI サービスを企業に提供することで、あらゆる組織が AI を活用できるよう支援するという目標を掲げています。 その一環としてAWS は 2023 年 6 月 22 日（米国時間）に、お客様の生成系 AI ソリューションの構築と展開を支援する新プログラム「 AWS 生成系 AI イノベーションセンター 」を稼働開始しました 。1 億米ドル（約 140 億円）を本プログラムに投資し、 世界中のお客様と AWS の AI と機械学習分野のエキスパートをつなぎ、生成系 AI によるサービス開発や業務効率化をサポートし企業がアイデアをすばやく効果的に実現できるよう支援するものです。 また、AWS ジャパンは、2023 年 7 月 3 日に、日本独自の施策として大規模言語モデル（ LLM ） 日本に法人または拠点を持つ企業・団体を支援する「 AWS LLM 開発支援プログラム 」を開始しました。本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンス、AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット 及びビジネス支援等のサポートを提供します。そしてこの度、本プログラムが支援する企業・団体が正式に決定し、本格的な LLM 開発支援が始まり、2023 年 12 月以降の成果発表会へと進むことになります。 本日 2023 年 9 月 4 日に開催されるキックオフ会では、AWS LLM 開発支援プログラム採択結果の発表に加え、採択された一部企業・団体からの挨拶も予定されています。また AWS からは、今後のプログラム詳細の説明、技術スペシャリストによる具体的な支援体制などの紹介を行います。 AWS LLM 開発支援プログラム採択企業（公開可能な企業および団体）※社名五十音順 会社・団体名（五十音順） ・カラクリ株式会社 ・株式会社サイバーエージェント ・ストックマーク株式会社 ・Sparticle 株式会社 ・Turing 株式会社 ・株式会社 Preferred Networks ・株式会社 Poetics ・株式会社松尾研究所 ・株式会社マネーフォワード ・株式会社ユビタス ・株式会社 Lightblue ・株式会社リクルート ・株式会社リコー ・rinna 株式会社 ・株式会社ロゼッタ ・株式会社わたしは AWS では、日本における生成系 AI の拡大、LLM の選択肢拡大に向けてこれからも支援を継続していきます。

みなさん、こんにちは。カスタマーソリューションマネージャー (CSM) の北川です。今回は AWS コストの最適化を行う際に役に立つ、コストモデルを用いたクラウドコストの見積もりの考え方と、出来上がった見積もりについてオンプレミス環境とクラウド環境の見積もりを比較する際の注意点をご紹介します。 コストのモデル化を行うことで、クラウド上で新たに稼働するワークロードの総保有コスト (TCO) の見積もりや、投資収益率 (ROI) の算出が可能になります。比較の際の注意点を確認いただくことで、適切な視点でコストの比較を行うことができるようになります。 クラウドコストの見積もりツール モデルのお話をする前に、まずは代表的な見積もりツールのご紹介をします。 料金ページ Amazon Web Service の各サービスにはウェブページが用意されており、サービスの内容、仕組み、料金設定の詳細が記載されています。コストの透明性は AWS の理念の一部であり、ウェブページを参照することでAWS のサービスに関連するコストを確実に把握できます。例えば、 AWS Lambda の料金は Lambda リクエストの所要時間 (ミリ秒単位) や、リクエストに割り当てられたメモリ量などに基づいて計算されます。当該サービスの 料金ページ には、詳細な料金の計算方法に加えて、具体的な例も記載されているため、予想される使用量に応じてコスト見積もりをすることができます。 AWS Price List API AWS の料金情報の取得および使用方法をプログラム的に行うには、 AWS Price List API を使用してください。JSON と HTML を使用して AWS サービスの価格をクエリできます。 また、 Amazon Simple Notification Service (Amazon SNS) の通知を購読して、価格の変動や、新サービスの導入時にアラートを受け取ることも可能です。 AWS 料金見積もりツール (AWS Pricing Calculator) AWS 料金見積もりツール (AWS Pricing Calculator) を用いてコスト見積もりを行うことも可能です。料金見積もりツール自体には こちら からアクセス可能です。このツールは、使用予定の AWS サービスと、その使用方法を指定することでコスト見積もりを行います。見積もり結果は、 CSV、 PDF、 JSON にエクスポートすることやリンクで共有することが可能です。リンクは公開リンクのため、機密情報が含まれないように注意が必要です。また、複数の条件を比較したい場合には、条件を変えて複数見積もりを作成することや、見積もりをグループに分類してグループ単位でコストの確認することも可能です。リージョンにより提供されているサービスが異なることも反映されています。なお、AWS 料金見積もりツールで算出可能な対象サービスは こちら をご参照ください。 移行評価ツール (AWS Migration Evaluator) 大規模なクラウド移行案件では、数百から数千のシステムが対象となることがあり、それぞれのシステムにおいてサーバとライセンスを特定して、AWS へのマッピングを行い、サイジングを行い最適化の検討が必要となります。この場合には、 移行評価ツール (AWS Migration Evaluator) を使用することが可能です。移行評価ツールは、大規模なクラウド移行案件の概算をするための優れたツールであり、仮説をもとにしたコスト再見積もりの自動化に加えて、主要なステークホルダーや意思決定者と共有するためのレポート (Business Summary Report) も提供します。当該ツールを使用するためには、 こちらのフロー を参照し、移行評価をリクエストする際には こちらのページ から必要な情報を送信ください。 クラウドコストモデル クラウド見積もりを行うためのコストモデルとして、まずは (1) 技術的なアーキテクチャの整理 から始めます。これには、既存環境の情報収集に加えて、新環境の要件の整理が含まれます。次に、想定しているアーキテクチャコンポーネントを実現するために、 (2) AWS サービスの特定とマッピング を行います。AWS サービスを特定した後には、要件を満たすために (3) AWS リソースの選定 をします。最後に、前述の見積もりツールを用いて (4) コスト概算の算出 をします。概算見積もりは設計を進める中で再作成が必要となる場合もあります。 1. 技術的なアーキテクチャの整理 見積もり対象がオンプレミスの移行ワークロードであるか、クラウド新規のワークロードであるかによって技術的なソリューションの整理を行う切り口が異なります。対象が移行ワークロードである場合には、クラウド環境の適切なリソースを選択するために既存環境のリソース使用履歴や稼働実績の情報が役に立ちます。対象がクラウド新規のワークロードである場合には、まずはアーキテクチャ方針の決定が必要です。アーキテクチャ方針は AWS Well-Architected フレームワーク を参考にして決定することが可能ですが、要件を踏まえてコストのトレードオフが必要な項目が含まれます。トレードオフとしては例えば、可用性の要件に応じてマルチ AZとするかマルチリージョンとするか、ということがあります。併せて、サードパーティー製品の構成やライセンス要件についても確認が必要です。オンプレミスのライセンスがそのままクラウド環境でも使用できるかどうかや、移行期間に環境が現新２環境になったときにライセンス追加が必要になるかどうかなどを明確にすることが必要です。 2. AWS サービスの特定とマッピング 技術的なソリューションの整理を行なった後には、ソリューションを実現する詳細アーキテクチャの決定をするために、ソリューションとAWSサービスのマッピングを行います。マッピングとは例えば、コンピューターサーバー（図ではCompute serverと表記）を Amazon EC2 にマッピングすることや、データベースサーバー（図ではTransactional databaseと表記）を Amazon RDS に変更することを行います。マッピングを行う際には、選んだAWS サービスが要件を満たすことを十分に確認することが必要です。 マッピングの例） 3. AWS リソースの選定 マッピングを行なった AWS サービスをより詳細化するために AWS リソースの選定を行います。リソースの選定としては例えば、システム要件を満たすために必要な、Amazon EC2 のインスタンスタイプを判断し決定することを意味します。 リソースの選定の例） 4. コスト概算の算出 AWS リソースの選定まで進めることで、コストの概算が可能になります。コストの概算には、前述のクラウドコストの見積もりツールを使用します。ワークロードによっては、リザーブドインスタンス、 Savings Plans、 スポットインスタンス などの購入オプションを使用する方針を決めることでさらに最適なコスト見積もりが可能です。例えば、移行期間はリソース使用量の変動が大きいためオンデマンド形式での購入を行い、移行後に安定稼働したところでリザーブドインスタンス や Savings Plans の購入を行うという方針や、冪等性が保証されるワークロードに対しては常にスポットインスタンスを使用する方針などが考えられます。 他の概算手法としては、実装と測定 (Build and Measure) アプローチがあります。 Proof-of-concept (PoC) として実際に小さな環境を実装してみて、AWS Cost Explorer でコストを確認することで、正確な予想の基準となる金額を実際に測定することが可能です。 PoC を実施する際に、PoC 用の AWS リソースに対して専用の AWS コスト配分タグ を付与することでリソースごとのコスト内訳を Cost Explorer で確認可能です。コスト配分タグについては、 こちらの記事 も合わせてご参照ください。 コストに関する追加の検討項目 より正確なコスト算出を行うために、例えば Amazon CloudWatch , AWS CloudTrail , Amazon GuardDuty などの監視ツールやセキュリティツール、バックアップに使う AWS Backup などの運用ツールのコストを含めることも重要です。また、開発やテストに必要な追加環境の検討も必要です。 AWS 金額見積もりツールを用いることで、これらの追加の検討項目についてもあわせて概算が可能です。 オンプレミス環境とクラウド環境のコスト比較 クラウド環境のコストを算出した後にはオンプレミス環境のコストとの比較が必要となるケースが多くあるかと思います。ここでは両コストを比較する際の注意点をご紹介します。 総所有コストの比較条件の一致 総所有コスト (TCO)を比較する際には、オンプレミス環境とクラウド環境で同一条件となるように注意が必要です。比較時に条件の不一致が発生しやすい項目は表中にオレンジで強調表示をしています。例えば、イニシャルコストの計算であれば、ハードウェアやソフトウェアの調達費用の算出時にサーバやストレージ費用だけでなく、ラック、電源タップ、スイッチ等の周辺機器も含めて条件が一致していることの確認が必要です。また、ランニングコストの計算であれば、物理機器の管理や保守の人件費、データセンターの使用量、場所代、電気代、空調代、ネットワーク機器代、ネットワーク回線費用や、定期的に発生する保守切れやリース切れに伴う機器交換費用を含めて条件が一致していることの確認が必要です。クラウド移行で実現できるビジネス価値と経済性評価の考え方については、 こちら の AWS Black Belt Online Seminar 資料も併せてご参照ください。 AWS クラウドエコノミクス AWS クラウドエコノミクス に基づいた検討を行うことで、上記でご説明をした総所有コスト (TCO) の削減だけでなく、クラウドを活用することでスタッフの生産性、運用の回復力、ビジネスの俊敏性、サステナビリティのそれぞれを向上させることが可能となります。以下の図に記載されている例にある通り、オンプレミス環境からクラウドへ移行することで得られる経済的メリットを定量化することで、数値的なメリットの可視化が可能になります。また、 The Business Value of Amazon Web Services, IDC Research, Inc. June 2022 によると、クラウド移行により得られる価値の90%以上をコスト削減以外の価値が占めていることが分かります。また、投資収益率 (ROI) の観点においても、インタビュー対象組織においては5年間で 413% の ROI と、10 か月以内の損益分岐点の試算をおこなったケースを報告しています。クラウドへの移行をご検討の際は、コスト削減（TOC）による価値だけでなく、それ以外の価値も含めて総合的にクラウド移行のメリットを評価されることをお勧めします。クラウドエコノミクスの詳細については、 こちら も併せて参照ください。 本ブログでは、コストモデルを用いたクラウドコストの見積もりの考え方と、出来上がった見積もりについてオンプレミス環境とクラウド環境の見積もりを比較する際の注意点をご紹介しました。ご紹介した考え方を活用して、最適なクラウドコスト見積もりを検討ください。 参考情報： この記事は、 AWS Cloud for Finance Professionals の “ Planning and Forecasting : Estimating Cloud Costs ” を基礎情報として、カスタマーソリューションマネージャーの北川裕介と山下大介により作成されました。 コストに関するご質問やお問い合わせは、 お問い合わせページ 、もしくは担当営業までご連絡をお願いします。 コスト最適化を行うために以下の情報も併せてご参照ください。 クラウドコストの請求と監視 30の目的別クラウド構成と料金試算例 Amazon Web Services ブログ：CFM

小売業で、過去の販売データをもとに売り上げ数量を予測する仕組みのサンプルソリューションを Github上でOSSとして公開しました。 実績データをDWHに取り込んで前処理し、LightGBMベースの予測を出すまでの仕組みをAWS  Cloud Development Kit (CDK) ベースで提供するものです。本エントリではソリューションの構成や使い方について説明します。 End2End Data Solution for Retail Industry (Github) シンプルで見通しが良い分析アーキテクチャの土台を提供する Amazon Web Services (以下AWS)では、多くのサービスが提供されており、それらを適切に組み合わせることで高い自由度でソリューションを構築できるようになっています。各サービスは数クリックですぐに起動でき、運用管理の負担が少ないマネージド・サービス、もしくはサーバーレスと呼ばれる形態で提供されています。 一方で、ソリューションを構築する時間が取れない場合もあります。特に巨大データの分析や予測といった用途においては、ある程度やってみてから発見・理解できる事も多く、すぐに始めることがビジネス上の優位性を生む場合があります。 そこで、複数のサービスを統合した構成（アーキテクチャ）を事前に検討してOSSで公開し、CDKでデプロイ可能にしておくことで、すぐに分析にトライすることができるようにしたのが今回のソリューションです。 ソリューションは、できるだけシンプルで見通しが良く、管理の手間が少ない予測ソリューションのひな形を提供することを目標に設計しました。ユースケースを「小売（リテール）業の売り上げ情報から売り上げ数量を予測する」こととし、構成済のアーキテクチャ、CDKによる構築、サンプルデータ、ドキュメントを提供します。 アーキテクチャは下図のような構成です。データをAmazon S3上に保存したうえで、AWS Step Functionsを起動すると、データをAmazon Redshift Serverlessにロードし、SQLを実行して前処理し、Amazon SageMakerのビルトインアルゴリズムであるLightGBMで学習し、予測をS3に出力します。そのデータはAmazon Athenaで閲覧したり、Amazon QuickSightで可視化することが可能です。 想定する利用者・使い方 本ソリューションはエンジニア（AWSについて技術的な知見がある方）が、自分の環境に合わせてカスタマイズをすることを前提に作成しています。 ソリューションは100%の完成品ではありません。例えば基幹システムからデータをS3に取り込む部分は含まれません。取り込む方法は環境によって大きく異なりますので、環境に合わせて(S3への)データ転送方法を検討・実装いただく事を前提にしています。同様にデータ整形（前処理）は、Redshift Serverless上でSQLを実行することで実施していますので、カスタマイズにはSQLの記述が必要になります。 一方で、見通しが良く設計しておりAWSエンジニアであれば拡張しやすい作りになっています。例外処理等、あえて作りこんでいない部分もありますが、その分全体をシンプルに保っています。このように、利用者がソースコードやSQLを修正して自分のニーズに合わせた活用がしやすい事を重視したソリューションです。全体の流れをつかむには、まずは ソリューション・アーキテクチャ を見ていただくと良いでしょう。 また、AWSのサーバーレス・サービスを中心としたアーキテクチャにすることで、運用の負担を減らす構成としつつ、大規模データ処理や将来の予測モデル拡張に耐えうるサービスを選択しています。ソースコードはAWS Cloud Development Kit (CDK) ベースで作成されており、ソリューションをほぼ自動的で構築可能です。サンプルデータと共に公開されており、動作を確認した後は利用者がニーズに合わせて改変して利用することが可能になっています。 フィードバック/プルリクエストをお待ちしております 今回のリリース (v0.1)はエンド・ツー・エンドで動作することを確認していますが、まだまだ不足している部分もあります。例えばドキュメントはもっと分かりやすいものがあると良いでしょうし、カスタマイズガイド等も充実させる必要があると思っています。機能面でも追加すべき部分が多数あると思いますし、不具合もあるかもしれません。 ご興味がある方はぜひ触っていただいて、Github上のIssueでのフィードバックや、プルリクエストをいただければと思います。必ずの対応をお約束するものではありませんが、できる範囲で改善していく予定です。 End2End Data Solution for Retail Industry (Github) AWS 伊藤、秋田、平間、下佐粉

AWS Cloud Development Kit (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。 AWS CDK は、プログラミング言語の使い慣れた表現力を利用してアプリケーションをモデル化します。 Construct は AWS CDK アプリケーションの基本的な構成要素です。 Construct は「クラウドコンポーネント」を表し、 AWS CloudFormation がコンポーネントを作成するのに必要なすべてのものをカプセル化します。さらに、 AWS Construct Library では、事前定義されたテンプレートとロジックを使用してアプリケーションを簡単に構築できます。 Construct には次の 3 つのレベルがあります。 L1 — これらは Cfn (CloudFormation の略) リソースと呼ばれる低レベルの Construct です。これらは AWS CloudFormation リソース仕様 から定期的に生成されます。名前パターンは Cfn Xyz で、 Xyz はリソースの名前です。これらの Construct を使用するときは、すべてのリソースプロパティを設定する必要があります。そのためには、基礎となる CloudFormation リソースモデルとそれに対応する属性を十分に理解している必要があります。 L2 — これらは、より高いレベルの使用用途に応じた便利な API を備えた AWS リソースを表します。デフォルトの設定、定型コード、コンポーネント間を簡単に結合するロジックなど、 L1 Construct を使って自分で開発するような追加機能を提供します。 AWS Construct には便利なデフォルト設定が用意されており、それが表す AWS リソースの詳細をすべて知る必要がなくなります。リソースの操作をよりシンプルにするための便利なメソッドが提供され、結果的にアプリケーションを作成することが簡単になります L3 — これらの Construct はパターンと呼ばれます。 AWS の一般的なタスクを完了するように設計されており、多くの場合、複数の種類のリソースが関係します。 このブログでは、サンプルアーキテクチャと、 L2 Construct を使用して AWS CDK アプリケーションの複雑さを軽減する方法を示します。 サンプルアーキテクチャの概要 このソリューションでは、 Amazon API Gateway 、 AWS Lambda 、および Amazon DynamoDB を使用して、シンプルなサーバーレスウェブアプリケーションを実装しています。アプリケーションは API Gateway 経由でユーザーから POST リクエストを受け取り、プロキシ統合を使用して Lambda 関数に転送します。 Lambda 関数はリクエスト本文を DynamoDB テーブルに書き込みます。 サンプルコードは GitHub にあります。 ウォークスルー GitHub リポジトリの README ファイルの指示に従ってスタックをデプロイできます。次のチュートリアルでは、それぞれの論理構成と、 L1 と L2 の Construct を使用して実装する場合の違いについて説明します。各サンプルコードの前に、ソースがある GitHub リポジトリ内のパスを示します。 DynamoDB テーブルの作成 まず、リクエストの内容を保存する DynamoDB テーブルを作成します。 L1 Construct L1 Construct では、テーブルの各属性を個別に定義する必要があります。 DynamoDB テーブルの場合、これらは keySchema 、 attributeDefinitions 、および provisionedThroughput です。これらはすべて、たとえば keyType の定義方法など、 CloudFormation に関する詳細な知識を必要とします。 lib/level1/database/infrastructure.ts dynamodb.CfnTable( this, "CfnDynamoDbTable", { keySchema: [ { attributeName: props.attributeName, keyType: "HASH", }, ], attributeDefinitions: [ { attributeName: props.attributeName, attributeType: "S", }, ], provisionedThroughput: { readCapacityUnits: 5, writeCapacityUnits: 5, }, }, L2 Construct 対応する L2 Construct では、 readCapacity (5) と WriteCapacity (5) のデフォルト値を使用できます。さらに複雑さを軽減するために、属性とパーティションキーを同時に定義します。さらに、 dynamodb.AttributeType.STRING 列挙型を利用しています。 lib/level2/database/infrastructure.ts this.dynamoDbTable = new dynamodb.Table( this, "DynamoDbTable", { partitionKey: { name: props.attributeName, type: dynamodb.AttributeType.STRING, }, }, ); Lambda 関数の作成 次に、リクエストを受け取って DynamoDB テーブルにコンテンツを保存する Lambda 関数を作成します。ランタイムは Node.js を使用します。 L1 Construct L1 Construct を使用して Lambda 関数を作成する場合、作成時にすべてのプロパティ (ビジネスロジックのコードの場所、ランタイム、関数ハンドラー) を指定する必要があります。これには Lambda 関数が引き受ける IAM ロールも含まれます。そのため、 IAM ロールのリソースネーム (ARN) を指定する必要があります。この記事の後半の「権限の付与」セクションでは、この IAM ロールの作成方法を示します。 lib/level1/api/infrastructure.ts const cfnLambdaFunction = new lambda.CfnFunction( this, "CfnLambdaFunction", { code: { zipFile: fs.readFileSync( path.resolve(__dirname, "runtime/index.js"), "utf8" ), }, role: this.cfnIamLambdaRole.attrArn, runtime: "nodejs16.x", handler: "index.handler", environment: { variables: { TABLE_NAME: props.dynamoDbTableArn, }, }, }, ); L2Construct Lambda 関数の NodeJSFunction L2 Construct を利用することで、同じ結果をより簡単に得ることができます。別のバージョンを明示的に指定しない限り、 Node.js ランタイムのデフォルトバージョンが設定されます。この Construct は、 TypeScript または JavaScript コードを自動的にトランスパイルしてバンドルする Lambda 関数を作成します。その結果、関数の実行に必要なコードと依存関係のみを含む Lambda パッケージが小さくなり、内部では esbuild が使用されます。 Lambda 関数ハンドラーコードはリポジトリの runtime ディレクトリにあります。 Lambda ハンドラーファイルへのパスは entry プロパティに指定しています。 NodeJSFunction Construct はデフォルトでハンドラー名を使用するため、ハンドラー関数名を指定する必要はありません。さらに、 L2 Lambda Construct の作成時に Lambda 実行ロール を指定する必要はありません。ロールが指定されていない場合は、 Lambda の実行権限を持つデフォルトの IAM ロールが生成されます。「権限の付与」セクションでは、 Construct の作成後に IAM ロールをカスタマイズする方法について説明します。 lib/level2/api/infrastructure.ts this.lambdaFunction = new lambda_nodejs.NodejsFunction( this, "LambdaFunction", { entry: path.resolve(__dirname, "runtime/index.ts"), runtime: lambda.Runtime.NODEJS_16_X, environment: { TABLE_NAME: props.dynamoDbTableName, }, }, ); API Gateway REST API の作成 次に、 クロスオリジンリソース共有 (CORS) を有効にして POST リクエストを受信するように API Gateway REST API を定義します。 L1 Construct 新しい API Gateway REST API の作成からデプロイプロセスまで、すべてのステップを個別に設定する必要があります。 L1 Construct では、 CORS とヘッダーとメソッドの正確な設定を十分に理解している必要があります。 さらに、 Lambda プロキシ統合タイプでは URI の構築方法を知っておく必要があるなど、すべての詳細を知っておく必要があります。 lib/level1/api/infrastructure.ts const cfnApiGatewayRestApi = new apigateway.CfnRestApi( this, "CfnApiGatewayRestApi", { name: props.apiName, }, ); const cfnApiGatewayPostMethod = new apigateway.CfnMethod( this, "CfnApiGatewayPostMethod", { httpMethod: "POST", resourceId: cfnApiGatewayRestApi.attrRootResourceId, restApiId: cfnApiGatewayRestApi.ref, authorizationType: "NONE", integration: { credentials: cfnIamApiGatewayRole.attrArn, type: "AWS_PROXY", integrationHttpMethod: "ANY", uri: "arn:aws:apigateway:" + Stack.of(this).region + ":lambda:path/2015-03-31/functions/" + cfnLambdaFunction.attrArn + "/invocations", passthroughBehavior: "WHEN_NO_MATCH", }, }, ); const CfnApiGatewayOptionsMethod = new apigateway.CfnMethod( this, "CfnApiGatewayOptionsMethod", { // fields omitted }, ); const cfnApiGatewayDeployment = new apigateway.CfnDeployment( this, "cfnApiGatewayDeployment", { restApiId: cfnApiGatewayRestApi.ref, stageName: "prod", }, ); L2 Construct CORS を有効にして API Gateway REST API を作成するのは、 L2 Construct を使用するとより簡単になります。 defaultCorspreflightOptions プロパティを利用すると、この Construct によって必要な OPTIONS メソッドが準備されます。オリジンとメソッドを設定するには、 apigateway.Cors 列挙型を使用できます。 Lambda プロキシオプションを設定するには、メソッドのプロキシ変数を true に設定するだけです。デフォルトのデプロイは自動的に作成されます。 lib/level2/api/infrastructure.ts this.api = new apigateway.RestApi( this, "ApiGatewayRestApi", { defaultCorsPreflightOptions: { allowOrigins: apigateway.Cors.ALL_ORIGINS, allowMethods: apigateway.Cors.ALL_METHODS, }, }, ); this.api.root.addMethod( "POST", new apigateway.LambdaIntegration(this.lambdaFunction, { proxy: true, }) ); 権限の付与 サンプルアプリケーションでは、次の 2 つの異なるリソースに権限を付与する必要があります。 Lambda 関数を呼び出す API Gateway REST API DynamoDB テーブルにデータを書き込む Lambda 関数 L1 Construct どちらのリソースでも、 AWS Identity and Access Management (IAM) ロールを定義する必要があります。これには IAM 、ポリシーの構造、必要なアクションに関する深い知識が必要です。次のコードスニペットでは、まずポリシードキュメントを作成します。その後、リソースごとに IAM ロールを作成します。これらは作成時に、前述のように対応する Construct に渡されます。 lib/level1/api/infrastructure.ts const cfnLambdaAssumeIamPolicyDocument = { // fields omitted }; this.cfnLambdaIamRole = new iam.CfnRole( this, "cfnLambdaIamRole", { assumeRolePolicyDocument: cfnLambdaAssumeIamPolicyDocument, managedPolicyArns: [ "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole", ], }, ); const cfnApiGatewayAssumeIamPolicyDocument = { // fields omitted }; const cfnApiGatewayInvokeLambdaIamPolicyDocument = { Version: "2012-10-17", Statement: [ { Action: ["lambda:InvokeFunction"], Resource: [cfnLambdaFunction.attrArn], Effect: "Allow", }, ], }; const cfnApiGatewayIamRole = new iam.CfnRole( this, "cfnApiGatewayIamRole", { assumeRolePolicyDocument: cfnApiGatewayAssumeIamPolicyDocument, policies: [{ policyDocument: cfnApiGatewayInvokeLambdaIamPolicyDocument, policyName: "ApiGatewayInvokeLambdaIamPolicy", }], }, ); 独自に定義された Database Construct は、任意の IAM ロールに書き込みアクセスを許可する関数を公開します。この関数はポリシーを作成し、データベースのテーブルで dynamodb:PutItem を許可し、それを IAM ロールに追加ポリシーとして追加します。 lib/level1/database/infrastructure.ts grantWriteData(cfnIamRole: iam.CfnRole) { const cfnPutDynamoDbIamPolicyDocument = { Version: "2012-10-17", Statement: [ { Action: ["dynamodb:PutItem"], Resource: [this.cfnDynamoDbTable.attrArn], Effect: "Allow", }, ], }; cfnIamRole.policies = [{ policyDocument: cfnPutDynamoDbIamPolicyDocument, policyName: "PutDynamoDbIamPolicy", }]; } この時点で、 Lambda 関数には DynamoDB テーブルにデータを書き込む権限がまだないことを除いて、すべての権限が設定されています。書き込みアクセスを許可するには、 Lambda 関数の IAM ロールを使用して Database Construct の grantWriteData 関数を呼び出します。 lib/deployment.ts database.grantWriteData(api.cfnLambdaIamRole) L2 Construct LambdaIntegration Construct を使用して API Gateway REST API を作成すると、 IAM ロールが生成され、そのロールが API Gateway REST API メソッドにアタッチされます。 Lambda 関数に DynamoDB テーブルへの書き込み権限を与えるには、次の 1 行を入力します。 lib/deployment.ts database.dynamoDbTable.grantWriteData(api.lambdaFunction); L3 Construct を使用する さらに複雑さを軽減するには、 L3 Construct を活用できます。このサンプルアーキテクチャの場合、 LambdaRestAPI Construct を使用できます。この Construct はデフォルトの Lambda プロキシ統合を使用します。メソッドとデプロイを自動的に生成し、権限を付与します。その結果、さらに少ないコードで同じことを実現できます。 const restApi = new apigateway.LambdaRestApi( this, "restApiLevel3", { handler: this.lambdaFunction, defaultCorsPreflightOptions: { allowOrigins: apigateway.Cors.ALL_ORIGINS, allowMethods: apigateway.Cors.ALL_METHODS }, }, ); クリーンアップ この記事で紹介するサービスの多くは AWS 無料利用枠 で利用できます。ただし、このソリューションを使用するとコストが発生する可能性があるため、不要になった場合はスタックを削除する必要があります。クリーンアップ手順は GitHub リポジトリ の README ファイルに含まれています。 結論 この記事では、 L1 と L2 の AWS CDK Construct を使用する場合の違いを、アーキテクチャ例とともに紹介しました。 L2 Construct を活用すると、定義済みのパターン、定型コード、コンポーネント間を簡単に結合するロジックを使用できるため、アプリケーションの複雑さが軽減されます。便利なデフォルト設定が用意されており、これらが表す AWS リソースの詳細をすべて知る必要がなくなると同時に、リソースをより簡単に操作できる便利なメソッドも用意されています。さらに、 L3 Construct を使用して一般的なタスクの複雑さをさらに軽減する方法も示しました。 AWS CDK のドキュメント を参照して、プログラミング言語の表現力を駆使して、耐障害性、スケーラビリティ、コスト効率の高いアーキテクチャを構築する方法の詳細をご覧ください。 本記事は、 David Boldt による “Leverage L2 constructs to reduce the complexity of your AWS CDK application” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。

行政 DX における生成系 AI の活用の可能性 民間企業における Generative AI（以下、生成系 AI ）のビジネスでの利活用に注目が集まっています。それに加え、政府・官公庁・自治体、教育、医療機関などの公共部門で業務の効率化や国民・市民サービスでの利活用においても、そのメリットや可能性が活発に話し合われ始めています。 アマゾン ウェブ サービス（以下、AWS ） は、過去 20 年以上にわたり、人工知能（ AI ）や機械学習（ ML ）を誰でもが使うことができるように民主化し、グローバル企業や大規模な公共部門の組織からスタートアップまで、あらゆる規模のお客様が安全に容易に、そして適切なコストで革新的な AI ソリューションを構築できるよう注力しています。その知識と経験は 2023 年 4 月以来発表している AWS の生成系 AI サービス群でも踏襲されています。 政令指定都市であり全国でも多くの人口を抱える大阪市では、データやデジタル技術の活用により、地域のあり方や、サービスおよび行政のあり方を再デザインし、社会環境の変化にも的確に対応していくデジタルトランスフォーメーション（ DX ）の取り組みを進めています。それにより、大阪市で生活や経済活動を行う多様な人々が、それぞれの幸せを実感できる都市への成長・発展をめざしています。とりわけ世界的に注目を浴びている生成系 AI の行政における活用の可能性について、大阪市は着目しています。 生成系 AI 活用で AWS と大阪市が共同検証 アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、2023 年 9 月 1 日に、大阪市と行政 DX に向けた生成系 AI の活用に関して連携することで協定を締結しました。大阪市における行政の業務の効率化と、市民サービスの向上に向けて、生成系 AI の利活用の可能性と、利用にあたっての課題解決などについて、共同検証を目的とするものです。なお、AWS ジャパンが生成系 AI の活用について、政令指定都市を含む自治体・行政機関と協定締結という形で連携するのは、大阪市が初となります。   （写真左）大阪市 市長 横山 英幸 ／ （写真右） AWS ジャパン　執行役員 パブリックセクター統括本部長 宇佐見 潮 現場の業務において検証 共同検証においては、実際の市民サービスに携っている市職員が、実際に現場の業務でどのように使えるかについて取り組みます。期待される効果としては、まず業務効率化や作業の負荷軽減、そして業務品質の向上を想定しています。手法やシステム構成などの技術面については、特定の手法やシステムありきではなく、利用内容に応じて大阪市と AWS ジャパンで検討していきます。 アマゾン ウェブ サービス ジャパン合同会社 AWS ジャパン 執行役員 パブリックセクター 統括本部長 宇佐見 潮は次の旨述べています。「この度、大阪市と市民サービスの向上及び業務の効率化に向けた生成系 AI の利活用において、AWS が連携させていただくことを大変嬉しく思います。AWS はテクノロジーの提供を通じて、日本政府や官公庁、各自治体、スタートアップと連携・支援し、イノベーションを起こし社会課題の解決や経済を加速させていくことにコミットしています。全国でもトップクラスの人口や経済の規模を誇る大阪市様の広い分野での市民サービスの向上や業務効率化において、AWS のサービスと知見が大阪市様の目指す行政 DX に大きく貢献できると考えています。今回の大阪市様との連携で新しいイノベーションが生み出されることを大いに期待しています」 AWS は、設計、開発、展開、運用といった包括的な開発プロセスの各段階を通じて、AI における正確性、公平性、適切な使用方法、社会への有害性、セキュリティ、安全性、プライバシーなど、さまざまな要素を考慮し、”責任ある AI ”を念頭に置いて AI を構築します。AI の責任ある利用は、継続的なイノベーションを促進する鍵であり、AWS は企業や政府機関向けに公正で正確な AI および ML サービスの開発に取り組み、企業や政府機関のミッションの実現に向けて支援していきます。

8月30日、Amazon Kinesis Data Analytics の名称が Amazon Managed Service for Apache Flink に変更されたことをお知らせします。これは、 Apache Flink を使ってリアルタイムのストリーミングアプリケーションを構築および実行するためのフルマネージドのサーバーレスサービスです。 進行中の運用、開発、またはビジネスユースケースに影響を与えることなく、同じエクスペリエンスが Flink アプリケーションで引き続き提供されます。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。 活気のあるオープンソースコミュニティによる多様なユースケースのサポートを始めとして、多くのお客様がデータ処理に Apache Flink を使用しています。Apache Flink アプリケーションは堅牢で広く使用されていますが、並列コンピューティングリソースまたはコンテナリソースのスケーリングと調整が必要なため、管理が難しい場合があります。データ量、データ型、データソースが飛躍的に増加する中、お客様は、パフォーマンスやコストを犠牲にすることなく、データのアクセス、処理、保護、分析をより簡単に行う方法を必要としています。 Amazon Managed Service for Apache Flink を使用すると、最小限のコードでデータソースまたは宛先を設定して統合すること、 Amazon Kinesis Data Streams や Amazon Managed Streaming for Apache Kafka (Amazon MSK) などの多くのデータソースからのデータを 1 秒未満のレイテンシーで継続的に処理すること、およびイベントにリアルタイムで対応することができます。 Apache Zeppelin による組み込みの視覚化機能を備えた Amazon Managed Service for Apache Flink では、数回のクリック操作だけでノートブックを使ってストリーミングデータをインタラクティブに分析することもできます。 Amazon Managed Service for Apache Flink では、規格に準拠したセキュアな高可用性アプリケーションをデプロイできます。サーバーやクラスターを管理する必要や、コンピューティングとストレージのインフラストラクチャをセットアップする必要はありません。請求はアプリケーションが消費するリソースに対してのみ発生します。 Apache Flink のサポートの歴史 独自の SQL エンジンをベースにとする Amazon Kinesis Data Analytics の 2016 年のローンチ以降、効率的なステートフルストリーム処理に必要な機能をお客様に提供するには SQL だけでは不十分であることがわかり、リアルタイムのデータストリーム処理で広く使われているオープンソースフレームワークおよびエンジンである Apache Flink への投資が開始されました。 2018 年には、Apache Flink ライブラリを使用してストリーミングアプリケーションを構築し、独自の統合開発環境 (IDE) でアプリケーションを構築するお客様向けのプログラム可能なオプションとして Amazon Kinesis Data Analytics for Java のサポートが提供されました。2020 年、Apache Flink への継続的なサポートを強調するために Amazon Kinesis Data Analytics for Java が Amazon Kinesis Data Analytics for Apache Flink に変更されました。2021 年、Apache Zeppelin による迅速な開発向けのシンプルで使い慣れたノートブックインターフェイスを備え、処理エンジンとして Apache Flink を使用する Kinesis Data Analytics Studio (現在の Amazon Managed Service for Apache Flink Studio) がリリースされました。 2019 年以降、Apache Flink コミュニティとの連携が強化され、Kinesis Data Streams や Kinesis Data Firehose など、Apache Flink 用 AWS コネクタの領域におけるコード貢献を拡大するとともに、毎年開催される Flink Forward イベントを後援してきました。最近では、 Flink 1.15 リリース に Async Sink を提供した結果、その他の更新と共に、クラウドの相互運用性が向上し、多くのシンクコネクタとフォーマットが追加されました。 コネクタ以外にも、AWS は、Flink コミュニティとの協力を継続し、可用性の向上とデプロイオプションに貢献しています。詳細については、AWS オープンソースブログの「 Making it Easier to Build Connectors with Apache Flink: Introducing the Async Sink 」を参照してください。 Amazon Managed Service for Apache Flink の新機能 先に説明したように、既存の Flink アプリケーションを Kinesis Data Analytics (現在の Amazon Managed Apache Flink) で引き続き実行できます。変更を加える必要はありません。コンソールの変更と新機能に加えて、ワンクリックでエンドツーエンドのデータパイプラインを作成するブループリントという新機能についてお伝えします。 最初に注目すべき点は、 Amazon Managed Service for Apache Flink の新しいコンソール を AWS の分析セクションから直接使用できることです。開始する際は、新しいコンソールで ストリーミングアプリケーション または Studio ノートブック を簡単に作成できます。操作方法は以前と同じです。 新しいコンソールでストリーミングアプリケーションを作成するには、 [一から作成] または [ブループリントを使う] を選択します。新しく追加されたブループリントオプションでは、 AWS CloudFormation を使用して 1 つのステップで使用を開始するために必要なすべてのリソースを作成および設定できます。 ブループリントは、厳選された Apache Flink アプリケーションのコレクションです。最初のアプリケーションには、Kinesis Data Stream から読み取られ、 Amazon Simple Storage Service (Amazon S3) バケットに書き込まれるデモデータがあります。 デモアプリケーションを作成したら、Apache Flink ダッシュボードを設定、実行、開いて Flink アプリケーションの状態をモニタリングできます。操作は以前と同じです。 GitHub リポジトリ のコードサンプルを変更して、独自のローカル開発環境で Flink ライブラリを使用してさまざまなオペレーションを実行できます。 ブループリントは拡張可能で、Amazon Managed Service for Apache Flink をベースにビジネス上の課題を解決するための複雑なアプリケーションを作成するために活用できます。 Apache Flink ライブラリの使用方法 の詳細については、AWS ドキュメントを参照してください。 ブループリントは、新しいセットアップオプションとして Apache Zeppelin を使用して Studio ノートブックを作成するために使用することもできます。この新しく追加されたブループリントオプションでは、AWS CloudFormation を使用して 1 つのステップで使用を開始するために必要なすべてのリソースを作成および設定することもできます。 このブループリントには、Amazon MSK トピックに送信され、Managed Service for Apache Flink で読み取られるでもデータを含む Apache Flink アプリケーションが含まれています。Apache Zeppelin ノートブックでは、ストリーミングデータを表示、クエリ、分析できます。ブループリントのデプロイと Studio ノートブックのセットアップには約 10 分かかります。セットアップが完了するまでコーヒーでも飲んでお待ちください。 新しい Studio ノートブックを作成したら、Apache Zeppelin ノートブックを開いて、ノート内の SQL クエリを実行できます。操作は以前と同じです。Apache Flink ライブラリの使用方法の詳細については、GitHub リポジトリのコードサンプルを参照してください。 このデモデータでは、ユーザー定義関数、タンブリングウィンドウとホッピングウィンドウ、 Top-N クエリ、ストリーミング向けの S3 バケットへのデータ配信など、多くの SQL クエリを実行できます。 また、 Studio ノートブックの使用方法 と Amazon MSK トピックのクエリ に関するブログ記事で説明されているように、Java、Python、または Scala を使用して SQL クエリを強化し、継続的に実行するアプリケーションとしてノートをデプロイすることもできます。 ブループリントのサンプルの詳細については、 MSK Serverless からの読み取りと Amazon S3 への書き込み 、 MSK Serverless からの読み取りと MSK Serverless への書き込み 、 MSK Serverless からの読み取りと Amazon S3 への書き込み などの GitHub リポジトリを参照してください。 今すぐご利用いただけます Amazon Kinesis Data Analytics から名称が変更された Amazon Managed Service for Apache Flink を使用できるようになりました。Kinesis Data Analytics で実行中の既存のアプリケーションはすべてそのまま動作します。変更を加える必要はありません。 詳細については、 新製品のページ と デベロッパーガイド を参照してください。フィードバックは、 Amazon Managed Service for Apache Flink の AWS re:Post または通常の AWS サポートチャネルから送ることができます。 — Channy 原文は こちら です。

イントロダクション 本日、 Amazon VPC Container Networking Interface (CNI) プラグイン での Kubernetes NetworkPolicy のネイティブサポートを発表できることを嬉しく思います。Kubernetes クラスター内の Pod ネットワーキングとネットワークポリシーの両方を実装するために、Amazon VPC CNI を利用できます。NetworkPolicy のネイティブなサポートは、私達の コンテナロードマップ において、最も要望の多かった機能の 1 つでした。 デフォルトでは、Kubernetes は全ての Pod が制限なく相互に通信することを許可しています。 Kubernetes の NetworkPolicy は、Pod 間のトラフィックフローのルールを定義し、強制できます。仮想ファイヤウォールとして機能し、クラスターをセグメント化し、保護します。これは、Pod の Label、Namespace、IP アドレス、IP ブロック (CIDR レンジ)、ポート番号などのさまざまな基準に基づいた受信および送信ネットワークトラフィックのルールを指定することでおこなわれます。今までは、お客様はサードパーティのネットワークポリシープラグインを使用して、NetworkPolicy を実装し、それによってしばしば運用と管理のオーバーヘッドが生じていました。Amazon VPC CNI の統合された機能によって、クラスターの構成とデプロイがシンプルになりました。トラフィックフローを制限することで、スケーリングの課題を心配することなく、より強力なセキュリティ体制を実現できます。 Amazon VPC CNI の NetworkPolicy のネイティブなサポートにより、AWS 上で Kubernetes を実行する場合に、機密性の高いワークロードを隔離し、認可されていないアクセスから保護するポリシーを作成できます。このきめ細やかなコントロールレベルにより、許可された Pod のみが相互に通信できる最小権限の原則を実装できます。NetworkPolicy は Amazon Elastic Computer Cloud (Amazon EC2) セキュリティグループ ( SG ) やネットワークアクセスコントロールリスト ( NACL ) などの、Amazon VPC によって提供されるセキュリティ機能を拡張する、多層防御のメカニズムを提供します。 Amazon Elastic Kubernetes Service (Amazon EKS) は、アップストリームの Kubernetes NetworkPolicy を完全にサポートしているため、互換性と Kubernetes 標準への準拠が保証されます。これは、Amazon EKS クラスターにおける NetworkPolicy API の全ての機能を使用できることを意味しています。アップストリームの API によってサポートされるさまざまな 識別子 を使って柔軟にポリシーを定義できます。これにより、Pod 間の通信を定義することが可能になり、クラスター内のセキュリティと分離が強化されます。 動作の仕組み Kubernetes の NetworkPolicy が最初に導入された時、広く採用されていたデフォルトの実装は iptables でした。 iptables はネットワークポリシーの強制には効果的であることが証明されましたが、特に Kubernetes クラスターのサイズが拡大する時に、いくつかの制約がありました。数多くの iptables ルールを管理することが課題になる可能性があります。また、各パケットでルールを順番に評価することで、ルール数の増加によって、パフォーマンスの問題が生じる可能性もあります。 これらの課題に対処し、パフォーマンスを改善するために、Amazon EKS は extended Berkeley Packet Filter ( eBPF ) を用いて NetworkPolicy を実装するという高度なアプローチを採用しました。このテクノロジーは NetworkPolicy の代替実装として、近年大きな支持を集めています。eBPF は iptables と比較してより効率的なパケットフィルタリングを提供し、全体的なパフォーマンスが向上する可能性を秘めています。これは、カーネル自体の中でカスタムコードを直接実行できるようにすることによって実現されます。 NetworkPolicy の実装を円滑に進めるために、Amazon EKS ではシームレスに連携する 3 つの主要なコンポーネントを導入しています。 Network Policy コントローラー: Amazon EKS は、最新バージョンの Amazon VPC CNI と共に、 Network Policy コントローラー のローンチを発表しました。現在、コントローラーは一般公開されています。新しい Amazon EKS クラスターを作成すると、機能が有効になった際に Network Policy コントローラーが Kubernetes のコントロールプレーンに自動的にインストールされます。クラスター内の NetworkPolicy の作成をアクティブに監視し、ポリシーエンドポイントを調整します。その後コントローラーは、ポリシーエンドポイントを通じて Pod の情報を公開することによって、ノード上で eBPF プログラムを作成または更新するよう、Node Agent に指示します。Network Policy コントローラーは、Pod のプロビジョニングと並行して、Pod のポリシーを設定します。それまで新しい Pod には、デフォルトの許可ポリシーが設定されます。既にあるポリシーに対して調整されるまで、新しい Pod への送受信トラフィックは全て許可されます。セルフマネージド型 Kubernetes クラスターの NetworkPolicy を効率的に管理するには、Network Policy コントローラーをデプロイする必要があります。この点については、この記事のウォークスルーのセクションで、セルフマネージド型クラスターに関する詳しい情報と重要な考慮事項を確認することができます。 Node Agent: Amazon VPC CNI の最新バージョンでは、クラスター内の全てのノードに CNI バイナリと ipamd プラグインと共に、 Node Agent もインストールされます。Node Agent は VPC CNI にバンドルされ、aws-node DaemonSet 配下でコンテナとして実行されます。NetworkPolicy がクラスターに適用されると、Node Agent はコントローラーからポリシーエンドポイントを受け取ります。Node Agent は eBPF プログラムの管理において重要な役割を果たし、シームレスな NetworkPolicy への道を開きます。 eBPF SDK (Software Development Kit): Amazon VPC CNI はサポートと運用を助けるために、ノード上の eBPF プログラムと対話するための直感的なインタフェースを提供する SDK を含んでいます。この SDK により、eBPF 実行時における、ランタイムのインストロペクション、トレース、分析が可能になり、接続性の問題の特定と解決に役立ちます。 本日より、v1.25 以降の新しい Amazon EKS (IPv4 および IPv6) で NetworkPolicy がサポートされます。Amazon EKS は、既存の全てのクラスターを、対応する Kubernetes マイナーバージョン用の最新の Amazon EKS プラットフォームバージョンに自動的にアップグレードします。まもなく、この機能をサポートするプラットフォームバージョンをリリース予定です。そのプラットフォームバージョンへの自動アップグレードがおこなわれた後に、NetworkPolicy が適用可能になります。 クラスターで NetworkPolicy を有効化するには、クラスターが Amazon VPC CNI 1.14.0 以降のバージョンを実行していることを確認します。新しいクラスターを作成する際には、Amazon VPC CNI 1.14.0 以降のバージョンを指定することができます。Amazon VPC CNI 1.14.0 で作成されていないクラスターについては、Amazon VPC CNI を更新してください。既存のクラスターのプラットフォームバージョンの更新が完了したら、VPC CNI をサポートされているバージョンに更新してください。 ローンチ時点では、NetworkPolicy は Kernel バージョン 5.10 以降を使った Amazon EKS-optimized Amazon Linux AMI 、 Amazon EKS-optimized Bottlerocket AMI 、 Amazon EKS-optimized Ubuntu Linux AMI でサポートされています。Kernel バージョン 5.10 以降を使って構築された Amazon EKS-optimized AMI は、eBPF ファイルシステム /sys/fs/bpf を自動的にマウントします。これは、ノードに NetworkPolicy を適用するために必要です。既存のクラスターにおいては、Amazon EKS プラットフォームバージョンが更新された時に、最新の Amazon EKS-optimized AMI に更新することを推奨します。カーネルバージョン 5.10 またはそれより下のバージョンを使用するノードの場合、eBPF ファイルシステムをマウントする手順について、Amazon EKS ユーザーガイド を参照してください。eBPF システムサポートを使用して独自のカスタム AMI を作成する方法については「 Amazon EKS-optimized Amazon Linux AMI ビルドスクリプト 」を確認してください。 始め方 NetworkPolicy の機能は Kubernetes マイナーバージョン 1.25 以降を実行しているクラスターでサポートされていますが、ローンチ時点ではデフォルトで無効になっています。クラスターを作成する際に、Amazon VPC CNI の設定パラメータを使用してクラスターの NetworkPolicy を有効化できます。 Amazon VPC CNI が IP アドレスを管理するには、AWS Identity and Access Management ( AWS IAM ) による許可が必要になります。Amazon EKS では、 AmazonEKS_CNI_Policy 管理ポリシーで定義されたアクセス権限を使用して、別の AWS IAM ロールを作成し、 IRSA (AWS IAM roles for service acount) を使用してそのロールを VPC CNI に関連付けることを推奨しています。IRSA は OpenID Connect (OIDC) エンドポイントを必要とするため、クラスター作成の一部として IAM OIDC プロバイダーを作成 します。詳細については「 サービスアカウントの IAM ロールを使用する Amazon VPC CNI plugin for Kubernetes の設定 」を参照してください。 以下の設定をコピーして cluster.yaml という名前のファイルに保存します。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: network-policy-demo version: "1.27" region: us-west-2 iam: withOIDC: true vpc: clusterEndpoints: publicAccess: true privateAccess: true addons: - name: vpc-cni version: 1.14.0 attachPolicyARNs: #optional - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy configurationValues: |- enableNetworkPolicy: "true" - name: coredns - name: kube-proxy managedNodeGroups: - name: x86-al2-on-demand amiFamily: AmazonLinux2 instanceTypes: [ "m6i.xlarge", "m6a.xlarge" ] minSize: 0 desiredCapacity: 2 maxSize: 6 privateNetworking: true disableIMDSv1: true volumeSize: 100 volumeType: gp3 volumeEncrypted: true tags: team: "eks" eksctl create cluster -f cluster.yaml Bash クラスターの作成が完了するのを待って、Amazon VPC CNI が Node Agent を実行するようになったかどうかを確認します。 kubectl get ds -n kube-system aws-node -o jsonpath= '{.spec.template.spec.containers[*].name}{"\n"}' 出力: aws-node aws-eks-nodeagent Apache Configuration eBPF SDK を使用する Amazon VPC CNI の最新バージョンには、ノード上の eBPF プログラムとやり取りするためのインタフェースを提供する SDK が付属しています。SDK は aws-node がノードにデプロイされる時にインストールされます。SDK バイナリはノードの /opt/cni/bin ディレクトリ配下にインストールされています。接続性の問題を特定したい場合は、SDK の使用を検討してください。ノード上の Pod のために eBPF プログラムが作成されていることを確認します。これを確認するには AWS System Manager ( AWS SSM ) を使用して、Amazon EC2 コンソールからノードに接続します。 ローンチ時には、SDK は eBPF プログラムやマップの検査など、基本的な機能をサポートしています。特定の利用リクエストがある場合は、 こちら の GitHub Issue から教えてください。SDK の使用方法については、ユーザーガイドを御覧ください。 sudo /opt/cni/bin/aws-eks-na-cli ebpf progs Apache Configuration サンプルアプリケーションのデプロイ 次に、demo-app というサンプル NGINX アプリケーションと、default Namespace にシンプルなクライアントアプリケーションをデプロイします。さらに、another-ns という default Namespace ではない Namespace に別のクライアントアプリケーションを作成します。 git clone https://github.com/aws-samples/eks-network-policy-examples.git cd eks-network-policy-examples kubectl apply -f advanced/manifests/ Apache Configuration 全ての Pod が Running 状態になるまで待ちます。 kubectl get pods --all-namespaces --watch Apache Configuration NetworkPolicy を実装する デフォルトでは、Kubernetes は全ての Pod が他の全ての Pod と自由に通信することを許可しています。Kubernetes の NetworkPolicy が Pod に適用されていない場合は、Pod に出入りする全てのトラフィックが許可されます。 アクセスを確認し、全ての送受信トラフィックを許可する 別のターミナルを使用して、前のステップでデプロイしたクライアントの Pod からの接続を確認できます。 kubectl exec -it client-one -- curl demo-app Apache Configuration API 呼び出しが成功したことを示す応答が表示されます。 全てのトラフィックを拒否する demo-app アプリケーションのために、全 Namespace に渡って全てのトラフィックを拒否するポリシーを適用することで、分離をおこないましょう。 kubectl apply -f advanced/policies/01-deny-all-ingress.yaml Apache Configuration NetworkPolicy では全ての Pod を選択したため、demo-app への受信トラフィックはすべて拒否されます。 kubectl exec -it client-one -- curl demo-app Apache Configuration 前のコマンドはタイムアウトになります。 curl: (28) Connection timed out after 3001 milliseconds<br />command terminated with exit code 28 同じ Namespace からの受信を許可する 次のステップでは、同じ Namespace 内で、client-one から demo-app への受信トラフィックを許可します。 kubectl apply -f advanced/policies/03-allow-ingress-from-samens-client-one.yaml Apache Configuration NGINX のウェルカムページの HTML が返されるはずです。 kubectl exec -it client-one -- curl --max-time 3 demo-app Apache Configuration another-ns Namespace からの受信を許可する 次に、別の Namesapce からのトラフィックを許可します。 kubectl apply -f advanced/policies/04-allow-ingress-from-xns.yaml これにより、別の Namespace のクライアントから demo-app にアクセスできるようになり、ウェルカムメッセージが返されるはずです。 kubectl exec -it -n another-ns another-client-one -- curl --max-time 3 demo-app.default 送信トラフィックを拒否する default Namespace の client-one Pod からの全ての送信の分離を適用します。 kubectl apply -f advanced/policies/06-deny-egress-from-client-one.yaml Apache Configuration DNS Lookup を含め、client-one からの全ての送信トラフィックが拒否されていることがわかります。 kubectl exec -it client-one -- nslookup demo-app Apache Configuration 送信トラフィックを許可する DNS トラフィックも含め、複数のポートと Namespace からの送信を許可しましょう。 kubectl apply -f advanced/policies/08-allow-egress-to-demo-app.yaml Apache Configuration DNS と demo-app への送信トラフィックを許可する必要があります。 kubectl exec -it client-one -- curl --max-time 3 demo-app Apache Configuration 重要な考慮事項 NetworkPolicy と Security Groups for Pods IPv4 モードの Amazon VPC CNI は、Security Groups for Pods と呼ばれる強力な機能があります。この機能により、Amazon EC2 セキュリティグループを使用して、ノードにデプロイされた Pod との間のインバウンドおよびアウトバウンドのネットワークトラフィックを管理するルールを定義できます。Security Groups for Pods と NetworkPolicy を組み合わせて活用することで、セキュリティ体制を強化できます。NetworkPolicy が有効になっている場合、Security Groups for Pods は多層防御戦略の追加のレイヤーとして機能します。NetworkPolicy を使うと、クラスター内のネットワークトラフィックの流れをきめ細かく制御できます。一方で、Security Groups for Pods は Amazon のセマンティックコントロールを活用し Amazon RDS データベースなどの Virtual Private Cloud (VPC) 内のリソースとの通信を管理することで保護を強化します。Amazon EKS では、Pod 間のネットワーク通信を制限する NetworkPolicy を採用することを強く推奨しています。これにより、攻撃対象領域が減少し、潜在的な脆弱性を最小限に抑えられます。NetworkPolicy とセキュリティグループの仕様に関する詳細のガイダンスについては、 Amazon EKS ベストプラクティス を参照してください。 NetworkPolicy とサードパーティ CNI プラグイン Amazon VPC CNI は、Kubernetes NetworkPolicy API を使って定義されたネットワークポリシーをサポートするようになりました。Pod ネットワーキング用のサードパーティ CNI プラグインを実行しているクラスターは、NetworkPolicy の機能を有効化するために、Amazon VPC CNI に移行しなければならないと注意しておくことが重要です。 この記事を書いている時点では、Amazon VPC CNI はサードパーティのネットワークポリシープラグインの Amazon VPC CNI へのインプレースでの移行をサポートしていません。移行を円滑に進めるために、Amazon EKS では Amazon VPC CNI の NetworkPolicy サポートを有効化する前に、既存のサードパーティネットワークポリシー API を Kubernetes NetworkPolicy API に変換することを推奨しています。本番環境に変更を適用する前に、移行したポリシーを別のテスト用クラスターでテストすることを推奨します。これによって、Pod 間通信の振る舞いにおける潜在的な問題や不一致を特定して対処できます。 一貫性を保ち、予期せぬ Pod の通信の振る舞いを回避するために、単一のネットワークポリシープラグインのみを実行することを推奨します。Amazon VPC CNI の最新バージョンにアップグレードする前に、既存のサードパーティのネットワークポリシー CNI プラグインを削除することが重要です。さらに、ワーカーノードを入れ替えることで、 iptables や eBPF プログラムなど、ノードに残っている変更を排除できます。Amazon VPC CNI の NetworkPolicy サポートに移行するための詳細な手順については、 こちら のドキュメントを参照してください。このオープンソース リポジトリ で提供されるスクリプトを使用して、サードパーティのネットワークポリシーを Kubernetes NetworkPolicy アーティファクトに変換できます。これらのリソースは Amazon EKS よって公式にサポートされておらず、ベストエフォートになります。リソースは、Amazon VPC CNI NetworkPolicy サポートへの移行を成功させるために、移行プロセスを合理化および簡素化することを目的としています。 セルフマネージド型 Kubernetes クラスター Amazon VPC CNI の最新バージョンでは、AWS 上のセルフマネージド型 Kubernetes に NetworkPolicy を適用できるようになりました。Amazon VPC CNI の更新に加えて、セルフマネージド型 Kubernetes クラスターに Amazon NetworkPolicy コントローラーをインストールして、NetworkPolicy を有効化します。 GitHub リポジトリに記載されている手順にしたがって、NetworkPolicy コントローラーをデプロイします。現在、Amazon VPC CNI と Network Policy コントローラーはサードパーティの NetworkPolicy プラグインとカスタム NetworkPolicy オブジェクトのインプレースでの移行をサポートしていないことに注意することが重要です。そのため、上記の手順に従って Amazon VPC CNI NetworkPolicy に移行するようにしてください。 クリーンアップ 将来のコストを避けるため、この演習用に作成した Amazon EKS クラスターを含む全てのリソースを削除してください。このアクションは、クラスターを削除するだけではなく、ノードグループも削除します。 eksctl delete cluster -f cluster.yaml Apache Configuration まとめ この記事では、Kubernetes NetworkPolicy が Amazon EKS でも利用できるようになったことをお伝えしました。これは、ロードマップで最も要望の多かった機能の 1 つに対応したものです。また、サードパーティのネットワークポリシープラグインを管理しなくても、きめ細やかな通信制御を実施し、ワークロードを分離し、AWS Kubernetes クラスター全体のセキュリティを強化する方法を示しました。 NetworkPolicy の領域を詳しく調べる時に、Amazon EKS ではアプリケーションの特定のセキュリティ要件を念頭に置き、新たな脅威に備えるために定期的にポリシーを見直して更新することを推奨しています。綿密な計画と実装をおこなうことで、Kubernetes NetworkPolicy のポテンシャルを最大限に活用して、アプリケーションとデータを不正なアクセスから保護できます。推奨事項や追加の考慮事項については、 Amazon EKS ベストプラクティスガイド をご覧ください。 Amazon VPC CNI のインストール手順については、Amazon EKS ユーザーガイド を参照してください。Amazon VPC CNI プラグイン に関するフィードバックは、GitHub でホストされている AWS コンテナロードマップ に Issue を開くか、コメントを残すことで提示できます。今後も機能を進化させ、eBPF テクノロジーを活用して Amazon VPC CNI 内でモニタリングやオブザーバビリティの機能を提供する追加の方法を模索していきますので、ご期待ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

本ブログの位置づけ AWS Customer Solutions Manager の山崎です。本ブログは現状オンプレミス上での多くの IT 資産が稼働しており、AWS への移行を考えたい、エンタープライズのお客様向けに記載しています。 オンプレミスからAWS への移行は評価、計画、移行、運用/最適化のフェーズに分かれます。本ブログは計画～移行のフェーズにおいて、個々のシステム群の移行をどのような切り口で整理するべきかを 前編 ／ 後編 でまとめています。ここでいう個々のシステム群の移行とは、システムを構成するリソースであるアプリケーションサーバー、データベース、ファイルサーバーの移行を指します。 前編 では、AWS へのシステム移行検討のアプローチとして、移行パターンの整理およびデータ転送経路の確保パターンについて整理しました。後編では、リソースごとの移行方法や活用できる AWS サービスについてご紹介していきます。 3. 移行に利用するサービスの識別 移行リソースごとに利用可能なAWS サービスを紹介していきます。リソースの種類や 移行方法 によって、最適なAWS サービスは変わります。お客様が移行したいリソース、準備状況、獲得したい効果、スケジュール感などを踏まえ、移行方法とあわせて利用するサービスを明確にしましょう。 3-1. アプリケーションサーバー移行 アプリケーションサーバーをどのように移行するのかは、 移行パス によって異なります。ここではリホスト、リロケート、リアーキテクチャの3 つのパターンで整理します。 オンプレミスからシステム構成を大きく変更せずにリホスト (リフト＆シフト) する場合 は、手動で移行する手段と自動で移行する手段があります。 運用の効率を高めるために OS やミドルウェアの最新化、パッケージ設定の整理やセットアップ・テストの自動化を付随して実施する場合は、手動での移行を考えます。 最新化やセットアップ作業が不要の場合、自動での移行が可能です。自動での移行には AWS Application Migration Service (AWS MGN) を利用します。AWS MGN は、移行元のサーバーにエージェントをインストールすることで、移行先であるAWS に環境をレプリケーションすることができます。ソースサーバーを物理、仮想、またはクラウドのインフラストラクチャから AWS でネイティブに実行するように自動的に変換することにより、AWS への移行を簡素化および迅速化します。 既存オンプレミスの vSphere ワークロードを AWS にリロケートする場合 、 VMwareCloud on AWS が利用できます。VMware Cloud on AWS により、VMware ベースのデータセンターと AWS 間で相互運用可能なインフラストラクチャとサービスが提供されるため、複雑な環境の管理を避け、関連するリスクを最小限に抑えることができます。 移行と同時に アプリケーションをリアーキテクチャしてモダナイズする場合 は、 AWS Lambda や  AWS Fargate といったサーバーレスプラットフォームが移行先として視野に入ります。この場合、アプリケーション自体をサーバーレスプラットフォームにあわせて変更するため、難易度は最も高くなります。得られる効果として、ビジネスアジリティの向上、運用負荷の削減、コストの最適化などがあります。 3-2. データベース移行 データベースは、一般的に顧客情報や商品情報などのマスタデータ、受注処理や入出金処理などのトランザクションデータを格納するために使用され、システムの基盤となります。 本章ではデータベースの中でも、オンプレミスのシステムで一般的に使われているリレーショナルデータベースについて記載します。 データベース移行には、 システムが許容できる停止時間 を見極めます。十分な停止時間をとれる場合は、一括移行が可能でなるべくシンプルな移行方式を選択します。ソースデータベースとターゲットが同一エンジンであればダンプツール  (Oracle の移行の場合は Oracle Data Pumpなど) 、異なる場合は CSV アンロードを使用します。 許容できる停止時間に余裕がない場合 は、差分移行が可能な移行方式を選択します。移行方式には、ソースデータベースとターゲットデータベースが同一エンジンでかつ純正のツールが使える場合はレプリケーション (Oracle の移行の場合は Oracle GoldenGate など)、それ以外の場合は AWS Database Migration Service (AWS DMS) を使用します。差分移行方式では、ダウンタイムを最小限にすることが可能ですが、一括移行方式に比較すると、難易度が高くなるため、事前の調査や検証、リハーサルなどを計画してください。 AWS-18：AWS のサービスを使ったオンプレミスからのデータベース移行 ダンプツールによる移行 データベース移行では、ダンプデータを転送しロードする方法がシンプルで確実です。停止時間を短縮する場合は、一括移行後に差分データを追加ロードすることが基本方針です。ダンプデータをロードする場合、データベースエンジンの純正ツールを使い、オンプレミスから AWS へデータを送りロードをします。移行先には一時的な領域とデータファイルの領域が必要です。 CSVアンロードによる移行 異なるデータベースエンジン間でデータベースを移行する際には、一般的にCSVのアンロードとロードが利用できます。オンプレミスのデータベースでは、SELECT 文などを使用して CSV 形式のファイルを作成し、それを AWS に送り、AWS 側でロードを行います。この移行方法では、ダンプファイルを使用する場合と同様に一時的な領域が必要です。CSV アンロードは、より柔軟な移行方式である一方、データ型 (LOB など) やデータ (制御文字など) によって CSV 化が難しい場合や、ダンプツールと比較して性能が劣る場合もありますので、利用範囲は限定的です。 レプリケーションによる移行 データベースベンダー純正のレプリケーション機能を利用することで、ダンプツールや CSV アンロードによるデータ移行よりもサービス停止時間を短縮できます。利用可能なライセンスやレプリケーション機能のノウハウがある場合には、純正レプリケーション機能 ( Oracleの移行の場合は Oracle GoldenGate や Oracle マテリアライズドビュー ) を検討してください。利用するレプリケーション機能については、各ベンダーのマニュアル等を参照し、事前調査や各種テストを計画してください。 AWS Database Migration Service (AWS DMS) による移行 AWS Database Migration Service (DMS) は、異なるデータベースエンジン間や同じエンジン内でのデータ移行を容易にするサービスです。AWS DMS はデータの抽出、変換、ロードを行い、既存の構成変更を最小限に抑えながらデータベースの移行を可能にします。AWS DMS はすでに存在するテーブルにデータをロードするという動きをするため、あらかじめテーブルやインデックスなどの各種オブジェクトを事前に作成する必要があります。これらの作業は、 AWS Schema Conversion Tool (AWS SCT) が利用可能です。AWS DMS を活用することで、短時間で安全かつ柔軟なデータベース移行が実現可能です。ただし AWS DMS は、柔軟な移行方式である一方、 ソースデータベースとしての制限 と ターゲットデータベースとしての制限 の双方があるため、プロジェクト初期フェーズでの確認が重要です。また、ソースデータベースのワークロードによっては同期性能が低下する場合やデータが正しく移行されない場合  (例: 文字コード変換による文字化け、制御文字の扱いなど) があるため、PoC (Proof of Concept) や各種テストを計画してください。 3-3. ファイルサーバー移行 ファイルサーバーのデータは、従来の転送プロトコルを使用して Amazon EC2 に転送できます。また、Amazon Simple Storage Service (Amazon S3) やマネージドファイルストレージサービスの移行方法も紹介します。 Amazon S3 へのデータ移行 Amazon S3 へのファイル転送方法について説明します。移行方式はオンラインとオフラインの2 つがあります。オンラインマイグレーションでは、AWS SDK や AWS CLI を使用して Amazon S3 の API を直接利用する方法がシンプルです。また Amazon S3 のPrivateLink や AWS Direct Connect を使用すれば、パブリックネットワークネットワークを経由せずにオンプレミスから Amazon S3にファイルを転送できます。 AWS Transfer Family を使用すれば、従来の FTP や SFTP などのプロトコルを使用して、データを Amazon S3 へと転送することができます。これにより、オンプレミスのサーバーのソフトウェア構成を変更せずに AWS 上にデータを送ることができます。オフラインマイグレーションでは AWS Snowball Edge または AWS Snowcone を使用し、大量のファイルを Amazon S3 に転送することも可能です。 マネージドファイルストレージサービスへのデータ移行 オンプレミスの Windows ファイルサーバーや NFS サーバーを AWS へ移行する方法について説明します。移行先としては、 Amazon EFS ( NFS プロトコル) 、 Amazon FSx for OpenZFS (NFS プロトコル)、 Amazon FSx for Windows File Server (SMB プロトコル) 、 Amazon FSx for NetApp ONTAP (NFS、SMB などのプロトコル) が利用できます。 オンラインマイグレーション に利用できるツールとして、 AWS DataSync がご利用できます。また、SnapMirror や robocopy などのオンプレミスでも使い慣れたツールもご利用できます。 オフラインマイグレーション では AWS Snowball Edge または AWS Snowcone を使用し、データの一括移行と差分のネットワーク転送を組み合わせます。移行対象データの量やネットワーク状況に応じて適切な方法を選択しましょう。 AWS Snowball Edge を利用した場合、大量のデータをオフラインで転送できるメリットがあるものの、メタデータが保持されない可能性があるため、プロジェクト初期フェーズでの確認が重要です。 4. 移行に付随するその他の作業 ここまでは主に、サーバー、データベース、データ (ファイル) に関する移行方法という技術的側面を説明してきました。実際にプロジェクトとしてシステム移行を考慮すると、サーバーやデータを移行する以外にもタスクがあります。これらのタスクは、 従来のオンプレミス間でのシステム移行と大きく変わるものではありません が、AWS を利用することで、各種テストなどの効率化が可能です。 4-1. アプリケーションテスト サーバーやデータを AWS へ移行した後は、移行したシステムの主要な機能をテストして、正常に動作していることを確認します。ユーザーが期待通りにシステムを利用できるかどうかを確認し、必要な修正や調整を行います。また、移行後のシステムのパフォーマンスをテストして、応答時間や処理能力などが要件を満たしているかどうかを確認します。 AWS であれば、移行したサーバーの Amazon Machine Image (AWS AMI) を取得し、そこからサーバーを複製することで複数の環境を作成し、並列で検証、テストを行うことが可能です。 4-2. システム移行時のサポート体制 システム移行のトラブル発生時のサポート体制や連絡体制の構築も重要です。ユーザ部門、システム部門、関連するシステムの関係部門などトラブルが発生した際の連絡体制を構築してください。AWSでは、本番切り替えなどの重要なイベントを実施する際に、 IEM (Infrastruture Event Managerment)  という特別なサポートを受けることが可能です。 4-3. 移行後の正常稼働の評価 本番運用を開始した後に、システムが正常に稼働していることの評価を行います。業務アプリケーションのイベントに合わせて、移行直後、週次バッチ後、月次バッチ後などのタイミングで、エラーの発生状況、性能やリソースの使用状況に問題がないかを確認します。 AWSはオンプレミス環境と比較して柔軟性に優れています。仮に、性能やリソース問題で性能チューニングが行われる期間中、一時的にリソースが必要になった場合にも柔軟に追加が可能で、性能チューニング完了後、不要なリソースを削減することも可能です。 5. まとめ ブログでは、オンプレミスから AWS への移行について、移行パターンの整理における切り口、データ転送経路やシステム移行をサポートする多様な AWS サービスを解説しました。移行パターンの整理や停止時間の考慮など、移行のポイントを押さえて十分な準備を行い、効率的かつスムーズな移行を実現しましょう。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM)　山崎 徹、甲斐 裕之 参考リンク これだけは押さえておきたい、AWS移行全12ツール一挙紹介！ AWS移行における移行プロセス 移行ツールを使ってWeb アプリケーションをAWS に移行したい – 目的別クラウド構成と料金試算例 はじめてAWS DMSを検討する際に読んでいただきたいこと AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

本ブログの位置づけ AWS Customer Solutions Manager の山崎です。本ブログは現状オンプレミス上で多くの IT 資産が稼働しており、AWS への移行を考えたい、エンタープライズのお客様向けに作成しています。 オンプレミスから AWS への移行は評価、計画、移行、運用/最適化のフェーズに分かれます。本ブログは計画～移行のフェーズにおいて、個々のシステム群の移行をどのような切り口で整理するべきか 前編 ／ 後編 でまとめています。ここでいう個々のシステム群の移行とは、システムを構成するリソースであるアプリケーションサーバー、データベース、ファイルサーバーの移行を指します。 【移行全体のフェーズと本ブログの位置づけ】 本編に入る前に、AWS の移行における全体像と本ブログの位置づけを記載します。上図は AWS 移行全体のフェーズと、必要なワークストリームを クラウド導入フレームワーク (AWS CAF) の観点で整理した図です。AWS への移行では、まず評価フェーズから始まり、移行に係る総保有コストの分析 や準備状況評価、 移行戦略と移行パス (7R) の策定などを実施します。次に計画フェーズでは推進組織を立ちあげ、PoC (Proof of Concept、概念検証) や、移行計画策定を実施します。そして移行フェーズで IT 環境を整備したうえでシステム移行を実行し、運用/最適化フェーズにて運用の自動化などを実施します。本ブログは、移行計画の中でシステムごとの移行方法を確立し、IT 環境を整備する際に参考となる情報として位置づけられます。なお、その他のワークストリームで必要な情報は以下のブログもご参照ください。  6 つの視点で移行の準備状況を分析 MRA  (移行準備状況評価)  から見えるクラウド移行におけるよくある課題とその対策 推進組織の立ち上げ CCoE 活動検討のはじめの一歩 AWSのクラウド移行トータル支援プログラム AWS ITトランスフォーメーションパッケージ 2023 ファミリー AWS へのシステム移行検討のアプローチ システム移行では、個々のシステムが求められる要件、サービスレベル、リソースの種類を踏まえ、4 つのステップで進めます。 1. 移行パターンを整理し、2. データ転送経路を確保したうえで、3. 利用可能なAWS サービスを選択し、4. 移行と付随する作業を実行します。 従来のオンプレミスにおける移行では、物理的な制約からシステム停止時間が長くなる、人手を介することから人的ミスの混入が避けられないなどの課題がありました。しかしAWS が用意するサービス群を利用することで、効率よくスピーディに移行を実現できます。 一方で、移行時のシステム要件やサービスレベルの整理が不十分なままに移行方法を決めてしまうと、ビジネスに大きな影響を及ぼしたり、多大な工数・コストを費やしたりするリスクもあるため、システムの特性を踏まえて十分な検討を重ねましょう。 1. 移行のパターンの整理 システムの移行方針を考えるうえで、まず移行作業中に システムが許容できる停止時間 を見極めます。停止時間が長いほど、作業時間の確保が可能です。短時間しか停止が許されないシステムであれば、データの整合性を確保するための複雑な考慮が必要となります。これらは既存システムのサービスレベルや非機能要件をインプットに検討します。 また、システムの規模とトラブル時の影響範囲の大きさも考慮が必要です。規模の大きいシステムではトラブル時のリスクを極小化するため、一度に移行するのではなく移行単位の分割が選択肢に入ります。 1-1. 一括移行 一括移行は、既存システム全体を停止しシステムを一度に移行します。通常、規模の小さいシステムの移行で採用されます。システム停止中に移行作業を行うため、一般的に停止時間が長くなります。既存システムにデータが流入しないため、データ静止点が明確で整合性が担保しやすく、移行作業自体の難易度は低くなります。 許容されるシステムの停止時間が短く、すべてのデータを停止時間中に移行できない場合、 差分移行 を検討します。差分移行は、移行作業を複数のステップに分割し、データのスナップショットをあらかじめ新環境に転送しておきます。移行開始後に既存システムを停止し、転送したスナップショットから最新のデータまでの最終差分のみを停止時間中に新環境に反映します。最終差分を反映する時間だけがシステム停止時間となります。 1-2. 分割移行 大規模なシステムの移行では、システム全体を一度に移行すると停止時間の長期化や、トラブル時にビジネスに与える影響範囲が大きいリスクがあります。そのため、構成する機能ごとに移行する分割移行が選択肢となります。システムの停止時間は、機能のサービスレベルによって異なります。外部顧客に影響する機能はシステム停止時間を短くする必要がある、社内向けの機能は長い停止時間を確保できる、などです。機能ごとの依存関係を考慮して移行するため、移行難易度は高くなります。 分割パターンは様々です。例えばフロントシステム、ミドルシステム、バックエンドシステムと分割して各々を移行する、特定の業務や商品に関連する機能だけを移行し、特殊性の高い業務・商品を後から移行する、などです。 2. データ転送経路の確保 オンプレミスから AWS への移行において、AWS へのデータ転送経路をどのように設定するのかを考えます。データ転送経路は、転送速度、移行着手までのリードタイム、転送するデータ容量、回線・機器コストを考慮して検討します。 2-1. ネットワークによるデータ転送 専用線接続 AWS への専用ネットワーク接続には AWS Direct Connect が利用できます。AWS Direct Connect は専用線で独立した専用のネットワークであり、帯域が保証されているため安定したデータ転送が可能です。ただし、設置のためのリードタイムが長いため、十分な準備期間をとる必要があります。また、回線・機器コストがかかる点に注意が必要です。あらかじめ帯域を確保できているため、移行に要する時間を精緻に見積もる必要がある場合の選択肢となります。 AWS Direct Connect デリバリーパートナー 経由で払い出すことで、より柔軟で幅広い選択肢を利用できます。 インターネット接続 移行は専用線だけでなく、インターネットを経由して実行することもできます。ただし専用線接続と比べて帯域が確保されておらず、ベストエフォートでの転送となります。AWS VPN を利用することで安全かつ柔軟にデータを転送できます。AWS Direct Connect よりも短期間で設置可能であり、VPN 接続費用も安価です。移行開始までの期間が限られている場合や、設置コストを安価に済ませたい場合の選択肢となります。ただしデータ転送にかかる時間を事前に読み切ることができないため、移行完了までの時間を精緻に見積もりたい場合には向いていません。 2-2. 物理デバイスでのデータ転送 移行完了の目標時間に対して利用できるネットワーク帯域が十分でない場合や不安定な場合、またアーカイブデータの移行には、オフラインデバイスを活用することができます。 AWS Snowball Edge や AWS Snowcone は、安全で堅牢なデバイスを提供するサービスです。AWS のコンピューティング機能とストレージ機能を提供し、AWS との間でデータを転送できます。マネジメントコンソールからジョブを作成すると、後日指定した住所に発送されます。移行作業時間には物理デバイスの発送時間や対象環境へのコピーなどの時間を考慮する必要があります。 まとめ 前編では、AWS へのシステム移行検討のアプローチとして移行パターンの整理およびデータ転送経路の確保パターンについて整理しました。 後編 では、リソースごとの移行方法や活用できる AWS サービスについてご紹介していきます。 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー (CSM)　山崎 徹、甲斐 裕之

AWS Step Functions は、ワークフローを通じてスケーラブルで分散型のサーバーレスアプリケーションを構築するための基礎ツールとして台頭しています。Step Functions チームは 2021 年に、 AWS マネジメントコンソール で Step Functions ワークフローを作成するためのローコードのビジュアルツールである Workflow Studio を立ち上げました。これにより、コーディングの経験が少ない人でもワークフローを構築できるようになりました。 お客様からのフィードバックに応えて、本日、Step Functions チームは包括的な新機能を導入しました。最も一般的なリクエストの一部に対応することで、構築体験がさらに直感的で汎用性が高まり、特定の開発アプローチに沿ったものになります。 What’s new? 最新リリースには、次の 3 つの新しいコンポーネントが含まれています。 スターターテンプレートエクスペリエンスの強化 : このアップデートは、開発者とビジネスユーザーに高度な基盤を提供し、ワークフローの作成とプロトタイプ作成を迅速に行うプロセスを効率化します。 Workflow Studio のコードモード : 本日、Workflow Studio には新しいコードモードが導入されました。これにより、ビルダーはデザインビューとコード構築ビューを切り替えることができます。この機能により、コンテキストを切り替える必要が減り、ワークフローの構築が迅速になります。たとえば、 Amazon States Language (ASL) のワークフロー定義を Step Functions Workflows Collection から直接 Workflow Studio にシームレスに貼り付けることができます。その後、デザインビューに移行してワークフロー開発を続行できます。または、新しい構築体験のスターターテンプレートを選択することもできます。必要に応じて、新しいコードモードに切り替えてきめ細かく調整できます。 ワークフローの実行と設定の強化 : このバージョンの Workflow Studio には、Workflow Studio 内の構築ビューから直接ワークフローを実行する機能も組み込まれています。さらに、権限、ロギング、トレースなどの補足的なワークフロー設定を構成して、ワークフロー管理を強化できます。 スターターテンプレートエクスペリエンスの導入 特筆すべき機能は、改善されたスターターテンプレートエクスペリエンスの導入です。これはワークフロー作成プロセスを迅速化するために設計された新しいインターフェースです。 ユースケースやサービスごとにテンプレートを絞り込むことができるため、プロジェクトのニーズに合った厳選されたテンプレートを選択できます。スターターテンプレートエクスペリエンスは強力な足がかりとなり、構築するための強固な基盤を築くことができます。 テンプレートからワークフローを作成する流れは下記のプロセスです。 AWS マネジメントコンソール の Step Functions ステートマシンページ に移動します。 [ステートマシンの作成] を選択します。 これにより、新しいテンプレート選択が表示されます。キーワードで検索するか、ユースケースとサービスでフィルタリングします。 [S3 で CSV ファイルを処理するための分散マップ] を選択し、 [次へ] を選択します。 次のビューには、ワークフローが視覚的に表示され、詳細な説明も表示されます。 各テンプレートには次の 2 つの使用オプションがあります。 デモの実行 : Step Functions は、ステートマシンとすべての関連リソースを備えた AWS CloudFormation スタックをアカウントに自動的にデプロイします。すぐに実行できるこのデモワークフローは、選択したテンプレートの機能を紹介するだけでなく、独自の構築を開始するきっかけにもなります。この基盤を土台に、お客様の仕様に適するようにワークフローをカスタマイズ、微調整、調整できます。 その上に構築する : これにより、ワークフローの ASL が新しい Workflow Studio コードビューに表示されます。重要なのは、この移行では関連するリソースは一切デプロイされないということです。目標は、ベストプラクティステンプレートを使用するワークフロー構築プロセスを迅速に行えるようにすると同時に、ゼロから構築しなくても特定のニーズに合わせてカスタマイズしたり調整したりできるようにすることです。 [デモの実行] を選択し、 [Use template] を選択します。これにより、ワークフローテンプレートは読み取り専用モードで Workflow Studio に配置されます。デモリソースをデプロイする前に、ワークフロー定義を詳しく調べることができます。 デモをデプロイするには、 [デプロイと実行] を選択します。 しばらくすると、デモアプリケーションがアカウントにデプロイされます。 ドラッグアンドドロップデザインとコードモード間のシームレスな移行 Workflow Studio のもう 1 つの強化点は、ドラッグアンドドロップのデザインビューと新しいコードモードをシームレスに切り替えられることです。この汎用性により、さまざまな好みやスキルセットに合わせて、ビジュアルデザインとコードベースの構築を切り替えることができます。デザインビューではワークフローを直感的に作成できますが、コードモードでは使い慣れたコーディング環境のような動的な空間が得られます。 以前にデプロイしたワークフローのデモを開くには、 ステートマシンのコンソール から選択して [編集] を選択します。 [Code] ボタンを選択して、コード構築ビューに切り替えます。 ここでは、 Visual Studio Code などの業界標準のコーディング環境を連想させるインターフェイスが表示されます。この変革により、経験豊富な開発者は ASL の可能性を最大限に活用して、複雑なカスタマイズや微調整が可能になります。また、右側のグラフビジュアライゼーションを使用して、簡単かつ迅速に順序を変更したり、ステップを複製、削除したりできるようになります。 [デザイン] ボタンを選択すると、ローコードエディターに戻ります。 これは、ASL の経験が少ないビルダーや、ワークフローのモックを迅速に構築する必要がある開発者、さらに編集するためのテンプレート、またはワークフローのプロトタイプを作成する必要がある開発者にとって理想的です。 Workflow Studio からワークフローを直接実行 Workflow Studio では、インターフェイス内からワークフローを開始できるようになりました。この機能は設計と実行の間のギャップを埋め、開発者は Workflow Studio の構築環境からワークフローを開始できます。 Workflow Studio 内からワークフローを開始するには、 [実行] ボタンを選択します。 これにより、Step Functions 実行インターフェースに直接移動し、入力ペイロードを入力してワークフローの実行を検査できます。この機能によりインターフェースを切り替える必要が減り、開発者はより迅速かつ効率的にイテレーションを行うことができます。 [ステートマシンの編集] を選択すると Workflow Studio に直接戻り、ワークフローを繰り返し調整できます。 Workflow Studio では、実行ロール権限の表示と編集、ロギングの設定、その他のパラメーターの調整もできるようになりました。このビューにアクセスするには、Workflow Studio から [設定] ボタンを選択します。 既存のワークフローの可用性 新機能は、追加費用なしで、既存のすべてのワークフローで自動的に利用できるようになります。これにより、追加の手順や設定を行わずに Workflow Studio の強化された機能を使用できるようになります。 Workflow Studio の新機能により、開発者は活動を強化できます。ワークフローの作成と実行を簡素化することで、開発者はより多くの時間とエネルギーをアプリケーション開発のクリエイティブな側面に注ぎ込むことができます。Workflow Studio の機能強化は、生産性を高めるだけでなく、クリエイティブなデザインを具体的でインパクトのあるアプリケーションに変えるためのプラットフォームも提供します。 結論 Workflow Studio は、Step Functions ワークフローを構築するプロセスを簡素化および強化するという継続的な目標のもと、進化を続けています。構築モードへのシームレスな遷移、直接実行する機能、改善されたスターターテンプレートエクスペリエンスの導入は、構築の効率と柔軟性の向上に向けた実用的な一歩であり、Workflow Studio を Step Functions のデフォルトの構築体験として確立しています。 その他のスターターテンプレート、パターン、ベストプラクティスについては、 Serverless Land の Serverless Workflows Collection をご覧ください。 翻訳はソリューションアーキテクトの松岡勝也が担当しました。原文は こちら です。

このブログはソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 このブログ記事では、 Amazon CodeCatalyst での .NET の使用に関する一連の投稿の最初の記事として、CodeCatalyst と AWS .NET deployment tool に含まれている ASP.NET Core Web API プロジェクトブループリントを使用して、.NET 6.0 ASP.NET Core Web API を構築して Amazon Elastic Container Service (Amazon ECS) にデプロイする方法について説明します。 Amazon CodeCatalystとは何ですか？ これは、ソフトウェア開発チーム向けの新しいクラウドベースの統合コラボレーションサービスです。継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールのフルセットを提供し、開発チームが作業を計画し、コードで共同作業を行い、アプリケーションを構築、テスト、デプロイするのに役立ちます。CodeCatalyst は、開発者の生産性を高め、チームがより少ない労力でより多くのことを達成できるように支援する 豊富な機能セット を提供することでこれを実現します。 CodeCatalyst ビルドオプションについて ASP.NET 6.0 ベースの Web API をビルドおよびデプロイするための CodeCatalyst の全体的なエクスペリエンスについて説明する前に、CodeCatalyst が提供する .NET アプリケーションのビルド オプションについて説明します。CodeCatalyst には、 ワークフロー を実行するための 2 つのコンピュート タイプ があります： オンデマンドフリートは、 Amazon Elastic Compute Cloud (Amazon EC2) または AWS Lambda を使用してフルマネージド型の Linux ベースのコンピュートで、ビルドアクションの開始時にプロビジョニングされ、終了時にプロビジョニング解除されます。 プロビジョニングされたフリートは、CodeCatalyst が管理する Linux または Windows ベースの Amazon EC2インスタンスを提供します。プロビジョニングされたフリートを使用するには、価格は Standard ティア である必要があります。 .NET アプリケーションを構築するには、任意のフリートタイプとオペレーティングシステムを選択できます。このブログ記事では、オンデマンドフリートを使用して .NET Web API を構築します。今後のブログ記事では、Windows ベースのプロビジョニングされたフリートを使用して .NET Framework アプリケーションを構築する方法について説明します。 前提条件 以下の前提条件の一覧を確認して、ご使用の環境で以下のセクションで説明するすべての手順が実行できることを確認してください。次のものが必要です。 AWS ビルダー ID。 作成方法 は製品ドキュメントに記載されています。 CodeCatalyst スペース へのアクセス。 自分で作成する方法 、または 招待を受ける方法 については、製品ドキュメントを参照してください。 CodeCatalyst スペースに追加された AWS アカウント。これは、デプロイするインフラストラクチャが AWS 内にあるためです。詳細は、 製品ドキュメント をご覧ください。 スペースに追加する AWS アカウントの AWS Identity and Access Management (IAM) ロールで、CodeCatalyst をそのアカウントにデプロイできるようにします。このチュートリアルでは、 製品ドキュメント の手順に従って、 CodeCatalystPreviewDevelopmentAdministrator IAM ロールを作成し、CodeCatalyst スペースにアタッチします。ベストプラクティスとして、これらのロールには、チームの運用に必要な最小限のアクセス許可を割り当ててください。 CodeCatalyst プロジェクトの作成 前提条件を満たしたら、CodeCatalyst で プロジェクト を作成できます。 CodeCatalyst アカウント にログインし、CodeCatalyst スペースに移動します。[プロジェクトの作成] を選択し、[ブループリントで開始] オプションを選択します （図 1）。 ブループリントは、アプリケーションのサポートファイルや依存関係を生成し、拡張するプロジェクト・シンセサイザーです。 図 1: CodeCatalyst .NET ブループリント画面 [ブループリントの選択] 検索ボックスに “.NET” と入力します。.NET アプリケーションで使用可能なブループリントの一覧が表示されます。このブログ記事を書いている時点では、次の 2 つのブループリントを使用できます。 ASP.NET Core Web API : CI/CD ワークフローと共に ASP.NET Core 6.0 Web API プロジェクトを作成し、アプリケーションをビルドして選択した AWS サービスにデプロイします。 .NET serverless application : アプリケーションをビルドして AWS Lambda にデプロイする CI/CD ワークフローと共に、.NET 6.0 AWS サーバーレスアプリケーションプロジェクトを作成します。 ブループリントを選択すると、右側にサイドパネルが表示され、詳細な説明、アーキテクチャの概要、接続とアクセス許可、およびブループリントによって作成されるプロジェクトリソースが表示されます （図 2）。 図 2: ASP.NET Core Web API ブループリントの説明画面 このブログでは、 ASP.NET Core Web API ブループリントの使用について説明します。そのオプションを選択し、[次へ] を選択してプロジェクトの設定を続行します。 次の画面（図 3）では、CodeCatalyst がプロジェクトを作成するための構成オプションを提供します。このブループリントでは、次の情報を指定する必要があります。 図 3: ASP.NET Core Web API ブループリント構成画面 プロジェクト名（必須） : CodeCatalyst はそれを使用して、プロジェクトとデフォルトのソースコードリポジトリに名前を付けます。 環境（必須） : AWS アカウント接続とデプロイロール : デプロイ先の AWS アカウントと、アプリケーションのデプロイ時に CodeCatalyst が使用するロール。 [AWS アカウントなし] を選択した場合は後で追加できますが、追加するまでワークフローは正常に実行されません。 言語 : ソース コードを作成するために使用する .NET プログラミング言語。C# または F# を選択できます。 AWS デプロイサービス : アプリケーションのデプロイ先としてサポートされている AWS サービス。[なし] を選択した場合、ワークフローファイルにはアプリケーションを AWS にデプロイするためのアクションは含まれません。 コード（オプション） : コードリポジトリ名 : ソースコードリポジトリの名前。 .NET プロジェクト名 : 作成するプロジェクトと名前空間の名前。 本稼働環境のデプロイ : これを選択すると、負荷分散と AWS のサービスに割り当てられたより大きなリソースの両方を含む設定が使用されます。 AWS リージョン : アプリケーションをデプロイするリージョン。 画面の右側（図 4）には、前の画面と同じ説明を含む、ブループリントに関する情報が表示されます。また、 [コードの表示] と [ワークフローの表示] の 2 つの追加ボタンもあります。 図 4: ASP.NET Core Web API ブループリント情報画面 [コードの表示] を選択すると、プロジェクト構成に基づいてブループリント テンプレートによって生成されるコードファイルを調べることができるパネルが表示されます （図 5）。構成を変更すると、生成されたファイルが自動的に更新されます。 図 5: ASP.NET Core Web API ブループリントコードのプレビュー画面 [ワークフローの表示] を選択すると、ワークフローエディターが表示されます（図 6）。CodeCatalyst がプロジェクト構成に基づいて作成するワークフローを視覚的にまたは YAML 形式で表示します。プロジェクト構成を変更すると、生成されたコード ビューの場合と同様に、ワークフローが更新されます。 図 6: ASP.NET Core Web API ブループリント ワークフローのプレビュー画面 この例では、言語として C# を選択し、 デプロイサービス として Amazon Elastic Container Service を選択します。 [プロジェクトの作成] を選択して、プロジェクトの作成を開始します（図 7）。これは数秒で完了するはずです。 図7:プロジェクト作成画面 生成されたファイルの探索 プロジェクトの作成が完了すると、プロジェクトの概要画面にリダイレクトされます。プロジェクトを構成するリポジトリ、ワークフロー、プルリクエストなどの情報を表示できます。プロジェクトの [概要] 画面 で、 [リポジトリの表示] ボタンを選択して、既定のソースコードリポジトリに移動します （図 8）。 図8:プロジェクトリポジトリ画面 プロジェクトのリポジトリページでは、ブループリントによって生成されたソースコードの構造が次のようになっていることが分かります（図 9 参照）。 図 9: ASP.NET Core Web API ブループリントで生成されたコード構造 次のフォルダーに注意してください。 .cloud9 : 開発環境として使用する場合に AWS Cloud9 を設定するために使用される AWS Cloud9 ランナー が含まれます。 .codecatalyst deployment-settings : AWS Elastic Beanstalk (Windows & Linux)、 AWS AppRunner 、および Amazon ECS 上の AWS Fargate にデプロイするときに .NET デプロイで使用されるさまざまなデプロイ設定ファイルが含まれています。各ファイルには、本番用と非本番用の 2 種類があります。 workflows : アプリケーションをビルドしてデプロイするための CodeCatalyst ワークフローの YAML コードが含まれています。 .vscode : 開発環境として使用する場合の Visual Studio Code の既定の構成が含まれています。 src : プロジェクトのソースコードが含まれます。 tests : プロジェクトの単体テストが含まれます。 “devfile.yaml” という名前のファイルも作成されます。これは、 CodeCatalyst 開発環境 を構成するために使用されます。 続行する前に、ファイル構造をより詳細に確認して、CI/CD ワークフローで作成およびデプロイされる内容を理解することをお勧めします。 デフォルトの CI/CD ワークフローの探索 CodeCatalyst では、ワークフローは、CI/CD システムの一部としてコードをビルド、テスト、およびデプロイする方法を説明する自動化された手順です。ワークフローの実行中に実行する一連の手順またはアクションを定義し、ワークフローを開始するイベントまたはトリガーも定義します。 次に、ASP.NET Core Web API ブループリントによって生成されたワークフローを調べます。ナビゲーション メニューで、 [CI/CD] メニューを展開し、 [ワークフロー] を選択します（図 10）。 図 10: CodeCatalyst ワークフローメニュー項目 すでに pull-request と main の2つのワークフローが作成されていることに注意しましょう。 pull-request ワークフローはプルリクエストに応じて実行され、 main ワークフローは新しいコミットがリポジトリの main ブランチにプッシュされたときに実行されます。 main ワークフローには、 pull-request ワークフローと同じステップに加え、デプロイステップがあります。 main ワークフローを選択して、その構成を調べてみましょう（図11） 図 11: ASP.NET Core Web API ブループリントで生成されたワークフロー 次の画面で、 [Definition] タブを選択して、ワークフローの視覚的な表現と YAML 定義を並べて表示します（図12）。 図 12: ASP.NET Core Web API ブループリントのメインワークフロー YAML ワークフローは、次の 3 つの主要な要素で構成されています。 Triggers : コミットがメインブランチにプッシュされるたびにワークフローを開始します。 Build_And_Test : デフォルトのビルドイメージ で実行されている .NET 6 CLI を使用して、コードをビルドしてテストします。そして、 ./TestResults フォルダーにあるテストレポートを検索し、その結果を画面に表示します。 Deploy_To_AWS : AWS Deploy Tool for .NET を使用してアプリケーションを AWS にデプロイします。Amazon Linux 用の zip yum パッケージのような必要な依存関係をインストールし、使用する AWS 接続を設定します。 –apply に渡す JSON ファイルを変更することで、デプロイ先の AWS サービスを簡単に変更できます。 デフォルトの CI/CD ワークフローの実行 メインワークフローは、CodeCatalyst プロジェクトを作成するとすぐに初めて自動的に実行されます。この最初の実行は、完了するまでに 15 分から 30 分かかります。完了したら、図 13 に赤枠で示すように、 Deploy_To_AWS アクション内で、 dotnet aws deploy コマンドのログの末尾にあるエンドポイントの Amazon ECS サービスロードバランサー URL に移動して、デプロイされたアプリケーションを確認できます。 図 13: ASP.NET Core Web API ブループリント成功実行ログ AWS.NET デプロイツールの設定を調べる AWS Deploy Tool for .NET は、.NET CLI と AWS Toolkit for Visual Studio の両方に対応するインタラクティブなツールであり、最小限の AWS 知識と数回のクリックまたはコマンドで .NET アプリケーションをデプロイできます。AWS Deploy Tool for .NET コマンドラインツールは、1 つのコマンドでアプリケーションをデプロイできるため、CI/CD に最適です。AWS Deploy Tool for .NET は、デプロイレシピとデプロイ設定の概念を通じて、 複数のアプリケーションタイプと AWS コンピューティングサービス をサポートします。 .codecatalyst/deployment/settings/non-prod/ecs-fargate-deployment-settings.json でデプロイ設定の内容を調べることができます。このファイルは、.NET アプリケーション（この場合は AspNetAppEcsFargate ）をデプロイするために使用するレシピを定義し、レシピで定義されたデフォルト値の一部をオーバーライドします。 AspNetAppEcsFargate レシピの場合、Amazon ECS クラスタ名、vCPU 数、Amazon ECS タスク定義で使用するメモリ量などのオプションを上書きします。このレシピと他のすべてのレシピのオプション設定の詳細については、 公式の GitHub repo を参照してください。 AspNetAppEcsFargate レシピを使用してアプリケーションをデプロイすると、.NET デプロイツールは次のタスクを実行します。 プロジェクト内の Dockerfile を検索し、 docker build を実行します。Dockerfile が見つからない場合は、ツールが Dockerfile を試みます 。 コンテナイメージをプッシュするための Amazon Elastic Container Registry (Amazon ECR) を作成します。 コンテナイメージを Amazon ECR リポジトリにプッシュします。 レシピに関連付けられた AWS Cloud Development Kit (AWS CDK) プロジェクトを、デプロイ設定ファイルで上書きした値でデプロイします。 ロードバランサーエンドポイントなどのコンソール AWS リソースの詳細に出力します。 レシピがデフォルトで作成するリソースがアプリケーションに必要なものでない場合は、カスタム デプロイプロジェクト を作成して、ニーズに合わせてカスタマイズできる AWS CDK プロジェクトを作成できます。 クリーンアップ 今後の課金を避けるために、CodeCatalyst ワークフローによって作成されたリソースを削除してください。このブログ記事で提供されている値を使用した場合、リソースは名前が付けられます： AWS CloudFormation stack: CompanyHelloWebAPI Amazon ECR repository: companyhellowebapi まとめ このブログ記事では、ASP.NET Core Web API ブループリントを使用して、Amazon ECS 上の AWS Fargate に .NET アプリケーションをデプロイする方法を学びました。ブループリントは、ソースコードリポジトリ、サンプルソースコード、CI/CD ワークフローを持つプロジェクトを作成し、AWS にデプロイする準備をすべて整えました。 これは、アプリケーションの道のりの出発点にすぎません。次に、独自のソースコードをプッシュし、独自のアプリケーションのニーズに合わせて CI/CD ワークフローを変更できます。 CodeCatalyst ブループリントがどのように .NET アプリケーションの開発を迅速に開始し、より生産的にするのに役立つかについてのアイデアがあれば、 .NET on AWS の公式 Twitter ハンドル で共有してください。AWS 上で .NET アプリケーションを実行するための追加情報やリソースについては、 .NET on AWS をご覧ください。 AWS は、貴社がクラウドを最大限に活用する方法を評価するお手伝いをします。クラウドでの最も重要なアプリケーションの移行とモダナイズで AWS を信頼する何百万ものお客様の仲間入りをしてください。Windows Server または SQL Server の最新化の詳細については、 Windows on AWS をご覧ください。モダナイゼーションの旅を始めるには、今すぐ お問い合わせ ください。 投稿者について Cristobal Espinosa は Amazon Web Services のシニアソリューションアーキテクトです。AWS 上で稼働する .NET アプリケーションのモダナイゼーションを専門に支援。2009 年以来、オープン Web 技術、Kubernetes、CI/CD、クラウドネイティブサービスを使用して、レガシー .NET アプリケーションの近代化を支援しています。 Jagadeesh Chitikesi は、AWS のシニア マイクロソフト スペシャリスト ソリューション アーキテクトです。彼は過去20年間、ヘルスケア、金融、小売、公益事業、政府のあらゆる規模の企業で開発者およびアーキテクトとして働いていました。彼はクラウドとAWSで起こっているすべてのイノベーションに情熱を注いでいます。

この記事は、Professional Services team の Principal Bigdata Consultant である Takeshi Nakatani と Amazon QuickSight の Specialist Solution Architect である Wakana Vilquin-Sakashita によって書かれた Manage users and group memberships on Amazon QuickSight using SCIM events generated in IAM Identity Center with Azure AD (記事公開日: 2023 年 3 月 22 日) を翻訳したものです。 Amazon QuickSight は、ID フェデレーションをサポートするクラウドネイティブでスケーラブルなビジネスインテリジェンス (BI) サービスです。 AWS Identity and Access Management (IAM) により、組織はエンタープライズ ID プロバイダー (IdP) で管理されている ID を使用し、シングルサインオン (SSO) を QuickSight に統合できます。オンプレミスアプリ、サードパーティアプリ、AWS 上のアプリケーションなど、すべてのアプリケーションを使用して一元化されたユーザー ID ストアを構築する組織が増えているため、これらのアプリケーションへのユーザープロビジョニングを自動化し、その属性を一元化されたユーザー ID ストアと同期させるソリューションが必要です。 ユーザーのリポジトリを構築する際、組織によっては、ユーザーをグループにまとめたり、属性 (部署名など) を使用したり、あるいはその両方を組み合わせたりします。組織で一元管理された認証に Microsoft Azure Active Directory (Azure AD) を使用し、そのユーザー属性を利用してユーザーの構成を管理している場合は、すべての QuickSight アカウント間のフェデレーションを有効にできるだけでなく、AWS プラットフォームで生成されたイベントを使用して QuickSight のユーザーとそのグループメンバーシップを管理できます。これにより、システム管理者は Azure AD からユーザー権限を一元管理できます。このソリューションにより、QuickSight のユーザーやグループのプロビジョニング、更新、削除を、QuickSight 上で管理する必要がなくなり、自動同期にて Azure AD の情報と一貫性を保つことができるようになります。 この記事では、Azure AD の自動プロビジョニングが有効になっている AWS アイデンティティセンター (AWS Single Sign-On の後継) を介して QuickSight と Azure AD 間のフェデレーション SSO を設定するために必要な手順について説明します。また、クロスドメインID管理システム (SCIM) イベントを使用して、ユーザーとグループのメンバーシップを自動的に更新するデモも行います。 ソリューション概要 次の図は、ソリューションのアーキテクチャとユーザーフローを示しています。 この記事では、IAM Identity Center を使用してユーザーと AWS アカウントやクラウドアプリケーションへのアクセスを一元管理できます。Azure AD はユーザーリポジトリであり、IAM Identity Center で外部 IdP として設定されています。このソリューションでは、特に Azure AD での 2 つのユーザー属性 ( department , jobTitle ) の使用方法を示します。IAM Identity Center は、SCIM v2.0 プロトコルを使用して Azure AD から IAM Identity Center へのユーザーおよびグループ情報の自動プロビジョニング (同期) をサポートしています。このプロトコルでは、Azure AD の属性が IAM Identity Center に渡され、IAM Identity Center で定義されたユーザープロファイルの属性に継承されます。IAM Identity Center は、SAML (Security Assertion Markup Language) 2.0 とのアイデンティティフェデレーションもサポートしています。これにより、IAM Identity Center は Azure AD を使用して ID を認証できます。その後、ユーザーは QuickSight などの SAML をサポートするアプリケーションに SSO で接続できます。この記事の前半では、これをエンドツーエンドで設定する方法に焦点を当てています (図の Sign-In Flow を参照)。 次に、ユーザー情報は SCIM プロトコルを介して Azure AD と IAM Identity Center の間で同期され始めます。 Amazon EventBridge でキャプチャされた IAM Identity Center から発生した CreateUser SCIM イベントによってトリガーされる AWS Lambda 関数を使用して、QuickSight でのユーザーの作成を自動化できます。同じ Lambda 関数で、指定したグループ (名前が department-jobTitle という2つのユーザー属性で構成されるもの) に追加することでユーザーのメンバーシップも更新できます。グループが存在しない場合は、メンバーシップを追加する前にグループを作成してください。 この記事では、この自動化の部分は、次のセクションで説明する内容と重複するため、省略しています。 この記事では、Azure AD でのユーザープロファイルの更新によってトリガーされる UpdateUser SCIM イベントについて説明し、そのデモを行います。イベントは EventBridge でキャプチャされ、Lambda 関数を呼び出して QuickSight のグループメンバーシップを更新します (図の Update Flow を参照)。この例では、特定のユーザーは一度に 1 つのグループにのみ所属することになっているため、この関数はユーザーの現在のグループメンバーシップを新しいグループメンバーシップに置き換えます。 パート I では、IAM Identity Center 経由で Azure AD から QuickSight への SSO を設定します。(サインインフロー) Azure AD を IAM Identity Center の外部 IdP として設定します。 Azure AD に IAM Identity Center アプリケーションを追加して設定します。 IAM Identity Center の設定を完了します。 Azure AD と IAM Identity Center の両方で SCIM 自動プロビジョニングを設定し、IAM Identity Center 上でその動作を確認します。 IAM Identity Center に QuickSight アプリケーションを追加して設定します。 SAML IdP と SAML 2.0 フェデレーション IAM ロールを設定します。 QuickSight アプリケーションで属性を設定します。 AWS コマンドラインインターフェイス (AWS CLI) または API を使用して、ユーザー、グループ、およびグループのメンバーシップを手動で作成します。 IAM Identity Center ポータルから QuickSight にログインして、設定を確認します。 パート II では、SCIM イベント時にグループのメンバーシップを変更する自動化を設定します。(更新フロー) EventBridge の SCIM イベントとイベントパターンについて理解しましょう。 グループ名の属性マッピングを作成します。 Lambda 関数を作成します。 イベントをトリガーする EventBridge ルールを追加します。 Azure AD のユーザー属性値を変更して構成を確認します。 前提条件 このチュートリアルでは、次の前提条件を満たしている必要があります。 IAM Identity Center の設定。手順については、 AWS IAM Identity Center のユーザーガイドの「はじめに」 のステップ 1 ～ 2 を参照してください。 QuickSight アカウントのサブスクリプション。 IAM に関する基本的な知識と、IAM IdP の作成に必要な権限、ロール、およびポリシーの理解。 Azure AD のサブスクリプション。Azure AD 上に以下の属性をもつ少なくとも一人のユーザが登録されている必要があります。 userPrincipalName – Azure AD ユーザーの必須フィールド。 displayName – Azure AD ユーザーの必須フィールド。 Mail – IAM Identity Center が QuickSight と連携するための必須フィールド。 jobTitle – ユーザーをグループに割り当てるのに使用。 department – ユーザーをグループに割り当てるのに使用。 givenName – オプションフィールド。 surname – オプションフィールド。 パート I: IAM Identity Center 経由で Azure AD から QuickSight に SSO をセットアップする このセクションでは、サインインフローを設定する手順を示します。 IAM Identity Center で外部 IdP を Azure AD として設定する 外部 IdP を設定するには、次の手順を実行します。 IAM Identity Center のコンソールで、 Settings を選択します。 Identity source タブで Actions を選択し、 Change identity source を選択します。 External identity provider を選択し、 Next を選択します。 IdP メタデータが表示されます。このブラウザタブは開いたままにしてください。 Azure AD での IAM Identity Center アプリケーションの追加と設定 IAM Identity Center アプリケーションをセットアップするには、次の手順を実行します。 新しいブラウザタブを開きます。 Azure 管理者の認証情報を使用して Azure AD ポータルにログインします。 Azure services で Azure Active Directory を選択します。 ナビゲーションペインの Manage で、 Enterprise applications を選択し、 New application を選択します。 Browse Azure AD Galley セクションで IAM Identity Center を検索し、 AWS IAM Identity Center (AWS Single Sign-On の後継) を選択します。 アプリケーションの名前を入力し (この記事では IIC-QuickSight を使用しています)、 Create を選択します。 Manage セクションで、 Single sign-on を選択し、次に SAML を選択します。 Assign users and groups セクションで、 Assign users and groups を選択します。 Add user/group を選択し、少なくとも 1 人のユーザーを追加します。 役割として User を選択します。 Set up single sign on セクションで、 Get started を選択します。 Basic SAML Configuration セクションで、 Edit を選択し、次のパラメータと値を入力します。 Identifier – IAM Identity Center issuer URL フィールドの値。 Reply URL – IAM Identity Center Assertion Consumer Service (ACS) URL フィールドの値。 Sign on URL – 空欄のままにしておきます。 Relay State – 空欄のままにしておきます。 Logout URL – 空欄のままにしておきます。 Save を選択します。 設定は次のスクリーンショットのようになるはずです。 SAML Certificates セクションで、 Federation Metadata XML ファイルと Certificate (Raw) ファイルをダウンロードします。 これで、Azure AD SSO の設定は完了です。後でこのページに戻って自動プロビジョニングを設定するので、このブラウザタブは開いたままにしておいてください。 IAM Identity Center の設定を完了 次の手順で IAM Identity Center の設定を完了します。 前のステップで開いたままにしておいた IAM Identity Center コンソールのブラウザタブに戻ります。 Identity provider metadata プロバイダーメタデータセクションの IdP SAML metadata については、 Choose file を選択します。 以前にダウンロードしたメタデータファイル ( IIC-QuickSight.xml ) を選択します。 Identity provider metadata セクションにある IdP certificate については、 Choose file を選択します。 以前にダウンロードした証明書ファイル ( IIC-QuickSight.cer ) を選択します。 Next を選択します。 ACCEPT と入力し、 Change Identity provider source を選択します。 Azure AD と IAM Identity Center の両方に SCIM 自動プロビジョニングをセットアップ プロビジョニング方法はまだ Manual (non-SCIM) に設定されています。このステップでは、IAM Identity Center がユーザーを認識できるように自動プロビジョニングを有効にします。これにより、QuickSight への ID フェデレーションが可能になります。 Automatic provisioning セクションで、Enable を選択します。 Access token を選択してトークンを表示します。 Step 1 で開いたままにしていたブラウザータブ (Azure AD) に戻ります。 Manage セクションで、 Enterprise applications を選択します。 IIC-QuickSight を選択し、次に Provisioning を選択します。 Provisioning Mode で Automatic を選択し、次の値を入力します。 Tenant URL — SCIM endpoint フィールドの値。 Secret Token — Access token フィールドの値。 Test Connection を選択します。 テスト接続が正常に完了したら、 Provisioning Status を On に設定します。 Save を選択します。 SCIM プロトコルを使用して自動プロビジョニングを開始するには、 Start provisioning を選択します。 プロビジョニングが完了すると、1 人以上のユーザーが Azure AD から IAM Identity Center に伝達されます。次のスクリーンショットは、IAM Identity Center 上にプロビジョニングされたユーザーを示しています。 この SCIM プロビジョニングでは、IAM Identity Center から発生したイベントによってトリガーされる Lambda 関数を使用して QuickSight のユーザーを作成する必要があることに注意してください。この記事では、AWS CLI を使用してユーザーとグループのメンバーシップを作成します (Step 8)。 IAM Identity Center での QuickSight アプリケーションの追加と設定 このステップでは、IAM Identity Center で QuickSight アプリケーションを作成します。また、アプリケーションが動作するように IAM SAML プロバイダー、ロール、およびポリシーを設定します。次の手順を実行してください。 IAM Identity Center コンソールの Applications ページで、 Add Application を選択します。 Select an application に Pre-integrated application に quicksight と入力します。 Amazon QuickSight を選択し、 Next を選択します。 Display name に Amazon QuickSight などの名前を入力します。 IAM Identity Center SAML metadata file の下の Download を選択し、コンピューターに保存します。 他のフィールドはすべてそのままにして、設定を保存します。 作成したアプリケーションを開いて、 Assign Users を選択します。 先に SCIM 経由でプロビジョニングされたユーザーが一覧表示されます。 アプリケーションに割り当てるユーザーをすべて選択します。 SAML IdP と SAML 2.0 フェデレーション IAM ロールの設定 IAM Identity Center の IAM SAML IdP と、 IAM ロールをセットアップするには、以下の手順を実行します。 IAM コンソールのナビゲーションペインで Identity providers を選択し、 Add provider を選択します。 Provider type として SAML を選択し、 Provider name として Azure-IIC-QS を入力します。 Metadata document で Choose file を選択し、以前にダウンロードしたメタデータファイルをアップロードします。 Add provider を選択して設定を保存します。 ナビゲーションペインで Roles を選択し、次に Create role を選択します。 Trusted entity type で、 SAML 2.0 federation を選択します。 Choose a SAML 2.0 provider で、作成した SAML プロバイダーを選択し、 Allow programmatic and AWS Management Console access を選択します。 Next を選択します。 Add Permission ページで、 Next を選択します。 この記事では、AWS CLI コマンドを使用して QuickSight ユーザーを作成しているため、許可ポリシーは作成しません。ただし、QuickSight のセルフプロビジョニング機能が必要な場合は、(QuickSight ユーザーのロールに応じて) CreateReader 、 CreateUser 、 CreateAdmin アクションの許可ポリシーが必要です。 Name, review, and create ページの Role details に、ロールとして qs-reader-azure と入力します。 Create role を選択します。 ロールの ARN をメモしておきます。 ARN を使用して IAM Identity Center アプリケーションの属性を設定します。 QuickSight アプリケーションでの属性の設定 IAM SAML IdP と IAM ロールを IAM Identity Center の QuickSight アプリケーションに関連付けるには、以下の手順を実行します。 IAM Identity Center コンソールのナビゲーションペインで、 Applications を選択します。 Amazon QuickSight アプリケーションを選択し、 Actions メニューで Edit attribute mappings を選択します。 Add new attribute mapping を選択します。 次の表でマッピングを設定します。 User attribute in the application Maps to this string value or user attribute in IAM Identity Center Subject ${user:email} https://aws.amazon.com/SAML/Attributes/RoleSessionName ${user:email} https://aws.amazon.com/SAML/Attributes/Role arn:aws:iam:: <ACCOUNTID> :role/qs-reader-azure,arn:aws:iam:: <ACCOUNTID> :saml-provider/Azure-IIC-QS https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email ${user:email} 次の値に注意してください。 <ACCOUNTID> をAWS アカウント ID に置き換えてください。 PrincipalTag:Email は、QuickSight 管理ページで有効にする必要があるセルフプロビジョニングユーザー向けのメール同期機能用です。この記事では、ユーザーを AWS CLI コマンドで登録するので、この機能を有効にしないでください。 Save changes を選択します。 AWS CLI を使用してユーザー、グループ、およびグループメンバーシップを作成する 前述のように、このソリューションでは QuickSight のユーザーとグループが手動で作成されます。これらを以下の AWS CLI コマンドで作成します。 最初のステップは、以前に作成した IAM ロールと Azure AD に登録されているメールアドレスを指定して QuickSight でユーザーを作成することです。2 番目のステップでは、最初のステップで作成したユーザーのために、Azure AD の属性値を組み合わせた名称でグループを作成します。3 番目のステップは、以前に作成したグループにユーザーを追加することです。 member-name は、QuickSight で作成された <IAM Role name>/<session name> で構成されるユーザー名を示します。次のコードを参照してください。 aws quicksight register-user \ --aws-account-id <ACCOUNTID> --namespace default \ --identity-type IAM --email <email registered in Azure AD> \ --user-role READER --iam-arn arn:aws:iam:: <ACCOUNTID> :role/qs-reader-azure \ --session-name <email registered in Azure AD> aws quicksight create-group \ --aws-account-id <ACCOUNTID> --namespace default \ --group-name Marketing-Specialist aws quicksight create-group-membership \ --aws-account-id <ACCOUNTID> --namespace default \ --member-name qs-reader-azure/<email registered in Azure AD> \ –-group-name Marketing-Specialist この時点で、Azure AD、IAM Identity Center、IAM、および QuickSight のエンドツーエンド構成は完了しています。 IAM Identity Center ポータルから QuickSight にログインして設定を確認します。 これで、IdP が開始する SSO フローを使用して QuickSight にログインする準備ができました。 ブラウザで新しいプライベートウィンドウを開きます。 IAM Identity Center ポータル ( https://d-xxxxxxxxxx.awsapps.com/start ) にログインします。 Azure AD のログインプロンプトにリダイレクトされます。 Azure AD の認証情報を入力します。 IAM Identity Center ポータルにリダイレクトされます。 IAM Identity Center ポータルで、 Amazon QuickSight を選択します。 QuickSight ホームに自動的にリダイレクトされます。 パート II: SCIM イベント発生時のグループメンバーシップ変更の自動化 このセクションでは、更新フローを設定します。 EventBridge の SCIM イベントとイベントパターンを理解する Azure AD 管理者が特定のユーザープロファイルの属性に変更を加えると、その変更は SCIM プロトコル経由で IAM Identity Center のユーザープロファイルと同期され、アクティビティは sso-directory.amazonaws.com (IAM Identity Center) をイベントソースとして、 UpdateUser という名前のイベントで AWS CloudTrail に記録されます。同様に、 CreateUser イベントは Azure AD でユーザーが作成されたときに記録され、 DisableUser イベントはユーザーが無効になったときに記録されます。 Event history ページの次のスクリーンショットは、2 つの CreateUser イベントを示しています。1 つは IAM Identity Center によって記録され、もう 1 つは QuickSight によって記録されます。この記事では、IAM Identity Center のものを使用します。 EventBridgeがフローを適切に処理できるようにするには、イベントパターンと一致させたいイベントのフィールドを各イベントで指定する必要があります。次のイベントパターンは、SCIM 同期時に IAM Identity Center で生成される UpdateUser イベントの例です。 { “source”: [“aws.sso-directory”], “detail-type”: [“AWS API Call via CloudTrail”], “detail”: { “eventSource”: [“sso-directory.amazonaws.com”], “eventName”: [“UpdateUser”] } } この記事では、 UpdateUser SCIM イベントによってトリガーされる QuickSight のグループメンバーシップの自動更新について説明します。 グループ名の属性マッピングを作成 Lambda 関数が QuickSight のグループメンバーシップを管理するには、2 つのユーザー属性 ( department と jobTitle ) を取得する必要があります。プロセスを簡単にするために、Azure AD の属性マッピング機能を使用して、Azure AD の 2 つの属性 ( department , jobTitle ) を IAM Identity Center の 1 つの属性 ( title ) にまとめています。次に、IAM Identity Center は title 属性をこのユーザーの指定グループ名として使用します。 Azure AD コンソールにログインし、 Enterprise Applications 、 IIC-QuickSight 、および Provisioning に移動します。 Edit attribute mappings を選択します。 Mappings で、 Provision Azure Active Directory Users を選択します。 Azure Active Directory Attributes のリストから jobTitle を選択します。 次の設定を変更します。 Mapping Type – Expression Expression – Join("-", [department], [jobTitle]) Target attribute – title Save を選択します。 これで、プロビジョニングの設定は完了です。 属性は IAM Identity Center で自動的に更新されます。更新されたユーザープロファイルは、次のスクリーンショットのようになります (最初の図は Azure AD、その次の図が IAM Identity Center)。 Lambda 関数を作成する 次に、SCIM イベント時に QuickSight グループのメンバーシップを更新する Lambda 関数を作成します。この機能の中核となるのは、トリガーされたイベント情報に基づいて IAM Identity Center でユーザーの title 属性値を取得し、そのユーザーが QuickSight に存在することを確認することです。グループ名がまだ存在しない場合は、QuickSight でグループを作成し、ユーザーをグループに追加します。次の手順を実行してください。 Lambda コンソールで、 Create function を選択します。 Name に UpdateQuickSightUserUponSCIMEvent と入力します。 Runtime には Python 3.9 を選択します。 Time Out には、15 秒に設定します。 Permissions については、以下の権限を含む IAM ロールを作成してアタッチします (信頼できるエンティティ (プリンシパル) は lambda.amazonaws.com でなければなりません)。 { "Version": "2012-10-17", "Statement": [ { "Sid": "MinimalPrivForScimQsBlog", "Effect": "Allow", "Action": [ "identitystore:DescribeUser", "quicksight:RegisterUser", "quicksight:DescribeUser", "quicksight:CreateGroup", "quicksight:DeleteGroup", "quicksight:DescribeGroup", "quicksight:ListUserGroups", "quicksight:CreateGroupMembership", "quicksight:DeleteGroupMembership", "quicksight:DescribeGroupMembership", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] } IdentityStore と QuickSight 用の Boto3 SDK を使用して Python コードを記述します。以下はサンプルの Python コード全体です。 import sys import boto3 import json import logging from time import strftime from datetime import datetime # Set logging logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): ''' Modify QuickSight group membership upon SCIM event from IAM Identity Center originated from Azure AD. It works in this way: Azure AD -> SCIM -> Identity Center -> CloudTrail -> EventBridge -> Lambda -> QuickSight Note that this is a straightforward sample to show how to update QuickSight group membership upon certain SCIM event. For example, it assumes that 1:1 user-to-group assigmnent, only one (combined) SAML attribute, etc. For production, take customer requirements into account and develop your own code. ''' # Setting variables (hard-coded. get dynamically for production code) qs_namespace_name = 'default' qs_iam_role = 'qs-reader-azure' # Obtain account ID and region account_id = boto3.client('sts').get_caller_identity()['Account'] region = boto3.session.Session().region_name # Setup clients qs = boto3.client('quicksight') iic = boto3.client('identitystore') # Check boto3 version logger.debug(f"## Your boto3 version: {boto3.__version__}") # Get user info from event data event_json = json.dumps(event) logger.debug(f"## Event: {event_json}") iic_store_id = event['detail']['requestParameters']['identityStoreId'] iic_user_id = event['detail']['requestParameters']['userId'] # For UpdateUser event, userId is provided through requestParameters logger.info("## Getting user info from Identity Store.") try: res_iic_describe_user = iic.describe_user( IdentityStoreId = iic_store_id, UserId = iic_user_id ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## User info retrieval succeeded.") azure_user_attribute_title = res_iic_describe_user['Title'] azure_user_attribute_userprincipalname = res_iic_describe_user['UserName'] qs_user_name = qs_iam_role + "/" + azure_user_attribute_userprincipalname logger.info(f"#### Identity Center user name: {azure_user_attribute_userprincipalname}") logger.info(f"#### QuickSight group name desired: {azure_user_attribute_title}") logger.debug(f"#### res_iic_describe_user: {json.dumps(res_iic_describe_user)}, which is {type(res_iic_describe_user)}") # Exit if user is not present since this function is supposed to be called by UpdateUser event try: # Get QuickSight user name res_qs_describe_user = qs.describe_user( UserName = qs_user_name, AwsAccountId = account_id, Namespace = qs_namespace_name ) except qs.exceptions.ResourceNotFoundException as e: logger.error(f"## User {qs_user_name} is not found in QuickSight.") logger.error(f"## Make sure the QuickSight user has been created in advance. Exiting.") logger.error(e) sys.exit() except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## User {qs_user_name} is found in QuickSight.") # Remove current membership unless it's the desired one qs_new_group = azure_user_attribute_title # Set "Title" SAML attribute as the desired QuickSight group name in_desired_group = False # Set this flag True when the user is already a member of the desired group logger.info(f"## Starting group membership removal.") try: res_qs_list_user_groups = qs.list_user_groups( UserName = qs_user_name, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: # Skip if the array is empty (user is not member of any groups) if not res_qs_list_user_groups['GroupList']: logger.info(f"## User {qs_user_name} is not a member of any QuickSight group. Skipping removal.") else: for grp in res_qs_list_user_groups['GroupList']: qs_current_group = grp['GroupName'] # Retain membership if the new and existing group names match if qs_current_group == qs_new_group: logger.info(f"## The user {qs_user_name} already belong to the desired group. Skipping removal.") in_desired_group = True else: # Remove all unnecessary memberships logger.info(f"## Removing user {qs_user_name} from existing group {qs_current_group}.") try: res_qs_delete_group_membership = qs.delete_group_membership( MemberName = qs_user_name, GroupName = qs_current_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error(f"## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## The user {qs_user_name} has removed from {qs_current_group}.") # Create group membership based on IIC attribute "Title" logger.info(f"## Starting group membership assignment.") if in_desired_group is True: logger.info(f"## The user already belongs to the desired one. Skipping assignment.") else: try: logger.info(f"## Checking if the desired group exists.") res_qs_describe_group = qs.describe_group( GroupName = qs_new_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except qs.exceptions.ResourceNotFoundException as e: # Create a QuickSight group if not present logger.info(f"## Group {qs_new_group} is not present. Creating.") today = datetime.now() res_qs_create_group = qs.create_group( GroupName = qs_new_group, Description = 'Automatically created at ' + today.strftime('%Y.%m.%d %H:%M:%S'), AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error(f"## Operation failed due to unknown error. Exiting.") logger.error(e) sys.exit() else: logger.info(f"## Group {qs_new_group} is found in QuickSight.") # Add the user to the desired group logger.info("## Modifying group membership based on its latest attributes.") logger.info(f"#### QuickSight user name: {qs_user_name}") logger.info(f"#### QuickSight group name: {qs_new_group}") try: res_qs_create_group_membership = qs.create_group_membership( MemberName = qs_user_name, GroupName = qs_new_group, AwsAccountId = account_id, Namespace = qs_namespace_name ) except Exception as e: logger.error("## Operation failed due to unknown error. Exiting.") logger.error(e) else: logger.info("## Group membership modification succeeded.") qs_group_member_name = res_qs_create_group_membership['GroupMember']['MemberName'] qs_group_member_arn = res_qs_create_group_membership['GroupMember']['Arn'] logger.debug("## QuickSight group info:") logger.debug(f"#### qs_user_name: {qs_user_name}") logger.debug(f"#### qs_group_name: {qs_new_group}") logger.debug(f"#### qs_group_member_name: {qs_group_member_name}") logger.debug(f"#### qs_group_member_arn: {qs_group_member_arn}") logger.debug("## IIC info:") logger.debug(f"#### IIC user name: {azure_user_attribute_userprincipalname}") logger.debug(f"#### IIC user id: {iic_user_id}") logger.debug(f"#### Title: {azure_user_attribute_title}") logger.info(f"## User {qs_user_name} has been successfully added to the group {qs_new_group} in {qs_namespace_name} namespace.") # return response return { "namespaceName": qs_namespace_name, "userName": qs_user_name, "groupName": qs_new_group } この Lambda 関数には Boto3 1.24.64 以降が必要であることに注意してください。 Lambda runtime に含まれている Boto3 がこれより古い場合は、Lambda レイヤーを使用して Boto3 の最新バージョンを使用してください。詳細については、 How do I resolve “unknown service”, “parameter validation failed”, and “object has no attribute” errors from a Python (Boto 3) Lambda function を参照してください。 イベントをトリガーする EventBridge ルールの追加 以前に作成した Lambda 関数を呼び出すための EventBridge ルールを作成するには、以下の手順を実行します。 EventBridge コンソールで、新しいルールを作成します。 Name に updateQuickSightUponSCIMEvent と入力します。 Event pattern には、次のコードを入力します。 { "source": ["aws.sso-directory"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventSource": ["sso-directory.amazonaws.com"], "eventName": ["UpdateUser"] } } Targets については、作成した Lambda 関数 ( UpdateQuickSightUserUponSCIMEvent ) を選択します。 ルールを有効にします。 Azure AD のユーザー属性値を変更して構成を確認 Azure AD でユーザーの属性を変更し、新しいグループが作成され、そのユーザーが新しいグループに追加されているかどうかを確認してみましょう。 Azure AD コンソールに戻ってください。 Manage から Users をクリックします。 以前に IAM Identity Center ポータルから QuickSight へのログインに使用したユーザーを 1 人選択します。 Edit properties を選択し、 Job title と Department の値を編集します。 設定を保存します。 Manage から、 Enterprise application 、自身のアプリケーション名、 Provisioning を選択します。 Stop provisioning を選択し、次に Start provisioning を順番に選択します。 Azure AD では、SCIM のプロビジョニング間隔は 40 分に固定 されています。すぐに結果を得るために、プロビジョニングを手動で停止して開始します。 QuickSight コンソールに移動します。 ドロップダウンユーザー名メニューで、 Manage QuickSight を選択します。 Manage groups を選択します。 これで、新しいグループが作成され、ユーザーがこのグループに割り当てられていることがわかります。 クリーンアップ ソリューションを使い終わったら、環境をクリーンアップしてコストへの影響を最小限に抑えます。次のリソースを削除したい場合があります。 Lambda 関数 Lambda レイヤー Lambda 関数用の IAM ロール Lambda 関数用の CloudWatch ロググループ EventBridge ルール QuickSight アカウント 注 : AWS アカウントごとに作成できる QuickSight アカウントは 1 つだけです。そのため、QuickSight アカウントは組織内の他のユーザーによって既に使用されている可能性があります。QuickSight アカウントを削除するのは、このブログをフォローするように明示的に設定していて、他のユーザーがそのアカウントを使用していないことが確実である場合だけにしてください。 IAM Identity Center インスタンス Azure AD 用の IAM ID Provider 設定 Azure AD インスタンス サマリー この記事では、QuickSight ユーザーを一元管理するために IAM Identity Center SCIM プロビジョニングと Azure AD から SAML 2.0 フェデレーションを設定する手順を段階的に説明しました。また、IAM Identity Center で生成された SCIM イベントを使用し、EventBridge と Lambda を使用して自動化を設定することで、Azure AD のユーザー属性に基づいて QuickSight でグループメンバーシップを自動的に更新するデモも行いました。 QuickSight でユーザーとグループをプロビジョニングするこのイベントドリブンアプローチにより、システム管理者は組織に応じてさまざまなユーザー管理方法を柔軟に決定できます。また、ユーザーがいつ QuickSight にアクセスしても、QuickSight と Azure AD 間でユーザーとグループの整合性が保たれます。 Quicksight のコミュニティ に参加して、他のユーザーと一緒に質問したり、回答したり、学んだり、その他のリソースを調べたりしてみてください。 翻訳はソリューションアーキテクト 溝渕 匡 が担当しました。原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、データベースアクティビティストリームをサポートするようになり、リレーショナルデータベース内のデータベースアクティビティをほぼリアルタイムでストリーム配信できるようになりました。データベースを内部および外部の脅威から保護し、コンプライアンスや規制要件を満たすために、データベースアクティビティストリームをサードパーティのデータベースアクティビティ監視ツールと簡単に統合して、データベースアクティビティを監視および監査できます。ログイン失敗などのデータベースアクティビティは、暗号化されたデータストリームに非同期的にプッシュされ、 Amazon Kinesis Data Streams を使用してデータベースインスタンスにプロビジョニングされます。 この投稿では、Amazon RDS for SQL Server で実行されているデータベースアクティビティのほぼリアルタイムのデータストリームのデータベースアクティビティストリームを有効にする方法を説明します。データベースアクティビティストリームを有効にすると、データベース内のアクティビティを監視して監査用のアラームを設定できます。 ソリューション概要 ソリューションを実装するには、以下の大まかな手順を実行します。 データベースアクティビティストリーム用の AWS Key Management Service (AWS KMS) キーを作成します。 Amazon RDS for SQL Server にサンプルデータベースを作成します。 サーバーとデータベースの監査仕様を作成します。 データベースアクティビティストリームを開始します。 データベースアクティビティを分析します。 ログを保存する Amazon Simple Storage Service (Amazon S3) バケットを作成します。 S3 バケットにログを保存するように Amazon Kinesis Data Firehose のデリバリーストリームを設定します。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 Amazon RDS for SQL Server では、データベースアクティビティストリームには次の要件があります。 データベースアクティビティストリームでサポートされている DB インスタンスクラス サポートされている SQL Server バージョン (SQL Server 2016 以降、すべてのエディション) AWS キーマネジメントサービス (AWS KMS) のカスタマー管理型のキー データベースアクティビティストリーム用の KMS キーの作成 データベースアクティビティストリームには、記録されたデータベースアクティビティを暗号化および復号化するために管理する KMS キーが必要です。データベースアクティビティストリーミングにはデフォルトの Amazon RDS KMS キーは使用できません。カスタマー管理型の KMS キーを新たに作成する必要があります。詳細については、「 キーの作成 」を参照してください。 AWS KMS コンソールで、[ キーの作成 ] を選択します。 キータイプ には [ 対称 ] を選択します。 [ キーの使用方法 ] で [ 暗号化および復号化 ] を選択します。 [ 次へ ] を選択します。 「 ラベルを追加 」セクションの「 エイリアス 」で、キーの名前を入力します。 [ 説明 ] には、次のようなキーの説明を入力します。 Customer managed Key for Amazon RDS for SQL Server Database Activity Streaming (DAS) [ 次へ ] を選択します。 「 キーの管理アクセス許可を定義 」で、AWS KMS API を通じてこのキーを管理できる AWS Identity and Access Management (IAM) ユーザーとロールを選択します。 [ 次へ ] を選択します。 「 キーの使用アクセス許可を定義 」セクションで、キーを管理する IAM ユーザーまたはロールを選択します。 [ 次へ ] を選択します。 キーポリシーを確認し、[ 完了 ] を選択します。 Amazon RDS for SQL Server にサンプルデータベースを作成する 最初にサンプルデータベース TestDB を作成し、次にテーブル TestTable を作成します。以下のステップを完了してください。 SQL Server Management Studio (SSMS) を開きます。 RDS for SQL Server データベースインスタンスに接続します。 [ 新しいクエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 CREATE DATABASE testDB Go Use testDB Go CREATE TABLE [testDB].[dbo].[TestTable]( textA varchar (6000), textB varchar (6000) ) サーバーレベル監査の仕様の変更とデータベース監査の仕様の作成 デフォルトでは、Amazon RDS 監査仕様は失敗したログインを追跡します。そこで、監査で成功したログイン情報を収集し、すべてのログイン試行を追跡できるようにしましょう。 まず、サーバーレベル監査の仕様から始めましょう。 SSMS では、[新しいクエリ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 ( SSMS で [セキュリティ] → [サーバー監査の仕様] に RDS_DAS_SERVER_AUDIT_SPEC が作成されているのでダブルクリックして内容を確認します。) USE [master] GO ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC] WITH (STATE = OFF) ALTER SERVER AUDIT SPECIFICATION [RDS_DAS_SERVER_AUDIT_SPEC] ADD (SUCCESSFUL_LOGIN_GROUP) WITH (STATE = ON) GO データベースレベルの監査では、テストテーブルの SELECT や INSERT などの DML ステートメントを監査します。 [ 新規クエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 (SSMS の testDB の [セキュリティ] → [データベース監査の仕様] に RDS_DAS_DA_testDB が作成されているのでダブルクリックして内容を確認します。) USE [testDB] Go CREATE DATABASE AUDIT SPECIFICATION [RDS_DAS_DB_testDB] FOR SERVER AUDIT [RDS_DAS_AUDIT] ADD (SELECT ON OBJECT::[dbo].[TestTable] BY [public]), ADD (INSERT ON OBJECT::[dbo].[TestTable] BY [public]) WITH (STATE = ON) Go 仕様を設定したら、データベースアクティビティストリームを開始しましょう。 データベースアクティビティストリームを開始する Amazon RDS for SQL Server でデータベースアクティビティストリームを開始するには、以下のステップを実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択します。 アクティビティストリームを開始する RDS for SQL Server データベースインスタンスを選択します。 「 アクション 」メニューで、[ データベースアクティビティストリームを開始 ] を選択します。 AWS KMS キー には、前に作成した KMS キーを選択します。 「スケジュール」セクションで、[ 今すぐ ] を選択します。 [ データベースアクティビティストリームを開始 ] を選択します。 この機能を有効にしても、ダウンタイムや再起動は必要ありません。 [ データベース ] ページで [ アクティビティストリームを設定中 ] から [ 使用可能] へのステータスの変化を監視します。 Kinesis Data Streams コンソールに移動し、データストリームのステータスが [ アクティブ ] であることを確認します。 Kinesis データストリームの サーバー側の暗号化 は無効のままにしておく必要があることに注意してください。暗号化を有効にすると、データベースのアクティビティストリームに直接影響します。 Kinesis クライアントアプリケーションを使用してデータベースアクティビティストリームを分析する データベースのアクティビティを記録するために、いくつかの INSERT ステートメントと SELECT ステートメントを実行してみましょう。 SSMS では、[ 新規クエリ ] を選択します。 次のクエリを入力し、[ 実行 ] を選択します。 USE [testDB] Go INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Bob', 'Johnson'); INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Jinnie', 'Johnson'); INSERT INTO [testDB].[dbo].[TestTable] VALUES ('Rob', 'Brown'); select * from [testDB].[dbo].[TestTable] Kinesis データストリームから監査データを読み取るには、前に作成したのと同じ KMS キーを使用してデータを復号化する必要があります。 以下のサンプル出力では、Kinesis クライアントライブラリ for Java を使用して Kinesis データストリームからデータを抽出し、監査レコードとそのフィールドを表示しています。 { "type": "DatabaseActivityMonitoringRecord", "clusterId": "", "instanceId": "db- HAFFQILMCDWKPXURN67M5TQFXY", "databaseActivityEventList": [ { "class ": "TABLE", "clientApplication": "Microsoft SQL Server Management Studio - Query", "command": "INSERT", "commandText": "INSERT INTO [testDB].[dbo].[TestTable]\r\nVALUES ('Jinnie', 'Johnson')", "databaseName": "testDB", "dbProtocol": "SQLSERVER", "dbUserName": "admin", "endTime": null, "errorMessage": null, "exitCode": 1, "logTime": "2023-02-02 22:01:49.5283055+00", "netProtocol": null, "objectName": "TestTable", "objectType": "TABLE", "paramList": null, "pid": null, "remoteHost": " 10.145.xx.xx", "remotePort": null, "rowCount": 0, "serverHost": "172. 30.2.173", "serverType": "SQLSERVER", "serverVersion": "15.00.4236.7.v1.R1", "serviceName": "sqlserver-se", "sessionId": 75, "startTime": null, "statementId": "0xaffb4ff267b e9d45a3e7518553d73a40", "substatementId": 1, "transactionId": "22914 7", "type": "record", "engineNativeAuditFields": {} } ] } ストリームログを保存する S3 バケットを作成する さらに、ログストリームを Amazon S3 にエクスポートして、サードパーティによる監視やアプリケーションの監査を行うことができます。 Amazon S3 コンソール、AWS SDK を使用してストリームログを保存する S3 バケットを作成できます。 または AWS コマンドラインインターフェイス (AWS CLI)。手順については、「 バケットの作成 」を参照してください。 レコードを長期間アーカイブして保存するには、 S3 ライフサイクル を設定します。 Kinesis Data Firehose のデリバリーストリームの設定 データベースアクティビティストリームを有効にしたら、Firehose 配信ストリームを作成する必要があります。以下のステップを完了してください。 Kinesis Data Firehose コンソールで、[ 配信ストリームを作成 ] を選択します。 [ ソース ] には [ Amazon Kinesis データストリーム ] を選択します。 送信先 には Amazon S3 を選択します。 [ 配信ストリーム名 ] に、配信ストリームの名前を入力します。 監査仕様の変更 監査仕様を変更するには、次の手順を実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択して DB インスタンスのリストを表示します。 RDS for SQL Server インスタンスを選択します。 「 アクション 」メニューで、[ データベースアクティビティストリームの変更 ] を選択します。 [ ロック解除済 ] を選択し、[ DB アクティビティストリームを変更 ] を選択します。 RDS for SQL Server インスタンスの監査仕様を必要に応じて変更します。 変更が完了したら、前のステップを繰り返して [ ロック済み ] を選択します。 データベースアクティビティストリームを停止する Amazon RDS for SQL Server のデータベースアクティビティストリームを停止するには、以下のステップを実行します。 Amazon RDS コンソールのナビゲーションペインで、[ データベース ] を選択して DB インスタンスのリストを表示します。 RDS for SQL Server インスタンスを選択します。 [ アクション ] メニューで [ データベースアクティビティストリームを停止 ] を選択します。 [ 今すぐ ] を選択します。 データベースアクティビティストリームが停止していることを確認するメッセージが表示されます。 データベースの状態が [ アクティビティストリームを設定中 ] から [ 利用可能 ] に変わることを確認します。 結論 この投稿では、データベース監査要件を満たすように RDS for SQL Server インスタンスでデータベースアクティビティストリームを設定する手順を説明しました。監視や警告のために監査データを視覚化するさまざまな方法について説明しました。この機能は、データベースオブジェクトに対して行われたユーザーアクティビティを監視して記録するのに役立ちます。Amazon RDS for SQL Server でこの機能を使用する前に、監査要件を確認し、パフォーマンスへの影響と追跡するアクティビティの種類を検討し、コンプライアンス基準を遵守することをお勧めします。 著者について Vikas Babu Gali は、アマゾンウェブサービスのマイクロソフトワークロードを専門とするシニアスペシャリストソリューションアーキテクトです。インド出身のVikasは、クリケットをプレーしたり、家族や友人と屋外で過ごすことを楽しんでいます。 Sudhir Amin は、アマゾンウェブサービスのデータベーススペシャリストソリューションアーキテクトです。ニューヨークを拠点に、さまざまな業種の企業顧客にアーキテクチャに関するガイダンスと技術支援を提供し、クラウドの導入を加速させています。彼はスヌーカー、ボクシングやUFCなどの格闘技の大ファンであり、野生生物保護区が豊富な国を旅して世界で最も雄大な動物を間近で見ることが大好きです。   翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

データベースのセキュリティを維持することは、あらゆる組織の成功にとって不可欠です。データベースユーザーの認証と認可の実装は、データベースシステムを保護するための重要な手順です。従来のデータベース認証は、ユーザー名とパスワードのメカニズムに基づいています。このプロセスでは資格情報を管理するために DBA とエンドユーザーの両方に一定の時間と労力が必要です。対照的にリレーショナルデータベース認証を Microsoft Active Directory (AD) などの集中認証サービスと組み込むことは、より安全で広く受け入れられている業界のベストプラクティスです。 SQL Server は ２ つの 認証 モードをサポートしています。 Windows 混合モード Amazon Relational Database Service (Amazon RDS) for SQL Server は、混合モード認証のみをサポートします。お客様が Windows 認証のみを利用したいシナリオでは、SQL ログイン作成を監視するカスタムソリューションを実装できます。 この投稿では、Amazon RDS for SQL Server インスタンス内で SQL ログインが作成されたときに E メール通知を受け取るソリューションを紹介します。 ソリューションの概要 この投稿のソリューションでは、 データベースメール が構成された Amazon RDS for SQL Server を使用します。データベースメールを使用すると、SMTP (Simple Mail Transfer Protocol) サーバーを使用して SQL Server からユーザーにメッセージを送信することができます。 Amazon RDS for SQL Server インスタンスには、データベースインスタンス内での SQL ログインの作成を定期的に監視するように設定された SQL エージェントジョブがあります。 SQL ログインの作成を検出すると、SQL Server エージェントジョブはデータベース管理者が適切なアクションを取れるように、ログインの詳細を含む E メールメッセージをデータベース管理者に送信します。 次の図は、ソリューションのアーキテクチャ図です。 Amazon Simple Email Service (Amazon SES) は、独自の E メールアドレスとドメインを使用して E メールを送受信するための簡単かつコスト効率の高い方法を提供する E メールプラットフォームです。 前提条件 開始するには、次の前提条件を満たしている必要があります。 Amazon RDS for SQL Server インスタンス Amazon SES で構成された SQL サーバー データベースメール SQL Server Management Studio (SSMS) の知識があること SQL エージェントジョブ の作成に関する知識があること Amazon SES 経由で E メールを送信するようにデータベースメールを構成する 「 Amazon RDS for SQL Server でのデータベースメールの使用 」の投稿では、Amazon SES でデータベースメールを設定するための詳細な手順を説明しました。データベースメールを使用すると、Amazon RDS on SQL Server データベースインスタンスからユーザーに E メールメッセージを送信できます。 Amazon RDS は、SQL Server の Web、Standard および Enterprise Edition のすべてのバージョンのデータベースメールをサポートします。 データベースメールを構成した後、テスト E メールを送信して成功したかどうかをすぐに検証できます。 SQLエージェントジョブの作成 次のステップは、SQL エージェントジョブを作成して、SQL ログインを定期的に監視するスケジュールを設定します。 SQL Server Management Studio を使用して SQL Server にログインします。 SQL Server エージェントの下の ジョブ のコンテキストメニューを開き (右クリック)、[ 新しいジョブ ] を選択します。 SQL エージェントジョブの 名前 を指定します。 「 ページの選択 」セクションで [ ステップ ] を選択し、[ 新規作成 ] を選択します。 ステップ名 を指定し、コマンドセクション内に次の T-SQL スクリプトをコピーして貼り付けます。このスクリプトは sys.sql_logins DMV を監視し、 マスターユーザー 以外の SQL ログインが見つかった場合に E メール通知を送信します。 必要に応じて、T-SQL スクリプトで次の変更を行う必要があります。 DECLARE @SQLLoginCount INT DECLARE @myTableVariable TABLE (SQLLogin Nvarchar(50), LoginCreateDate datetime) DECLARE @mailBody Nvarchar(MAX); DECLARE @xml NVARCHAR(MAX) DECLARE @body NVARCHAR(MAX) SET @SQLLoginCount = (SELECT count(*) FROM master.sys.sql_logins where name not like '##%' and name not in ('rdsa', 'admin')) --Edit master username Insert into @myTableVariable (SQLLogin, LoginCreateDate) Select [name], [create_date] FROM master.sys.sql_logins where name not like '##%' and name not in ('rdsa', 'admin') --Edit master username If @SQLLoginCount > 0 BEGIN SET @xml = CAST(( SELECT [SQLLogin] AS 'td','',LoginCreateDate AS 'td','' FROM @myTableVariable FOR XML PATH('tr'), ELEMENTS ) AS NVARCHAR(MAX)) SET @body ='<html><body><H3>A new SQL login(s) was detected on the RDS SQL Server. Please verify why this login(s) was created</H3> <table border = 1> <tr> <th> SQLLogin </th> <th> LoginCreateDate </th> </tr>' SET @body = @body + @xml +'</table></body></html>' EXEC msdb.dbo.sp_send_dbmail @profile_name = 'Notifications', @recipients = '<xyz@example.com>', --Edit email address @body = @body, @body_format ='HTML', @subject = 'New SQL Login(s) Created On RDS SQL server '; END admin – このソリューションではマスターユーザーとしてデフォルトの「admin」を使用しました。デフォルトの「admin」からマスターユーザー名を変更する場合は、マスターユーザー名を編集します。この変更箇所はスクリプト内で 2 箇所 あります。 @recipients – 必要に応じて受信者の E メールアドレスを編集します。この変更箇所はスクリプト内で 1 箇所 です。 スクリプトに変更を加えたら、[ OK ] を選択します。 「 ページの選択 」セクションで [ スケジュール ] を選択し、 [ 新規作成 ] を選択します。 ジョブ スケジュールの 名前 を入力し、必要に応じて 頻度 を選択し、[OK] を選択します。 [ OK ] を選択して SQL サーバーエージェントジョブを作成します。 セットアップのテスト SQL ログインを作成します。これは、T-SQL または SSMS を使用して実行できます。 USE [master] GO CREATE LOGIN [sid] WITH PASSWORD=N'******', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO 数分後、新しい SQL ログインについて警告する E メール通知が届きます。次のスクリーンショットは E メールの例を示しています。 後片付け このソリューションをテストした場合、追加の課金を回避するために次の手順を実行して作成されたコンポーネントを削除します。 SSMS を使用して RDS インスタンスに接続し、作成された SQL Server エージェントジョブを 削除 します。 Amazon RDS コンソールで RDS SQL Server インスタンスを選択し、[ アクション ] メニューで [ 削除 ] を選択します。 まとめ この投稿では、Amazon RDS for SQL Server インスタンス内で SQL ログインが作成されたときに Amazon SES を通じて E メール通知を送信する SQL Server エージェントジョブを作成する方法を説明しました。 ご質問、コメント、フィードバックがありましたら、この投稿のコメントセクションに残してください。 著者について Sid Vantair は、戦略アカウントを担当する AWS のソリューション アーキテクトです。リレーショナル データベースを扱う 10 年以上の経験を持つ彼は、顧客のハードルを克服するために複雑な技術的問題を解決することに熱心に取り組んでいます。仕事以外では、家族と過ごす時間を大切にし、子供たちの好奇心を育んでいます。 Poulami Maity は、アマゾン ウェブ サービスのデータベース スペシャリスト ソリューション アーキテクトです。彼女は AWS の顧客と協力して、既存のデータベースを AWS クラウドに移行して最新化するのを支援しています。       翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。