サブスクリプションの自動販売

2025-05-07

サブスクリプションの自動販売機は、ワークロードをデプロイする必要があるアプリケーションチームにプログラムによってサブスクリプションを発行するためのプラットフォームメカニズムを提供します。次の図は、サブスクリプションの自動販売機がプラットフォームとワークロードのライフサイクルに適合する場所を示しています。

サブスクリプションの自販は、サブスクリプションの民主化の概念に基づいており、アプリケーションのランディングゾーンに適用されます。サブスクリプションの民主化では、リソースグループではなくサブスクリプションがワークロード管理とスケールの主要な単位です。詳細については、以下を参照してください。

サブスクリプションの自販を行う理由

サブスクリプションの自動販売機は、Azure にワークロードをデプロイする必要がある組織に対して、いくつかの利点を提供します。アプリケーションランディングゾーンのサブスクリプションを要求、デプロイ、および管理するプロセスを標準化し、自動化します。サブスクリプションの自動販売機により、サブスクリプションの作成プロセスが簡略化され、組織のガバナンスの下に配置されるため、アプリチームは、自信と効率を高め、ワークロードのデプロイに集中できます。

合理化されたプロセス: サブスクリプションの自動販売機は、アプリケーションチームがサブスクリプションを要求するための公式のフロントドアを提供し、サブスクリプションプロセスを自分でナビゲートする必要がなくなります。
速度の向上: アプリケーションチームは、アプリケーションランディングゾーンにすばやくアクセスし、ワークロードをより迅速にオンボードできます。
効率的なガバナンス: プラットフォームチームは、最小限のオーバーヘッドでアプリケーションランディングゾーンにガバナンスを適用できます。

サブスクリプションの自動販売機を実装する方法

サブスクリプション販売には3つのチームが関与しています。クラウドセンターオブエクセレンス (CCoE) は、ビジネスロジックと承認プロセスを確立します。準備ができたら、アプリケーションチームはサブスクリプション要求を行います。プラットフォームチームは、アプリケーションチームにサブスクリプションを渡す前に、要求を使用してサブスクリプションを作成および構成します。アプリケーションチームは予算を更新し、ワークロードをデプロイし、運用を確立します。次のガイダンスでは、サブスクリプションの自動販売機プロセスの各手順について詳しく説明します。詳細については、サブスクリプションの自動販売機の実装ガイダンスを参照してください。

プラットフォームチームは、アプリケーションチームに多くのオプションとサブスクリプションの種類を自販できます。これらのタイプは、プラットフォームエンジニアリングの原則とプラクティスに関連するため 、製品ライン と呼ばれます。ニーズに最も適したオプションの選択の詳細については、「共通サブスクリプションの自動販売機の製品ライン」を参照してください。

ビジネスロジックと承認プロセスを確立する

サブスクリプションの自動販売機モデルを実装するには、重要なサブスクリプション情報を収集する承認プロセスを確立する必要があります。クラウドセンターオブエクセレンス (CCoE) は、承認プロセスをプログラムし、収集する情報に関するビジネスルールを確立する必要があります。

プロセスを自動化します。 プロビジョニングを高速化し、コンプライアンスを向上させるために、サブスクリプション要求のキャプチャと承認のプロセスを自動化する必要があります。

既存のツールと統合します。 サブスクリプションの自販承認プロセスを既存の IT サービス管理 (ITSM) ツールに統合する必要があります。この統合により、承認プロセスを簡素化し、手動の労力を削減し、エラーを減らしながら効率を向上させることができます。また、時間の経過と共にメンテナンスが容易になり、監査のコンプライアンスレポートにも役立ちます。

デプロイパイプラインに接続します。 承認プロセスのビジネスロジックを、プラットフォームチームが管理するサブスクリプションデプロイパイプラインに結び付けるのがベストプラクティスです。 Azure Pipelines または GitHub Actions ワークフローは、サブスクリプションデプロイパイプラインの一般的なソリューションです。

取り込み時に要件を収集します。 ビジネスロジックでは、アプリケーションチームがサブスクリプションを要求し、サブスクリプションの要件を提供できるようにする必要があります。これらの要件には、予想される予算、サブスクリプション所有者、ネットワークの期待、およびビジネスの重要度と機密性の分類が含まれている必要があります。プロセスの開始時にこの情報を収集すると、デプロイパラメーターと利害関係者の承認のニーズが通知されます。また、取り込みプロセスでは、ワークロードを管理グループ階層に配置するのに十分な情報をプラットフォームチームに提供する必要があります。

