概要
- Delos Cloud はもはや覚書や政策概念だけではありません。同社の発表によると、最初の運用センターは2025年9月にギュータースロー広域圏で稼働開始、2番目の運用センターは2026年1月にライプツィヒ広域圏で稼働開始、セキュリティ運用センターは既に準備完了、データセンターは本番サービスの最終準備段階にありました。
- 商用提供は、Microsoft Azure テクノロジーを基盤とし、Delos Cloud が Arvato Systems の要員と共に運用するドイツ公共セクター向けクラウドです。Delos は、インフラを所有し、プラットフォームを運営し、製品をライセンス供与する一方、Microsoft はテクノロジーを提供し、Arvato はドイツでの運用を支援します。
- 公開ルーティングの証拠は確かです。AS198678 の RIPE RDAPは Delos Cloud GmbH を指名し、RIPEstat のアナウンス済みプレフィックスデータは4つの IPv4 プレフィックスと1つの IPv6 アグリゲートを示し、RIPEstat のルーティングステータスは広範なコレクター可視性を示しています。可視的な依存関係も明確です：RIPEstat の隣接データは、AS212185（別の Delos Cloud システム）を AS198678 の唯一の公開隣接として認識しています。
- したがって、回復力のテストは Delos Cloud が信頼できる公開フットプリントを持っているかどうかではありません。それは持っています。テストは、重要な公共セクターのワークロードがそれらに依存する前に、顧客がホステッドサービスの背後にある施設の電力、冷却、キャリア多様性、保守慣行、在庫、サポートエスカレーションを検証できるかどうかです。
公開証拠は現在、真剣な運用調査を支持している
Delos Cloud GmbH は、公式企業ページ、SAP のリリース、パートナーページ、顧客パイロット資料、インターネットレジストリデータを通じて可視化されています。その概要ページは、同社をドイツのデジタル公共サービスのための主権プラットフォームとして位置づけ、ドイツのセキュリティ要件に沿い、連邦、州、自治体の IT プロバイダーをサポートすることを目的としています。その製品ページは、提供内容が Delos Cloud によって主権的に提供される Microsoft サービスを中心としており、従量課金型およびユーザー型サービスを含み、サードパーティソフトウェア、オープンソースソフトウェア、顧客開発アプリケーションの余地も残しています。
これは、「薄いフットプリント」仮説が会社の存在に関する疑問として読まれる場合、それが示唆するよりも強力な公開姿勢です。より適切な格下げは異なります。Delos Cloud は、現実的で先進的な構築として扱うのに十分な証拠を持っています。しかし、すべてのデータセンター、トランジット、メンテナンス、移行の依存関係を本番環境で実証済みとして評価するために必要な物理的および運用上の詳細をまだ公開していません。公共セクターのクラウドでは、この区別はブランド認知よりも重要です。主権的提供は依然としてホステッドキャパシティの提供です。機器が故障した場合でも使用可能なサービスに変換するために、建物、ラック、ルーター、スタッフ、契約を依然として必要とします。
タイムラインは重要です。2025年9月のSAP リリースによると、Delos Cloud は最初の運用センターをギュータースロー広域圏で稼働させたと述べています。リリースによれば、60名以上のスタッフが常駐し、Arvato Systems の運用スタッフが Delos Cloud サービスを運用し、センターはプラットフォーム運用、セキュリティ、認定において主要な役割を果たすとされています。また、2番目の運用センターがライプツィヒ広域圏でほぼ完成し、3番目の運用センターがフランクフルト広域圏で間もなく建設開始、そしてフランクフルト広域圏のセキュリティ運用センターは準備完了とされました。
2026年1月のSAP リリースは話を前進させました。ライプツィヒ広域圏の2番目の運用センターが稼働し、本番運用のための運用センターインフラが完成し、2つの完成した運用センターによりプラットフォームは障害や危機シナリオに対して地理冗長の運用保護を実現したと述べています。同じリリースは、関連するセキュリティ運用センターが準備完了であり、Delos Cloud のデータセンターが本番運用の最終準備段階にあるとも述べています。また、ライプツィヒセンターは80のワークプレースを提供し、厳格なセキュリティ対策の下で24時間体制の運用を行うとしています。
公開されている顧客の証拠も一般的な関心を超えて進展しました。Delos Cloud の顧客ページには、連邦および州レベルの公共ユースケースにおけるパイロット顧客と具体的な例がリストされており、連邦雇用機関、ノルトライン＝ヴェストファーレン州の金融・テクノロジープロジェクト、バーデン＝ヴュルテンベルク州の文化機関などが含まれます。2026年5月のSAP リリースによると、シュトゥットガルト州立劇場が Delos Cloud プラットフォーム上で Microsoft Office 365 と一部の Azure サービスのパイロットを開始し、カールスルーエ州立劇場も参加し、SVA がコンサルティングおよび導入パートナーを務めています。2026年6月のSAP リリースでは、Delos Cloud がパートナープログラム開始時に15社と戦略的パートナーシップを締結したと述べています。
これらを総合すると、これらの情報源は懐疑的な却下ではなく、真剣なインフラ分析を正当化します。問題はもはや Delos Cloud が公開記録に現れるかどうかではありません。問題は、実証済みのローンチインフラと、顧客がまだ調査する必要がある部分（物理データホール、キャリア経路、サポートエスカレーション、復旧経路、セキュリティ認証、Microsoft テクノロジーベースへの商業的依存）の間の線がどこにあるかです。
サービスエリアはドイツだが、サイトマップはまだ限定的
Delos Cloud のサービスエリアに関する約束は異常に明確です。同社の資料は、プラットフォームがドイツの公共セクター向けであり、データ処理と運用はドイツ内に留まると繰り返し述べています。2025年2月の価格リリースでは、プラットフォームはドイツの公共顧客向けであり、機密の行政データはドイツ国内のデータセンターと運用サイトでのみ処理され、Delos Cloud GmbH とプラットフォームはドイツの管轄下にあると述べています。2025年5月のD-Trust 証明書リリースも、暗号化および認証通信のためのドイツの TLS 証明書について説明しながら、同じ地域性を強調しています。
その地域性は商業的に価値があります。しかし、それは完全なサイトマップではありません。公開リリースは、ギュータースローとライプツィヒ広域圏の運用センター、およびフランクフルト広域圏のセキュリティ運用センターを特定しています。データホールの住所、ユーティリティ供給設計、ラック数、電力密度、建物所有者、ミートミールーム、燃料設備、キャリア入口は公開していません。2026年1月の時点で Delos Cloud のデータセンターは最終準備段階にあったと述べていますが、ここでレビューした公開リリースではそれらのデータセンターの名前は明らかにされていません。
その境界は明確に保たれるべきです。運用センターは人が監視、運用、セキュリティ、対応を行う場所です。データセンターはコンピュート、ストレージ、ネットワーク機器が電力を消費し、熱を排出し、キャリアに接続する場所です。両者は関連していますが、互換性はありません。2拠点の運用体制は、コンピュートプラットフォームが別個の物理的依存関係を持っていても、スタッフと指揮の回復力を向上させることができます。逆に、運用デスク、アクセス制御、キャリアエスカレーション、変更承認が利用できない場合、2つのデータホールは顧客にとって機能しない可能性があります。Delos Cloud の公開資料は運用センター層について最も強力であり、データホール層については弱いです。
同じ注意が地理冗長性にも当てはまります。2026年1月のリリースでは、2つの完成した運用センターが、障害や危機シナリオに対する地理冗長性を通じて運用を保護すると述べています。これは運用層に関する重要な主張です。しかし、それだけでは、すべての顧客ワークロードが2つの独立したデータホール間で同期的にレプリケートされていること、すべての管理システムがアクティブ/アクティブ制御を持っていること、すべての顧客サービスがテスト済みのリージョンフェイルオーバーを持っていること、またはすべてのストレージサービスが特定のリカバリポイントを満たせることを証明するものではありません。これらの詳細は顧客向け文書に存在する可能性がありますが、すべてが公開されているわけではありません。
したがって、調達において、適切なサイトの質問は具体的です。注文するサービスをサポートするリージョン、可用性設計、データセンターのペアはどれか？ギュータースロー、ライプツィヒ、フランクフルトから制御される機能と、データホール内で実行される機能はどれか？運用センターが吸収できる障害と、データセンタースタッフ、キャリアエンジニア、スペアハードウェア、Microsoft テクノロジーサポートを必要とする障害はどれか？公開資料はそのデューデリジェンスの線を開きますが、閉じるわけではありません。
運用者の境界が主権的主張の中核
Delos Cloud の主権論は役割の分離に基づいています。2025年2月の価格リリースでは、Delos Cloud は Microsoft Azure ハイパースケールテクノロジーを使用するが、それらのサービスをドイツの行政に主権的に提供すると述べています。Delos Cloud GmbH がインフラの所有者として、プラットフォーム運用と製品ライセンスを引き受けるとしています。Microsoft はテクノロジーサプライヤーとして貢献します。2024年10月のSAP 契約リリースおよび同じ契約に関するベルテルスマンのレポートは、Delos Cloud、Microsoft、Arvato Systems 間の最終契約を説明し、Arvato Systems がドイツでのプラットフォーム運用を支援すると述べています。
この構造は重要な理由があります。公共セクターの購入者は仮想マシンや Office コラボレーションだけを購入しているわけではありません。制御の法的・運用上の割り当てを購入しているのです。Delos Cloud は、ドイツ企業が運用し、ドイツの管轄下にあり、ドイツのセキュリティクリアランスを持つスタッフが配置され、データがドイツで処理される環境で Microsoft テクノロジーを提供するといいます。これは、グローバルリージョンで通常のパブリッククラウドサービスを購入し、ドイツの請求ラッパーを追加するのとは異なる提案です。
境界はまた依存関係を生み出します。Microsoft がテクノロジーサプライヤーであれば、Delos Cloud は依然として Microsoft のソフトウェア開発、セキュリティアップデート、製品進化、ライセンス権に依存します。Arvato Systems のスタッフが運用センターでサービスを運用する場合、Delos Cloud は Arvato の採用、トレーニング、クリアランス、シフトカバレッジ、施設手順に依存します。SAP が親会社であり投資家である場合、Delos Cloud は SAP の規模の恩恵を受けますが、資金調達、契約、公共の信頼を維持しなければならない戦略的プログラムの中に位置づけられます。主権は一部のリスクを軽減しますが、他のリスクを注意深く設計されたチェーンに集中させます。
2025年11月の Bleu および Microsoft との復旧力発表はそのチェーンを示しています。SAP リリースによると、Delos Cloud と Bleu は広範な危機および緊急シナリオに対する国境を越えた技術的・運用上の協力に合意し、Delos Cloud と Microsoft は、外部制限が特定の顧客向け Microsoft クラウドサービスに影響を与える場合に欧州での事業継続を支援するための別個の合意に署名しました。これは、Delos Cloud が地政学的なサービス継続リスクについて考えていることを示すため有用です。また、運用者の境界が単一の壁として扱えない理由も示しています。一部の緊急対策には、法的権利、ソフトウェアアクセス、Delos の容量、運用スタッフ、顧客移行能力が同時に必要です。
支持可能な結論はバランスが取れています。Delos Cloud には、名前付きの役割分離を伴う公開主権設計があります。その設計は意味があります。それはまた、物理施設、更新パス、スタッフ手順、緊急移行取り決めが負荷の下で機能するという証明の代わりにはなりません。顧客は設計を拒否する必要はありません。顧客はそれを障害に対してテストする必要があります。
Delos Cloud が販売するのは単一の単純なクラウド製品ではない
Delos Cloud の製品カタログは、インフラ、プラットフォーム、コラボレーションサービスに及びます。ポートフォリオページには、Azure Foundational Services、Azure Mainstream Services、Office 365、SAP サービス、サードパーティソリューション、オープンソースソフトウェア、顧客開発アプリケーションがリストされています。コンピュート、ストレージ、ネットワーキング、データベース、コンテナサービス、監視、セキュリティ関連アイテムがポートフォリオ全体に含まれています。ロードマップページは、サービスセットを主権的公共セクタークラウドへの段階的な道筋として位置づけています。
その幅広さは容量にとって重要です。仮想マシンは CPU、メモリ、ストレージ、ネットワークポート、ホストスケジューリング容量、管理プレーン容量、サポート時間を消費します。マネージドデータベースはストレージ、メモリ、バックアップ容量、運用ケアを消費します。コラボレーションテナントはアイデンティティ、メール、ストレージ、ポリシー、サポート容量を消費します。バックアップまたはサイトリカバリサービスはセカンダリストレージ、ネットワークスループット、復元手順、テスト時間を消費します。Kubernetes サービスはコントロールプレーン容量、ワーカーノード、イメージ、ログ、セキュリティメンテナンスを消費します。購入者は一つのクラウドカタログを見ます。運用者は多くの容量プールを運用しなければなりません。
2025年2月の価格リリースは経済的枠組みを追加します。それによると、Delos Cloud はドイツ公共顧客向けの主権的 Microsoft サービスを、現在の Microsoft ドイツリスト価格の15%上乗せで価格設定し、その価格は Delos Cloud が提供する Microsoft インフラおよびプラットフォームサービス（Azure Foundational Services、Azure Mainstream Services、Microsoft Office 365 を含む）に適用されます。上乗せ額は主権の可視的な価格ですが、容量の保証ではありません。15%の上乗せは、プラットフォームが十分な需要に達し、基盤となるプラントが使用可能な予備を持って計画されている場合にのみ、ドイツでの運用、セキュリティ要件、別個のインフラ、制御取り決めのコストを賄うことができます。
使用可能な予備は隠れた分母です。Delos Cloud は運用センターと製品ポートフォリオを発表できますが、本番移行を評価する顧客は、公開が難しい容量数値を必要とします：コミッション済み IT 負荷、販売済み負荷、予備負荷、サービス別ホストクラスタ、ストレージ予備、ネットワークオーバーサブスクリプション、バックアップ容量、サポート人員、パッチウィンドウ、復元パフォーマンス。インストールされたサーバーは使用可能なクラウド容量と同じではありません。テスト済みの自動化、予備ストレージ、承認されたメンテナンスパス、キャリア多様性のないラックのハードウェアは、重要なワークロードを安全に処理できません。パイロットテナントを開始できるリージョンは、大規模な部門移行に自動的に準備ができているわけではありません。
これが、プラットフォームのオープンでベンダーニュートラルな主張が重要である理由です。パートナープログラムと製品ページは、サードパーティが Delos Cloud にソリューションを持ち込めることを示しています。これはエコシステムの深さを向上させることができますが、ばらつきも追加します。Delos インフラ上のパートナー構築アプリケーションは、Office 365 サービスとは異なるサポート、ライセンス、パッチ、復元条件を持つ可能性があります。オープンソースコンポーネントは、Microsoft 提供のコンポーネントとは異なるメンテナンス責任を持つ可能性があります。顧客開発アプリケーションは、Delos が部分的にしか提供しないランディングゾーン、監視、バックアップ、シークレット処理、ネットワークセグメンテーションを必要とする可能性があります。クラウドカタログは容量計画の開始点であり、終点ではありません。
ルーティングの証拠は到達可能性を証明するが、物理的経路全体ではない
Delos Cloud のネットワーク証拠は、多くの初期段階の主権クラウドプロジェクトよりも強力です。AS198678 の RIPE RDAPは、自律システムをdeloscloudとして識別し、2023年5月1日に登録され、Delos Cloud GmbH が登録者です。RIPEstat の AS 概要は、AS が2026年7月12日にアナウンスされたと報告しました。アナウンス済みプレフィックスビューは、2026年6月28日から7月12日の期間に5つの可視プレフィックスを示しました：123.2.0.0/15、142.221.0.0/16、161.37.0.0/16、168.86.0.0/17、2a07:3040::/32。
これらのプレフィックスの規模は無視できません。RIPEstat のルーティングステータスは、294,912 の IPv4 アドレスを持つ4つの IPv4 プレフィックスと、65,536 の /48 に相当する1つの IPv6 アグリゲートを報告しました。また、サンプリングされた326の IPv4 ピアのうち326、322の IPv6 ピアのうち322が、クエリ時にルートを認識していると報告しました。Delos IPv4 範囲の RIPE RDAP IP レコードは、Delos Cloud GmbH を可視割り当てのアドレス保持者として識別します。RIPEstat の RPKI 検証は、AS198678 と123.2.0.0/15に対して有効な発信元ステータスを返し、対応するIPv6 検証は AS198678 と2a07:3040::/32に対して有効を返しました。
これらの事実は一つの重要な主張を支持します：Delos Cloud は自社名でライブの公開インターネットルーティングを持っています。しかし、クラウド購入者が関心を持つすべての主張を支持するわけではありません。RIPEstat の隣接ビューは、AS198678 の公開隣接を1つだけ確認しました：AS212185。AS212185 の RIPE RDAPは、その AS をdeloscloudconnectとして識別し、2025年6月26日に Delos Cloud GmbH に登録されました。AS212185 の RIPEstat アナウンス済みプレフィックスデータは、2つの IPv4 /23 と2つの IPv6 /48 を示し、AS212185 の RIPEstat 隣接データは AS2914、AS3356、AS198678 を確認しました。
そのパターンは、Delos 接続 AS の背後にある内部発信元 AS が、その後大規模アップストリームを通じてグローバルトランジットに到達するように見えます。それは完全に意図的で回復力があるかもしれません。また、公開 BGP ビューでは見えない物理的依存関係を隠している可能性もあります。AS212185 は多様なファイバー入口を受け取っていますか？AS2914 と AS3356 は別々のミートミールーム、導管、光システムを通じて入口していますか？一方が故障した場合、もう一方が完全な本番負荷を処理できますか？管理プレーンとカスタマープレーンは分離されていますか？PeeringDB で見えないインターネットエクスチェンジピアリングはありますか？公開ルーティングはこれらの質問に答えられません。コレクターが見る経路形状を示すだけです。
PeeringDB エントリの欠如も限定的な証拠です。AS198678 の PeeringDB クエリはネットワークレコードを返しません。PeeringDB は任意参加であり、欠如は Delos Cloud に施設、プライベートインターコネクト、アップストリーム契約がないことを意味しません。しかし、一般が施設の存在、エクスチェンジポート、トラフィックポリシー、ピアリング連絡先を PeeringDB で確認できないことを意味します。公共セクターネットワークへの信頼できる接続に依存する主権クラウドにとって、公開相互接続プロファイルの欠如は直接的な顧客証拠の必要性を高めます。
したがって、ネットワークグレードは弱いというよりは中程度です。ルートはライブで、RPKI 検証済みであり、広く可視です。公開ルートグラフは、ネットワークエッジを実証済みの回復力として扱うのに十分な物理的多様性を明らかにしていません。顧客は、高影響ワークロードを Delos Cloud に依存する前に、ルート発信元設計、アップストリームキャリアリスト、物理的入口多様性、DDoS 対応、プライベート公共セクター接続、ルートリーク保護、フェイルオーバーテスト結果、メンテナンス通知ルールを尋ねるべきです。
電力と冷却は依然として魅力のない証明ポイント
主権クラウドは依然として、ソフトウェアが上に積まれた発電所と冷却プラントです。Delos の公開リリースは、データがドイツのデータセンターで処理され、それらのデータセンターは2026年1月に本番運用の最終準備段階にあったと述べています。ユーティリティ容量、変圧器トポロジー、UPS 設計、発電機定格、燃料稼働時間、冷却トポロジー、水暴露、防火区画、ラック密度制限は開示していません。その省略はセキュリティおよび商業的理由で理解できますが、購入者にスキップできない質問を残します。
BSI C5 カタログページとC5:2026 カタログ PDFは、このレベルの証拠がクラウド保証にとって正常である理由を示しています。クラウドセキュリティには、物理的セキュリティ、運用、インシデント処理、事業継続、移植性、サービスレベル、サプライチェーン管理が含まれます。Delos Cloud 自身の資料は、BSI 要件に準拠し、機密の公共セクターデータの処理をサポートすることを目指していると述べています。その主張は最終的には、ローンチ声明だけでなく、認証とテスト証拠によって裏付けられるべきです。
電力については、顧客はサービス境界を知る必要があります。顧客ワークロードは物理的に独立した2つのデータホールに配置されていますか？ユーティリティフィードは変電所からラックまで独立していますか？コミッション済み IT 負荷は単にインストールされたものと比較してどの程度ですか？発電機プラントは IT 負荷と冷却を同時に処理できますか？長時間の停電中に給油中はどうなりますか？どのシステムが同時にメンテナンス可能で、どのメンテナンス状態が冗長性を低下させますか？A/B ラックフィードは、それらが上流の一つの配電盤または UPS トレインに収束する場合、あまり意味がありません。
冷却については、顧客は除熱マップを必要とします。プラットフォームは電力が供給されていても、入口温度が上昇し、コンポーネントがスロットルし、ホストが負荷を shed する可能性があります。冷却プラントは販売負荷に対して十分な予備を持っていますか？チラー、ポンプ、制御装置、給水、熱交換器は独立した電源でバックアップされていますか？冷却メンテナンスは顧客ワークロードを移動せずに行えますか？冷却ユニット、コントローラー、センサーネットワークが故障した場合のインシデントパスは何ですか？これらは学術的な関心事ではありません。短いプラント障害がサービスインシデントになるかどうかを決定します。
火災と水暴露については、顧客は建物固有の緩和策を必要とします。ドイツの所在地は管轄権と人員配置に役立ちますが、フロアレベル、漏洩検知、ガス消火、煙ゾーニング、燃料貯蔵、隣接テナントリスク、緊急アクセスを明らかにしません。公式のセキュリティ評価はそれらの事実をカバーする可能性があります。公開リリースはそれらを公開していません。適切な機密保持の下で購入者に事実が可視になるまで、安全な公開声明は、データセンターの所在地はドイツであり、データホールの回復力は公開スコアリング不能であるということです。
修理窓口は、顧客が実際に誰がサービスを運用しているかを知る場所
メンテナンスウィンドウは設計を現実に変えます。サービスは2つのサイト、2つのキャリア、重複コンポーネントを持っていても、修理手順が安全でない手動ステップを必要としたり、スペアパーツが不足していたり、スタッフがサイトに到達できなかったり、ロールバックパスなしで変更が適用されたりすると、依然として失敗する可能性があります。この面での Delos Cloud の最も強力な公開証拠は、運用センターの構築です：2つの完成した運用サイト、セキュリティクリアランスを持つドイツ人スタッフ（Arvato Systems）、セキュリティ運用センター、成長するパートナーエコシステム。
それは肯定的です。また、次の一連の質問を生み出します。どのチームがデータホールのラックを開けられますか？どのチームが故障したストレージシェルフを交換できますか？どのチームがルーター変更を承認できますか？どのチームが Microsoft テクノロジーアップデートを遅延または拒否できますか？どのチームが顧客にメンテナンスウィンドウを通知しますか？どのチームがインシデントを宣言しますか？三者パーティ設計では、顧客体験は機器数と同じくらい契約と権限マップに依存します。
Arvato Systems の Delos Cloud ページは、Arvato を行政向け主権クラウドのパートナーとして位置づけており、2025年9月と2026年1月の Delos リリースは両方とも、運用センター内で Arvato Systems の運用スタッフを特定しています。ベルテルスマンのレポートは、Arvato Systems がプラットフォームを運用し、複数のドイツの拠点が長期運用に関与していることを追加しています。これにより、Arvato は修理チェーンにおいて重要な役割を担います。正確なエスカレーションラダー、リモートハンド応答時間、スペア在庫ポリシー、チケット目標は開示されていません。
修理ウィンドウはまた、公共セクターの変更管理と相互作用します。通常のハイパースケールクラウドは、グローバルリージョン全体で変更を継続的にロールアウトする場合があります。主権的公共セクタークラウドは、より厳格な通知、承認、文書化、職務分離を必要とする場合があります。それは制御を改善できますが、適切に設計されていないと修正を遅らせる可能性があります。顧客は、標準的なメンテナンスリードタイム、緊急変更ルール、顧客承認ポイント、ロールバック手順、および計画されたメンテナンスが代表的な規模でサービス損失なく完了したという証拠を尋ねるべきです。
サポートカバレッジも同様に重要です。運用センターのリリースは24時間体制の運用を約束しています。24時間体制の運用は、自動的にすべてのサービスが24時間専門家サポートを持ち、すべてのパートナーアプリケーションが夜間に修理可能であり、すべての顧客が同じ重大度パスを持つことを意味しません。Delos Cloud のパートナープログラムは、パートナーをサービス、販売、構築の役割に分類しています。つまり、顧客は一つのインシデントパスに Delos Cloud、サービスパートナー、ソフトウェアベンダー、内部公共セクターIT プロバイダーを持つ可能性があります。修理ウィンドウは、誰が誰に電話するか、誰がクロックを所有するか、誰が修正を行えるかを指定する必要があります。
顧客移行は依存関係であり、一回限りのオンボーディングタスクではない
Delos Cloud は、公共セクターの顧客が所在地、管轄権、運用制御を放棄せずに最新のクラウドサービスを望むために存在します。その移行の約束は中心的です。また、回復力を過大評価しやすい場所の一つでもあります。ワークロードを主権クラウドに移動しても、自動的にそれらが移植可能、復元可能、または基盤となるテクノロジーベースから独立するわけではありません。
Delos の顧客ページは、パイロットを、大規模な採用前に技術的、契約的、組織的な取り決めをテストする方法として説明しています。シュトゥットガルト州立劇場のリリースは、パイロットが実際の条件下で Office 365 機能と選択された Azure サービスをテストし、セキュリティ、効率性、公共文化業務への統合に注意を払うと述べています。これはパイロットの良い使い方です。移行を仮定ではなく経験的に扱います。
顧客にとって、実用的な移行の質問は具体的です。アイデンティティはどのように統合されますか？テナントポリシーはどのように設定されますか？どの Office 365 データをエクスポートおよび復元できますか？どの Azure サービスがローンチ時に含まれ、どれが後で提供されますか？仮想マシンはイメージとして外部に移動できますか、それとも再構築のみですか？データベース、バックアップ、ログ、暗号化キー、監視データはどのようにエクスポートされますか？公共セクター団体が通常の Microsoft サービスで開始し、後で Delos Cloud に移行する場合、または Delos Cloud で開始し、緊急で別の場所に移動する必要がある場合はどうなりますか？ワークロードがマネージドサービスを使用すればするほど、移行は製品固有のエクスポートパスに依存します。
ドイツ行政クラウド戦略資料とFITKO DVC ガイダンスは、孤立したプラットフォームではなく、より広範な連邦クラウドエコシステムを指しています。この文脈は重要です。Delos Cloud は一つの大きなコンポーネントかもしれませんが、公共団体は相互運用性、調達の明確さ、そして単に国内の別の依存関係に依存関係を置き換えることを避ける方法も必要とします。データローカリティは一つの問題を解決します。データ移植性は別の問題を解決します。
2025年11月の Microsoft 継続性契約は移行をさらに明確にします。特定の顧客は、外部制限が Microsoft によるサービス提供を妨げた場合、ワークロードを Delos Cloud に移行するオプションを持つ可能性があると述べています。それは戦略的なコンティンジェンシーです。その実用的価値は、容量、法的権利、ソフトウェアアクセス、互換性のあるサービスバージョン、顧客準備、帯域幅、テスト演習に依存します。リハーサルされたことのない緊急移行は希望であり、復旧能力ではありません。
したがって、購入者は移行アーティファクトを生きた運用証拠として扱うべきです。必要な証拠には、ランディングゾーンパターン、アイデンティティ統合ガイド、エクスポート手順、サービスごとの制限、バックアップと復元テスト、ロールバック基準、コスト影響、顧客受け入れテストが含まれます。目的はすべてのワークロードをクラウドに依存しないようにすることではありません。目的は、依存関係が意図的である場所、一時的である場所、危険になる場所を正確に知ることです。
主な障害経路は普通であり、異例ではない
Delos Cloud の戦略的設定はリスクを地政学的に感じさせる可能性がありますが、ほとんどのサービス障害は依然として通常のインフラから始まります。
最初の経路はラックまたはホストの障害です。サーバー、ストレージシェルフ、トップオブラックスイッチ、または配電ユニットが故障します。スペアハードウェアがローカルにあり、自動化が機能すれば、顧客はほとんど影響を受けないかもしれません。障害が小さなサービスクラスタ、未成熟なリージョン、または限られた予備しかない管理システムを直撃した場合、顧客はプロビジョニングエラー、パフォーマンス低下、または復元失敗を経験する可能性があります。Delos Cloud の公開資料は、クラスタサイズ、スペア比率、復元時間を公開していません。
2番目の経路はアップストリームまたはキャリアの障害です。公開 BGP は AS198678 が AS212185 の背後にあり、AS212185 が大規模トランジットプロバイダーに隣接していることを示しています。設計は良好なプライベート多様性を持つ可能性がありますが、公開ルートグラフはそれを証明しません。キャリアのメンテナンスイベント、ファイバーカット、光プラットフォーム障害、またはルートリークは、コンピュートが健全なままであっても、顧客ワークロードや管理パスを分離する可能性があります。顧客は AS 番号だけでなく、物理的経路の多様性を知る必要があります。
3番目の経路はソフトウェアアップデートとプロバイダー契約の障害です。Delos Cloud は Microsoft テクノロジーに依存しながら、ドイツでの運用と制御を保持します。セキュリティアップデート、機能変更、ライセンス、緊急権限はすべてその境界を安全に越えなければなりません。更新フローが少なすぎるとセキュリティと互換性のリスクが生じます。仲介されない更新フローが多すぎると主権論が弱まります。公開リリースは契約が存在することを示していますが、顧客は運用ルールと証拠を必要とします。
4番目の経路はサポートとスタッフの飽和です。2つの運用センターはスタッフサイトリスクを低減しますが、広範なインシデントは依然としてサービスデスク、パートナーチーム、エスカレーションキューを過負荷にする可能性があります。公共セクターの顧客は、インシデント分類、重大度目標、コミュニケーションテンプレート、時間外権限、および演習からの証拠を望むでしょう。大規模な認証、メール、ネットワーク、またはストレージインシデントは、単一の仮想マシン停止よりもはるかに多くの人々に影響を与えます。
5番目の経路は請求、調達、および資格の不一致です。Delos Cloud の公開提供はドイツの適格な公共顧客に限定され、パートナーおよび公共セクター IT プロバイダーを通じて実行されます。サービスは技術的に準備できていても、契約、資格、予算、調達カタログ、パートナー可用性、またはセキュリティ承認によってブロックされる可能性があります。ホステッドキャパシティは、顧客が適用される公共セクターのルール内で注文、構成、接続、サポートできる場合にのみ使用可能になります。
6番目の経路はデータ移植性の障害です。顧客がアイデンティティ、メール、ストレージ、データベース、スナップショット、ログを十分な速さでエクスポートできない場合、サービス停止はロックインインシデントになります。Delos Cloud の DVC 準拠とパートナーエコシステムはそのリスクを低減する可能性がありますが、証明には標準の文言だけでなく、テストされた出口経路が必要です。
これらの経路のいずれも Delos Cloud を却下する理由ではありません。それらは、真剣なクラウドプラットフォームが退屈にしなければならない経路です。退屈とは、文書化され、テストされ、リハーサルされ、測定され、契約上所有されることを意味します。
ホスティング経済学は、どれだけの回復力を予備として維持できるかを決定する
2025年2月の価格声明は、購入者の提案だけでなく経済的問題も明らかにするため有用です。Delos Cloud は、主権的 Microsoft サービスを、適格な公共顧客向けに現在の Microsoft ドイツリスト価格の15%上乗せで価格設定すると述べています。これは、しばしば戦略的言語でしか説明されない製品カテゴリとしては比較的明確な数字です。顧客に難しい質問をさせます：そのマージンは何をカバーしなければならないのか？
答えはソフトウェアライセンスよりも広いです。上乗せ額は、ドイツのデータセンターインフラ、ドイツの運用センタースタッフ、セキュリティクリアランスを持つ要員、コンプライアンス作業、別個の証明書取り決め、パートナー調整、顧客オンボーディング、インシデント対応、サポートカバレッジ、そして成長と障害を吸収するための十分な未使用容量をサポートしなければなりません。これらのコストの一部は最初の大規模顧客が到着する前に固定されます。一部は使用量に応じてスケールします。一部は、予備ホスト、予備ストレージ、代替ネットワークパス、上級エンジニアが通常の日にはアイドル状態であっても利用可能でなければならない障害時にのみ可視化されます。
ここでインストール容量と使用可能容量が分かれます。プラットフォームはドイツのデータホールにハードウェアがインストールされているかもしれませんが、予備、メンテナンスヘッドルーム、災害復旧割り当て、管理プレーン要件、バックアップスペース、成長バッファーを差し引いた後の販売可能部分は低くなります。プラットフォームがインストールされた天井に近づきすぎて販売すると、メンテナンスはリスクが高まります。大きな予備を維持する場合、経済的ケースはそれらを資金化するのに十分な顧客需要を必要とします。顧客はクラウド価格を見ます。運用者はセキュリティと地域性の制約の下で在庫問題を管理します。
公共セクターの調達は課題を増幅させる可能性があります。顧客はフレームワーク契約、パイロット承認、予算サイクルの後に波状に到着するかもしれません。ゆっくりとした立ち上がりは高価なインフラを十分に活用されないままにする可能性があります。突然の立ち上がりはサービスチーム、クォータ計画、パートナー容量にストレスを与える可能性があります。一部の顧客はセキュリティチェックを完了する間、保守的な制限を必要とするかもしれません。他の顧客はパイロットが成功したら大規模な移行を望むかもしれません。Delos Cloud のパートナーエコシステムはその作業を吸収するのに役立ちますが、それはパートナーの準備、Delos のクォータ、顧客ガバナンスが同時に一致する場合のみです。
購入者にとって、経済的デューデリジェンスは実用的です。どのサービスが一般提供され、どれが容量制限され、どれが予約を必要とし、どれがリージョンまたはテナントクォータを持ち、どのサポート条件がサービスクラスによって変わるかを尋ねてください。売り切れゾーン、希少なストレージティア、大規模な Office 移行、突然のバックアップ拡張、または別の環境からの緊急移行を Delos がどのように処理するか尋ねてください。主権クラウドは、価格が地域性と法的制御だけでなく、通常のインフラストレスに耐える十分な予備を購入する場合にのみ、良い価値になり得ます。
システム障害時に影響を受けるのは誰か
直接の顧客はドイツの公共団体とその IT プロバイダーです。実際のユーザーは、公務員、劇場スタッフ、財務チーム、雇用センター職員、自治体管理者、ケースハンドラー、セキュリティチーム、公共デジタルサービスに依存する市民であり得ます。具体的な影響を受ける人口は、どのサービスが故障するかによって異なります。Office コラボレーションの停止はスタッフのコミュニケーションに影響を与える可能性があります。仮想ネットワークの停止はアプリケーションを分離する可能性があります。データベースまたはストレージインシデントはケース処理を停止する可能性があります。ID インシデントは多くのサービスへのアクセスを一度にブロックする可能性があります。
責任の連鎖は階層的です。Delos Cloud は公開プラットフォーム運用者およびインフラ所有者です（リリースによる）。Microsoft はテクノロジーベースを提供します。Arvato Systems はドイツでの運用を支援します。サービスパートナーは顧客環境を設計、実装、移行する場合があります。ビルドパートナーはプラットフォーム上でアプリケーションロジックを実行する場合があります。公共セクター IT プロバイダーは最終サービスを契約、統合、サポートする場合があります。利用できないサービスを経験する市民はそれらの層を見ることはありませんが、インシデント対応はそれらを通過します。
これが記事のタイトルが重要である理由です。Delos Cloud はホステッドキャパシティを販売します。ホステッドキャパシティは、法的ラッパーが主権的でソフトウェアベースが馴染みのあるものであっても、ラック、トランジット、修理ウィンドウに依存します。故障したストレージシェルフは管轄権では解決されません。キャリアの切断は政策声明では解決されません。移行のボトルネックは価格表では解決されません。主権は制御の主張であり、信頼性は運用記録です。
Delos Cloud の最も強力な公開ケースは、契約から施設、パイロット、パートナー、ルートへと段階的に進んできたことです。最も強力な公開警告は、最終的な本番証拠が必然的に公開発表よりも具体的であることです。データホールは最新の認証を必要とします。トランジット設計は多様性の証明を必要とします。修理チェーンは権限の証明を必要とします。顧客の出口経路はリハーサルを必要とします。それらが購入者に利用可能になれば、Delos Cloud は戦略的な約束ではなく本番プラットフォームとして評価できます。
残る疑問を解決するもの
Delos Cloud から必要な証拠は、機密のフロアプランや顧客名の要求ではありません。それは、重要なホステッドキャパシティの通常の保証パッケージです。
第一に、適切な機密保持の下で、データセンターの運用境界（施設運用者、ドイツの所在地地域、データホール範囲、ユーティリティおよび発電機クラス、冷却回復力、物理的セキュリティ管理、火災および水保護、現在の認証または保証範囲）を公開または提供すること。目標は正確なラック列を明らかにすることではありません。評価されたシステム境界を示すことです。
第二に、サービスごとの容量証拠を提供すること。顧客は、現在技術的に利用可能なもの、パイロット中のもの、計画中のもの、Microsoft のリリースサイクルに依存するもの、移行波に十分な予備容量があるものを知る必要があります。Delos のロードマップとポートフォリオは有用ですが、本番ワークロードは現在の可用性、クォータ、制限、メンテナンス状態、サポートコミットメントを必要とします。
第三に、適切なレベルでネットワーク設計を開示すること。公開 BGP はすでに AS198678 と AS212185 を示しています。顧客は依然としてアップストリーム多様性、物理的入口多様性、プライベート公共セクター接続、ルーティングセキュリティ、DDoS 応答、ルートフェイルオーバーテスト、メンテナンス手順を必要とします。PeeringDB の欠如はそれ自体欠陥ではありませんが、欠如している公開相互接続ビューは顧客向けの直接証拠に置き換えられるべきです。
第四に、修理を証明すること。それは、電力転送テスト、冷却フェイルオーバー、キャリアフェイルオーバー、セキュリティインシデント処理、バックアップ復元、ID リカバリ、ストレージリカバリ、パッチロールバック、顧客コミュニケーションの最近の証拠を意味します。メンテナンスウィンドウは、作業がいつ発生するかだけでなく、作業中にどの冗長性が残るかも示すべきです。
第五に、移植性を証明すること。顧客は、テナントデータ、仮想マシン、データベース、ログ、キー、バックアップ、アプリケーション依存関係のテスト済みパスを必要とします。DVC 文脈は相互運用性を戦略的目標にしていますが、Delos Cloud は特定の顧客がどのように参入、拡張、一時停止、復旧、または退出できるかをまだ示す必要があります。
その証拠があれば、Delos Cloud の評価は「先進的だが物理的および運用層でまだ証明が必要」からより強力なものになります。それがなければ、責任ある結論は慎重です。Delos Cloud GmbH は公開の運用マイルストーン、顧客パイロット、パートナー規模、明確な主権設計、ライブネットワークリソースを持っています。検証すべき残りは、企業の存在ではありません。それは、クラウドサービスの通常の機械が故障した場合に、その名の下で販売される容量の信頼性です。