re:Invent 2025: MicrosoftワークロードのAWS移行戦略とAI活用による自動化手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - AWS migration journey: 2025 itinerary for Microsoft workloads (MAM309)
この動画では、MicrosoftベースのワークロードをAWSに移行するための包括的なアプローチが解説されています。AWS TransformやApplication Migration Serviceを活用した環境のディスカバリーから、サーバー・VM、Active Directory、SQL Server、.NETアプリケーション、ファイルストレージまで、各ワークロードカテゴリーの移行戦略が実演されます。特に注目すべきは、生成AIを活用したAWS Transform for VMware MigrationやSQL Server Modernizationによる自動化、新サービスのAWS Managed Microsoft AD Hybrid Editionによる既存ドメインの拡張、そしてQiro CLIとCloud Migration Factoryを組み合わせたエージェント型AIによる大規模移行の簡素化です。Human in the loopの概念を通じて、自動化と人間の監視のバランスを保ちながら、効率的なマイグレーションを実現する方法が詳細に示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
マイグレーションジャーニーの始まり：ディスカバリーとAWS Transformの活用
はい。皆さんこんにちは、私たちのセッションにご参加いただきありがとうございます。実は二重にお礼を言いたいんです。だって正直なところ、もうサミット3日目ですよね。ここはラスベガスです。もう夜遅い時間です。ハッピーアワーはもう始まっています。それは承知しています。つまり、Lady Gagaが歌っているように、皆さんには私たちをすっぽかす理由が何百万とあったはずなのに、でもここにいる一つの良い理由があったんだと思います。それはマイグレーションですよね。
挙手をお願いします。海外からいらっしゃった方はどのくらいいますか?海外からの方はいらっしゃいますか?ようこそ。残りの方々はアメリカ国内からだと思います。ラスベガスの地元の方はいらっしゃいますか?この照明のせいでよく見えないんですが、とにかくようこそ。自分で旅行の計画を立てた方はどのくらいいますか?ご自身でやられた方。本当に、あなただけですか?では残りの方々は、エグゼクティブアシスタントに旅行の手配をしてもらうという贅沢ができたんですね。いいですね。本当に感心します。
誰がやってくれたかに関わらず、ここに来る前にいくつか明確にしておく必要があったことがあります。まず、どこに行くのか、なぜ行くのか、いつ行くのか、どうやって行くのか。いくらお金を使っていいのか?予算は?宿泊施設は必要か?これらの答えは、今回のような比較的短い旅行を計画する場合でも、もっと長い旅を計画する場合でも、実際に意味のある成功したミーティングを実現するためには、きちんとした答えが必要なんです。
本日は、インフラストラクチャのモダナイゼーションとマイグレーションを専門とするシニアAWSソリューションアーキテクトの私、Sassan Hajrasoolihaと、同僚のMangesh BudkuleとAdi Simonが、Microsoftベースのワークロードに焦点を当てて、ワークロードをAWSに移行するというデジタルジャーニーにおいて、同じような質問に対してデータドリブンな答えを得る方法をお見せします。
はい、まず一般的なマイグレーションがどのようなものかについて、ポートフォリオの観点から少しお話しします。ディスカバリーについてお話しして、それから皆さんの環境で実行されているかもしれないワークロードのポートフォリオの各カテゴリーについて、より深く掘り下げていきます。デモはすべて織り交ぜながら進めます。エンゲージングなセッションにしますので、始めましょう。
皆さんがここにいらっしゃるのは、おそらく皆さんの組織が、いまだにオンプレミスで稼働しているワークロードの70%を抱えている組織の一つだからでしょう。なぜクラウドに移行したいのか？繰り返しになりますが、そこに移行する理由は無数にあるかもしれません。 この組み合わせに最近加わったのが、AIとML全般、特にGenerative AIの採用です。 しかし、私が再び提起した質問に対する答えが必要であることは分かっていますし、それらの答えが簡単には得られないことも分かっています。主な問題はリソースの不足です。そのリソースとは人的リソースかもしれません。予算かもしれません。時間かもしれません。スキルセットかもしれません。移行を成功させる前に、これらを把握する必要があることは分かっています。
人々がすでに歩んできた道のりを振り返ると、いくつかのマイルストーンが見えてきます。まず、90年代後半から2000年代初頭にかけて、誰もがオフィスのサーバールームでワークロードを実行していました。その後、商用データセンターとコロケーションの概念を採用することにしました。2005年に進むと、クラウドの黎明期でした。人々はクラウドが提供するものをより多く採用し始めました。そして前進しながら様々なマイルストーンがあり、今現在のマイルストーンは Generative AI、AIのため、そしてAIによるクラウドへの移行です。
おそらく2023年にGenerative AIをプロジェクトで考えていたとき、皆さんはどこかにプロンプトを用意して、フィードバックを得て、モデルから推奨事項を得て、それを手動で実装することを考えていただけでした。そして2024年が来ました。今度はRAGや拡張検索のようなシステムを使って、AIモデルに対してより良い、よりコンテキストに沿ったプロンプトを提供し、より合理化された体験を得ることができるようになりました。しかし、それでもすべては手動でした。そして今、2025年には、AIに何をすべきか教えてもらうだけでなく、もちろん私たちの監督とセキュリティガイドラインの下で、実際に物事を実行してもらいたいのです。それがAgentic AIの意味するところです。
そして、それを移行プロジェクトにどのように活用できるかをお見せします。
典型的なジャーニーにおいて、すでに答えが分かっている些細な質問の一つは、私はどこから来ているのかということです。自分がどこにいるかはすでに分かっていますが、移行のようなデジタルジャーニーでは、それは実際に答える必要がある質問なのです。何を移行するのか、そしてなぜそれを持っているのか？それがディスカバリーの概念です。 その質問に答えるための私たちの主要なメカニズムは、常にそうでしたし、今もそうですが、Optimization and Licensing Assessment、略してOLAと呼ばれるこのメカニズムです。このプロセスを通じて、AWSはパートナーとともに皆さんの環境に入り、ツールで環境をスキャンし、 様々なベンダーとの関係を確認し、様々なベンダーからのライセンス推奨事項を含む推奨事項を提示します。Bring Your Own Licenseシナリオを使用するのが良い選択なのか、それともライセンス込みで購入するのが良いのか。OLAを実施すれば、これらの答えが得られます。このトピックに興味がある方は、セッションの最後に向けて共有するリソースがあります。
では、別の方法があるのかという質問ですが、答えはイエスです。皆さんはおそらくすでにこのサービスについて聞いたことがあると思います。私たちが非常に力を入れているサービスで、AWS Transformと呼ばれています。これは、マイグレーションへの道のりの各ステップで皆さんを支援するサービスとモジュールの総称です。実際、アセスメントにも役立ちます。インベントリデータを入力していただきます。一般的で人気のある多くのフォーマットがサポートされていますが、これは生成AIです。おそらく、皆さんが理解できるフォーマットであれば、ほぼ間違いなく私たちの生成AIも理解できるでしょう。つまり、インベントリデータを取得し、さらに入力可能なサポートデータに基づいて、インサイトを得ることができます。では、実際にどのように動作するか見てみましょう。
AWS Discovery Toolによる環境スキャンとインベントリ分析の実践
見慣れた画面から始めます、vCenterです。私は2台のESXiホストのクラスタを持っていて、その上で多数の仮想マシンが稼働しています。これらは様々な環境で多数のアプリケーションをホストしています。例えば、こちらは出張経費アプリケーションで、3層のアーキテクチャ要素で構成されています。AWS Discovery Toolを使用します。これは私たち独自のディスカバリーツールです。初回実行時には、新しいパスワードが必要です。ここにパスワードを入力します。これがそのインターフェースです。最初に行うことは、vCenter環境へのアクセスを許可して、仮想環境のインベントリを取得できるようにすることです。入力した瞬間、画面下部に表示されているように、エージェントが環境のスキャンを開始しますが、私はもっと情報が欲しいのです。依存関係マッピングデータや、後で最適化できるSQLバージョンも必要です。そのため、ゲスト仮想マシンに認証情報を提供して、より深く仮想マシン自体と通信できるようにします。
そして、それを行った瞬間、データベースディスカバリーとネットワークディスカバリーのエージェントもすべて起動します。ご覧のように、それぞれ異なる更新サイクルを持っています。VMは1時間ごと、データベースは24時間ごと、そしてネットワーク依存関係マッピングデータを取得するために15秒ごとです。すでにいくつかの情報が得られています。インベントリに何があるか見てみましょう。これは先ほどvCenterで見たのと同じ環境です。ご覧のように、いくつかはエラーが出ています。認証情報が異なっていたためですが、理由はともかく、実際にインベントリをzipファイルでダウンロードできます。ファイル名を見ると、28日間と書かれています。これが、ツールを実行し続けることを推奨する期間です。
AWS Transformにログインします。これはIdentity Centerです。多数のアイデンティティプロバイダーがサポートされています。これがAWS Transformのフロントページです。ご覧のように、下部にはお客様の声といくつかの新着情報があります。最初に行う必要があるのは、ワークスペースの作成です。ワークスペースは、特定のマイグレーションプロジェクトに必要なすべてのアクティビティを保持するスペースです。ワークスペースを作成しました。では中に入ります。ご覧のように、右側には提案されたプロンプトと、選択可能なマイグレーションタスクのカテゴリがあります。カテゴリを直接入力して、実行したいアクションをモデルに伝えることができ、適切なジョブが開かれます。
ここでジョブ名などの提案を受け入れるよう提案されています。そしてここが実際のアクションが起こる場所です。Human in the loopです。今、前のステップで取得したインベントリデータを求められています。zipファイルをアップロードして、マイグレーションの潜在的なターゲットとして宛先リージョンを選択し、分析を実行します。
データを処理している間、ワークロードを通じてモデルが何をしているのかを確認することができます。モデルが何をしているのかを表示してくれています。アーティファクトがあります。モデルに投入したすべてのもの、そしてモデルが生成したすべてのものが、アーティファクトに含まれます。AWS Transform内にはいくつかのコラボレーション機能があります。そしてもちろん、メインパネルはジョブパネルになります。実行された各ステップにはチェックボックスがあります。黄色はhuman in the loopを意味し、こちらはまだ作業中です。
作業中でも、例えばこの例では、ステータスオブジェクトなど、何でも要求することができます。いくつかの例を示してくれています。これらは完了したアクションです。こちらが残っているもので、もちろん真ん中のこれは完了しています。このアセスメントが何を提供してくれたのか見てみましょう。
最初にあるのは、エグゼクティブサマリーのPDFレポートです。クラウドで得られるコスト削減の予測、推奨事項の概要など、すべてが人間が読みやすい形式でまとめられています。同じ情報がPowerPointプレゼンテーションとしても提供されます。パートナーとしてお客様に、あるいは社内の上層部に対してプレゼンテーションを行う際の基礎として使用できます。すべてのデータがすでに入力されています。それを使用できます。
そして、このアセスメントの核心部分がこちらのExcelスプレッドシートです。ご覧いただけるように、投入したすべてのインベントリデータに対して、1行ごとの分析が行われています。サーバー名、接続されているストレージ、スペック、どのインスタンスタイプに移行すべきかという推奨事項、そしてもちろん、ライセンスとコンピュートを分けた1行ごとの見積もりです。これらはすべて、ジョブが完了した後もワークスペースに残り、マイグレーションの次のステップのために他のジョブを作成する際に、これらのアーティファクトを再び使用することができます。ここに表示されているように。依存関係のマッピングなど、すべてマイグレーションの他のステップで後から使用できます。素晴らしいですね。
Microsoftワークロードの分類と移行の7つのR：Rehost、Replatform、Refactoring
これで環境を検出し、特にMicrosoftベースのワークロード、サーバーとVM、一般的なインフラストラクチャサーバーや一般的なアプリケーションサーバーについて考えると、ワークロードがこれらのカテゴリのいずれかに該当する可能性が高いことがわかりました。Microsoftの環境であれば、95%の確率でActive Directoryをアイデンティティおよびアクセス管理として使用しているでしょう。SQLデータベースは常にMicrosoftベースの開発における選択肢のデータベースでした。.NETも同様ですが、WindowsとWebアプリケーションに関しては、すでにモダナイゼーションへの道を歩んでいるかもしれません。おそらく、世の中にあるコンテナ化機能を通じて、そしてファイルストレージです。
私たちの用語に馴染みのある方々のために説明しますと、マイグレーションの7つのRというコンセプトがあります。実際のものはハイライトされているものですね、もちろん。Rehost、つまり別のホストにリフト＆シフトするだけです。Replatformは、同じテクノロジーを使用しますが、一部の管理要素をサードパーティプロバイダー、私たちの場合はAWSにオフロードします。そしてRefactoringは、アプリケーションを分解して新しいものを作成し、 クラウドネイティブの機能をできるだけ多く活用できるようにすることを意味します。では、各カテゴリーについて詳しく見ていきましょう。
最初のものは、サーバーとVMです。挙手をお願いしますが、VMwareを使用していない方はどのくらいいらっしゃいますか？そうですね、おっと、実際に2人いらっしゃいますね。それは素晴らしい。では、使用している残りの皆さんのために、 Amazon Elastic VMware Service、またはEVSと呼ばれる新しいサービスをカバーするセッションがたくさんあります。このセッションでは、お客様のアカウントにESXiホストを提供し、その後、すでに馴染みのあるテクノロジーを使用してVMwareの仮想マシンをAWSに移行できる、ということだけ言えば十分です。
リフト＆シフトのための汎用サービスについては、 これ以上深く掘り下げるつもりはありません。このサービスはしばらく前から存在しており、Application Migration Service、またはMGNと呼ばれています。これは、ソースサーバーに小さなエージェントをインストールし、その後、ゼロとイチのブロックをお客様自身のアカウント内のステージング環境に転送するサービスです。
カットオーバーの準備ができたら、テストカットオーバーでも最終的な本番カットオーバーでも、各サーバーに対して定義した起動テンプレートに基づいてEC2インスタンスをハイドレートします。そうすると、オンプレミスサーバーのレプリカがAWS上で実行されることになります。それには小さなバリエーションもあります。その場合、 オンプレミス環境でVMwareを使用している場合、各サーバーに個別にエージェントをインストールする必要はなく、中央のアプライアンスに依存してレプリケーションを行い、VMwareのスナップショットテクノロジーに依存して、ゼロとイチのデルタを取得します。
どちらを使用するかに関わらず、MGNは単なるエンジンです。大規模なマイグレーションを行う場合、ウェーブプランニングをオーケストレーションし、依存関係が満たされていることを確認できる必要があります。これまでは、 大規模なマイグレーションプロジェクトを追跡するために使用するサービスはこれらでした。しかし今、私たちはこれらすべての経験を AWS Transform for VMware Migrationカテゴリーにまとめました。そして、ここにいる我らが頼もしいMangeshがそれについてさらに深く説明します。
AWS Transform for VMware：エージェント型AIによる大規模サーバー移行の自動化
ありがとうございます、Sassan。皆さん、こんにちは、Mangeshです。それでは、サーバー移行の旅を続けましょう。私たちは人工知能の時代に生きていますので、仕事のスピードが重要です。大規模な移行は複雑で、時間がかかり、エラーが発生しやすく、多くの労力と調整が必要です。では、エージェント型AIが従来の移行プロセスを変革する可能性があると信じている方は手を挙げてください。その通りです。それでは、私たちの最初のエージェント型AIサービスであるAWS Transform for VMwareについてお話しできることを嬉しく思います。これは、私たちが70年以上の経験で構築した目標駆動型の専門エージェントを使用して、最小限の人間の監視で、お客様の環境からAmazon EC2へのサーバー移行を簡素化するものです。
この新しいサービスは、移行プロセス全体を通じて、より柔軟性とAI駆動のエージェント体験を提供します。では、どのように機能するか見てみましょう。柔軟性は、OKTA、Entra、またはAWS Identity Centerなど、お客様自身が選択したアイデンティティを使用してTransformにオンボーディングすることから始まります。4つの主要なフェーズがあり、まずディスカバリーから始まります。ここでは、RVToolsや、CloudamizeやModernize ITなどのパートナーを使用している場合、またはSassanがすでに説明したツールであるAWS Transform for Discoveryなど、お客様が選択したツールを使用してVMware情報を提供できます。これが私たちが推奨するものです。
Transformエージェントがお客様の環境の分析を取得すると、そのエージェントはサーバーを異なるウェーブとアプリケーションにグループ化します。そして、エージェントと協力して、アプリケーションオーナーベース、機能、部門、またはOSやIPサブネットなど、お客様のビジネスや技術的な制約に基づいてグループ化するようにガイドできます。Transformエージェントは、ソースネットワークも理解し、それをVPC、サブネットなどのAWS固有のネットワークコンポーネントに変換し、CloudFormationとCDKテンプレートを提供します。これをダウンロードして、必要に応じて適切な変更を加え、デプロイメントを実行できます。
Cisco ACIやFortiGate、Palo Altoなど、お客様が通常使用するファイアウォール用のサードパーティツール、またはNSX駆動のネットワークを使用している場合は、その情報をTransformにインポートして、より多くのコンテキストを提供できます。Transformエージェントは、デプロイ時にハブアンドスポークモデルや分離されたVPCなど、さまざまな設計オプションも提供します。現在、複数の柔軟なIPアドレスマッピングと、さまざまな複数アカウントデプロイメントをサポートしており、これは大規模な移行に非常に必要です。
Transformエージェントがこれらすべてのネットワーク情報、ウェーブ、計画などを取得すると、次のフェーズである移行フェーズに進みます。ここでは、Sassanが説明したAWS MGNサービスをバックグラウンドで使用して、エンドツーエンドの移行をオーケストレーションします。現在、TransformはVMwareからだけでなく、Hyper-V、KVM、または物理サーバーがある場合でも、サーバーを移行できます。
重要なのは、human in the loopについてです。これは、エンドツーエンドの自動化と人間による監視のバランスを生み出すという点で非常に重要です。これにより、この移行プロセス全体を通じて、すべての重要なタスクにユーザー入力を提供できるようになります。 そして、統一されたウェブ上の協働体験を生み出すことで、チームが効率的なコミュニケーションを行い、障害を迅速に解決し、大規模な移行全体で通常発生する調整の遅延を回避できるようになります。
さて、それでは、大規模な移行を行うための代替手段はあるのでしょうか？ 先ほど申し上げたように、大規模な移行は複雑で時間がかかりますが、それだけでなく、大規模な移行は異なるデータソース、異なるサービス、そしてツールと通信します。 移行前のタスクと移行後のタスクが数多くあります。これらは実際には通常のシナリオです。では、どのようにこれを克服するのでしょうか？私たちにはすでに実績のあるCloud Migration Factoryというサービスがあり、お客様はこれを使用して一度に何千ものサーバーを大規模に移行しています。
Qiro CLIとCloud Migration Factoryを活用したエージェント駆動型移行の実演
しかし、ここでの質問は、私たちが今AI時代に生きていることを考えると、これを次のレベルに引き上げることができるのか、ということです。つまり、どのように機能するか、どのように作業するかが最も重要なのです。例えば、AIエージェントを使って、あるいはAIエージェントに、私が頭の中に持っている移行フローチャートを分析してもらうことはできるでしょうか？そして、エージェントにこれを分析してもらい、Cloud Migration Factoryと連携して、エンドツーエンドの移行を行うためのすべてのパイプラインと自動化ジョブを作成してもらうのです。そして私は、人間の専門家として、エージェントが正しく動作していることを確認します。 はい、Qiro CLIをエージェントとして使用することで可能です。
このケースでは、私の移行エージェントアシスタントは、Cloud Migration Factoryと連携して、私が絵に描いた移行として行いたいすべてのパイプラインやその他すべてを作成できます。これはMCPサーバー、つまりModel Context Protocolサーバーの助けを借りて行われます。このサーバーには、Cloud Migration Factoryと通信するために必要なすべてのツールが含まれています。そして、Cloud Migration Factoryには、その間に自動化エンジンがあります。これは、MGNを使用した事前構築済みの自動化に他なりません。ですから、Sassanが説明したように、MGNサービスが今や非常に重要であることがお分かりいただけると思います。これは、私たちのすべてのサービスで舞台裏で使用されています。
これをさらに強化することはできるでしょうか？ はい、AWS Transformを活用することができます。Sassanが説明したと思いますが、大規模なデータセンターのアセスメントを行うためのアセスメントとして使用できますし、waveプランニングなどをそこから活用して、それを Cloud Migration Factoryにインポートして検討することができます。さて、移行前のタスクと移行後のタスクについてはどうなのか、という疑問があるかもしれません。そこで、Amazon Bedrock Agent Coreを活用することができます。ここでは、独自の移行エージェントを構築して、例えばチケット作成、Jiraストーリー、あるいは移行後のDNS更新、その他多くのことをメールコミュニケーションと共に処理することができます。これらすべてを、私たちのセキュアなプラットフォームであるAgent Coreを通じて処理できます。
それでは、これを実際に動かしてみましょう。はい、これが移行したいWordPressアプリケーションです。 はい、これは複数のサーバーです。その中の一つは明らかにWordPressサーバーです。 これはオンプレミスからAWSへの移行です。これが私がすでにデプロイしたCloud Migration Factoryです。時間を節約するためにデプロイしましたが、これは空のファクトリーです。ご覧のように、サーバーゼロ、アプリケーションゼロ、すべてゼロです。 私はAIエージェントとしてQiroを起動しました。そして、これがMCPのツールで、Cloud Migration Factoryのすべてのツールを持っています。これを使用します。
これがAgent Coreで、ここで移行エージェントを構築しました。チケット作成用のものや、メール通信用のものなどです。 そして、これが先ほどお話ししたフローチャートです。手動タスクや自動タスクがあり、チケットから始まって通知で終わる、その間に移行ステップがあるシンプルなフローチャートです。 さて、これが私がAIエージェントに与えたプロンプトです。先ほどお見せしたこのJPGファイルを分析して、私のために仕事をしてください。パイプラインを作成し、Cloud Migration Factoryと連携して作業してください、と。
システムはMCPプロトコルを使用してCloud Migration Factoryと連携し、バックグラウンドでパイプライン全体を作成しています。ご覧のように、今それを実行しています。 次に、サーバーのインベントリを求められます。これはAWS TransformまたはCSV形式の独自のインベントリから取得できます。システムに提供できます。私たちの場合は、 3つのアプリケーション、5つのサーバー、そして2つのウェーブが作成されました。Cloud Migration FactoryのUIに行くと、 2つのウェーブ、5つのサーバー、3つのアプリケーションが表示されています。これがUIですが、AIエージェントにステータスを尋ねることもできます。 移行のステータスは何ですか？そして今、Wave 1を作成しようとしているのがわかります。なぜなら、これがデモで示しているWordPressサーバーを移行するものだからです。 そうですよね？これがCloud Migration FactoryのUIで、ここでも制御できますが、私たちはAIを通じて制御したいのです。では、戻りましょう。はい、移行のステータスは何ですか、と尋ねることができます。 確認しに行きますが、移行が開始されていないのがわかります。なぜでしょうか？以前に手動プロセスがあったからです。チケット作成です。 チケットを提供してください、と求めています。つまり、手動プロセスと自動プロセスを理解しているのです。今、はい、チケットがあります、と提供しています。今、私の フローチャートに従って、AWS Application Migration Serviceを使用してバックグラウンドで移行を実行してくれます。UIで見ると、レプリケーションエージェントをインストールしています。 バックグラウンドで、ブロックレベルの移行を開始し、ステップバイステップですべてのプロセスに従います。テストインスタンスの作成、テスト、そしてカットオーバー、そして 本番インスタンスのデプロイです。これらすべてを私のために実行してくれます。例えば、そこに新しく移行された2つのサーバーがあったのがわかります。そして今、ステータスは何か尋ねることができます。すべて順調に見えます。 これはデモですが、失敗もあるかもしれません。考えられる問題について尋ねることができます。今、ここですべてのパイプラインを見ることができます。繰り返しますが、主な目的は、 複数のUI、Cloud Migration Factory、そしてAWS Application Migration Serviceを使って作業したくないということです。すべてを確認したいだけです。通知を見ることができ、通知を受け取りました。 これが新しく移行されたサーバーからのアプリケーションで、これが全体的なステータスです。これが今、 AIを使ってどれだけ速く作業できるかということです。こうした質問をすることができ、このケースではすべてうまくいきました。しかし実際には、失敗するかもしれません。エージェントをインストールできないかもしれません。AIエージェントと行ったり来たりして、なぜ失敗したのか尋ね、自然言語のコミュニケーションを使って修正できます。それがここでの主な意図です。
Active Directory移行の3つのネイティブオプションと顧客からのフィードバック
繰り返しますが、サーバー移行をどのように行うことができるかをカバーしました。複数の方法があります。技術的要件であれビジネス要件であれ、自分自身の要件から逆算して作業することをお勧めします。そして、どのソリューションが最適かを確認してください。例えば、AWS Transform、あるいはCloud Migration Factory、またはパートナーやサービスツールなどです。さて、それでは今度はコアサービスであるActive Directoryにトピックを変えましょう。Active Directoryを使用している方はどのくらいいらっしゃいますか？ほぼ全員、おそらくそうですよね。 これは業界全体で最も使用されているアプリケーションであり、移行を考える際に非常に重要なアプリケーションです。では、どのような設計オプションがあるか見てみましょう。 AWSには3つのネイティブオプションがあります。最初は自己管理型のActive Directoryドメインコントローラーです。 自己管理型と言う場合、このモデルではこれらのドメインコントローラーの管理、監視、またはドメインコントローラーのライフサイクル全体を通じての保守に責任を持つことを意味します。ここでの重要なポイントは、自分自身のドメインをAmazon EC2に拡張できるということです。5万人、あるいは10万人のユーザーがいる場合、Active Directoryレプリケーションで簡単に拡張し、移行したアプリケーションに認証を提供し始めることができます。これが最も速く開始できる方法であり、ほとんどの顧客がこれを行っています。
2つ目のオプションは、AWS Managed Microsoft ADです。これは私たちが管理するものです。皆さんのためにActive Directoryをデプロイし、舞台裏ではドメインコントローラーを管理しますので、ドメインコントローラーの差別化されない重労働について心配する必要はありません。私たちがそれを管理します。そしてこれはエンタープライズ対応のサービスですので、AWSアプリケーションとのシームレスな統合、例えばディレクトリ共有やレプリケーションなどの拡張機能が付属しています。しかし、このサービスの重要なポイントは、Active Directoryをデプロイする際に、単一ドメイン用の単一フォレスト、つまり単一ドメイン用の新しい単一フォレストをデプロイするということです。これは何を意味するかというと、既存のドメインをAWS Managed Microsoft ADに拡張することはできないということです。ですので、認証を提供したい場合は、ユースケースに応じて、一方向または双方向の信頼関係を作成する必要があります。
3つ目はActive Directory Connectorです。AD ConnectorはActive Directoryではありません。これはゲートウェイのようなもの、あるいはもっと簡単に言えば、オンプレミスのActive DirectoryとAD Connectorをサポートする AWS固有のアプリケーションとの間の橋のようなものです。
認証とルックアップを提供します。これは一対一の関係ですので、爆発半径の問題を回避するために一意のサービスアカウントを使用できるよう、複数のAD Connectorをデプロイすることになるかもしれません。
さて、これらのオプションは、政府、教育、金融、ライフサイエンス、ヘルスケアなど、あらゆるセグメントのお客様によって常に使用されています。私は長い間、これらのお客様がActive Directoryをデプロイするのをサポートしてきましたが、フィードバックをいただいています。お客様は、AWSにおいて柔軟で保守が容易な管理ソリューションを求めており、Managed ADのような管理された体験を得られると同時に、自分たちのドメインをManaged ADに拡張できることを望んでいます。これは現在は不可能です。そうすれば、信頼関係を構築したり、あるいは自分たちのドメインからManaged ADへの実際の移行を行う必要がなくなります。これは皆さんもすでにご存知の通り、大きなプロジェクトです。AD移行を行うのは非常に困難です。
AWS Managed Microsoft AD Hybrid Edition：既存ドメインの拡張を可能にする新サービス
それでは、皆さんもご存知の通り、私たちのサービスや機能のほとんどは皆さんのフィードバックから生まれています。ですので、私たちの新しいサービスについてお話しできることを嬉しく思います。AWS Managed Microsoft AD Hybrid Editionです。このサービスでは、既存のドメインをManaged Microsoft AD Hybrid Editionに拡張できますので、管理された体験を活用できます。なぜなら、私たちがドメインコントローラーを管理するからです。そしてEC2と同じように、移行したアプリケーションに対して迅速に認証を提供し始めることができます。
これをどのように設計するかですが、オンプレミスにドメインコントローラーがある場合は、それをManaged Microsoft ADの追加ドメインコントローラーとして拡張するだけで、Systems Managerにオンボードされていることを確認できます。これは前提条件の1つです。EC2ドメインコントローラーがある場合は、それをHybrid Editionに拡張するだけです。ただし、この場合、Hybrid Editionのドメインコントローラー、つまりあなたのドメインのみが私たちによって管理されますが、EC2とオンプレミスはあなたによって管理されます。つまり、私たちの間で共同管理になるわけです。
では、この新しいサービスが実際にどのように機能するか、実際に見てみましょう。ご覧のとおり、これらは私がすでに自分のオンプレミスから移行した2つのドメインコントローラーです。これはSystems Managerにオンボードされています。これが注目すべき重要な点で、OU構造です。これがあなたのOU構造ですよね？そして、これらはあなたによって自己管理されているドメインコントローラーです。これは私たちが作成する必要があるシークレットです。なぜなら、追加のドメインコントローラーを追加するために、あなたのドメインへのアクセスが必要だからです。そこで、シークレットを作成しました。そして、これらは非常に特定の名前のシークレットです。これは私たちのウェブサイトに文書化されています。これらは同じ名前である必要があります。
そして、シークレットが準備でき、ドメインコントローラーがSystems Managerにオンボードされたら、通常のManaged ADと並んで、ここに新しいオプションであるManaged Hybrid Editionが表示されます。すべてのドメイン情報、DNS、ネットワーキングを提供します。これは裏側で非常に重要です。それらすべてを提供します。ここで、あなたが提供した2つのドメインコントローラーが表示されます。これは最小要件です。追加のドメインコントローラーのデプロイに使用するには、最低2つを提供する必要があります。
そして、すべて問題なさそうですが、インストールすることはできません。私たちはHybrid Editionを直接インストールしているわけではありません。アセスメントを作成しています。なぜでしょうか？なぜなら、あなたが私たちに提供したドメインコントローラーが正常で、正常に動作していることを確認する必要があるからです。そこで、裏側で、58のテストを実行します。これは非常にシンプルで、名前解決やレプリケーションなどのAD固有のテストで、それらが正常であることを確認します。そして、このアセスメントが成功することを、ハイブリッドドメインコントローラーを作成するための別の前提条件として使用します。
そして次に、サービスアカウントを提供する必要があります。私たちが作成したサービスアカウントが表示されます。そして、すべてが問題なく、すべての情報が正しければ、ハイブリッドディレクトリを作成すると言えます。では、裏側で何をするかというと、私たちのアカウントにドメインコントローラーをデプロイします。もちろん、それは私たちによって管理されます。そして、今、IP ハイフンが表示されます。このIP ハイフンは、私たちがあなたのドメインのためにデプロイしたドメインコントローラーですが、管理されており、OU構造があります。新しいOUが追加されているのがわかります。AWS Reservedです。これがまさに私たちによって管理されているものです。他のすべては、とにかくあなたのドメインです。
そして、2つのドメインコントローラーをご自身で管理していただき、合計で、今ご覧いただいているように、4つのドメインコントローラーがあります。つまり、2つはお客様が管理し、2つは私たちが管理するという、この共同管理の形になっています。そして実際のディレクトリに移動して確認すると、ご覧のように、すべてが正常に動作しており、アセスメントも成功しています。ここでドメインをクリックすると、これがマネージド型のエクスペリエンスであることがわかります。アプリケーション管理などが表示されています。このようにマネージドエクスペリエンスが得られるようになりました。それでは、次のジャーニーについてAdiに引き継ぎます。
SQL Server移行の選択肢：EC2、RDS、RDS Customとモダナイゼーションへの道
ありがとうございます。さて、お客様のマイグレーションジャーニーの一環として、次に最もよく話題に上るワークロードは、データベースとアプリケーションです。今日Microsoft SQL Serverを実行されている方、挙手をお願いできますか?素晴らしい。ほとんどの方ですね。それでは、私の名前はAdiです。データベース層とアプリケーション層についてお話しします。
SQL Serverから始めましょう。では、AWS上でSQL Serverを実行するためのオプションについて理解していきましょう。最初のオプションは、EC2上のSQL Serverへのリホストです。これにより、SQL Serverのエディション、SQL Serverのバージョンに関して最も柔軟性が得られ、非常に使い慣れた管理エクスペリエンスとSQL Serverの完全なコントロールが可能になります。ライセンス込みを選択することも、適格要件を満たしていればBYOLを選択することもできますが、完全なコントロールには完全な責任が伴います。つまり、物理インフラストラクチャを除いて、EC2上のすべてを管理する責任はお客様にあります。
では、この運用上のオーバーヘッドをオフロードする方法はあるのでしょうか?答えはイエスです。マネージドデータベースソリューションであるAmazon RDS for SQL Serverへリプラットフォームすることができます。これにより、マネージドエクスペリエンスが得られ、アーキテクチャを最適化します。AWSがパッチ適用やバックアップを自動化します。また、Multi-AZを選択すれば高可用性も得られ、このオプションにはライセンスも含まれています。
また、RDS Custom for SQL Serverという3つ目のオプションもあります。これは、オペレーティングシステムにアクセスして、セキュリティエージェント、モニタリング、ログフォワーダーなどのサードパーティエージェントをインストールする必要があるユースケースがある場合に使用できます。これはRDS Customで実現できます。AWS上でSQL Serverを実行する際の目的地がわかったところで、そこに到達するためのアプローチについてお話ししましょう。
マイグレーションのアプローチにはどのようなものがあるでしょうか？これから4つの非常に一般的なアプローチをご紹介します。最初のアプローチは、AWS Application Migration Serviceを使用する方法です。これについてはSassanさんとMangeshさんがすでにお話しされていますが、オンプレミスまたは他のクラウド上のSQL Serverから、EC2上のSQL Serverへ完全なリフト＆シフトを行います。これはブロックレベルのレプリケーションを行いますので、データベース、オペレーティングシステム、データ、設定など、すべてがEC2に移行されます。非常にシンプルで、リフト＆シフトに適しており、個別のデータベースに適しています。
次のアプローチは、データベース管理者の皆さんにとって非常に馴染み深いものです。ネイティブバックアップとリストアです。このアプローチでは、通常通りSQL Serverをバックアップし、そのバックアップファイルをAmazon S3やFSxなどのストレージサービスにアップロードし、それをEC2、RDS、またはRDS Customにリストアします。ただし、1つ注意点があります。ダウンタイムを考慮する必要があるということです。バックアップとリストアには間違いなくある程度のダウンタイムが伴います。
では、ダウンタイムを最小限に抑えるアプローチが必要な場合はどうでしょうか？現在クラスター環境を運用していて、Always On Availability Group、Failover Cluster Instance、ログシッピングなどの組み込みの高可用性機能を活用している場合、SQL Serverを搭載したEC2インスタンスを立ち上げて、それを既存のクラスターに追加ノードとして加えることができます。ノードを同期させ、すべてのデータが移行されたら、準備ができた時点でソースデータベース上で制御されたフェイルオーバーを実行します。最後に、準備ができたらソースデータベースを廃止できます。これはクラスター環境を運用している場合に最適ですが、EC2上のSQL Serverに移行する場合にのみ機能します。ただし、利点としては、これをディザスタリカバリのアプローチやソリューションとしても活用できるということです。
そして最後に、最も柔軟性が高いのがDMSです。Database Migration Serviceを使用すると、ソースデータベースから、これまでお話ししたあらゆるオプションへの継続的なデータレプリケーション、CDC（Change Data Capture）を実現できます。つまり、最小限のダウンタイムでEC2、RDS、RDS Customに移行できます。これは高可用性アプリケーションに最適です。
しかし、データベースマイグレーションに関しては、モダナイゼーションと密接に関連しています。現在SQL Serverを運用している場合、おそらくMicrosoftのWindows Server上で実行していると思います。少なくともMicrosoft Windows Serverのライセンスコストを削減する方法はあるでしょうか？はい、あります。Replatforming Assistantを使用します。これはスクリプティングツールです。これを使用すると、Windows Server上のSQL ServerをエクスポートしてEC2 Linuxにリストアできるため、Windowsのライセンスコストを削減できます。ただし、SQL Server自体はライセンスの面でまだかなり高額です。
では、データベースを移行して、MySQLやより一般的にはPostgreSQLなどのオープンソースの代替手段にモダナイズすることを検討している場合、例えばAurora上で、Database Migration Serviceを使用してデータを移行することができます。しかし、その前にスキーマを変換する必要があり、そのためのツールも用意されています。DMSの一部として、Schema Conversion Toolがあり、これによってSQL ServerのスキーマをPostgreSQLの同等のものや、お好みのデータベースに変換することができます。しかし、これまでは、SCTを使用して手動で変換し、その後DMSを手動でオーケストレーションする必要がありました。そして、アプリケーションコードはどうでしょうか?
AWS Transform for SQL Server Modernization：生成AIによるデータベースとアプリケーションの統合モダナイゼーション
さて、アプリケーションに手を加えずにデータベースをモダナイズすることは、アプリケーションにとって破壊的な変更と見なされますよね?ですから、PostgreSQLで動作するようにアプリケーションを調整する必要があります。これまでは、これらすべてを手動でオーケストレーションする必要がありました。しかし、それに対して、AWS Transform for SQL Server Modernizationをご紹介したいと思います。これは、生成AIを使用して、これらの実証済みの移行およびモダナイゼーションツールをすべてオーケストレーションし、合理化することで、Microsoft SQL ServerからAurora PostgreSQLへのデータベースとアプリケーション層のモダナイゼーションを可能にします。
では、実際に見てみましょう。Sassanのデモでご覧いただいたように、AWS Transformへのエントリーポイントはワークスペースを作成することですよね?そして、ワークスペース内でジョブを作成できます。私たちが興味を持っているジョブは、Windows Modernizationというカテゴリの下にあり、このジョブを作成するには、SQL Server Modernizationオプションを選択する必要があります。ジョブが作成されると、左側に、前提条件から実際のウェーブフロントまで、本当にガイド付きのエクスペリエンスが表示されます。これはインタラクティブなエクスペリエンスです。エージェントと会話することができ、前提条件を見ると、明確なガイドラインが示されています。
さて、AWS Transformがあなたのデータベースで動作するには、データベースにアクセスする必要があります。ログインに使用するユーザーが必要になります。これが私たちのソースデータベースです。いくつかのテーブルがあり、ここにユーザーがいます。このユーザーはSecrets Managerに保存され、AWS Transformが動作できるように、非常に特定の方法でタグ付けされます。データベース内には、先ほど述べたように、いくつかのテーブルがあり、ここでselect文を実行すると、テーブル内にいくつかのデータがあることがわかります。
アプリケーション側では、これはEntity Framework SQL Serverプロバイダーであり、これは書店に似たWebアプリケーションです。さて、AWS Transformに戻ります。前提条件では、データベース認証情報を含むシークレットをどのようにタグ付けすべきかが示されています。ですから、正確にタグ付けするようにしてください。これは私たちのウェブサイトに文書化されています。そして、コードについては、Code Connectionsを準備して、リポジトリにセットアップしておくようにしてください。これは、GitHub、GitLab、Bitbucket、またはAzure DevOpsのいずれかです。
それでは、データベースシークレットへの接続と、AWS Transformからのコード接続を確立します。これを承認すると、すべてのアクセスが問題ないか、IAMロールが問題ないかを検証し、リソースの検出に進みます。 ご覧のとおり、シークレットを通じてアクセスできるデータベースが1つあることを正常に識別し、また このデータベースに関連付けられているリポジトリにアクセスして正常に検出しました。さて、これが完了すると、次はアセスメントフェーズに移り、データベースとアプリケーションの複雑さを 確認します。
つまり、すべてのデータベースオブジェクトを確認し、その複雑さを判断し、アプリケーションがデータベースにどのようにアクセスしているかを確認して、 次に来るウェーブプランニングを実行できるようにします。アセスメントが完了すると、ダウンロード可能なレポートが得られます。ダウンロードできる項目の1つは、 データベースにあるものの概要を含むCSVファイルです。また、適切にフォーマットされたPDFレポートも提供されます。アプリケーション側では、リポジトリ、 複雑さの評価、およびコード行数の概要が表示されます。
これが問題なければ、ウェーブプランニングフェーズに進みます。 ここでは1つのアプリケーションとリポジトリしかありませんが、複数ある場合、ウェーブプランニングとは、実際にアプリケーションとデータベースのグループ化を行うことを意味します。ですので、 ヒューマン・イン・ザ・ループとして、OKをクリックする前に必ずこれを確認してください。なぜなら、そうすると実際のウェーブフロントに進むからです。ウェーブフロントの最初のタスクはスキーマ変換で、 Transformに新しいデータベースを作成させることも、ここで行っているように既存のデータベースをターゲットとして選択することもできます。
これが書き込み先のデータベースであることを確認したら、OKをクリックします。すると、バックグラウンドでSchema Conversion Toolが調整され、スキーマがSQL Serverから Aurora PostgreSQLに変換されます。それでは、PostgreSQL側のpgSQLに移動すると、bookstoreスキーマができており、これを展開すると、SQL Server側で見たすべてのテーブルが ここに存在しています。しかし、selectステートメントを実行すると、これらのテーブルにはまだデータがありません。これは当然のことで、データは次のステップで移行されるからです。 データマイグレーション、2番目のステップです。AWS Transformにデータマイグレーションも調整してもらうこともできます。
バックグラウンドで行われることは、DMSで手動でタスクを作成する必要がなく、 データマイグレーションを実行するためのDMSタスクを作成して設定してくれます。データマイグレーションの準備ができて、 このテーブルを再度選択すると、SQL Server側にあるデータとまったく同じに見えるすべてのデータが表示されます。
次は何でしょうか？ コードですよね？つまり、あなたのコードを調べて、コードをスキャンし、実際にコードに変更を加えていくわけです。既存のコードを上書きするのではなく、指定した新しいブランチに書き込んでいきます。新しいデータベースで動作するように、Entity Frameworkのクラスを変更します。アプリケーションに埋め込まれたSQLコードがある場合は、それも変更します。接続文字列をPostgreSQLの接続文字列に置き換えます。また、アプリケーションの検証も行います。ビルドエラーがあれば解決します。ユニットテストがある場合は、ユニットテストも実行してくれます。
それが完了すると、先ほど申し上げたように、結果をこの新しいターゲットブランチに書き込み、ダウンロード可能なレポートが得られます。これは率直に言って詳細なレポートです。プロジェクトごとに確認できます。このレポートの一部として、各プロジェクト内の個々のファイルの変更まで掘り下げることもできます。では、コードリポジトリに切り替えてみましょう。AWS Transformによって作成されたこの新しいブランチが確認できます。
実施されたコードの変更を見てみると、Entity Framework側から必要なクラスマッピングがすべて行われていることがわかります。下にスクロールすると、実際にSQL ServerプロバイダーがPostgreSQLプロバイダーに置き換えられていることがわかります。そして、接続文字列も置き換えられ、接続文字列がリンクされています。ベストプラクティスである接続文字列の外部化を行っている場合、それらを見つけて、シークレットも置き換えてくれます。
アプリケーション側ですが、アプリケーションをお見せする前に、PostgreSQL側のデータに小さな変更を加えて、このブックタイトルが、SQL Server側で表示される1001ではなく、1002と表示されるようにします。これにより、アプリケーションが確かにPostgreSQLと通信していることを証明します。よろしいですか？では、このアプリケーションを起動して、ブックを閲覧すると、1001ではなく1002と表示されるはずです。つまり、このアプリケーションは確実にPostgreSQLと通信しているわけです。
.NETアプリケーションとファイルサーバー移行の選択肢、そして移行を成功に導くリソース
データベースは単独で存在するものではありません。アプリケーションと一緒に動作します。では、アプリケーションについて少しお話ししましょう。Microsoftの環境を使用している場合、レガシーな.NET Frameworkアプリケーションと、より最新のクロスプラットフォーム.NETアプリケーションを組み合わせて実行しているかもしれません。おそらくWindows Serverで実行していて、場合によってはLinuxサーバーも使用しているでしょうし、すでにコンテナ化への取り組みを始めているかもしれません。すでにコンテナ技術の使用を開始しているかもしれません。
では、これをAWSで実行するための選択肢は何でしょうか？完全なOSレベルのアクセスが必要な場合は、EC2またはElastic Beanstalkで実行できます。自動パッチ適用、自動スケーリングが必要な場合、またはVMwareをお使いの場合は、Sassanがすでに触れたように、EVSに環境全体を移行することができます。さて、コンテナを実行したい場合は、多くの選択肢があります。ECSは、非常にシンプルでありながら強力なオーケストレーションプラットフォームです。Kubernetesを実行したい場合はEKSがあります。Red Hat OpenShiftでコンテナを実行している場合は、AWSでROSA、つまりRed Hat OpenShift on AWSで引き続き実行できます。VMware Tanzuをお使いの場合は、Amazon EVS上でVMware Tanzuを実行できます。または、Lambdaのようなサーバーレスのイベント駆動型関数にリファクタリングすることもできます。
では、左から右へどのように移行するのでしょうか？もちろんMGNがありますが、アプリケーションに関してはあまり一般的ではありません。ソースコードにアクセスできる場合は、おそらくCI/CDパイプラインを使用してこれらの環境にデプロイすることになるでしょう。そしてCodePipelineとCodeDeployがこれを支援してくれます。では、移行と同時にこの機会を利用してモダナイゼーションを行いたい場合はどうでしょうか？例えば、コンテナ化したい、コンテナ上で実行するリプラットフォームを行いたい、あるいはリファクタリングして、よりクラウドネイティブなアーキテクチャを採用するためにリアーキテクトしたい場合です。
これは従来、非常に複雑になります。なぜなら、パズルの一部を解決するこれらのツールを一つ一つ手動でオーケストレーションしなければならないからです。移植にはPorting Assistant for .NET、コンテナ化にはApp2Containerを使います。マイクロサービスに分解したい場合は、別のツールを使う必要があります。そこで今、AWSTransform for .NETがあります。これは.NET Frameworkアプリケーションを変換し、.NETをLinux対応にするために設計されています。これをAWS Transform for SQL Server Modernizationと組み合わせることで、生成AIによって支援されるフルスタックのモダナイゼーション機能が提供されます。
また、Q DeveloperとQuiroもあります。これは私たちのエージェント型AI機能を備えたコーディングアシスタントです。Q Developerは、ほとんどの人気のあるIDEで拡張機能として利用でき、Quiroは、パターン開発やエージェントフックなどの高度なエージェント機能を備えたフル機能のIDEです。
それでは、次のワークロードについてお話しするために、Sassanに戻したいと思います。
ありがとうございます、Adiさん。さて、最後になりますが、決して重要度が低いわけではありません、ファイルサーバーについてです。これらをどうするか？つまり、このセクションは、皆さんが既にお持ちのオプションのレビューのようなものになります。まず、セルフマネージド。EC2を立ち上げます。適切なEBSの階層と、スループット、転送速度、IOPSをサポートするEC2のサイズを確保すれば、問題ありません。もし管理タスクの一部を私たちにオフロードしたい場合は、FSxシステムを使うことになります。必要なのがWindowsベースのSMBだけであれば、FSx for Windows File Serverが利用すべきサービスです。そしてそれ以上のものが必要な場合、つまりNFSプロトコル、iSCSI、階層型ストレージやそのようなコントロールが必要な場合は、Amazon FSx for NetApp ONTAPが、お探しのサービスになります。
これらへの移行方法については、既にいくつかのオプションがあります。リフトアンドシフトのためのMGNについては詳しくお話ししました。使用したいターゲットによっては、実際にWindows環境のネイティブサービスの一部を活用できる可能性があります。例えば、DFSRです。これはFSx for Windowsシステムとの統合機能を持っています。あるいはEC2に移行したい場合は、Windows ServerのStorage Replicaコンポーネントという別のオプションもあります。つまり、もし非常に小規模なものであれば、単純にRobocopyを使うか、サードパーティのシステムを使って手動でコピーすることもできます。ネットワーク経由で行うには大きすぎる場合は、Snow Coneから最大Snowmobileまで、私たちに送ってください。セキュアなデバイスをお送りしますので、データをロードして、セキュアに私たちに送り返していただければ、Amazon S3に配置します。そこから先は、データをどうするか決めていただけます。
そしてもちろん、これらすべてのデータを取得するための最も直接的なサービスが、AWS DataSyncです。ソース環境が何であるか、どのアクセスプロトコルをサポートしているか、SMB、NFS、またはS3互換APIに応じて、それらのオブジェクトを取得し、バックエンドに同期します。そして、データを配置したいターゲットストレージタイプに応じて、そこに配置します。サマリーに移る前に、本当に簡単にですが、いくつかのプログラムやインセンティブが利用可能であることを知っていただきたいと思います。これらについてアカウントマネージャーと相談して、対象となるものがあるか確認してください。これらは存在しますし、移行プロジェクトに活用していただきたいと思っています。
全体として、このセッションの目的は、皆さんに持ち帰っていただきたいことは、質問は同じかもしれませんが、今では、私たちが持っている新しいツールや生成AI ベースのツールを考えると、皆さんに答えを提供できるということです。そして、ソリューションアーキテクト、アカウントマネージャー、CSM、そして私たちが持つ広範なパートナーネットワークのチームとして、皆さんのそばにいます。私たちは皆さんの移行の旅をより簡単にするためにここにいます。具体的には、私たちが提供しているハイブリッドActive Directoryサービスで、管理の一部を私たちにオフロードできることをご覧いただきました。AWS Transformが提供する幅広い機能の広範なデモも既にご覧いただきました。そしてもちろん、プログラムとインセンティブについてもお話ししました。
もし私たちのセッションから持ち帰っていただきたいスライドが一つだけあるとすれば、それはこれです。ここには、今日お話しした個々のサブセクションすべてについて、より深く掘り下げるための包括的で広範なリソースのリストがあります。VMwareやMGNについては深く掘り下げませんでした。これらのトピックについては、いくつかのリソースがあります。その中にはこのre:Inventからのものもあり、現時点では参加していただくためのカタログを指しています。そして後ほど、YouTubeにセッションの録画が公開されたら、このページを更新して、もちろんこのセッションも含めて、これらすべての映像のYouTube録画を掲載します。そして、ブログ、技術ノート、Skill Builderを通じたトレーニング資料などもご覧いただけます。これらすべてをここにまとめましたので、ブックマークして、興味があればより深く掘り下げていただきたいと思います。それでは、改めて感謝申し上げます。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion