Azure Cloud Services (extended support)（CSES）でClassic Load Balancer＋Basic SKU パブリック IP を使っていると、リタイア情報と例外条件が混在して判断が難しくなります。本記事では期限の考え方と、Standard SKU へ移行する際の現実的な進め方・注意点をまとめます。
まず押さえるべき前提：CSESは「Basic SKU前提」のサービス
CSES（Cloud Services extended support）は、移行先としてよく候補に挙がる一方で、ネットワーク周りに明確な制約があります。特に重要なのが、CSESはBasic SKUのパブリック IP のみサポートし、Standard SKUのパブリック IP は利用できない点です。
さらに、CSESのデプロイではAzure側でClassic SKUのロードバランサーが自動生成され、ARM上では読み取り専用として扱われます。つまり、一般的な「Load Balancer（Standard）へアップグレード」という発想で、そのまま置き換えられないケースが出てきます。
そしてもう一点、長期計画を立てるうえで無視できないのが、CSES自体がすでに非推奨となっており、将来のリタイア日が明示されていることです。CSESを「例外だから安心」と捉えて放置すると、別の期限で詰むことがあります。
Microsoft Learnの手順ページでは、CSESは2025年3月31日に非推奨となり、2027年3月31日に完全リタイアすると明記されています。つまり「CSESだから当面はBasicで良い」としても、最終的にはこの期限までに脱CSESを完了させる必要があります。
| 要素 | 公式情報としての位置づけ | 実務への影響（要点） |
|---|---|---|
| CSES | 非推奨（将来リタイア日あり） | 長期運用は「脱CSES」前提でロードマップを組む必要がある |
| Basic SKU パブリック IP | CSESでは利用可能（Standardは不可） | Standard化したいなら、CSESの外にワークロードを移す必要がある |
| Classic SKU Load Balancer | CSESと一緒に自動作成され、ARMでは読み取り専用 | LB設定の変更は、CSES側の設定ファイル（.cscfg/.csdef）経由が前提になりやすい |
結論：移行が「必須になる期限」と「推奨される期限」を分けて考える
まず大枠として、Basic SKUのパブリック IP と Basic Load Balancer は、2025年9月30日を節目にリタイア（サポート終了）とされています。一方で、CSESに紐づくデプロイはこのリタイアの影響を受けない、と明記されています。
実務のマイルストーンは大きく2つです。2025年9月30日（Basic SKU Public IP / Basic Load Balancer のリタイア日）と、2027年3月31日（CSESの完全リタイア日）です。CSESに紐づくリソースは例外扱いでも、周辺にBasic/Classicが混在していれば2025年9月30日が効いてきますし、最終的には2027年3月31日までに脱CSESが必要になります。
ここで混乱しやすいのが、「対応不要」と「将来もそのままで良い」は別物だという点です。公式ガイダンスでも、CSESに依存しないARMネイティブなリソースでは、可能な限りStandard SKUを推奨する立て付けになっています。
さらに、Microsoft Q&Aの回答では、Classic Load Balancerに紐づくBasic SKU IPは2025年9月30日までは影響を受けないが、それ以降はアップグレードが必要、という補足も提示されています。これは「CSES内外でBasic/Classicが混在している」環境では特に注意が必要、という実務上の示唆として受け止めるのが安全です。
| あなたの構成 | Basic/Classic リタイアの直接影響 | いつまでに何をすべきか（実務上の結論） |
|---|---|---|
| CSESに紐づくBasic SKU Public IP／Classic SKU LB | 原則として「影響なし」 | 短期は現状維持も可能。ただし、CSES自体のリタイア日から逆算し、脱CSESの計画を作る |
| VM/VMSS/他サービスでBasic SKU Public IPを利用 | 影響あり | Standard SKUへアップグレード（または作り直し）を前提に計画。移行時はNSG/通信設計が必須 |
| Basic Load Balancer（ARM）を利用 | 影響あり | Standard Load Balancerへ移行。Outboundや監視の仕様差を踏まえてリハーサルする |
| Classic Load Balancer（非CSES）＋Basic IP | 影響あり（見落としやすい） | 影響範囲の切り分けを先に実施。CSES外ならStandard化を急ぐ |
なお「リタイア＝即停止」と決めつけるのも危険です。公式ガイダンスでは、リタイア後も一定期間は動作し得るが、サポート外・SLA対象外になる旨が説明されています。つまり、動いているから大丈夫ではなく、障害時に守られない状態に入る、という捉え方が現実的です。
なぜStandard SKUが推奨されるのか：機能だけでなく「運用事故」を減らす
Standard SKUへ寄せる理由は「新しいから」ではありません。現場で効いてくるのは、セキュリティと可用性、そして運用のしやすさです。
セキュリティ：Standardは“デフォルトで閉じる”
Standard SKUのパブリック IP はSecure by default（既定で受信を閉じる）モデルで提供されます。移行後に「急にアクセスできない」事故の多くは、NSG（Network Security Group）で許可ルールを入れ忘れることが原因です。切替前に、現行の公開ポートと送信要件を洗い出し、NSG設計を先に固めるのが鉄則です。
可用性：Availability ZonesやSLAが前提になる
Standardは可用性ゾーン（zonal / zone-redundant）に対応し、ロードバランサーにはSLAも提示されています。運用中に「冗長化したい」「監視を強化したい」が出てきた時、Basic/Classicに縛られて設計が詰むのを避けられます。
運用：メトリクスやOutbound制御が“標準装備”
Standard Load BalancerはAzure Monitorの多次元メトリクスに対応し、Outboundもルールとして宣言的に管理できます。Basic/Classicから移るときは「Outboundが既定でブロックされる」仕様差があるため、切替前にOutbound設計まで含めて詰める必要があります。
| 観点 | Basic / Classic | Standard | 移行時に注意するポイント |
|---|---|---|---|
| 受信（Inbound） | 開放が前提になりやすい | 既定で閉じる（NSGで許可が必要） | 切替前にNSGの許可ルールを用意し、段階的に適用する |
| 送信（Outbound） | “気づかないまま通っている”ことが多い | LB側のOutbound rule / NAT Gateway設計が必要 | 外部API、CRL、OS更新、監視送信などを棚卸しして漏れを防ぐ |
| 可用性 | ゾーン非対応 | zonal / zone-redundant対応 | ゾーン冗長を狙うなら「新規作成」が必要になるケースがある |
| 監視 | メトリクスが限定的 | Azure Monitor多次元メトリクス | 切替と同時にメトリクス/アラート設計を更新する |
| 混在可否 | BasicとStandardを混ぜられない | 同左（SKU整合が必須） | フロント/バックエンドのPublic IPも含めてSKUを揃える |
移行方針の選び方：CSES継続か、ARMネイティブへ移行か
「Standard SKUへ移行したい」という要望は、言い換えると「CSES依存を減らしたい」「Classic/BASICから脱却したい」という意思表示でもあります。なぜならCSESはBasic SKUのパブリック IPのみサポートし、Standard SKUをそのまま持ち込めないからです。
| 方針 | 狙い | メリット | デメリット／注意点 |
|---|---|---|---|
| CSESを当面維持（現状維持＋監視強化） | 短期の変更最小化 | システム改修がほぼ不要。運用負荷を増やさずに延命できる | CSES自体のリタイア日があるため、いずれ大きな移行が必要になる |
| 段階的にARMネイティブへ移行（並行稼働→切替） | リスク分散しながら脱CSES | 検証と切替を分離でき、ダウンタイムを読みやすい | 一時的に二重コスト。DNSや証明書など“外部接点”の切替設計が要る |
| 全面刷新（アプリ含め再設計） | 機能・セキュリティ・運用の最適化 | 将来のスケール、ゾーン冗長、ゼロトラスト等に合わせやすい | 要件定義からやり直しになりやすい。スコープ管理が重要 |
実務で失敗しにくい移行プロセス（ロードマップ）
現状の棚卸し：最初に“外部公開”と“送信先”を全部書き出す
移行プロジェクトで最もコストが高いのは、作業そのものではなく「見落としによる手戻り」です。Standard化で事故が起きやすいのは、受信を閉じる/Outboundを制御する、といった挙動が変わるためです。
| 棚卸し項目 | 具体例 | 落とし穴 |
|---|---|---|
| 公開エンドポイント（ポート/プロトコル） | 80/443、管理用ポート、API用の特定ポート | NSG許可ルールの作り漏れで切替後に“全面不通” |
| ロードバランサー設定 | ルール、NAT、ヘルスプローブ、タイムアウト | プローブ仕様差でバックエンドが不健康判定になる |
| 送信（Outbound）要件 | 外部API、メール、証明書失効確認、OS更新、監視送信 | Outbound設計不足で“ログインはできるが内部処理が失敗” |
| IP変更可否（固定IP要件） | 顧客のFW許可、連携先のIP制限 | IP維持が必要なのにDNS切替前提で計画してしまう |
| DNS運用 | A/CNAME、TTL、切替手順、戻し手順 | TTLを下げ忘れて切替が長引く。戻しもできない |
移行先の設計：Standard化で“必ず追加で考える”3点
- NSG設計（受信許可の明文化）：Standard Public IPは既定で閉じるため、許可ルールの設計が必須です。
- Outbound設計：Standard Load BalancerではOutboundが既定でブロックされるため、Outbound ruleまたはNAT Gateway等の設計が必要です。
- SKU整合（混在不可）：Load BalancerとPublic IPのSKUは一致が必要で、BasicとStandardを混ぜられません。
新環境の構築：まず“動く最小構成”を作ってから機能を足す
いきなり本番相当のフル機能を作り込むと、検証範囲が爆発します。おすすめは、次の順序で段階的に固めることです。
- Standard Public IP（または代替の公開経路）を用意する
- Standard Load Balancer（Public/Private）を作成し、バックエンドを接続する
- ヘルスプローブ→LBルール→必要なNATの順に追加する
- NSGで受信許可を最小から開始し、疎通確認しながら拡張する
- Outbound rule / NAT Gateway等で送信経路を確立する
- 監視（メトリクス/ログ/アラート）を切替前に仕込む
移行（切替）と検証：DNS切替は“手順書＋戻し手順”までセット
切替当日に慌てないために、少なくとも次を事前に用意します。
- 切替の前日までにTTLを短くする（運用ポリシーに合わせて調整）
- 外部連携先のIP許可（allowlist）変更が必要なら、先方作業の手配を取る
- 切替後の確認項目（HTTP/HTTPS応答、ログイン、バッチ、外部API呼び出し等）をチェックリスト化する
- 障害時の戻し手順（DNS戻し、旧経路再開）を用意する
手順詳細：Basic Public IPをStandardへアップグレードする場合（IP維持を狙う）
「IPアドレスを変えたくない」場合にまず検討されるのが、Basic Public IPをStandardへアップグレードする方法です。ポイントは、アップグレードには“切り離し”が必要で、IPが静的であることが前提になる点です。アップグレード自体は同じIPを保持しますが、作業中は一時的な停止を織り込む必要があります。
また、Standard化は後戻りできない（不可逆）であること、アップグレード後のIPはゾーン属性が付かないケースが多いことも、設計上の注意点です。
- 対象のPublic IPが「Static」か確認する（DynamicならStaticへ変更）
- Public IPを関連リソース（NIC/LBなど）から切り離す
- Public IPをStandardへアップグレードする（不可逆であることを理解したうえで実施）
- Standard側の受信が閉じる前提で、NSGの許可ルールを適用する
- 切り離したリソースに再アタッチし、疎通と監視で確認する
注意：CSESはStandard Public IPをサポートしないため、「CSESのままIPだけStandard化」はできません。IP維持を狙う場合でも、まず脱CSES（移行先のARMネイティブ環境）を用意するのが現実的です。
手順詳細：Basic Load BalancerをStandardへ移行する場合（ARMリソース向け）
ARM上でBasic Load Balancerを使っている場合は、Standard Load Balancerへの移行が基本方針になります。Microsoftのガイダンスでは、PowerShellの自動化スクリプトを使った移行も推奨されています。
移行で特に事故が多いポイント
- BasicとStandardは混在できない：Load BalancerとバックエンドのPublic IPを含め、SKU整合が必須です。
- Public IPは切り離し前にStaticへ：割り当て方式の扱いを誤ると、IPを失うリスクがあるため、順序を守ります。
- 受信はNSGで明示許可：Standardは既定で閉じるため、NSGが未整備だと即不通になります。
- Outboundは別途設計：StandardはOutboundが既定でブロックされるため、Outbound ruleやNAT Gatewayが必要です。
手順イメージ（手作業でやる場合の流れ）
- 現行LBの設定（プローブ、LBルール、NAT、バックエンド所属）を控える
- 関連するPublic IPをStaticに統一する
- Standard Load Balancerを新規作成し、設定を複製する
- NSGで許可ルールを作成し、受信を通す
- バックエンドをStandard側へ付け替える
- Outbound rule / NAT Gatewayで送信を成立させる
- 疎通・負荷・監視を確認後、旧Basic LBを削除する
“CSES＋Classic Load Balancer＋Basic IP”からStandardへ移る現実的なやり方
CSES環境の特徴は「CSESがBasic/Classicに依存している」ことです。つまり、Standard SKUへ寄せたい場合、単にIPやLBだけを差し替えるのではなく、ワークロードごとARMネイティブへ移すプロジェクトとして捉えるのが近道です。
移行先パターンの例
- Cloud Serviceのロール相当をVirtual Machine Scale Set（VMSS）に置き換え、Standard Load Balancerで受信を分散する
- Web中心ならApp Serviceへ寄せ、外部公開はFront Door / Application Gatewayなどを併用する
- コンテナ化できるならAKSへ寄せ、Ingressで公開する
切替の進め方（並行稼働→DNS切替）
- 移行先の基盤（VNet、サブネット、NSG、監視）を先に用意する
- Standard Public IP＋Standard Load Balancer（または別の公開経路）を作る
- アプリ/サービスを移行先で起動し、内部テストで動作を固める
- 本番相当のテスト（証明書、外部API、送信、監査ログ）を実施する
- DNSを切替し、アクセスを新環境へ寄せる
- 監視期間を置いたうえで、旧CSES側の公開を閉じ、リソースを整理する
よくある落とし穴と対策
“つながらない”の多くはNSGとOutbound
Standard化で最も多いトラブルは、「NSGが無い/許可が足りない」「Outboundが成立していない」です。Standard Public IPは受信が既定で閉じ、Standard Load BalancerはOutboundが既定でブロックされます。切替前に、受信・送信の両方を設計に含めましょう。
IP維持は“できることもある”が、前提条件が厳しい
Basic Public IPのアップグレードは同一IPを保持しますが、切り離しが必要で、静的割り当てが前提です。さらに、CSESはStandard IP非対応なので、IP維持を狙うほど「脱CSES＋リハーサル」が重要になります。
“動いているから後回し”が最大のリスク
リタイア後も動作し得る、という情報は「先送りして良い」ではなく「サポート外で動く期間がある」という意味です。障害時にSLAやサポートの前提が崩れるため、運用上のリスクを定量化して優先度を上げることをおすすめします。
よくある質問
CSES上のBasic IPは本当に移行不要？
Basic SKU Public IP/Basic Load Balancerのリタイアは、CSESの既存・新規デプロイには影響しない、と公式ガイダンスに明記されています。ただし、CSES自体は非推奨でリタイア日も示されているため、長期運用するなら脱CSESの計画は必要です。
Standard化したら“セキュリティが上がる”のに、なぜ障害が起きる？
StandardはSecure by defaultのため、許可ルールが無い限り受信が閉じます。また、Standard Load BalancerではOutbound設計が必要です。機能としては望ましい挙動ですが、移行時に設計・設定が追いつかないと障害に見えるため、事前の棚卸しとリハーサルが重要です。
Classic Load Balancerの設定変更が難しいのはなぜ？
CSESのデプロイに伴って作成されるClassic SKU Load Balancerは、ARM上で読み取り専用として扱われ、CSESの設定ファイル経由で更新する前提が示されています。そのため、運用変更の自由度が低く、Standard化を考えるなら脱CSESの方が早いケースがあります。
まとめ：判断を誤らないためのチェックポイント
- CSESはBasic SKU Public IPのみサポートし、Classic SKU LBが自動生成される。Standard化＝脱CSESの計画が前提。
- Basic Public IP / Basic Load Balancerは2025年9月30日を節目にリタイアだが、CSESは例外として影響を受けない。
- CSESは2025年3月31日に非推奨となり、2027年3月31日に完全リタイアが示されているため、長期運用は脱CSESが必須。
- リタイア後も動作し得るが、サポート外・SLA外になるリスクを理解して早めに移行する。
- Standard移行の成否は、NSG（受信）とOutbound設計（送信）にかかっている。
- IP維持を狙うなら、Static化・切り離し・不可逆など前提条件を満たし、検証でリハーサルする。
コメント