承認プロセスが実施されたので、アプリケーションチームはサブスクリプション要求の作成を開始できます。

サブスクリプション要求を行う

サブスクリプションの自動販売機は、アプリケーションチームがサブスクリプションを要求するための標準的なプロセスを提供します。サブスクリプションの自動販売機の可用性をソーシャル化し、サブスクリプション要求を簡単に行えるようにすることが重要です。アプリケーションチームがサブスクリプション要求を送信すると、プラットフォームチームはプロセスの制御を引き受けます。プラットフォームチームは、サブスクリプションを作成し、アプリケーションチームにサブスクリプションを配信するまで制御を維持します。

ネットワークの構成

サブスクリプションの自動化では、必要なネットワークコンポーネントを設定する必要があり、各アプリケーションチームのニーズを満たすのに十分な柔軟性が必要です。一般的なガイダンスとして、1 つのルーティングドメインで重複する IP アドレスを使用しないでください。サイズ要件が変更された場合は、ダウンタイムなしで仮想ネットワークのアドレス空間を追加または削除できます。詳細については、以下を参照してください。

IP アドレス管理 (IPAM) ツールを使用します。 IP アドレスの割り当てを効率化するには、IPAM システムを使用して自動販売機プロセスに統合する必要があります。詳細および IPAM ガイダンスについては、 IP アドレス管理 (IPAM) ツールを参照してください。

アプリチームに自律性を付与します。 サブスクリプション内のサブネットと一部の仮想ネットワークを作成する権限をアプリケーションチームに付与する必要があります。プラットフォームチームは、常に中央ハブにピアリングする仮想ネットワークを作成する必要があります。

ネットワークガバナンスを適用します。 プラットフォームチームは、(1) 管理グループ階層に割り当てられた Azure ポリシー、または (2) Azure Virtual Network Manager とセキュリティ管理者ルールを使用して、仮想ネットワークガバナンスを適用する必要があります。詳細については、「ポリシー駆動型のガバナンス」および「高リスクポートをブロックする方法」を参照してください。

サブスクリプションの配置を決定する

プラットフォームチームは、ネットワークとガバナンスの要件を使用して、管理グループ階層にサブスクリプションを配置する必要があります。また、サブスクリプションを作成する前に、サブスクリプションクォータの制限も確認する必要があります。詳細については、「要件を満たすように Azure ランディングゾーンアーキテクチャを調整する」を参照してください。

適切な管理グループを特定します。 管理グループは、サブスクリプションとワークロードのデプロイを整理および管理するのに役立ちます。各ワークロードの分類とニーズに必要なポリシーを適用する管理グループを見つけるか、作成します。

柔軟な自動化を構築します。 自動化は、(1) 複数のサブスクリプションをデプロイするのに十分な柔軟性を備え、(2) サブスクリプションサービスの制限に適応する必要があります。

複数のサブスクリプション: 一部のワークロードには、複数のサブスクリプションが必要です。たとえば、一部のワークロードには、サブスクリプションで区切られた複数のインスタンスがあります。または、顧客ごとに専用リソースを使用する SaaS アーキテクチャでは、多くの場合、数十のサブスクリプションが使用されます。
サブスクリプションサービスの制限: 数千のサブスクリプションを持つ企業には、制限を回避するために、古いサブスクリプションにデプロイしたり、サブスクリプション内のワークロードを併置したりできる自動化が必要です。詳細については、 Azure ランディングゾーンに関する FAQ を参照してください。

クォータの引き上げは、プロビジョニング後に Azure portal を使用して手動で要求できます。使用可能な API を使用してこのプロセスを自動化する方が簡単です。ただし、クォータ要求は失敗する可能性があるため、スクリプトを実行してエラーを処理する必要があります。詳細については、Microsoft.Capacity、Microsoft.Quota、および Microsoft.Support を参照してください。

サブスクリプションの作成と構成

要求されたサブスクリプションを作成して構成できるようになりました。目標は、反復可能で一貫性のあるプロセスを作成することです。可能な限り多くのサブスクリプションの作成と構成プロセスを自動化します。

コードとしてのインフラストラクチャ (IaC) を使用します。 サブスクリプションの自動販売機の一般的な戦略は、IaC を使用してプログラムでサブスクリプションを作成して構成することです。 Azure サブスクリプションをプログラムで作成するには商用契約が必要ですが、商用契約なしでサブスクリプション構成のすべての側面を自動化できます。詳細については、以下を参照してください。

サブスクリプションサービスの例として Bicep と Terraform のモジュールがあり、商業契約への登録に関係なく、サブスクリプションサービスモデルを採用できます。自動化を調整するには、GitHub アクションまたは Azure Pipelines を使用する必要があります。

