BYOCは単なる「相手のクラウドへのデプロイ」ではない

従来のSaaSモデルでは、ベンダーがアプリケーション、データプレーン、インフラストラクチャ、ネットワーキング、運用を自身のクラウドアカウントでホストします。BYOC（Bring Your Own Cloud）では、その境界がシフトし、顧客はワークロード、データ、ネットワーク制御、監査ログ、そして多くの場合請求を自身のクラウド環境内に保持しますが、ベンダーは引き続きマネージドプロダクト体験を提供します。この定義は良い出発点ですが、不完全です。実際には、BYOCは常に「ベンダーに新しいクラウドアカウントを提供してデプロイさせる」ことを意味するわけではありません。エンタープライズ、規制対象組織、AIインフラチーム、プラットフォームエンジニアリンググループはそれぞれ異なる制約を持っています。専用アカウントを提供できる企業もあれば、既存のVPCへのデプロイを要求する企業もあります。承認されたKubernetesクラスターへのワークロードのみを許可する企業や、インターネット接続を一切許可できない企業もあります。だからこそ、BYOCはデプロイメントとオペレーティングモデルのスペクトラムとして理解するのがより良いのです。1ベンダーSaaS2BYOC-Account3BYOC-VPC4BYOC-K8s5Air-gapped / disconnected より深いポイント：BYOC Anywhereは単なるインフラストラクチャの配置ではありません。それは、多くの顧客管理下の環境全体でソフトウェアを配信、保護、運用、計測、アップグレード、監視、ガバナンスする能力です。 なぜ顧客は異なるBYOCの形態を必要とするのか 顧客がBYOCを求める理由は様々であり、それらの理由はしばしば複合的です。データレジデンシーと主権を望む顧客もいます。データは特定の地域、アカウント、クラウド、または管轄区域内に留まる必要があります。他の顧客はセキュリティ制御を望みます。プライベートネットワーキング、顧客所有の鍵、監査ログ、生データへのベンダーアクセスなし、そして自身のIDおよびガバナンスシステムを通じたポリシー施行などです。一部のバイヤーは商業的な整合性を重視します。彼らはすでにクラウド支出、リザーブドキャパシティ、GPU予約、または社内チャージバックモデルにコミットしています。自身の Сloud アカウントでソフトウェアを実行することは、二重に支払うのではなく、それらのコミットメントを利用するのに役立ちます。AIやデータ集約型のワークロードでは、その理由はしばしばデータグラビティです。大量のログ、埋め込み、モデル出力、ファイル、またはテレメトリをベンダーSaaS環境に移動することは、高価であったり、遅かったり、禁止されていたりする可能性があります。BYOCはコンピュートをデータに近づけます。プラットフォームチームは標準化を要求する場合もあります。彼らはすでに承認されたVPCパターン、Kubernetesクラスター、サービスメッシュ、シークレットマネージャー、CI/CDシステム、オブザーバビリティスタック、およびサプライチェーンスキャンを実行しています。それらのパターンに適合できないベンダーは、運用上の摩擦を生み出します。最後に、規制された環境では、ソフトウェアアップデート、コンテナイメージ、ライセンス、およびテレメトリがライブインターネットアクセスを想定できない、切断されたまたはエアギャップされた配信が必要になる場合があります。エアギャップ環境では、オフラインアップデートワークフロー、ミラーリングされたリポジトリ、および制御されたアーティファクト転送プロセスが必要です。（Ubuntuのエアギャップシステムドキュメント） 4つの主要なBYOCバリアント 1. BYOC-Account（Bring your own Cloud Account） 図1：標準的なBYOC-Accountデプロイメントモデル。 BYOC-Accountは最も一般的なメンタルモデルです。顧客は専用のクラウドアカウント、プロジェクト、またはサブスクリプションを作成します。ベンダーは、通常、スコープされたIAMロールを通じて、またはエージェントをデプロイして残りを自動化する（またはTerraform、CloudFormation、使い捨てインストーラー/スクリプトのセットを通じて手動で）ことで、その環境にデータプレーンをデプロイします。顧客の視点では、このモデルは次のように感じられます：1アカウント作成2IAMロール承認3ベンダーデプロイ4サービスが顧客クラウドで実行 この形態は、顧客がベンダーを既存のネットワークのあらゆる詳細に強制することなく、クリーンな分離を望む場合にうまく機能します。顧客はアカウント境界、請求、クラウドログ、リージョン選択、および多くのポリシー制御を所有します。ベンダーは、デプロイメント、スケーリング、ヘルスチェック、アップグレード、およびサポートといった製品ライフサイクルを所有します。BYOC-Accountは、関心の明確な分離を作成するため、しばしば適切な出発点となります。しかし、厳格なネットワーキング、ルーティング、プライベートエンドポイント、または社内プラットフォームの要件を持つ顧客には十分ではありません。 2. BYOC-VPC（Bring your own VPC） 図2：顧客承認済みのネットワーク境界を持つセキュアなBYOC-VPCデプロイメント。 BYOC-VPCはさらに一歩進みます。ソフトウェアは顧客承認済みのネットワーク境界内で実行される必要があります。単に新しいアカウントにデプロイするのではなく、ベンダーは既存のVPC、VNet、サブネットレイアウト、ルーティングモデル、DNS設定、ファイアウォールポリシー、プライベートエンドポイント、およびエグレス制御と統合する必要があります。顧客の視点では、このモデルは次のように感じられます：1VPC / サブネット提供2ルート、エンドポイント、セキュリティグループ承認3プライベートにデプロイ これは、顧客が次のような要件を持つ場合に重要です：パブリックエンドポイントなし。社内システムへのプライベート接続。エグレス許可リスト。PrivateLinkスタイルの接続。集中化されたファイアウォール検査。社内DNSおよび証明書ポリシー。既存のネットワークセグメンテーション。例えば、AWS PrivateLinkのようなプライベート接続サービスは、パブリックIP、インターネットゲートウェイ、NATデバイス、またはパブリックルーティングパスを必要とせずに、顧客がサービスにプライベートに接続できるように設計されています。（AWS PrivateLink） BYOC-VPCはBYOC-Accountよりも要求が高くなります。なぜなら、デプロイメントはクラウド全体で顧客のネットワークアーキテクチャを尊重する必要があるからです。ベンダーは、開いたアウトバウンドインターネット、デフォルトDNS、許可されたセキュリティグループ、またはベンダー管理のインバウンドを想定できません。 3. BYOC-K8s（Bring your own Kubernetes） 図3：顧客管理のKubernetesランタイム内での標準化されたBYOC-K8sデプロイメント。 BYOC-K8sは、顧客がKubernetesランタイムを提供するという意味です。ベンダーは、多くの場合Helmチャート、オペレーター、コントローラー、CRD、ネームスペース、サービスアカウント、およびコンテナイメージを通じて、顧客管理のKubernetesクラスターにデプロイします。顧客の視点では、このモデルは次のように感じられます：1クラスター提供2Helm / オペレーターインストール3ライセンス / コントロールプレーン接続4ワークロード運用 この形態は、顧客がクラウド、オンプレミス、エッジ、またはGPUインフラストラクチャ全体でKubernetesを中心に標準化している場合に一般的です。Kubernetesは、コンテナ化されたワークロードとサービスを管理するためのポータブルで拡張可能なプラットフォームとして明確に設計されており、マルチ環境配信のための自然な抽象化レイヤーとなっています。（マルチ環境配信のためのKubernetes） BYOC-K8sはプラットフォームチームにより多くの制御権を与えます。彼らは独自のAdmissionポリシー、イメージスキャナー、シークレット管理、ストレージクラス、イングレスコントローラー、サービスメッシュルール、ノードプール、GPUスケジューリング、およびオブザーバビリティ統合を強制できます。しかし、それは責任モデルも変更します。ベンダーはもはや完全な基盤を制御しません。クラスターバージョン、CNIの動作、ストレージドライバー、ノードの自動スケーリング、リソースクォータ、Podセキュリティ設定、およびイメージレジストリアクセスは広く異なる場合があります。ベンダーは基盤となるインフラストラクチャもプロビジョニングしないため、インフラのプロビジョニング、サイジング、アップグレード、およびトラブルシューティングは、顧客のプラットフォームチームとの調整を必要とすることがよくあります。これは、ハードウェア、ネットワーキング、およびストレージの抽象化が大きく異なる従来のオンプレミス環境では特に困難です。 4. Air-gapped Software Distribution（エアギャップソフトウェア配信） 図4：顧客制御のオフライン配信による高度にセキュアなエアギャップデプロイメント。 エアギャップは厳密にはBYOCではありませんが、同じ顧客制御配信スペクトラムの自然な拡張です。このモデルでは、ソフトウェアはインターネット接続がまったくない環境で実行されます。これは、防衛、公共部門、重要インフラ、金融サービス、ヘルスケア、または主権上の理由によることが多いです。顧客の視点では、このモデルは次のように感じられます：1署名済みアーティファクト受信2スキャン / 承認（サプライチェーン）3オフラインインポート4ローカルでインストール / アップグレード エアギャップ配信には異なるオペレーティングモデルが必要です。ベンダーは、ライブテレメトリ、リモートデバッグ、オンラインライセンスチェック、自動イメージプル、ホストされたパッケージリポジトリ、または継続的なコントロールプレーンアクセスを想定できません。アップデート、パッチ、コンテナイメージ、依存関係リポジトリ、およびドキュメントは、しばしばミラーリングされるか、制御されたプロセスを通じて環境に転送される必要があります。（高度にセキュアな、エアギャップUbuntuアーキテクチャ） これは