Azure Cloud Services (extended support) は 2027 年に提供終了予定であり、今のうちから移行計画を立てておかないと、ある日突然「OS イメージが更新できない」「新しい証明書に対応できない」といったリスクに直面します。本記事では、.NET Framework 4.8 で動く Web ロール×2・Worker ロール×1 構成を例に、どの Azure サービスへ、どの順番で移行すべきかを、実務的な視点で整理します。
Azure Cloud Services (extended support) 提供終了が意味するもの
まずは前提となる「Azure Cloud Services (extended support)」の位置付けと、2027 年の提供終了が意味する影響を整理します。
Cloud Services (extended support) の特徴
Cloud Services (extended support) は、いわゆる「クラシック PaaS」を Resource Manager 対応にしたもので、Web ロール / Worker ロール の概念を持つのが最大の特徴です。
- Web ロール：IIS ホストの Web アプリケーションを実行
- Worker ロール：バックグラウンド処理やキュー処理を実行
- サービス構成：ServiceConfiguration.cscfg / ServiceDefinition.csdef によるロール定義
- OS イメージ：Azure 側で提供される Windows Server ベースのイメージに依存
このモデルはシンプルで分かりやすい反面、現在の Azure で主流となっている「コンテナ」「マイクロサービス」指向の世界とは設計思想がやや異なります。そのため、提供終了に合わせて、よりモダンな PaaS / コンテナ基盤へ移行することが推奨されます。
2027 年の提供終了で想定されるリスク
「提供終了」と聞くとサービスが突然停止するイメージがありますが、実際には以下のような段階的なリスクの高まりとして現れることが多いです。
- OS イメージの更新が限定され、セキュリティ更新や TLS バージョン対応に制約が出る
- 証明書・暗号化方式のアップデートが追従しづらくなる
- 新しい Azure 機能（監視・ネットワーク・セキュリティ）の対象外になっていく
- トラブル発生時のサポート範囲が徐々に縮小する
特に、外部公開されている Web ロールは TLS や暗号化方式の更新に追従できないと、情報セキュリティ監査で指摘されるケースが増えます。「サービスが動いているうちに」安全に移行を完了させることが重要です。
現行システム (.NET Framework 4.8) の棚卸しポイント
移行候補の比較に入る前に、まずは現行の Cloud Services 構成と .NET Framework 4.8 アプリケーションの棚卸しを行いましょう。これをサボると、移行先選定を誤ったり、後工程で手戻りが増えがちです。
| 観点 | 具体例 | 移行時に確認すべきポイント |
|---|---|---|
| ロール構成 | Web ロール×2、Worker ロール×1 | Web/Worker それぞれの責務と依存関係、スケール要件 |
| ランタイム | .NET Framework 4.8 | .NET 8 へ移行可能か、サードパーティライブラリの対応状況 |
| データストア | SQL Database、Storage Queue、Table など | 接続文字列の管理方式、マルチリージョン対応の有無 |
| 認証/認可 | 独自認証、AD FS、Azure AD (Entra ID) など | 今後 Azure AD / OpenID Connect に統一可能か |
| バッチ/バックグラウンド | Worker ロールでキュー処理、定期処理を実行 | トリガー方式（スケジュール / メッセージ）と SLA、ピーク時の負荷 |
| 運用・監視 | 診断ログ、Event Viewer、独自ログなど | Application Insights / OpenTelemetry への統一可否 |
この棚卸し結果をベースに、「移行先で必須な要件」と「将来的に改善したいポイント」の二つを分けておくと、短期と長期のロードマップを描きやすくなります。
移行先候補の比較：.NET Framework 4.8 のまま動かすか？
今回の前提は「現行ランタイムが .NET Framework 4.8」であることです。まずは .NET Framework のまま動かせるかどうか を観点に、主要な移行先を比較します。
| 移行先候補 | .NET Framework 4.8 のまま稼働 | 主なメリット | 主な注意点・デメリット |
|---|---|---|---|
| Azure Service Fabric | 可能（.NET Framework 4.6.2 以降） | Cloud Services のロールをステートレス/ステートフル サービスにマッピングしやすい。 ローリングアップグレード、自動スケールなど PaaS のメリットを継承。 | クラスタ運用の学習コストが高い。 将来を考えると .NET（クロスプラットフォーム版）への移行計画は必須。 |
| Azure Kubernetes Service (AKS) | 可能（Windows Server コンテナ上で動作） | コンテナ単位で OS/ランタイムのライフサイクルを管理可能。 .NET Framework と .NET 8 以降の混在運用がしやすい。 | コンテナ化と CI/CD 構築が前提。 Windows コンテナは Linux コンテナより制約が多く、事例も少なめ。 |
| Azure App Service / ASE v3 | 可能（Windows プラン） | Web ロールをほぼそのまま Web アプリとしてホスト可能。 Worker ロールを WebJob や Functions に置き換えやすい。 | 高負荷なバッチや長時間ジョブが多いと構成が複雑化しやすい。 細かいネットワーク要件がある場合は ASE v3 が前提になることも。 |
| Azure Container Apps + .NET Aspire | 不可（.NET 8 以降が前提） | マイクロサービス / Dapr 連携など最新のクラウドネイティブ機能が利用可能。 オブザーバビリティ、構成管理が標準化される。 | 現行コードを .NET 8 へ全面移行する必要があり、短期移行には不向き。 アーキテクチャの見直し（マイクロサービス化）がほぼ前提。 |
短期的には Service Fabric または App Service が「リフト＆シフト」に近い選択肢となり、中長期では AKS や Container Apps へのリファクタリング移行 が視野に入ります。
Azure Service Fabric への移行イメージ
まずは、Cloud Services のロール概念にいちばん近い Azure Service Fabric を具体的に見ていきます。
Cloud Services のロールと Service Fabric の対応関係
| Cloud Services | Service Fabric での対応 | 補足 |
|---|---|---|
| Web ロール | ステートレス Service（ASP.NET アプリを自己ホスト） | Owin/Kestrel など、自己ホスト型にリファクタリングして移行 |
| Worker ロール | ステートレス/ステートフル Service | キュー処理などはステートレス、ローカル状態を持つ処理はステートフル |
| クラウド サービス | Service Fabric アプリケーション | 複数サービスを 1 つのアプリケーションとしてパッケージ |
Cloud Services で使用していた OnStart / Run などのライフサイクルイベントは、Service Fabric の RunAsync やサービスライフサイクルにマッピングできます。大規模なアーキテクチャ変更を行わずに、まずはホスティング基盤だけを置き換えるイメージです。
Service Fabric への移行ステップ例
- PoC 用の小規模 Service Fabric クラスタを構築（テスト環境）
- 既存 Web ロールを ASP.NET 自己ホストアプリとして分離し、ステートレス Service として登録
- Worker ロールをステートレス or ステートフル Service に落とし込み、キュー処理や定期処理を実装
- ストレージ接続情報や構成値を Service Fabric の構成パッケージに移行
- ローリングアップグレード/ヘルス監視の設定を行い、本番クラスターを構築
- 段階的に Cloud Services からトラフィックを切り替え、最終的に Cloud Services を廃止
| フェーズ | 主な作業 | アウトプット |
|---|---|---|
| 設計 | サービス分割方針、クラスタサイズ、可用性要件の整理 | Service Fabric アプリケーション設計書 |
| PoC | 一部ロールのみ移行し、性能・監視・運用容易性を検証 | PoC 評価レポート、改善項目リスト |
| 本移行 | 全ロール移行、トラフィック切替、切替後の観察 | 移行実施報告、ロールバック手順の確立 |
Service Fabric は柔軟な一方で、クラスタ運用・障害解析・アップグレード運用の学習コストが無視できません。そのため、「2027 年までの逃げ場」として一度移行し、その間に .NET 8 ベースの次期アーキテクチャを準備するという位置付けが現実的です。
Azure Kubernetes Service (AKS) への移行イメージ
AKS は中長期的には非常に強力な選択肢です。特に「将来的には Linux コンテナ + .NET 8 を中心にしたいが、当面は .NET Framework 4.8 のコンテナも混在させたい」という場合にマッチします。
.NET Framework 4.8 を Windows コンテナで動かす
.NET Framework アプリケーションをコンテナ化する場合、ベースイメージとしては Windows Server 2022 LTSC 系のイメージを選択するのが一般的です。サポート期間が長く、セキュリティ更新も安定しているためです。
典型的な Dockerfile のイメージ（簡略化）は以下のようになります。
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
WORKDIR /inetpub/wwwroot
COPY ./publish/ .
このコンテナイメージを AKS の Windows ノードプールにデプロイすることで、Cloud Services からの移行先として機能させることができます。
AKS への移行ステップの要点
- アプリケーションをコンテナ化（Web ロール / Worker ロールそれぞれのイメージを作成）
- AKS クラスタを構築し、Linux ノード + Windows ノードのハイブリッド構成を検討
- Azure Container Registry (ACR) へのイメージプッシュと、CI/CD パイプラインの構築
- Ingress Controller（Application Gateway Ingress Controller など）による公開設定
- ConfigMap / Secret による設定値・接続文字列管理
- Horizontal Pod Autoscaler による自動スケール設定
| メリット | デメリット |
|---|---|
| コンテナ標準の世界に踏み出せる。 .NET Framework と .NET 8 のサービスを同じ基盤に混在させやすい。 マルチクラウド対応や、将来の移設（オンプレ/他クラウド）も検討しやすい。 | Kubernetes 自体の学習コストが高い。 Windows コンテナは Linux コンテナに比べ制約やトラブルシュートの難易度が高い。 小規模構成だと「持て余す」こともある。 |
AKS は「中長期の標準基盤」として優秀ですが、2027 年までの時間とチームスキルを考慮した上で選択する必要があります。
Azure App Service / App Service Environment v3 への移行イメージ
最もシンプルに見える選択肢が Azure App Service（Windows プラン） です。Cloud Services の Web ロールの多くは、わずかな修正で App Service に載せ替えられるケースが多いです。
Web ロール → App Service Web アプリ
Web ロールで運用している ASP.NET アプリケーションは、基本的には以下のような流れで App Service へ移行できます。
- Web ロール固有の API（ロール環境変数など）の使用箇所を抽象化
- 設定値を App Service のアプリケーション設定（環境変数）に移行
- デプロイ方法を Visual Studio デプロイ / GitHub Actions / Azure DevOps に切り替え
- スロット機能を使ったステージング/本番切り替えのフローを整備
Worker ロール → WebJob / Azure Functions
Worker ロールで行っていた処理は、おおまかに以下のどちらかに割り当てられます。
| Worker ロールでの処理パターン | 移行先候補 | 備考 |
|---|---|---|
| キューからのメッセージ処理 | Azure Functions（Queue トリガー） | Isolated Worker モデルなら .NET 8 への移行がスムーズ |
| 定期バッチ（1 日 1 回など） | WebJob（Continuous / Scheduled） | .NET Framework 4.8 のまま動かしやすい |
| 長時間実行ジョブ | App Service + WebJob、または AKS コンテナ | タイムアウトやスケール要件によって選択を変更 |
ネットワーク要件が厳しく、VNet 内に閉じて運用したい場合には App Service Environment v3 (ASE v3) も検討対象になりますが、コストと運用の複雑さも増えるため、要件に応じて判断が必要です。
Azure Container Apps + .NET Aspire への移行イメージ
完全に .NET 8 へシフトした後の「最終形」として有力なのが Azure Container Apps + .NET Aspire です。
- .NET Aspire により、マイクロサービス構成・テレメトリ・構成管理を一括定義
- Azure Container Apps によるコンテナベースの PaaS 運用（Kubernetes の細かい管理から解放）
- Dapr 連携により、サービス間通信・状態管理・Pub/Sub などを標準化
ただしこれは .NET 8 への全面移行が前提 であり、かつアーキテクチャをマイクロサービス寄りにリデザインする必要があるため、「2027 年までの第一ステップ」ではなく、「2027 年以降を見据えた長期的なゴール」と位置付けるのが現実的です。
推奨ロードマップ：短期・中期・長期で考える
ここからは、実際のプロジェクトとして どの順番で何を行うか を整理します。
フェーズ 1：短期的リスク回避（～2025 年頃）
最初のゴールは「2027 年の提供終了までに間に合う基盤を確保する」ことです。
- .NET Framework 4.8 のまま動く選択肢から、Service Fabric または App Service を選定
- 現行 Cloud Services と機能が 1:1 で対応する構成を用意（リフト＆シフトに近い形）
- 監視・ログを Application Insights / OpenTelemetry に統一
- デプロイパイプラインを CI/CD ベースに再構成
| タスク | 優先度 | アウトカム |
|---|---|---|
| 移行先プラットフォームの決定（Service Fabric / App Service / AKS） | 高 | 経営判断まで含めた「逃げ場」の明確化 |
| PoC 実施と見積もりの精緻化 | 高 | 工数・コスト・リスクの具体的な数字 |
| 最小機能セットの移行（限定的なユーザー/テナントに限定） | 中 | 移行方式の妥当性検証とノウハウ蓄積 |
フェーズ 2：中期的最適化（.NET 8 への段階的マイグレーション）
フェーズ 1 で「とりあえず落ち着ける場所」を確保したら、次は .NET 8 への段階的移行 に着手します。
ポイントは、一気に全てを書き換えるのではなく、ビジネスドメイン単位やコンポーネント単位で少しずつ移行することです。
| パターン | 概要 | メリット |
|---|---|---|
| ストラングラー（締め付け）パターン | 既存モノリスの周辺に .NET 8 サービスを追加し、徐々に機能を移管 | 大規模な一括切り替えを避け、リスクを小分けにできる |
| 新規機能は .NET 8 / コンテナ前提 | 既存機能は .NET Framework のまま維持し、新機能から新スタックを採用 | 投資対効果の高い領域からモダナイズを進められる |
| 低リスクな機能からの段階移植 | バッチや管理画面など、ユーザー影響の小さい機能から移植 | 技術的な学習とノウハウを蓄積しながら、本丸機能に備えられる |
.NET Framework から .NET 8 への移行では、非互換 API やライブラリ依存 が最大のハードルになります。早期に「移行難度の高いライブラリ」を洗い出し、代替ライブラリの候補や自前実装の方針を検討しておきましょう。
フェーズ 3：長期的クラウドネイティブ化（AKS / Container Apps への再配置）
.NET 8 への移行がある程度進んだタイミングで、改めて AKS / Container Apps / .NET Aspire のようなクラウドネイティブ スタックへの再配置を検討します。
| 観点 | AKS が向くケース | Container Apps が向くケース |
|---|---|---|
| 運用ポリシー | 細かい制御やマルチクラウドを見据えたい | Kubernetes の運用負荷を避けたい |
| サービス規模 | 数十〜数百マイクロサービス規模 | 中〜中大規模程度、Azure 前提の構成 |
| チーム構成 | インフラ/SRE 専任チームを置ける | アプリ開発チームが中心でインフラ専門要員が少ない |
いずれの場合も、監視やログ、構成管理を早い段階で統一しておくと、プラットフォームをまたいだ移行がかなり楽になります。
共通技術テーマ：ストレージ・監視・セキュリティ
ストレージ・メッセージングの移行ポイント
Cloud Services のアプリケーションは、しばしば以下のような PaaS サービスに依存しています。
- Azure Storage（Blob / Queue / Table）
- Azure SQL Database
- Service Bus（Queue / Topic）
これらは App Service / AKS / Service Fabric / Container Apps のいずれからもそのまま利用できますが、移行時には以下の点を意識しましょう。
| 項目 | チェックポイント |
|---|---|
| 接続文字列 | アプリケーション設定・Key Vault に移行し、コードに埋め込まない |
| 認証方式 | 可能であれば接続文字列ではなくマネージド ID + RBAC へ移行 |
| リージョン構成 | DR（災害対策）やマルチリージョン構成をこのタイミングで見直す |
監視基盤の統一：Application Insights / OpenTelemetry
移行先が複数に分かれたとしても、監視・ログ・トレーシングは 1 カ所に統一しておくと、運用負荷を大きく下げられます。
- アプリケーションログ：構造化ログ（JSON）で出力し、Query しやすくする
- 分散トレーシング：OpenTelemetry による TraceId/SpanId の引き回し
- メトリクス：リクエスト数、レイテンシ、エラー率をプラットフォーム横断で可視化
Cloud Services から移行する段階で、ログ出力方式を 「テキストログ」から「構造化ログ」へ 見直すと、後々のプラットフォーム移行でもログ基盤をそのまま再利用しやすくなります。
セキュリティとネットワーク設計
提供終了に合わせた移行は、セキュリティとネットワーク設計を見直す絶好のタイミングでもあります。
- Public IP ベースの公開から、Application Gateway / Front Door を経由した公開に変更
- Private Endpoint を活用し、データストアへの直接公開を避ける
- 認証を独自方式から Azure AD (Entra ID) / OpenID Connect に統一
とくに「TLS バージョンが古い」「暗号化方式の更新がしづらい」といった問題は Cloud Services のままでは解消しにくいため、移行設計の早い段階で要件整理しておくことをおすすめします。
プラットフォーム別「向き・不向き」早見表
最後に、よくあるシナリオごとに「どの移行先がフィットしやすいか」をまとめます。
| シナリオ | おすすめ移行先 | 理由 |
|---|---|---|
| 短期間で Cloud Services から脱出したい | Service Fabric / App Service | 現行アプリを大きく変えずに移行しやすい |
| .NET Framework 4.8 をしばらく維持したい | Service Fabric / AKS (Windows コンテナ) | フル .NET 移行までの中継地点として機能 |
| 将来的にマイクロサービス化を進めたい | AKS / Container Apps + .NET Aspire | クラウドネイティブな設計に移行しやすい |
| インフラ運用要員が少ない | App Service / Container Apps | マネージド度が高く、運用負荷を抑えられる |
| 閉域網・厳格なネットワーク制御が必要 | ASE v3 / AKS (専用サブネット) | VNet 統合・NSG 制御・専用回線構成が取りやすい |
まとめ：2027 年までに押さえておきたいこと
Azure Cloud Services (extended support) の提供終了は、単なる「古いサービスの終わり」ではなく、.NET Framework から .NET 8 以降への移行、Windows ベースからクラウドネイティブ基盤への移行を一気に進めるチャンスでもあります。
- 短期：Service Fabric や App Service など、.NET Framework 4.8 をそのまま動かせる基盤を確保する
- 中期：.NET 8 への段階的移行と、アーキテクチャの分割・整理を進める
- 長期：AKS や Container Apps + .NET Aspire によるクラウドネイティブ運用へシフトする
また、Azure のロードマップ上、PaaS 機能は Linux コンテナ優先で進化 していく傾向があるため、Windows コンテナや .NET Framework に依存した構成は、あくまで「移行のための中継点」と捉えておくのが安全です。
2027 年までにはまだ時間がありますが、要件整理・PoC・段階移行・モニタリング強化など、やるべきことは想像以上に多くなります。まずは現行システムの棚卸しと、短期～長期のロードマップ作成から着手し、無理のないスケジュールで Azure Cloud Services (extended support) からの安全な卒業を目指しましょう。
コメント