コスト管理にはタグを使用します。 Microsoft Cost Management でコスト管理とレポートを行うために、各サブスクリプションへのタグの一貫した割り当てを自動化する必要があります。商用契約で課金レポートを受け取りますが、Cost Management は優れた機能を提供します。たとえば、特定のタグを持つサブスクリプションのレポートを作成できます。詳細については、「コストと使用状況データでタグを使用する方法」および「タグの継承を使用してコストをグループ化して割り当てる方法」を参照してください。

運用サブスクリプションと非運用サブスクリプションを使用します。 新しいサブスクリプションの要求では、ワークロードが運用環境用か DevTest 用かを指定する必要があります。 DevTest 環境では、リソース料金は低くなりますが、他の条件があります。注: DevTest オファーは MPA では使用できません。詳細については、以下を参照してください。

ID とロールベースのアクセス制御 (RBA) を設定します。 セキュリティで保護された準拠環境を維持するには、Azure サブスクリプション内のリソースへのアクセスを管理することが重要です。アクセスを制御するには、ID と RBAC を設定することが不可欠です。このセットアップには、サブスクリプション所有者の指定、アクセスを管理するための Microsoft Entra グループの作成、ワークロードをデプロイするための自動化 ID の確立が含まれます。

サブスクリプションの所有者を指定します。 サブスクリプションの自動販売機の自動化では、作成時にサブスクリプション所有者を指定する必要があります。サブスクリプション要求では、この情報を取り込む必要があります。サブスクリプションの所有者は、選択したサブスクリプションディレクトリ内のユーザーまたはサービスプリンシパルに限定できます。ゲストディレクトリのユーザーを選択することはできません。サービスプリンシパルを選択する場合は、そのアプリ ID を入力します。
Microsoft Entra グループを作成します。 サブスクリプション所有者に加えて、自販プロセスで Microsoft Entra グループ構造を使用してサブスクリプションへのアクセスを管理する必要があります。昇格された (書き込みなど) アクセスの場合は、グループに PIM を使用することをお勧めします。この作成プロセスを自動化することは、サブスクリプション所有者の数を制限し、必要最小限のアクセスレベルを使用するなどのベストプラクティスに違反してはなりません。
ワークロード ID を確立します。 ワークロードのデプロイに使用されるワークロード ID (サービスプリンシパル) には、多くの場合、サブスクリプションスコープで昇格されたアクセス許可があります。サブスクリプション要求プロセスでは、取り込み時にワークロード ID のニーズを収集する必要があります。自販プロセスでは、これらの ID を作成し、適切なサブスクリプションアクセスを割り当てる必要があります。ワークロード ID は PIM を使用できないため、リソースへの永続的なアクセスを受け取ります。シークレットを管理する必要がないように、マネージド ID を使用することをお勧めします。詳細については、 ID 設計領域を参照してください。

アプリケーションチームに引き渡します。 プラットフォームチームがサブスクリプションを作成したら、サブスクリプションをアプリケーションチームに渡す必要があります。

サブスクリプションの予算を更新する

プラットフォームチームとワークロードチームは、サブスクリプションの財務状態に対する責任を共有します。デプロイでは、サブスクリプション要求の情報に基づいてサブスクリプション予算を作成する必要があります。アプリケーションは、サブスクリプションを受け取ったときにニーズに合わせて予算を更新する必要があります。予算は、現在の使用状況と予測使用量に対する支出を監査するのに役立ちますが、ハード制限ではありません。ワークロードが予算のしきい値を超えようとしている場合は、サブスクリプション所有者に通知する予算アラートを作成する必要があります。 API Management などの共有サービスの場合は、 Azure のコスト割り当て規則を使用して、サブスクリプションを使用する間にコストを再配布することを検討してください。

ワークロードをデプロイして運用する

アプリケーションチームには、ワークロードに必要なリソースを作成し、操作を管理するための自律性が必要です。プラットフォームチームは引き続きサブスクリプションガバナンスを担当します。ワークロードのガバナンス要件が変化するにつれて、プラットフォームチームは、ワークロードのニーズに最も適した管理グループにサブスクリプションを移動する必要があります。 Bicep または Terraform を使用して移動を自動化できます。詳細については、以下を参照してください。

次のステップ

アプリケーションチームに販売できるサブスクリプション (製品ライン) を確認します。さまざまなシナリオに対応できるように、優れた出発点を確立します。

一般的なサブスクリプションサービスの製品ラインを確立する