![[アップデート] AWS Transform に Windows のフルスタック（.NET + Microsoft SQL Server）アプリケーションをモダナイズする機能が追加されました #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/33a7q65plkoztFWVfWxPWl/a718447bea0d93a2d461000926d65428/reinvent2025_devio_update_w1200h630.png?w=3840&fm=webp)
[アップデート] AWS Transform に Windows のフルスタック（.NET + Microsoft SQL Server）アプリケーションをモダナイズする機能が追加されました #AWSreInvent
いわさです。
AWS re:Invent 2025 の期間中にいくつかの AWS Transform のアップデートがアナウンスされました。
.NET モダナイゼーション機能が少し拡張されたのですが、それとあわせて Windows フルスタックアプリケーションをまとめてモダナイゼーションする機能も登場しました。
簡単にいうと、アプリケーションのコンバートだけでなく、実際に動作している Microsoft SQL Server データベースを Aurora PostgreSQL（非 Babelfish）へ変換してくれるというものです。
アプリケーションとデータベースを一緒に変換することで、フルスタックと表現しているみたいですね。
今回結果としてエラーが出てうまくいかなかったのですが、少し試してみたのでその様子を紹介します。雰囲気を感じ取ってください。
また、エラーが出て自力で解決できなかったので、せっかく re:Invent 現地に来ているので Expo ブースで SA さんにトラブルシューティングがてら質問しに行きました。現地ならではのムーブなのでありだなと思いました。
使ってみる
この機能ではアプリケーションコードの変換と、データベースの変換が同時に行われます。
アプリケーションコードについては Git リポジトリ上での変換をかけます。データベースについては AWS Database Migration Service (DMS) や AWS Schema Conversion Tool (SCT) を裏側で使うみたいで、Microsoft SQL Server から Amazon Aurora PostgreSQL へのリソース上での変換が行われます。
後者については RDS を使っても良いですし、オンプレミスや EC2 でも良いみたいです。
今回は適当な GitHub リポジトリと、適当な RDS for SQL Server を用意して試しています。
スタートは .NET モダナイゼーションと同じ流れで、ワークスペースとジョブの作成から開始します。
ジョブタイプは「Windows Modernization」の「SQL Server modernization」を選択します。
まずは前提条件の準備から案内されます。
データベースについてはデータベース上にユーザーを作成し権限を付与、認証情報を AWS Secrets Manager のシークレットに格納しておく必要があります。
それに必要なクエリや手順が表示されています。一点注意事項として、シークレットにタグをつけるのを座れないようにしてください。このタグで認識しているっぽいです。
アプリケーションコードについては .NET モダナイゼーションと同じ流れですが CodeConnection を事前に用意して ARN などを指定する形になります。
AWS Transform でコネクタのリソースがありまして、従来はリポジトリ接続用のコネクション管理だと思っていたのですが、データベース接続タイプのコネクションもここで管理するみたいです。なるほど。
コネクション名をきめて承認リンクから承認します。
その後、各構成のチェックが行われます。
ドキュメントに書いていなくてここが少し悩ましかったのですが、IAM ロール関係のエラーが大量に発生すると思います。
ほとんどのものは対応できない（確認したが対応済み）のものが多かったので、それらについては「Ignore」を選択しました。
うまくいけば最後に対象リソースの選択を行います。
データベースとリポジトリとそれぞれタブがあって選択します。
ここでまたひとつ注意点がありまして、リポジトリですがデフォルトで全リポジトリが対象になっています。
一度すべて解除して変換が必要なリポジトリだけ選択するのが良いでしょう。
ただ、リポジトリの数が多いと複数ページで一覧表示されてしまうので、選択解除をしても対象ページのみ解除されている状態になることがあります。
歳魚それに気が付かずに 100 件ほどのリポジトリのアセスメントを開始して応答がなくなってしまったので、選択するリポジトリについては注意してください。
データベースとリポジトリの選択が完了すると、アセスメントが開始されます。しばらく待ちましょう。
まずはデータベースから開始されます。
データベースが完了すると、今度はリポジトリのアセスメントが開始されます。
アセスメントが無事完了したら、wave planning を開始します。要は実際の変換タスクの最終レビューです。
今回は２つデータベースが存在していたので、２つの wave が作成されました。
ただしコードにデータベースアクセス関係のクエリや ORM の実装コードが含まれていなかったので、リポジトリについては変換対象外であると判定されていました。なるほどね。
wave の確認が終わったらいよいよデプロイです。
まず初めに AWS 環境上に移行に必要な IAM ロールを作成する必要があります。
CloudFormation テンプレートがダウンロードできるのでこちらをデプロイしました。内容は S3 バケットひとつといくつかの IAM ロールを作成するものです。
デプロイが完了したら AWS Transform に戻って「Run validation」ボタンを押しましょう。
あとは wave がそれぞれ開始されます。
私はここで残念ながらエラーになりましたが、スキーマ変換、データ移行、コード変換、テスト＆デプロイという流れになっているみたいです。
ブースで質問してみる
Expo の AWS Village 内に Migration & Modernize のエリアがありまして、そこの一角に「Windows, SQL, .NET」のブースがあります。ここだ！
ここで先程のエラー内容などを伝えて色々聞いてみました。
こちらの画面はちょうどフルスタック Windows アプリケーションをモダナイズする機能についての説明です。Babelfish ではなくて Aurora PostgreSQL への移行だよという説明も改めて受けました。
結論として、問題に対する解決策を得ることは出来なかったのですが、クレジットと AWS Transform のステッカーを得ることができました。やったぜ。
さいごに
本日は AWS Transform に Windows のフルスタック（.NET + Microsoft SQL Server）アプリケーションをモダナイズする機能が追加されたので試してみました。
公式ドキュメント上の前提条件の記載がおそらく足りていなくて、まだ試行錯誤しながらやってみる必要があります。ドキュメントが充実してくればもっとすんなり行くと思うのですが。
また整備されてきたタイミングで試してみたいと思います。
