要約
- Scaleway の最も強力な入り口は、欧州のインフラがハイパースケールクラウドより自動的に優れているというような一般的な主張ではない。そのより強力な主張は、一部の欧州ワークロードには、地域管理、透明な配置、よりシンプルなコストルール、そしてグローバルプラットフォームに全システムを明け渡すことなく運用可能な AI またはクラウド容量が必要だということである。
- 公開されている証拠は、リアルで拡大中のプラットフォームを裏付けている。Scaleway は、欧州のリージョンとアベイラビリティゾーン、マネージド Kubernetes コントロールプレーンティア、S3 互換オブジェクトストレージ、VPC ネットワーキング、IAM、Audit Trail、マネージドデータベース、サポートプラン、GPU インスタンス、そして欧州委員会のソブリンクラウド調達における公式な役割を文書化している。
- 証拠はまた、判断を条件付きにしている。公開情報源は、顧客固有の GPU 可用性、移行の成功、復元時間、サポート品質、ハイパースケーラーとのサービス同等性、または負荷下でのパフォーマンスを証明していないため、Scaleway はソブリン言語だけでなく、ワークロード受け入れテストを通じて採用されるべきである。
真のテストは、ワークロードが受け入れられた状態に達するかどうかである
Scaleway SAS は、1 プロバイダーよりも大きな物語を持つ欧州クラウド市場に位置している。政府、規制対象企業、AI ラボ、開発者、プラットフォームチームは、より多くのデジタルインフラを欧州の運用枠組みの中でホスト、管理、復旧できるかどうかを問うている。その問いは理論的ではない。公共調達、健康・金融データ、産業システム、AI モデルトレーニング、ローカルサポート、エグレス経済、法的エクスポージャー、そして顧客から遠く離れた場所でのプラットフォーム決定時にもサービスを継続できる能力に触れている。
しかし、市場の戦略的言語は運用テストを隠すことがある。ワークロードは、クラウドリージョンが欧州であるからといって受け入れられるわけではない。ページに「ソブリン」と書いてあるから受け入れられるわけではない。プロバイダーが GPU を購入し、データセンターを開設し、調達枠組みに参加し、魅力的な価格を公開したからといって受け入れられるわけではない。ワークロードが受け入れられるのは、顧客がそれを繰り返しデプロイし、動作場所を確認し、変更できる者を制御し、プラットフォームの健全性を観測し、データを復旧し、インシデントを処理し、請求を照合し、運用負荷が現行プラットフォームに留まる負荷よりも低いと判断できるようになった時だけである。
この区別は Scaleway にとって極めて重要である。同社は信頼できる欧州クラウドアイデンティティを持ち、多くのローカルホスティングプロバイダーよりも幅広い製品提供面を持つ。Iliad Group の一部であるが、本記事は Iliad のより広範な通信またはデータセンター戦略ではなく、Scaleway SAS と Scaleway 運用プラットフォームに焦点を当てる。Scaleway のクラウド提供は、仮想インスタンス、ベアメタル、Elastic Metal、Kubernetes Kapsule、オブジェクトストレージ、ブロックストレージ、マネージド PostgreSQL と MySQL、マネージド Redis、サーバーレス製品、VPC ネットワーキング、サポートプラン、IAM、Audit Trail、GPU インスタンス、ジェネレーティブ API サービス、AI インフラに及ぶ。これは、単なるニッチなホスティングオプションではなく、本格的な欧州クラウド代替の候補とするに十分な幅である。
候補としての地位は、問題を決着させるものではない。Scaleway は、受け入れられた欧州クラウドワークロードによって判断されなければならない。つまり、バイヤーは実践的な問いを立てるべきである：このプロバイダーは、クラウドまたは AI ワークロードを、政治的に魅力的であるだけでなく、エンジニアリング、セキュリティ、財務、運用によって技術的に受け入れられた欧州インフラ状態へと移行させることができるか？答えは有益な意味で混在している。Scaleway は多くの正しい要素を示している。しかし、真剣なバイヤーが見過ごすべきでないいくつかの限界も露わにしている。
要素はリアルである。Scaleway は、パリ、アムステルダム、ワルシャワ、ミラノのリージョンとアベイラビリティゾーンを文書化している。製品可用性ガイダンスを公開している。共有および専用ティアを備えたマネージド Kubernetes コントロールプレーンオファーを持っている。サポート対象エンドポイントの IAM ポリシーと Audit Trail ロギングを公開している。欧州データセンターと、表示価格に含まれるエグレスについての公的表明とともに、ストレージやアタッチされたパブリック IPv4 などの除外事項を明記した上で仮想インスタンスを販売している。NVIDIA H100 オプションを中心に構築された GPU インフラを提供しており、パリとワルシャワでのデプロイを説明する公式ページや、より大型の H100 および B300 シェイプを掲載した価格ページがある。インシデントやメンテナンスを報告するパブリックステータスページを持っている。欧州委員会により、ソブリンクラウド調達枠組みのプロバイダーの一つに指名されている。
限界もリアルである。公開情報源は、顧客のワークロードが要求時に要求された GPU 容量を取得できることを証明しない。Kubernetes のアップグレードが無事であること、データベースの復元が復旧目標を満たすこと、サポートチケットが停止を迅速に解決すること、または、移行されたアプリケーションがエンジニアリング作業、エグレス設計、可観測性、バックアップ、監視、スタッフトレーニングを含めた後にコストが低くなることを証明しない。Scaleway は、バイヤーが受け入れを調達ラベルとしてではなく、測定された運用状態として扱う場合にのみ、真剣な欧州オルタナティブとなり得る。
受け入れには6つの層があり、各層が重要である
受け入れられた欧州クラウドワークロードには6つの層がある。第1に、デプロイ可能でなければならない。プラットフォームは、チームが手動の英雄的行為なしにインフラを再現できるだけの十分なコンピュート、ストレージ、ネットワーク、アイデンティティ、自動化面を必要とする。第2に、配置されなければならない。顧客は、特にプラットフォームを選択する理由が管轄、レイテンシ、または耐障害性である場合に、リージョン、アベイラビリティゾーン、製品可用性を明確に把握する必要がある。第3に、ガバナンスが効いていなければならない。アイデンティティ、アクセスルール、監査ログ、運用ロールは、ワークロードが顧客自身のプロセスによって制御可能でなければならない。
第4に、到達可能で可観測でなければならない。アプリケーションは、トラフィックを受信し、依存関係と通信し、ログとメトリクスを発行し、顧客が行動できる形でステータスを提示する必要がある。第5に、復旧可能でなければならない。ストレージ、データベース、スナップショット、バックアップ、コントロールプレーンの健全性、インシデントワークフローは、単なるリソース作成だけでなく、真のロールバックをサポートしなければならない。第6に、経済的に受け入れられなければならない。顧客は、移行、統合、メンテナンス、トレーニング、サポートコストをカウントした後でも、欧州配置、よりシンプルな価格、サポート、低いロックインが依然として価値があるかどうかを知る必要がある。
Scaleway の公開資料は、6つの層すべての一部をカバーしているが、均等ではない。デプロイ可能層が最も強い。開発者やプラットフォームエンジニアは、認識可能な製品セットを見ることができる：仮想マシン、ベアメタル、Kubernetes、オブジェクトストレージ、データベース、プライベートネットワーキング、パブリックゲートウェイ、ロードバランシング、サーバーレス関数とコンテナ、マネージド推論、API、CLI、Terraform 指向パス。これはハイパースケーラーの全カタログではないが、大規模な Web サービス、内部プラットフォーム、データアプリケーション、推論ワークロード、制御された AI インフラを実行するには十分である。
配置も比較的可視化されているが、製品ごとの確認が必要である。Scaleway の可用性ドキュメントには、パリ、アムステルダム、ワルシャワがそれぞれ3つのアベイラビリティゾーンを持ち、ミラノには新しい第1ゾーンがあると記載されている。一部の製品ページでは、3リージョンに9つのアベイラビリティゾーンという古い簡略表記がまだ見られる。これは致命的な矛盾ではなく、製品可用性が時間とともに変化することを思い出させるものである。顧客は「Scaleway は欧州にある」と言って立ち止まるべきではない。選択した製品が選択したリージョンに存在するか、一般提供か限定か、実際のサービスに対してマルチ AZ 設計がサポートされているか、バックアップやスナップショットのパスが必要な管轄内に留まるかを問うべきである。
ガバナンスは信頼できるが、範囲を定める必要がある。Scaleway の IAM ドキュメントは、組織、プロジェクト、メンバー、グループ、ポリシー、権限セット、プログラム的アクセス用の非人間 IAM アプリケーションについて説明している。その Audit Trail ドキュメントは、サポートされるエンドポイントと認証イベントを列挙している。これにより、プラットフォームには可視的な制御枠組みが与えられる。しかし、バイヤーが気にするすべてのサービスアクションがログに記録されること、ログ保持がバイヤーのポリシーに一致すること、または特権サポートアクセスがセンシティブなワークロードに許容されることを証明するものではない。それらは契約およびテストの事項である。それでも、IAM と Audit Trail の存在は重要である。なぜなら、欧州ワークロードが共有アカウントとインフォーマルなオペレーター信頼によってのみ制御可能であるならば、受け入れられないからである。
到達可能性と可観測性はよりワークロード固有である。Scaleway は VPC、プライベートネットワーク、ルーティング、パブリックゲートウェイ、およびサイト間 VPN パターンを文書化している。一部の製品コンテキストでメトリクスとログ用の Cockpit を提供している。これらは正しいプリミティブである。しかし、顧客の実際の成果は、リージョン、ルート、トラフィックソース、サービスミックス、ファイアウォール設計、DNS、TLS、プロバイダーステータス、およびインシデント中のチームの対応能力に依存する。公開製品ページはそれを証明できない。
復旧は、受け入れが最も困難になる場面である。Scaleway は、ストレージの責任共有、データベースのバックアップとスナップショット、Kubernetes コントロールプレーンの制限、複数のアベイラビリティゾーンまたはリージョンにわたる高可用性ガイダンスを文書化している。また、2026年7月のミラノにおけるオブジェクトストレージ接続問題や、オブジェクトストレージパフォーマンスに関する古い技術的ポストモーテム的資料など、ステータスインシデントを公開している。これは、動作メカニズムと実際の故障モードの両方を示しているため有用である。しかし、復旧は顧客自身のデータに対してテストされなければならない。バックアップポリシーは、復元が実行され計時されるまで受け入れられない。
経済層は最も誤解されやすい。Scaleway の公開価格ストーリーは、ハイパースケーラーの複雑さに不満を抱くバイヤーにとって魅力的である。仮想インスタンスの価格ページでは、欧州データセンター、分かりやすい価格設定、表示価格にエグレス料金が含まれないこと、割引プランが強調される一方で、ストレージとアタッチされたパブリック IPv4 が除外されることも明示されている。業界・ソリューションページでは、価格優位性と予測可能な請求について説明している。しかし、サポートプランでは、Advanced、Business、Enterprise ティアに固定費または支出割合のコストが追加される。GPU、スナップショット、ストレージ、IP、サポート、移行作業、運用ツールが最終的な答えを変え得る。受け入れられた経済性は、低い時間単価の見出しと同じではない。
Scaleway の有用なポジションは、ホスティングの簡素さとハイパースケールの幅広さの間にある
Scaleway が最も興味深いのは、誤った選択を強いられていない時である。単に新しいソブリン用語をまとった古いホスティングプロバイダーではない。また、フランス語訛りの AWS、Azure、Google Cloud でもない。その有用なポジションは両者の間にある：単純なホスティングよりもクラウドネイティブで API 駆動的であり、ハイパースケーラーよりも狭くグローバル支配力が低く、選択されたワークロードに対して欧州の管轄、サポート、コスト期待とより適合する可能性がある。
この中間ポジションは価値があり得る。多くの欧州組織は、あらゆるワークロードにハイパースケーラーの全カタログを必要としない。彼らは、配置や管轄の問いにより直接的に答えられるプロバイダーとともに、コンピュート、コンテナ、データベース、オブジェクトストレージ、プライベートネットワーク、制御された AI 推論または GPU ジョブを実行する場所を必要としている。スタートアップは大きなエグレスのサプライズを避けたいかもしれない。公共団体は、ソブリン性を測定可能な要件として扱う調達経路を必要とするかもしれない。規制対象企業は、センシティブなサブシステムを欧州運用枠組みに留め、よりセンシティブでないシステムを他に残したいかもしれない。プラットフォームチームは、長大なプロプライエタリサービスのリストよりも、Kubernetes と S3 互換ストレージを望むかもしれない。
中間ポジションは居心地が悪いこともある。ハイパースケーラーは、規模だけでなく、マネージドサービスの深さ、エコシステムへの精通、グローバルリージョンカバレッジ、マーケットプレイス統合、ドキュメンテーション量、サードパーティツーリング、トレーニング可用性、パートナー能力によって勝つ。ハイパースケーラーサービスから Scaleway に移行する顧客は、見かけのインフラ節約が台帳の1行に過ぎないことを発見するかもしれない。マネージドキュー、プロプライエタリデータベース、グローバルロードバランシング、可観測性スタック、シークレット管理、アイデンティティ統合、デプロイパイプライン、またはデータサービスを置き換えることは、重大なエンジニアリングプロジェクトになり得る。
したがって、Scaleway の製品セットは、その強みを活かせるワークロードに適合させるべきである。基本的なインフラサービス、コンテナ化されたアプリケーション、欧州 Web プラットフォーム、要件が制御されたデータストア、オブジェクトストレージのユースケース、開発環境、バッチ処理、AI 推論またはファインチューニングジョブ、そして局所性が価値を持つワークロードは、妥当な候補となり得る。深く統合されたハイパースケーラーネイティブシステムは、より注意が必要である。問いは、Scaleway が Linux、Kubernetes、PostgreSQL を実行できるかどうかではない。問いは、ワークロードが密かに依存するようになった周辺のマネージドサービス挙動を置き換えられるかどうかである。
受け入れられたワークロードレンズは、誇張された主張を避ける。Scaleway の欧州アイデンティティは一部のリスクを低減しつつ、いくつかの責任を増大させ得る。地域制御は管轄の曖昧さを減らすが、バックアップ設計を不要にはしない。S3 互換オブジェクトストレージは可搬性を容易にするが、互換性はすべてのツール、権限モデル、ライフサイクルポリシー、または故障モードが AWS 上と全く同じに振る舞うことの保証ではない。Kubernetes Kapsule はコンテナ移行を親しみやすくするが、クラスター設計、ノードプール、ストレージクラス、コントロールプレーンティア、アップグレードポリシーには依然としてエンジニアリングが必要である。GPU アクセスは欧州 AI チームにとって戦略的であり得るが、モデルトレーニングと推論は容量予約、ドライバー管理、データ移動、ネットワーキング、コスト規律に依存する。
これが、Scaleway が政治的答えとしてではなく、ワークロードプラットフォームとして評価されるべき理由である。政治的および調達的文脈は、バイヤーが注目している理由を説明する。運用成果が、彼らが留まるかどうかを決定する。
リージョン配置は、製品可用性が明示されている場合にのみ役立つ
欧州クラウドの採用は、しばしば地図から始まる。Scaleway の地図は、同社の利点の一つである。同社は、パリ、アムステルダム、ワルシャワ、ミラノ周辺に欧州拠点を文書化しており、最近のイタリア拡張は継続的な地域成長を示している。フランス、オランダ、ポーランド、イタリア、またはより広範な欧州配置要件を持つワークロードにとって、それは重要である。欧州ユーザーへのレイテンシを低減し、ローカル調達ナラティブを簡素化し、遠くのグローバルクラウドリージョンに配置するよりも明確な管轄対話を生み出すことができる。
しかし、地図が普遍的な製品保証として読まれると、誤解を招く可能性がある。クラウドリージョンは一つの能力ではない。それはアベイラビリティゾーン、コンピュートタイプ、ストレージサービス、マネージドサービス、ネットワークオプション、サポートプロセス、容量プール、故障ドメインの束である。Scaleway 自身の製品可用性ガイダンスこそ、顧客がマーケティング地図よりも重要視すべき文書である。バイヤーは、どのサービスが意図したリージョンで利用可能か、どのサービスが特定のゾーンに限定されているか、どれが新しく、どれが異なる耐障害性期待を持つかを確認する必要がある。
ミラノはこの問題を示している。Scaleway は欧州拡張の一環としてイタリアに新しいクラウドリージョンを発表したが、製品可用性ガイダンスはミラノの最初のアベイラビリティゾーンを示している。これは有用な成長であり、即時の同等性ではない。顧客は、新しいリージョンを局所性、レイテンシ、市場カバレッジの機会として捉えるべきだが、同時により厳格な受け入れ計画に値するリージョンとしても捉えるべきである。必要なサービスは今利用可能か？容量は十分深いか？マネージドデータベース、Kubernetes、オブジェクトストレージ、VPC、KMS、Audit Trail、その他依存関係はすべて同じ成熟状態にあるか？サービスはリージョン内でマルチ AZ か、あるいはワークロードは単一ゾーンと他でのバックアップに依存しているか？
答えはワークロードごとに異なり得る。ステートレスな Web サービスは、他でフェイルオーバーできるなら新しいリージョンを受け入れられるかもしれない。規制対象データベースは、プライマリデータロケーションとして使用する前により強力な証拠を必要とするかもしれない。GPU トレーニングジョブは、正しいアクセラレータ、ストレージ、ネットワークスループットの即時可用性の方が、リージョンフェイルオーバーよりも重要かもしれない。政府ワークロードは、クラウド主権フレームワーク、サポートアクセス、監査可能性、契約条件を最も重視するかもしれない。
製品可用性はコストとも相互作用する。あるゾーンに存在するが別のゾーンに存在しないサービスは、アーキテクチャ変更を強いる可能性がある。チームは、リージョン間レプリケーション、外部 DNS フェイルオーバー、異なるバックアップ配置、またはハイブリッド設計を必要とするかもしれない。その作業は正当化され得るが、それは経済比較に含まれるべきである。欧州プロバイダーは、顧客の元のアーキテクチャがハイパースケールの地域均一性を仮定していた場合、単価層では安く、統合層では高くなる可能性がある。
実践的な結論は、Scaleway のリージョンストーリーは近道ではなく、意味のある利点であるということだ。それはバイヤーが欧州運用ターゲットを定義するのを助ける。選択した場所での製品可用性、容量、故障ドメイン、復旧動作を証明する必要性を取り除くものではない。
Kapsule がコントロールプレーンを最初の本格的な受け入れテストにする
多くの現代的なワークロードにとって、Scaleway の最初の本格的なテストは Kubernetes Kapsule となる。Kubernetes は、多くのクラウド移行計画が依拠する可搬性の約束である。ワークロードが既にコンテナ化されているなら、欧州のマネージド Kubernetes サービスは移行を単純化するように見えるかもしれない。実際には、Kubernetes は難しい問いを排除するのではなく、移動させる。クラスターのコントロールプレーン、ノードプール、ストレージクラス、イングレス、ネットワーキング、シークレット、ログ、メトリクス、オートスケーリング、アップグレードポリシーがすべて受け入れ基準となる。
Scaleway の Kubernetes ドキュメントは、バイヤーに有用な詳細を提供する。Kapsule と Kosmos はマネージド Kubernetes 製品であり、Kapsule は Scaleway インスタンスで構成され、Kosmos はマネージドコントロールプレーンの下のマルチクラウドノード向けに設計されている。Scaleway は、Kubernetes コントロールプレーンとコアコンポーネントを管理すると述べている。共有および専用コントロールプレーンティアを提供している。コントロールプレーンオファーのドキュメントには、API サーバーの可用性、etcd の可用性、SLA、監査ログ、最大クラスターサイズ、etcd サイズの違いが記載されている。共有コントロールプレーンはその表に SLA が記載されておらず、専用コントロールプレーンは 99.5% のアップタイム、高可用性のための2つの API サーバーレプリカ、マルチ AZ etcd レプリカ、監査ログ、より大きなクラスターサイズ、より高い etcd 制限が記載されている。
その詳細は、一般的な Kubernetes の約束を設計判断に変えるため重要である。開発クラスター、小規模な内部ツール、または非クリティカルなサービスは、共有コントロールプレーンを受け入れられるかもしれない。本格的な本番アプリケーションは専用コントロールプレーンを必要とし、それに伴い30日間のコミットメント期間と、移行計画に含まれなければならないコストプロファイルが必要となる。Scaleway のドキュメントはまた、頻繁なコントロールプレーンの変更が互換性問題やサービス中断を引き起こす可能性があること、およびコミットメント期間中のダウングレードが制限されることを警告している。これは弱点ではなく、可視化された運用上の現実である。
etcd の制限はもう一つの受け入れポイントである。Kubernetes の障害はしばしばアプリケーションの不安定性として現れるが、その根本原因はコントロールプレーンの状態増大、不適切に管理されたカスタムリソース、過剰なイベント、または誤動作するコントローラーであるかもしれない。Scaleway が文書化した共有および専用の etcd サイズ制限は、プラットフォームチームが意図的にコントロールプレーンのサイズを計画することを求める。複雑なオペレーター、サービスメッシュ、多数のシークレット、または重いカスタムリソースを実行するクラスターは、最小ティアが安全であると仮定すべきではない。
Kapsule の FAQ には、状態に関する貴重な警告も含まれている。それはノードをステートレスと説明し、状態を必要とするアプリケーションは永続ボリュームを使用すべきと述べている。これは通常の Kubernetes の教義だが、移行時に重要になる。マネージドハイパースケーラー Kubernetes プラットフォームから移行するチームは、ストレージクラス、ボリューム動作、バックアップ統合、ノード置換、オートスケーリング、イングレス動作、プライベートネットワーキング、IAM マッピング、可観測性をチェックしなければならない。Kubernetes 設定が適用されるという事実だけでは不十分である。受け入れられた状態とは、全運用ループである。
ここで、顧客が規律正しければ Scaleway は強みを発揮できる。Kapsule は欧州のマネージド Kubernetes ターゲットを提供し、Scaleway のドキュメントは証明を構成するのに十分具体的である。クラスターを作成する。共有または専用のコントロールプレーンを意図的に選択する。代表的なサービスをデプロイする。オートスケーリングをテストする。永続ボリュームをアタッチする。ノードプールをアップグレードする。ポッドの再スケジュールを強制する。イメージプル、イングレス、DNS、証明書の処理を測定する。監査ログをチェックする。状態を復元する。課金を観測する。これらのタスクが再現可能になれば、Scaleway は信頼できるワークロード受け入れストーリーを持つ。それらが手動の回避策に依存しているなら、ソブリン性の利点は運用上の脆弱性を補償しない。
ストレージとデータが、障害を生き残る受け入れを決定する
コンピュートは可視的であるため過度に強調されがちである。クラウドの受け入れが通常容赦なくなるのはストレージである。データを復旧できない欧州ワークロードは、コンピュートがどこで実行されていようと受け入れられない。Scaleway のストレージストーリーには、Amazon S3 プロトコルに基づくオブジェクトストレージ、ブロックストレージ、ファイルストレージ、データベースストレージ、スナップショット、バックアップ機能、責任共有ドキュメントが含まれる。それは深刻なプリミティブセットだが、各々はワークロードの復旧要件とコンプライアンス要件にマッピングされなければならない。
オブジェクトストレージは、より可搬性の高いピースの一つである。Scaleway のドキュメントは、オブジェクトストレージが Amazon S3 プロトコルに基づいており、Amazon S3 互換クライアント、ツール、API を通じて使用可能であると説明している。設定例において、パリ、アムステルダム、ワルシャワ、ミラノなどのリージョンを挙げている。これは、既に S3 互換ツールを使用しているバックアップ、メディア、アーティファクト、ログ、データレイク、アプリケーションオブジェクトの実際の移行パスをサポートする。また、顧客がすべてのオブジェクトクライアントを書き直す必要がないかもしれないため、ローカルクラウドへの置き換えを容易にする。
しかし、互換性を同等性として扱うべきではない。S3 互換ストレージは、IAM マッピング、バケットポリシー、ライフサイクル動作、パフォーマンス、一貫性のエッジケース、暗号化オプション、イベンティング、ツールサポート、リージョン障害動作において異なり得る。顧客は、自身が使用する正確なクライアントライブラリとオペレーションをテストすべきである：マルチパートアップロード、署名付き URL、ライフサイクルルール、関連する場合はオブジェクトロック、暗号化、削除、大規模下でのリスト表示、バックアップツールの復元、アクセスポリシーの強制。受け入れられた状態は「API が見慣れている」ではない。それは「アプリケーションと復旧ワークフローが正しく動作する」である。
Scaleway のステータス履歴と過去のオブジェクトストレージパフォーマンスブログも、議論を正直に保つ。公開ステータスページはインシデントを報告しており、2026年7月のミラノでのルーティング問題によるオブジェクトストレージ接続問題を含む。また、Scaleway は以前、マルチ AZ ストレージ移行中のオブジェクトストレージパフォーマンス劣化に関する技術的アカウントを公開した。インシデントがプロバイダーの資格を剥奪するわけではない。どのクラウドにもインシデントはある。重要なのは、顧客が影響を理解し、影響を受けたサービスを隔離し、障害を迂回し、データを復旧し、プロバイダーに説明責任を負わせる能力である。
マネージドデータベースは別の層を追加する。Scaleway は、高可用性、データレプリケーション、自動バックアップ、スケーリング、監視、スナップショットを備えたマネージド PostgreSQL と MySQL を文書化している。これは、自己管理データベース VM よりも多くの通常のアプリケーションに適している。しかし、マネージドデータベースは、フェイルオーバー、バックアップ、復元、アップグレード、アクセス制御がテストされた後にのみ受け入れられる。データベースが目標復旧時点と目標復旧時間を満たさなければならない場合、バイヤーは機能リストだけでなく、実際の復元からの証拠を必要とする。
責任共有モデルも重要である。Scaleway のストレージ責任ドキュメントは、可用性、バックアップ、設定、セキュリティ対策に関するプロバイダーの義務と顧客の義務を分離している。これはまさにクラウドバイヤーがよく間違える点である。彼らは「マネージド」があらゆるデータ損失や誤設定シナリオがプロバイダーに属することを意味すると仮定する。実際には、顧客は依然としてデータ分類、アクセスポリシー、バックアップ設計、保持、復元テスト、暗号化選択、アプリケーションの一貫性、削除規律を所有している。欧州クラウドはそれを変えない。
ストレージの結論はシンプルである：Scaleway は、深刻な欧州データ状態を設計するのに十分なプリミティブをバイヤーに提供する。それは復旧動作を証明する必要性を取り除かない。ワークロードは、顧客が制御された訓練でコンポーネントを削除、破損、または喪失させ、ビジネス許容範囲内で復旧できる場合にのみ受け入れられる。
GPU 容量は、スケジュール可能なインフラになった時のみ価値を持つ
Scaleway の AI インフラストーリーは、欧州が地域 AI 容量を求めているため注目を集める。公開資料には、H100 GPU インスタンス、より大型の H100 SXM シェイプ、B300 参照、GPU クラスター、ジェネレーティブ API、専用デプロイメント、マネージド推論がジェネレーティブ API - 専用デプロイメントに改名されたもの、NVIDIA エコシステム内の関係が含まれる。NVIDIA 自身のブログは、Scaleway の Nabuchodonosor システムを、フランス内外のスタートアップが AI ワークロードをスケールするのを支援する 127 基の DGX H100 システムを備えた NVIDIA DGX SuperPOD と説明した。Scaleway の製品ページは、パリとワルシャワの H100 PCIe インスタンス、GPU あたり 80 GB メモリ、高帯域幅ネットワーキング、シングルからマルチ GPU 構成までのオプションを説明している。
これは重要である。欧州 AI チームは、しばしばローカルガバナンス要件と最新アクセラレータへの実際的な必要性との間の厳しい選択に直面する。Scaleway が GPU 供給を使用可能なクラウドインフラに変えることができれば、それはコンプライアンスオプション以上のものになる。それは地域の AI 運用能力の一部になる。
しかし、GPU 容量は、マーケティングが最も容易に受け入れを追い越すことができる分野である。顧客はプレスリリース上でモデルを実行しない。適切な GPU タイプ、適切なリージョン、適切なメモリ、ストレージ、ネットワーク、ドライバスタック、クォータ、スケジューリング動作、イメージサポート、コストモデル、サポートパスが必要である。容量がオンデマンドで利用可能か、予約可能か、コミットメントか、キューか、カスタムセールスを通じて販売されているかを知る必要がある。ワークロードがトレーニング、ファインチューニング、バッチ推論、リアルタイム推論、科学シミュレーション、または開発であるかを理解する必要がある。各ユースケースは、プラットフォームに異なるストレスを与える。
Scaleway のジェネレーティブ API ドキュメントは、サーバーレスと専用の動作を分離しているため有用である。それは、99.9% の可用性目標、レート制限、最適化され監視されるが、顧客側のパラメータと共有インフラに依存するために厳密に保証されないパフォーマンスを持つサーバーレス標準およびバッチ処理を説明している。クリティカルなパフォーマンス要件を持つ顧客には専用デプロイメントを指し示している。また、専用デプロイメントは主に推論ワークロードのデプロイと実行のためであり、トレーニングやファインチューニングには別個の GPU インスタンスが必要になるかもしれないと述べている。
その区別は購買判断を形作るべきである。サーバーレス AI API は、実験、プロトタイプ、内部ツール、変動するワークロードに便利であり得る。専用デプロイメントまたは生の GPU インスタンスは、レイテンシ、スループット、プライバシー、コスト、またはモデル制御が重要な場合により適している。受け入れられたワークロードの問いは「Scaleway に AI はあるか？」ではない。「Scaleway の AI 面のどの部分がこのジョブに適合し、繰り返し運用可能か？」である。
GPU の単価経済も通常のコンピュートとは異なる。アイドル容量は高価である。大規模データセットの移動がタイムラインを支配することがある。ドライバとフレームワークの互換性のデバッグがエンジニアリング時間を消費することがある。チェックポインティング、スクラッチストレージ、オブジェクトストレージのスループット、ネットワーク動作が重要である。トレーニングジョブは、ソフトウェア、クォータ、ストレージ、またはプリエンプション類似動作のために数時間後に失敗することがある。推論サービスは、低トラフィックでは安く見え、レプリカ、ウォーム容量、サポートが計画されていなければスケールで高価になり得る。
したがって、Scaleway の AI インフラは、厳格な条件付きの戦略的利点である。それはスケジュール可能なインフラにならなければならない。顧客は、通常のクラウドサービスに使用するのと同じ規律で、GPU ワークロードを予約、プロビジョニング、観測、スケール、復旧、会計処理する必要がある。公開証拠は、本格的な GPU オファリングの存在を支持している。それは顧客固有の容量やパフォーマンスを証明しない。バイヤーは、受け入れを宣言する前に、代表的なモデル、データセット、ランタイム、チェックポイント戦略、コストウィンドウでテストすべきである。
ソブリン性は運用パスの特性であり、スローガンではない
欧州委員会のクラウド調達枠組みは、Scaleway にとって重要な市場シグナルである。2026年4月、委員会は、EU の機関、団体、局、エージェンシーが6年間で最大1.8億ユーロのサービスを調達できるソブリンクラウド入札を落札したと発表した。指名されたプロバイダーには、Post Telecom、OVHcloud、Clever Cloud のパートナーシップ、STACKIT、Scaleway、そして S3NS、Clarence、Mistral のサービスを利用する Proximus 主導のパートナーシップが含まれる。委員会は、この枠組みがソブリン性を、戦略的、法的、運用的、環境的、サプライチェーン、技術的開放性、セキュリティ、EU 法コンプライアンスの目標にわたる測定可能な調達基準に変換したと述べた。
Scaleway にとって、この枠組みへの参加は重要である。それは公的部門や規制対象バイヤーに、同社を評価するより強い理由を与える。また、欧州のクラウド政策が抽象的な選好から測定可能な基準へ向かっていることを示している。委員会は、Scaleway を含むほとんどの落札プロバイダーが、デジタルレジリエンスレベル SEAL-3 に到達し、これはサービス、技術、または運用が非 EU 第三国からのサプライチェーン混乱の影響を受けないことを意味すると述べた。これは通常のマーケティング言語よりも具体的である。
それでも、ソブリン性はワークロード保証ではない。委員会の枠組みは調達と保証のシグナルであり、すべての顧客アプリケーションが適切にアーキテクトされ、手頃で、復旧可能であることの証明ではない。民間バイヤーは、単に委員会の評価を継承し、それが自身のワークロードに関連するすべてのサービス、リージョン、データフロー、サポートアクセス、サブプロセッサー、バックアップロケーションをカバーしていると仮定することはできない。それをデューデリジェンスの出発点として使用すべきである。
Scaleway 自身のソブリンクラウド資料は、いくつかの有用な点で注意深い。それはソブリン性がデータ所在地を超え、誰がどの規則の下でデータにアクセスできるか、どのような顧客制御があるかに関する法的、運用的、技術的条件をカバーすると述べている。地域インフラ、管轄制御、運用制御、アクセス管理、セキュリティとコンプライアンス、可搬性と開放性を強調している。それらは正しいカテゴリーである。同時に、証拠を必要とするカテゴリーでもある。
SecNumCloud も別の例である。Scaleway は、Scaleway Cloud オファリングのための SecNumCloud 認定プロセスを開始し、「J0」マイルストーンを通過し、認定取得を目指していると発表した。また、ISO 27001 および HDS 認証を挙げた。これはポジティブなシグナルだが、認定プロセスのステータスは最終認定と同列に扱われるべきではなく、最終認定でさえも範囲境界がある。顧客は、どの製品、リージョン、サポートプロセスが対象かを問うべきである。
重要なのは運用パスである。データはどこに保存されるか？バックアップはどこに保存されるか？誰がサービスを管理できるか？どの法人が契約に署名するか？どのサブプロセッサーが関与するか？どのサポートチームがメタデータや顧客コンテンツにアクセスできるか？何がログに記録されるか？監査のために何をエクスポートできるか？どの暗号化モードがサポートされるか？ワークロードをプロプライエタリの罠なしに移動できるか？どのインシデントコミットメントが適用されるか？
Scaleway の価値は、これらの問いの多くをより容易に、設計によってより欧州的にできることにある。その弱点は、「ソブリン」という言葉をそれらに答えることの代替として扱う顧客や販売活動である。受け入れられた欧州クラウドワークロードは、ソブリン性がアーキテクチャと運用を通じて証明されることを要求する。
ハイパースケーラーとの比較は、統合コストがカウントされた後に勝敗が決まる
Scaleway の商業的問いは、選択されたサービスにおいてハイパースケーラーより低価格を公開できるかどうかではない。問いは、統合、容量、コンプライアンス、サポート、移行コストをカウントした後に、欧州立地、価格設定、サポートがハイパースケーラーの幅広さに勝るかどうかである。それはより厳しいが、より有用な比較である。
ハイパースケーラーは、バイヤーが理解する面と、しばしば手遅れに発見する面で高価である。エグレス料金、マネージドサービスのスプロール、コミットメント支出、不透明な割引、運用的ロックイン、トレーニング要件、アーキテクチャ依存はすべてコスト高になり得る。Scaleway は、よりシンプルな価格設定、地域サポート、より少ないプロプライエタリ依存、より明確な欧州ガバナンスを求めるチームにアピールできる。その仮想インスタンス価格ページは、表示価格に含まれるエグレスと IPv6 アドレスを強調しつつ、ストレージとアタッチされたパブリック IPv4 を除外している。サポートプランドキュメントはサポートコストを明示する。これらは良い兆候である。隠れた経済性がバイヤーが代替案を探す理由の一つだからである。
逆のリスクは、ハイパースケーラーの幅広さの価値を過小評価することである。ワークロードがマネージドキュー、グローバル CDN、イベントバス、プロプライエタリデータベース、アイデンティティ統合、WAF ルール、可観測性プラットフォーム、キー管理システム、機械学習パイプライン、データウェアハウス、CI/CD 統合を使用している場合、コンピュート層の移行はプロジェクトの最小部分かもしれない。Scaleway は一部のピースの代替を提供し、他は提供しないかもしれない。残りは再構築するか、オープンソースツールで置き換えるか、サードパーティから購入するか、ハイブリッドアーキテクチャに残さなければならない。
統合コストは初期移行だけではない。メンテナンスを通じて継続する。エンジニアはプラットフォームを学ぶ必要がある。ランブックは書き直す必要がある。監視は適応されなければならない。インシデントプレイブックは変更しなければならない。セキュリティレビューはやり直さなければならない。バックアップおよび復旧訓練は再構築しなければならない。調達と財務は新しい請求を照合しなければならない。サポート契約は理解されなければならない。チームがクラウド支出を節約しても、人的オペレーター負荷が増加するなら、ビジネスケースは失敗し得る。
Scaleway の最良の商業的ケースは、おそらくワークロードが既に可搬性を持つ、または顧客が意図的にプロプライエタリ依存を減らしたい場合である。Kubernetes ベースのサービス、Linux VM フリート、S3 互換オブジェクト使用、PostgreSQL または MySQL ワークロード、内部プラットフォーム、開発/テスト環境、地域 Web システム、明確な配置要件を持つ AI 推論ワークロード、ベアメタル隣接アプリケーションが良い候補となり得る。マネージドサービス依存が重いハイパースケーラーネイティブシステムは、より慎重な財務モデリングを必要とする。
サポートも商業比較に含まれる。Scaleway は Basic、Advanced、Business、Enterprise のサポートティアを提供し、固定月額料金またはネット支出の割合に基づく有料プランがある。これは一部のエンタープライズサポート交渉よりも明確であり得るが、それでも総コストを変える。クリティカルなワークロードは、インフラの単価だけを比較することはできない。サポートティア、応答期待、エスカレーションパス、言語、インシデントコミュニケーション、解決を待つ内部スタッフのコストを含めなければならない。
最善の答えは、オールオアナッシングの移行ではないかもしれない。欧州組織は、局所性、可搬性、コスト明確性が最も重要なワークロードに Scaleway を使用し、他のシステムをハイパースケーラーに残すことができる。それは失敗ではない。それはワークロード配置の規律である。Scaleway は、受け入れ可能にできる仕事に選ばれた時に勝ち、グローバルクラウドアカウントの全サービスを置き換える負担を負わされた時に勝つわけではない。
公開ステータス証拠は役立つが、下限として読まれなければならない
Scaleway の公開ステータスページは、マーケティングを超えた運用シグナルを顧客に提供するため有用である。インシデント、更新、コンポーネント状態を報告する。2026年7月、そのページはミラノゾーンにおけるオブジェクトストレージ接続問題を示し、修正が実施され監視中であるルーティング問題と説明された。他のステータス情報源は、同じ時期前後にサーバーレス、データベース、オブジェクトストレージ、Audit Trail、マネージド推論コンポーネントにわたるアクティブまたは最近の問題を観測した。プロバイダー維持のステータスページは完璧ではないが、受け入れ面の一部である。
ステータスの透明性は、厳しすぎても甘すぎても読まれるべきではない。厳しすぎると、バイヤーはあらゆるインシデントを見てプラットフォームが信頼できないと結論するかもしれない。それは非現実的である。すべてのクラウドプロバイダーにインシデントはある。甘すぎると、バイヤーはステータスページが影響と復旧の完全な証明であると仮定するかもしれない。それも非現実的である。ステータスページは遅延し、ローカルな影響を過小評価し、コンポーネントの健全性を顧客体験から分離し、またはプライベートな顧客障害を見逃すことがある。
受け入れられたワークロードは、ステータスを下限として使用すべきである。最低限、プロバイダーはインシデント、影響を受けたコンポーネント、タイムスタンプ、更新、解決ノートを公開すべきである。顧客は更新をサブスクライブし、自身のインシデントプロセスにルーティングし、公開通知を観測されたメトリクスと比較すべきである。公開ページがオブジェクトストレージが劣化していると言えば、顧客は自身のバケット、リージョン、アプリケーションパスが影響を受けているかどうかを知るべきである。ページが修正は監視中と言えば、顧客は再試行すべきか、フェイルオーバーすべきか、待つべきかを知るべきである。
Scaleway の過去のオブジェクトストレージパフォーマンス投稿は、簡潔なインシデントラインを超えているため価値がある。それは、マルチ AZ 標準ストレージの使用増加、サーバー負荷、エラーの増加、一部のリクエストに対する許容できないレイテンシを説明した。その種の運用説明は、故障モードを明らかにするためバイヤーに有用である。ストレージシステムは、完全な停止だけでなく、テールレイテンシ、503 レスポンス、ルーティング問題、過負荷、内部依存効果を通じても故障し得る。復旧を計画する顧客は、これらの部分的な故障に備えて設計すべきである。
ステータス証拠はサポートとも相互作用する。公開インシデントは、顧客がチケットを開く必要性を減らすかもしれないが、すべてのワークロードの問いに答えるわけではない。顧客はサービスリクレジットの資格があるか？サポートプランはコミュニケーションに影響するか？回避策はあるか？データはリスクに晒されているか？リージョンのフェイルオーバーは可能か？将来のメンテナンスウィンドウは予想されるか？アカウントレベルの問題をプロバイダー全体のインシデントから区別できるか？
したがって、Scaleway のステータス面とサポート面は限界を伴うポジティブなシグナルである。それらは、プロバイダーがインシデントコミュニケーションとサポートティアのメカニズムを持っていることを示す。それらはプレッシャー下でのサポートの品質を証明しない。それは、クリティカルなワークロードが受け入れられる前に、非破壊的なサポート演習と契約レビューを通じてテストされなければならない。
実践的な Scaleway 移行は、誰もごまかせないワークロードから始まる
最も安全な Scaleway 採用パスは、パンフレット比較ではなく、代表的なワークロードから始まる。バイヤーは、プラットフォームを試すのに十分重要なサービスを選ぶべきだが、初回接触学習が許容できないリスクを生むほどクリティカルであってはならない。Scaleway が担うと期待される層を含めるべきである：コンピュート、ストレージ、ネットワーク、アイデンティティ、監視、バックアップ、復旧、課金。難しい部分を避けるおもちゃのデプロイであってはならない。
Kubernetes ワークロードでは、テストは意図したコントロールプレーンティアで Kapsule クラスターを作成し、本物のサービスをデプロイし、永続ボリュームをアタッチし、イングレスを設定し、プライベートネットワーキングをテストし、オートスケーリングを実行し、ノードをアップグレードし、ノード損失をシミュレートし、ログを検査し、シークレット動作を確認し、アプリケーション状態を復元すべきである。オブジェクトストレージワークロードでは、現実的なオブジェクトサイズをアップロードおよびダウンロードし、マルチパート操作、署名付き URL、使用する場合はライフサイクルルール、IAM ポリシー動作、バックアップツール互換性、地域フェイルオーバー仮定をテストすべきである。データベースワークロードでは、高可用性、バックアップ、スナップショット、復元、エンジンアップグレード、接続プーリング、メンテナンスウィンドウ、監視をテストすべきである。
AI ワークロードでは、テストはさらに具体的であるべきである。実際のモデルクラス、データセットサイズ、フレームワーク、GPU タイプ、コンテナイメージ、チェックポイント戦略、予想実行時間を選択する。クォータと容量を確認する。ジョブを実行する。プロビジョニング時間、起動、スループット、故障動作、チェックポイント復元、ストレージ移動、最終請求を測定する。意図された使用が推論である場合、コールドスタート、レイテンシ、スループット、レート制限、スケーリング、専用デプロイメント動作をテストする。意図された使用がトレーニングまたはファインチューニングである場合、スクラッチストレージ、オブジェクトストレージスループット、ドライバスタック、中断されたジョブからの復旧を検証する。
バイヤーはガバナンスもテストすべきである。最小権限の IAM ロールを作成する。自動化に非人間アプリケーションを使用する。キーをローテートする。重要なアクションに対する Audit Trail カバレッジを検証する。必要であればログをエクスポートする。セキュリティとコンプライアンスチームがスクリーンショットに頼らずに必要な証拠を得られることを確認する。デプロイ可能だが監査不可能なワークロードは受け入れられない。
復旧は、計画された訓練としてテストされるべきである。ノードを壊す。データベースを復元する。クラスターを再構築する。コードからインフラを再作成する。オブジェクトデータを復元する。トラフィックを移動する。失敗したデプロイから復旧する。誰がステータス更新を受け取るかを確認する。実際のただし緊急ではない質問のサポートチケットを開き、応答を判断する。これらはどれも特殊ではない。クラウド決定を選好から運用コミットメントに変えるために必要な最低限である。
最後に、コストを照合する。通常の使用を見るのに十分な期間ワークロードを実行する。サポートティア、ストレージ、スナップショット、IP アドレス、ネットワーク仮定、GPU アイドル時間、バックアップ保持、監視、スタッフ時間、移行作業を含める。その合計を、置き換えられるハイパースケーラー状態と比較する。この完全な計上後にワークロードがより安価であるか戦略的により安全である場合、Scaleway の商業的ケースは説得力を増す。見かけの節約が統合とオペレーター努力によって消費されるなら、それは弱くなる。
Scaleway は、欧州受け入れがカタログマキシマリズムよりも重要な場所で勝てる
Scaleway に最も適合するのは、欧州受け入れがカタログマキシマリズムよりも重要なワークロードである。これには、欧州におけるデータ所在地、運用管轄、調達保証、可搬性、サポート明確性、コスト透明性、または AI 容量が重要なワークロードが含まれる。既にオープンツールとインフラプリミティブを好むチームが含まれる。ハイパースケーラーエコシステム内ですべての技術決定を行うことを避けたい組織が含まれる。
ワークロードがハイパースケーラーネイティブのマネージドサービス、グローバルフットプリント、成熟したサードパーティマーケットプレイスサポート、特殊なプラットフォーム製品、または大規模なエラスティック容量と不可分である場所では、あまり強くない。Scaleway はこれらの環境でも役割を果たせるかもしれないが、通常は完全な置き換えではなく、ハイブリッドまたはマルチクラウド配置戦略の一部としてである。
このポジションのために、同社は信頼できる資産を持っている。その欧州拠点は管轄とレイテンシの関連性を与える。Kubernetes、オブジェクトストレージ、データベース、ネットワークサービスが、多くのアプリケーションに十分なクラウドネイティブ面を与える。ベアメタルおよび Elastic Metal オプションは、より密接なハードウェア制御を必要とするワークロードに役立つ。GPU と AI インフラは、欧州 AI 容量が乏しい時に戦略的重要性を付与する。委員会調達の役割は公共セクターの信頼性を与える。コントロールプレーン、IAM、Audit Trail、ステータス、サポート、責任共有に関する文書は、バイヤーに有用な運用資料を提供する。
主なリスクは行き過ぎである。Scaleway は、重要であるために完全なハイパースケーラークローンにならなければならないかのように判断されるべきではない。また、欧州アイデンティティ自体が本番エンジニアリングを解決することを示唆することを許されるべきではない。正しい基準はより狭く、より要求が多い：Scaleway は、欧州の運用制約下で選択されたワークロードを受け入れられた状態にできるか？多くの場合、答えはイエスかもしれない。他の場合では、統合コスト、マネージドサービスギャップ、容量制限、または復旧証拠がハイパースケールまたはハイブリッド設計に戻ることを指し示すかもしれない。
その条件付きの答えは弱点ではない。それは、真剣なクラウド配置の仕組みである。市場は、一律のクラウド決定から脱却しつつある。ソブリン性、AI 容量、コスト圧力、規制監視が、バイヤーにワークロードをより注意深く分類するよう促している。あるものはグローバルハイパースケーラーに属する。あるものは欧州プロバイダーに属する。あるものはプライベートインフラに属する。あるものは分割されるべきである。Scaleway の機会は、欧州プロバイダーオプションを、政治的理由だけでなく運用上の理由で選べるほど十分に具体化することである。
最終判断は、信頼できる条件付き受け入れである
Scaleway SAS は、選択されたワークロードに対して信頼できる欧州クラウドおよび AI インフラプロバイダーであるが、「選択された」という言葉が実際の役割を果たす。公開記録は、意味のあるクラウドプリミティブ、欧州リージョン、マネージド Kubernetes、ストレージ、データベース、ネットワーキング、IAM、監査メカニズム、サポートプラン、ステータス報告、GPU インフラを備えたプラットフォームを支持する。また、気にかける明確な市場理由も支持する：欧州の顧客は、管轄、耐障害性、制御、コスト、AI 容量を考慮したワークロード配置をますます必要としている。
同じ公開記録は、盲目的な移行を正当化するのに十分な証明をしない。顧客固有の容量、パフォーマンス、復旧時間、サポート成果、コンプライアンス範囲、完全な製品同等性、または最終経済性を確立していない。それはクラウドプロバイダーにとって珍しいことではない。単に、バイヤーが戦略的整合性と運用上の受け入れを混同すべきでないことを意味する。
受け入れられた欧州クラウドワークロードが正しいテストである。Scaleway がチームにワークロードをデプロイさせ、必要なリージョンに配置し、アクセスを管理し、健全性を観測し、状態を復旧し、サポートを管理し、コストを照合させることができれば、その役割を獲得する。それができなければ、欧州ラベルはデプロイを救わない。ソブリン性は、サービスが依然として機能する場合にのみ重要である。
Scaleway にとって、より強力な証明への道は、測定された運用証拠である：より明確な容量シグナル、リージョンごとの製品成熟度、テストされた復旧パターン、サポートパフォーマンス、ワークロード移行ガイド、透明なインシデントフォローアップ、顧客検証済み経済性。バイヤーにとって、道は規律ある採用である：ワークロードを選び、受け入れを定義し、各層をテストし、全コストをカウントする。
Scaleway は、戦略的に重要であるために至る所でハイパースケーラーを打ち負かす必要はない。十分な数の欧州ワークロードを退屈なほどデプロイ可能、管理可能、復旧可能にして、バイヤーがその決定を信仰の跳躍として扱わずに選択できるようにする必要がある。利用可能な証拠に基づけば、それはもっともで価値のある命題である。負担は、ワークロードごとにそれを証明することである。