Summary

  • TEMPLE Cloud Temple SAS は、可視性のあるフランスのソブリンクラウド事業にマッピングされています。Cloud Temple の公開ページには、規制対象セクター向けに、SecNumCloud 認定の IaaS、VMware IaaS、OpenSource IaaS、オブジェクトストレージ、ベアメタル、VPC、プライベートバックボーン、ハウジング、およびサポートサービスが記載されています。
  • 公式のコンプライアンスページでは、IaaS Secure Temple の範囲が VMware IaaS、OpenSource IaaS、S3 オブジェクトストレージ、HSM-KMS 暗号化、ベアメタルをカバーし、SecNumCloud v3.2 の有効性が 2028年5月30日までと記載されています。同ページでは PaaS OpenShift は別途記載されています。
  • パブリックルーティングは実在し、最新です。RIPEstat は、2026年7月12日に AS33930 が 6 つの IPv4 プレフィックスと 2 つの IPv6 プレフィックスで広告され、チェックされたビューで完全な RPKI 有効オリジン結果が得られ、広範な RIS 可視性があることを示しました。
  • リスクは、プロバイダーが公開運用証拠を欠いていることではなく、認定、AS の可視性、製品ラベルが、特定のワークロードを保護するラック、アベイラビリティゾーン、復旧パス、サポート階層、または退出プロセスを正確に顧客に伝えていない点にあります。
  • 購入者は、Cloud Temple の公開証拠をデューデリジェンスの強力な出発点として扱い、重要システムを移行する前に、ワークロードの配置、サポートエスカレーション、ハードウェアの可用性、リストアテスト、顧客回線の責任、課金への影響、データポータビリティの制限を確認する必要があります。

TEMPLE Cloud Temple SAS は、ディレクトリカードではシンプルに見えても、顧客が実際に何が機能する必要があるのかを尋ねた途端に複雑になるタイプのクラウド企業です。その名前は、可視的なフランスのオフィス、コンプライアンス主張、ルーティングされた自律システム、公開サポート提供、公式ステータスページ、そしてコンピュート、ストレージ、ネットワーク、物理ホスティング、責任境界を記述した技術文書を持つ、ソブリンクラウドプロバイダーを指し示しています。それだけでは、弱い運営状況という見方を退けるのに十分ですが、すべての可用性や主権の主張を自己実行型として扱うには不十分です。同社はホスト型キャパシティを販売していますが、そのキャパシティは依然として実際の施設スペース、電力、ケーブル配線、経路選択、ベンダープラットフォーム、サポート要員、顧客設定、リストアテスト、契約条件に依存しています。

同社の「私たちについて」ページは、Cloud Temple を機密性の高いセクターに位置づけ、産業、金融、ヘルスケア、公共セクターを、その約束が重要となる市場として挙げています。ロケーションページには、パリ/ラ・デファンス、リヨン、トゥール、カーン、ナントのオフィスが記載されており、パリ/ラ・デファンスの住所は Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux です。これは有用なアイデンティティ証拠ですが、オフィスマップはインフラマップではありません。購入者は、オフィスの住所を、仮想マシン、ベアメタルブレード、S3 バケット、VPC ゲートウェイ、または物理ラックが稼働しているサイトと混同してはなりません。

より強力な公開証拠は、コンプライアンスと製品のフットプリントです。Cloud Temple のコンプライアンス手続きページには、同社がインフラに関する ISO 27001 認証を 2018 年から、マネージドサービスに関する認証を 2022 年から取得し、医療データ活動に関する HDS 認証、SecNumCloud v3.2 認定、ISAE 3402 報告書、その他の欧州コンプライアンス項目を有していると記載されています。同ページでは、最も具体的な範囲声明として、「IaaS Secure Temple」が SecNumCloud v3.2 の下で 2028年5月30日まで有効と記載され、脚注にはその範囲に VMware IaaS、OpenSource IaaS、S3 オブジェクトストレージ、HSM-KMS 暗号化、ベアメタルが含まれるとあります。これにより、すべての製品が同一になるわけではありませんが、主要なインフラ製品が公開認定範囲内に位置づけられます。

Cloud Temple のSecNumCloud アプローチページでは、クラウドは企業や公的機関の信頼を保護すべきであり、製品設計は厳格な欧州セキュリティ基準に沿うべきであると戦略的に説いています。また、認定は 700 以上の ANSSI 要件と、技術、物理、契約、運用の各分野にわたるベストプラクティスへの準拠を意味するとしています。この声明は、サイバー管理よりも明示的に幅広いため、インフラリスクにとって重要です。プロバイダーの運営方法に関するものです。しかし、幅広い認定であっても、顧客ごとのアーキテクチャ文書ではありません。病院、保険会社、公共機関、産業クライアントに対し、自社テナントが 2 つのコンピュートホストを有しているか、どのアベイラビリティゾーンがパッシブコピーを保持しているか、ファイアウォールの変更が現在のサポート階層でカバーされるかどうかを伝えるものではありません。

製品ラインは、これらの詳細がなぜ重要なのかを示しています。Cloud Temple のコンピュート提供は、複数の消費パターンに及びます。公開サイトでは、ソブリンプラットフォーム上の仮想化インフラ向けのOpenSource IaaS、認定クラウド環境での VMware 環境向けのVMware IaaS、専用物理サーバー向けのベアメタル、より共有型のクラウドスタイルの仮想マシンとしてプレビュー中の VM インスタンスが説明されています。同社の OpenSource IaaS の公開ドキュメントには、Cisco UCS コンピュート、IBM Spectrum Virtualize と IBM FlashSystem ブロックストレージ、Dell ECS オブジェクトストレージ、Juniper ネットワーキング、専用コンピュートブレードとストレージボリューム、月額消費料金、リージョンとアベイラビリティゾーンの概念、バックアップ、レプリケーションオプション、API または Terraform 操作が記載されています。これは軽量なホスティングカタログではなく、物理的かつ運用上のスタックです。

このスタックには特定の意味があります。導入済みキャパシティと使用可能キャパシティは同じではありません。ページにはブレードクラス、ストレージクラス、接続性の数値が表示されていても、顧客は依然として、希望するリージョンでそのクラスが利用可能か、別のホストを追加するにはハードウェア在庫が必要か、GPU ブレードにはリードタイムがあるか、第 2 アベイラビリティゾーンのストレージパフォーマンスが一致するか、顧客のライセンスでライブフェイルオーバーが許可されるか、といったことを確認する必要があります。Cloud Temple の OpenSource IaaS の概念リストには、ECO から PERFORMANCE 4 までのブレードクラスが、メモリ、コア数、10 Gbit/s または 25 Gbit/s の接続性、そして最上位クラスでは 2024年5月1日時点の NVIDIA L40S GPU とともに記載されています。これは有用な詳細ですが、キャパシティは抽象的ではなく、有限の在庫を持つ特定のハードウェアファミリによって提供されることを購入者に示しています。

ベアメタルは、この点をより鮮明にします。ベアメタルのドキュメントには、分散ブロックストレージに接続された専用物理サーバー、Cisco UCS ブレード、IBM Spectrum Virtualize ストレージ、アベイラビリティゾーン配置、KVM スタイルのコンソールアクセス、ISO マッピング、電源操作、VLAN タギング、および速度がブレードクラスに依存する 2 つのネットワークインターフェイスが記載されています。この製品が魅力的なのは、まさに顧客にオペレーティング環境のより多くの制御を提供するからです。しかし、その制御は一部のリスクを顧客に押し戻します。顧客が独自のハイパーバイザーやオペレーティングシステムをインストールする場合、Cloud Temple はブレード、ストレージ、プラットフォームアクセスを提供できますが、ハードウェアを回復力のあるアプリケーションに変える選択肢は依然として顧客が所有することになります。

VMware 側でも同様の緊張があります。Cloud Temple の VMware IaaS の資料では、専用ブレード、ストレージ、ネットワークリソース、vSphere 互換性、L2 VLAN、アベイラビリティゾーン間伝播、ドキュメント上のビューでのゾーン内レイテンシ 3 ms 未満、ゾーン間レイテンシ 5 ms 未満、および必要なホスト設計を備えたクラスタでのみ機能する高可用性が説明されています。公開ドキュメントには、アベイラビリティゾーンに 1 つのハイパーバイザーしか含まれない場合、別のハイパーバイザーでの自動再起動は不可能であると記載されています。これは、クラウドの約束をエンジニアリングの現実に変える種類の一文です。顧客は、認定プロバイダーからインフラを購入しても、誤った構成を選択したり、第 2 ノードを延期したりすると、脆弱なシングルホスト環境を構築する可能性があります。

ストレージも精度が必要です。Cloud Temple の公開オブジェクトストレージページでは、サービスが Dell Elastic Cloud Storage に基づき、高い S3 互換性を提供し、SecNumCloud 認定、HDS および ISO 27001 認証を取得し、3 つのアベイラビリティゾーンに自動レプリケーションされ、EC 12+4 イレージャーコーディングを使用し、TLS 1.2/1.3 とサーバーサイド暗号化オプションをサポートし、99.99% の可用性と 99.999999999% の耐久性を謳い、エグレス料金が無料であると宣伝されています。これらは、バックアップ、アーカイブ、アプリケーションストレージの購入者にとって重要な主張です。それでも、ライフサイクル、不変性、キー、復旧ポリシーを設定するという顧客自身の責任にマッピングする必要があります。3 ゾーンオブジェクトストレージはプラットフォームの耐久性に役立ちますが、それ自体では、ランサムウェア、誤削除、不適切な保持設計、アクセスキーの侵害後に、顧客が適切なオブジェクトバージョンを復元できることを証明するものではありません。

責任分担は隠されていません。Cloud Temple の共有責任ページでは、IaaS、VM インスタンス、オブジェクトストレージ、ネットワーク、その他のサービスに関する RACI マトリックスを参照するよう案内しています。IaaS 責任マトリックスでは、Cloud Temple が物理データセンター、コンピュートインフラ、ストレージインフラ、バックボーン接続、必須プラットフォームソフトウェアライセンス、ベースラインテナント構成、初回バックアップセットアップの実装について責任と説明責任を負うとしています。また、顧客は、全体アーキテクチャ、テナント数、アベイラビリティゾーン数、継続性および復旧戦略、コンピュート、ストレージ、ネットワーク、バックアップのサイジング、仮想マシンの作成と保守、各 VM と一貫性のあるバックアップおよび復旧計画の関連付け、定期的なバックアップと復旧テストの実施について責任と説明責任を負うとしています。

この区分は、おそらく記録全体で最も重要な事実です。これは、同社が認定インフラプロバイダーでありながら、重要な設計判断を顧客に委ねていることを意味します。顧客がテナントのサイズを過小評価したり、バックアップテストを省略したり、ワークロードをゾーン全体に分散しなかったり、壊れたファイアウォールルールを維持したり、管理者アクセスを失ったり、他の点では回復力のあるプラットフォーム内で単一のアプリケーションノードを維持したりした場合、障害は単純なプロバイダー障害のようには動作しません。それは、プロバイダーのコミットメントでカバーされるのは一部のレイヤーのみである、共同アーキテクチャ障害となります。したがって、この記事のリスク問題は「TEMPLE Cloud Temple SAS は本物のクラウド企業か？」ではありません。答えはイエスです。問題は「この顧客システムのどの部分が Cloud Temple の説明責任範囲内にあり、どの部分がまだ顧客自身の設計に委ねられているのか？」です。

ネットワーキングでも同じ分担が見られます。Cloud Temple のプライベートバックボーンのドキュメントでは、この製品がアベイラビリティゾーン間の L2 VPLS プライベートネットワーク、プライベートインターネットアクセスコンポーネント、IP アドレッシング、ネイティブの Anti-DDoS 保護、外部接続用ポート、1G/10G 回線、専用回線製品向けの 2 つの多様化された光パス上のプライベートリンクを提供するとされています。インターネットの概念ページでは、Cloud Temple が独自の AS を運用し、2 つのトランジットパスと 2 つのパリのエクスチェンジポイントを提供し、BGP4 をサポートし、パブリック IPv4 をユニット単位で、IPv6 プレフィックスを提供し、インターネット帯域幅を 100 Mbit/s 単位で予約し、ボリュームエグレスではなく 95 パーセンタイルベースで課金するとしています。これらは装飾的な主張ではなく、重要なネットワーク設計の事実です。

しかし、ここでも境界が重要です。ネットワーク責任マトリックスでは、顧客は、物理的な Cloud Temple データセンターにアクセスするための事業者接続を契約し、顧客自身の事業者リンク上のインシデント、問題、キャパシティを管理する責任と説明責任を負うとされています。Cloud Temple は、バックボーン、集約ポイント、データセンター相互接続ポイントに責任を負い、物理ハウジングについてはトップオブラック機器から責任を開始します。この境界こそが、多くのインシデントが厄介になる場所です。ワークロードは Cloud Temple 内で健全であっても、顧客サイトはエンタープライズ MPLS リンク、キャリアアクセス回線、不適切な IPsec 変更、ローカルファイアウォール、DNS ミス、または顧客側のキャパシティ制限によって依然として障害が発生する可能性があります。

公開ルーティング証拠は、同社が実際のネットワークを運用しているという考えを裏付けています。AS33930の RIPE RDAP では、CLOUD-TEMPLE という名前で、登録エンティティとして Cloud Temple SAS が記載され、組織の住所は Le Belvedere, 1 Cours Valmy, 92800 Puteaux となっています。RIPEstat のAS 概要では、保有者が CLOUD-TEMPLE Cloud Temple SAS と識別され、2026年7月12日のクエリ時点で AS が広告されていることが示されました。RIPEstat の広告プレフィックスビューでは、2026年7月12日に終了するウィンドウで、91.223.207.0/24、45.15.212.0/22、185.56.204.0/22、194.6.240.0/24、93.187.40.0/21、80.75.152.0/21、2a02:668::/36、2a02:668:9000::/36 の 8 つのアクティブな広告が示されました。

このルーティング記録は、マーケティングのみのフットプリントよりも強力です。RIPEstat のルーティングステータスビューでは、6 つの IPv4 プレフィックス、2 つの IPv6 プレフィックス、6,656 の広告 IPv4 アドレス、8,192 の IPv6 /48、54 の監視対象ネイバー、チェックされたスナップショットでのほぼ完全な RIS 可視性が示されました。RIPEstat のルーティング一貫性ビューでは、広告された AS33930 プレフィックスが BGP と RIPE 経路ポリシーソースの両方に存在し、チェックされた出力に不整合なプレフィックスリストはありませんでした。RPKI 検証では、チェックされた 8 つの AS33930 プレフィックス-オリジンペアに対して「有効」が返されました。これらの事実は、特定のサービスがどの程度冗長化されているかを顧客に伝えるものではありませんが、ネットワーク層が可視化され、維持されており、単なるレガシーの残存物ではないことを示しています。

トランジットとピアリングの証拠も有用ですが、慎重に読む必要があります。AS33930 の RIPE RDAP の備考には、ピアリングリクエスト、France-IX、Equinix Paris のエクスチェンジ詳細が記載されています。PeeringDB のCloud Temple ネットワークページでは、ネットワーク名が Cloud Temple とされ、Cloud Temple の旧称 Intrinsec、オープンな一般ピアリングポリシー、2025年4月の更新日が記載されています。PeeringDB の公開エクスチェンジビューでは、France-IX Paris と Equinix Paris IX のエントリが 10 Gbit/s で表示され、ファシリティビューでは、Telehouse Paris 2、Telehouse Paris 3、Equinix PA6、Digital Realty Paris PAR7、DATA4 Paris Marcoussis - PAR1 がネットワークプロファイルに関連付けられたファシリティとしてリストされています。これはパリ市場での相互接続を裏付けていますが、それでも公開ピアリングプロファイルであり、顧客ワークロード配置の拘束力のあるマップではありません。

公開ステータスページは別の角度を追加します。Cloud Temple のステータスページでは、FR1 の下にコンポーネントが公開されており、PA6、PAR7、TH3、PAR7S、TH3S、AZ07 などの AZ ラベルや、OpenIaaS、Object Storage、PaaS OpenShift、Bare Metal、VPC、エッジサービス、パブリックインターフェイスなどのカテゴリが含まれています。ステータスページは、顧客にインシデントやメンテナンスを監視するための公開の場を提供するため価値があります。しかし、それだけでは、この顧客が実際にどのアベイラビリティゾーン、サービス、コンポーネントを使用しているのか、また、そのうちの 1 つが劣化した場合に顧客自身のアプリケーションが存続するのかという、より深い疑問には答えられません。

製品ラインを 1 つのシステムとして読むと、障害パスがより明確になります。ラックやファシリティの障害は、配置に応じてコンピュート、ストレージ、ネットワーク、ハウジングに異なる影響を与えます。アップストリームや経路の障害は、BGP 設計に応じてインターネット向けサービス、顧客プレフィックス、VPN アクセス、サポートの可視性に異なる影響を与えます。ハードウェア在庫の障害は、ベアメタル、GPU ブレード、ストレージ拡張、ファイアウォールアプライアンス、交換用ホストにとって重要です。サポートの障害は、Standard、Premium、Company の各階層で異なる影響を与えます。課金や注文の障害は、プロビジョニングや拡張を遅延させる可能性があります。移行の障害は、プラットフォームが健全であってもワークロードを立ち往生させる可能性があります。これらのリスクのどれも、プロバイダーが弱いことを意味しません。それらは、クラウド契約が魔法の抽象化ではなく、インフラストラクチャとして読まれる必要があることを意味します。

サポート条件はそのインフラの一部です。Cloud Temple のサポートレベルページでは、Standard、Premium、Company のサポートが、サービス課金の 5%、7%、10% の月額料金、最低月額課金レベル、異なるテクニカルアカウントマネージャーアクセス、P1 レスポンス目標が 2 時間、30 分、15 分、クラウドインシデントに対する 24 時間 365 日の監視と介入とともにリストされています。また、エンジニアはクラウドインシデントに対して 24 時間 365 日対応可能である一方、サポートリクエストは営業時間内のチャネルで、フランス語と英語でのフランス拠点のサポートが提供されるとしています。この違いは重要です。Cloud Temple が責任を負う本番インシデントは、一般的な支援リクエスト、顧客側の設定変更、移行計画の質問、カタログ外のタスクのリクエストと同じではありません。

サポートページはまた、Cloud Temple が責任を負う本番影響のあるインシデントについて、責任マトリックスに戻ります。その但し書きは実際には小さな文字ではありません。顧客の VM がハイパーバイザーレイヤーでは稼働していても、ゲストオペレーティングシステムが壊れているためにアプリケーションがダウンしている場合、サポートパスは変わります。顧客の VPC が健全でも、オンプレミスのキャリア回線がダウンしている場合、サポートパスは変わります。バックアップが存在しても、顧客がリストアテストを一度も実行していない場合、サポートパスは変わります。優れたサポートはこれらのすべてのケースに役立ちますが、契約の境界と有料階層が速度、チャネル、説明責任を決定します。

公開されている SLA 文書は、数字で同じことを示しています。VM インスタンス SLAでは、アクティブな課金対象 VM インスタンスごとに月間 99.95% の可用性コミットメントが定義されており、許容される月間非可用性は 21.9 分に相当します。しかし、非可用性は基盤となる Cloud Temple インフラレイヤーで測定され、ゲスト OS、顧客ソフトウェア、顧客ネットワーク構成、アプリケーション障害、計画メンテナンス、欠如した管理コンポーネント、不正行為、不可抗力を除外し、サービスクレジットを請求するには 30 暦日以内のサポートチケットが必要です。これは通常のクラウド構造であり、同時に警告でもあります。SLA はアプリケーションのアップタイム保証ではありません。

VPC SLAも同様に具体的です。VPC データプレーンには月間 99.99%、コントロールプレーンには 99.9% の可用性が提供され、カウントされる非可用性の閾値は 5 分です。ルーター、プライベートネットワーク、外部ゲートウェイ、NAT、DNAT、フローティング IP など、Cloud Temple が管理する VPC コンポーネントがカバーされます。顧客のフィルタリングルール、不適切なアドレッシング、接続されたコンピュートの障害、Cloud Temple の境界を超えた外部インターネット接続、計画メンテナンス、不正行為、不可抗力は除外されます。これらの除外は文書の欠陥ではなく、実際の運用境界がどのように引かれているかを示すものです。

オブジェクトストレージには、異なる退出と復旧のプロファイルがあります。公開製品ページでは、顧客は S3 互換アクセスを通じてオブジェクトを復旧でき、Cloud Temple はエグレス料金を請求しないとされています。S3 責任マトリックスでは、Cloud Temple は S3 プラットフォームの維持とセキュリティ、サービスへのアクセス、ログ、監視、インシデント、問題、キャパシティ、サービス変更に責任を負うとしています。顧客は、オブジェクトの作成、アクセスキーの作成、オブジェクトライフサイクルの管理、オブジェクト権限の管理、論理セキュリティの管理、データのバックアップ、定期的な復旧テスト、アプリケーション継続性計画、可逆性の実行に責任を負うとしています。つまり、エグレス料金が無料であることは有用ですが、ポータビリティには依然として顧客の計画、認証情報、帯域幅、保持ロジック、テスト済みの宛先が必要です。

移行は、ホスト型キャパシティがしばしば真のコストを明らかにする場面です。Cloud Temple の製品は、VMware 環境、S3 アクセス、OpenStack スタイルの OpenSource IaaS、API ベースの操作、Terraform ベースのプロビジョニング、顧客プレフィックス用の BGP など、馴染みのあるエコシステムと明示的に互換性があります。これらは相互運用性のシグナルであり、クローズドなプロプライエタリスタックと比較してロックインを低減します。しかし、プラットフォームからの移行は依然としてプロジェクトです。サーバーイメージ、ストレージボリューム、オブジェクトバケット、ファイアウォールルール、アクセス権、ルーティング、キー、DNS、監視、サポート契約、ロールバックウィンドウのすべてが整う必要があります。IaaS RACI では、顧客は可逆性の計画、ターゲットインフラの選択、移行操作の実行、移行中のサービス品質影響の管理に責任を負い、Cloud Temple は契約終了後の構成解除と安全な消去を処理するとしています。

課金と発注は副次的な問題ではありません。サポートページでは、リソースがプロビジョニングされると最低サポート課金が開始されるとしています。ネットワークドキュメントでは、パブリック IPv4 アドレスは利用可能在庫内で提供され、インターネット帯域幅は 100 Mbit/s 単位で予約され、プライベート回線には 36 か月のコミットメントが伴う場合があり、専用ハウジングやハンズ・アンド・アイズサービスはアイテムに応じて 12 か月または 36 か月の期間があるとしています。オブジェクトストレージの価格は使用量ベースですが、ベアメタルとハウジングは物理ユニットに紐づいています。この組み合わせは回復力に影響します。緊急時には、顧客は緊急対応が単なる技術コマンドではなく、新規注文、サポートリクエスト、回線見積もり、在庫依存の納入、契約修正である可能性に気付くかもしれません。

調達チャネルは別の運用レイヤーを追加します。Cloud Temple の IaaS およびベアメタルのページは、公共セクターやヘルスセクターの購入者を UGAP や CAIH などの公共調達ルートに導きます。これは、アドホックな交渉を通じてインフラを購入できない組織にとって、プロバイダーを採用しやすくする可能性があるため重要です。また、回復力計画がフレームワーク条件、事前承認されたカタログエントリ、注文書、最低コミットメント、公共調達のタイミングによって形成される可能性があることも意味します。公共の購入者は、認定サービスをよりクリーンに注文できるかもしれませんが、後日のキャパシティ拡張、緊急回線、プレミアムサポートへの変更、移行支援リクエストが同じ購入パスに適合するかどうかを依然として把握する必要があります。

これが、ホスト型キャパシティの経済性を月額単価に還元すべきではない理由の一つです。自社のサーバールームから TEMPLE Cloud Temple SAS に移行する顧客は、資本コスト、人員負担、ファシリティリスクを、専門化されたインフラを持つプロバイダーにシフトしています。これは合理的であり、特に SecNumCloud グレードの管理を単独で容易に構築できない規制対象の顧客にとってはそうです。しかし、顧客はまた、予約帯域幅、サポート階層の割合、ストレージ消費量、IP アドレス、プライベート回線、ハンズ・アンド・アイズ時間、専門支援、物理ホスティング条件、退出帯域幅という新しいコスト構造を受け入れています。クラウドの請求は、単にコンピュートとストレージだけではありません。それは、障害の前に行われた選択の代価でもあります。

オブジェクトストレージのエグレス料金無料の主張は、運用上の意味が文脈に依存する、購入者にとって有利な条件の良い例です。顧客がエグレス料金なしで S3 互換アクセスを通じてすべてのオブジェクトを復旧できる場合、退出の商業的障壁は多くのハイパースケールの取り決めよりも低くなります。しかし、数テラバイトまたはペタバイトの移動には、依然として時間、帯域幅、アクセスキー管理、宛先キャパシティ、オブジェクト命名規則、保持ポリシーの認識が必要です。エンティティ Lock が有効な場合、顧客は自身の不変性の選択も尊重しなければなりません。エグレス料金がないからといって、移行ウィンドウ、宛先設計、検証済みのコピープロセスの必要性がなくなるわけではありません。

公開ステータスページも同じ実用的な方法で使用されるべきです。これは、インシデント中に顧客が監視できるコンポーネントを挙げており、Cloud Temple がその運用状態の一部を可視化したことを示すため、価値があります。しかし、ステータスコンポーネントは、顧客がそれが自分のサービスにどのようにマッピングされるかを知っている場合にのみ有用です。顧客が FR1 Object Storage や特定のアベイラビリティゾーンラベルのアイテムを見たとしても、自分のバケット、テナント、VPC ゲートウェイ、ベアメタルブレードが影響を受けるかどうかを判断できるでしょうか？顧客自身のインシデント対応チームには、これらのラベルを理解する人が含まれていますか？サポート階層は、目前の重大度に対する通信チャネルを約束していますか？可視性は、顧客のランブックと所有権記録に接続されている場合にのみ役立ちます。

プロバイダー自身のパブリックエッジには、静かな依存関係もあります。ある時点の DNS ルックアップでは、cloud-temple.com が Cloud Temple のアドレス空間、Gandi のネームサーバー、Microsoft のメール保護、別の Cloud Temple アドレス上のコンソール、Atlassian Statuspage と CloudFront 経由のステータスホスト名で観測されました。これらは通常の選択であり、中核プラットフォームの証拠を弱めるものではありません。しかし、これらは顧客の通信が AS33930 を超えたレイヤーに依存する可能性があることを示しています。深刻なインシデントでは、プロバイダーの Web サイト、コンソール、ステータスページ、メール経路、電話サポート、顧客テナントは、異なる組み合わせで障害が発生したり、存続したりする可能性があります。顧客は複数のエスカレーションチャネルを保持し、停止が発生するまでテストを待つべきではありません。

この記事に割り当てられたグローバルカテゴリにもニュアンスが必要です。クラウドサービスは世界的に購入および到達可能であり、AS33930 は世界的なルーティング可視性を持っています。しかし、Cloud Temple の公的なソブリンストーリーは主にフランスおよび欧州向けであり、FR1 製品言語、フランスのオフィス、フランスのサポートチーム、ANSSI 認定、HDS 関連性、パリのピアリング、フランスのファシリティ市場シグナルを伴います。フランス国外の顧客にとって、その依存関係は、目的がフランスまたは欧州のデータローカリティである場合、依然として魅力的かもしれません。また、レイテンシ、顧客アクセス回線、法的期待、運用サポート時間は、実際のユーザーベースに対して評価されるべきであることも意味します。フランスのソブリンクラウドから提供されるグローバルなユーザー母集団は、追加のキャッシング、地域アクセス設計、またはアプリケーションレベルの耐性を必要とする場合があります。

主権は、顧客がそれをアーキテクチャの代替として扱う場合、誤った完全性の感覚を生み出す可能性もあります。認定されたフランスのプロバイダーは、特定の法的、運用的、セキュリティ上の懸念への露出を低減できますが、顧客のデータ分類、経路フェイルオーバー、アプリケーションクラスタリング、テナント権限、キーローテーション、復旧頻度、退出優先度を決定することはできません。Cloud Temple の公開ドキュメントは、これらの項目の多くが顧客に委ねられていることを異例なほど明確にしています。その明確さは朗報です。それは、本番稼働前に分担を明示的にする機会を購入者に与えます。リスクは、購入者が認証の見出しを読んで責任表を無視することです。

したがって、最もクリーンな調達質問は、イエスかノーかの信頼問題ではなく、境界の表です。各ワークロードについて、顧客はコンピュートサービス、ストレージサービス、ネットワークサービス、アベイラビリティゾーン、バックアップターゲット、復旧責任者、サポート階層、顧客回線、パブリックプレフィックス、アイデンティティ管理者、キー所有者、課金責任者、メンテナンス連絡先、退出先を書き留めるべきです。次に、TEMPLE Cloud Temple SAS に、どの項目がプロバイダー運用か、顧客運用か、SecNumCloud 範囲内か、HDS 関連か、認定範囲外か、プレビューか、個別の専門支援が必要かを確認する必要があります。この作業は平凡ですが、クラウドの回復力が見えるようになる場所です。

物理ハウジングは、クラウドにエッジがあることを最も具体的に思い出させるものです。Cloud Temple のハウジングドキュメントでは、共有ラック内のラックユニット単位、または専用 42U ラックによる物理ホスティング、共有ラック用の 2 系統の電気チェーン、U あたりの電力制限、C19 電源を備えたサーバー向け 2U ユニット、2 系統の 16A 電気チェーンで 3 kW の専用ラック、追加 2 kW 刻み、最大機器質量 1,000 kg、監視付き PDU、銅線または光ファイバーネットワークポート、Meet-Me-Room 接続、ハンズ・アンド・アイズサービスが説明されています。また、専用ラックは SecNumCloud エリア外の共有ホスティングスペースにあるとしています。この最後の区別は重要です。「Cloud Temple ハウジング」と「認定 IaaS Secure Temple」は互換性のあるフレーズではありません。

一部の顧客にとって、ハウジングは橋渡しです。レガシーアプライアンス、メインフレーム隣接システム、プロプライエタリストレージボックス、HSM、ファイアウォール、または移行ステージングサーバーは、規制対象ワークロードの移動中にクラウドリソースの近くに配置する必要がある場合があります。それは理にかなっていますが、2 つの境界からなるアーキテクチャを作り出すこともあります。一部は認定クラウド、一部は非認定物理ホスティング、一部は顧客所有機器、一部は Cloud Temple 管理ネットワーク、一部はキャリア回線です。顧客がそれらすべてが同じ認定、サポート応答、復旧メカニズムを持つと想定すると、設計は誤解を招く可能性があります。ハウジングドキュメントは、まさに購入者にラックユニット、ワット、ポート、光パス、ハンズ・アンド・アイズ応答、サポートエスカレーションについて話し合うことを強いるため、有用です。

したがって、データ主権の議論は、具体的に保たれる場合に最も強力です。Cloud Temple のページは、フランスでの運用、SecNumCloud 認定、HDS、ISO 27001、フランスのサポートチーム、規制対象セクター向けに設計された製品に関して、信頼できる主権の主張をしています。オブジェクトストレージページは、フランスおよび欧州の規制ニーズを強調しています。サポートページでは、サポートチームがフランスに拠点を置き、フランスから活動しているとしています。コンプライアンスページには、公式の有効期限と範囲が記載されています。しかし、主権は単なる国のラベルではありません。それはまた、配置、サポートアクセス、下請け業者の証拠、キー保管、インシデント通信、輸出経路、削除証明、残留リスク開示でもあります。顧客は、各データコピー、バックアップ、ログストリーム、サポートアーティファクト、サポート介入がどこにあるかを尋ねるべきです。

パブリックネットワークのフットプリントも同様の教訓を与えます。AS33930 には可視的なプレフィックスがあり、チェックされたビューでの有効な経路起点認証、エクスチェンジ参加、ファシリティリストがあります。これは、他社のネットワーク上のリセラーフロントエンドだけを見るよりも優れています。これは、Cloud Temple が直接的なルーティング面と公的な相互接続のストーリーを持っていることを意味します。それでも、ルーティング証拠は、どの顧客テナントがどのプレフィックスを使用しているか、攻撃中に DDoS 緩和がどのように誘導されるか、メンテナンス中にすべてのパスが等しく利用可能か、顧客所有のプレフィックスにどの経路優先度が適用されるか、顧客が IP アイデンティティをプラットフォームからどれだけ迅速に移動できるかを明らかにしません。強力な BGP レコードは一部のワークロードには必要ですが、すべてに十分ではありません。

最も影響を受ける顧客は、Cloud Temple 自身がターゲットとしているところです。公共セクター機関、医療提供者、金融会社、産業事業者、ソフトウェアパブリッシャー、およびコンプライアンス保証と運用継続性の両方を必要とするその他の組織です。これらの環境では、クラウドの停止は単なる不便ではありません。ケアを遅らせ、規制報告を凍結し、プラント隣接システムを停止させ、市民サービスをブロックし、アイデンティティアクセスを中断し、ソフトウェアパブリッシャーが下流の顧客にサービスを提供するのを妨げる可能性があります。適切なデューデリジェンスの質問は、「Cloud Temple は VM をホストできるか？」ではありません。明らかに可能です。質問は、「このアプリケーションが停止した場合、選択されたサービス設計は運用上の損害に一致するか？」です。

公共機関にとって、その答えには SecNumCloud の範囲、テナント分離、サポート階層、インシデント通信、可逆性が含まれるかもしれません。医療提供者にとっては、HDS の範囲、バックアップ復旧テスト、サポートアクセス、エンティティ Lock 保持、下請け業者の証拠がすべてのパスをカバーしているかどうかが含まれるかもしれません。財務チームにとっては、監査証拠、経路多様性、不変アーカイブ、暗号化、キー保管、DORA スタイルの退出計画が含まれるかもしれません。産業企業にとっては、低レイテンシリンク、ファシリティの近接性、プライベートバックボーン設計、メンテナンスウィンドウ、ローカル運用フォールバックが含まれるかもしれません。単一の製品ラベルではこれらの質問に答えることはできません。顧客は、公開証拠をワークロード固有の設計レビューに変える必要があります。

最もテストする価値のある障害パスは複合的なものです。プロバイダーインフラ、顧客設定、サポートプロセスを横断するインシデントです。顧客が、ファイアウォールペア、S3 バックアップコピー、顧客所有プレフィックス、オンプレミスのファイバーパス、Premium サポート階層で、2 つのアベイラビリティゾーンにわたって VMware IaaS を実行していると想像してください。1 つのゾーンが劣化すると、アプリケーションは HA 構成、ストレージレプリケーション、ファイアウォール状態、DNS 動作、経路収束、S3 可用性、正しく分類されたチケットに依存する可能性があります。顧客自身のキャリア回線にも問題がある場合、Cloud Temple のバックボーンはボトルネックではないかもしれません。顧客のバックアップポリシーが誤って設計されていた場合、3 ゾーンのオブジェクトストレージは誤ったデータを保存する可能性があります。だからこそ、共有責任は停止前に履行される必要があり、停止中に単に引用されるだけではいけないのです。

メンテナンスウィンドウも同様の注意に値します。SLA 文言では、顧客のサポート契約に基づいて通知された計画メンテナンスは除外されます。これは正常ですが、実用的な計画を顧客にシフトします。メンテナンス通知は誰が受け取りますか？アプリケーションを所有するチームに転送されますか？ハイパーバイザーの更新が再起動を引き起こす可能性があることを顧客は知っていますか？Cloud Temple はすべてのワークロード固有の制約を認識しているわけではないため、一部のハイパーバイザー OS 更新は顧客の決定事項になる可能性があることを理解していますか？バックアップ、監視、ファイアウォールチームはウィンドウ中に待機していますか？メンテナンスイベントは、顧客にとっても日常的である場合にのみ、プロバイダーにとって日常的なのです。

修復期間とハードウェア在庫は、公開情報源から検証することがより困難です。ドキュメントはブレードのクラス、ストレージ制限、ネットワークポート、物理ホスティングユニットを明らかにしますが、予備ブレード数、ストレージコントローラーの予備、GPU 在庫、クラス別のリードタイム、アベイラビリティゾーン別の正確な交換プラクティスは公開していません。これは在庫が存在しないことを意味するのではなく、公開調査ではそれを証明できないことを意味します。顧客の正しい要求はシンプルです。選択したサービスのキャパシティ予約、拡張、交換プロセスを示すことです。緊急時にさらに 4 つの GPU ブレードが必要な場合、ブレード障害後の交換ホストが必要な場合、復旧中に追加のオブジェクトストレージスループットが必要な場合に、回答が即時か、スケジュール済みか、注文依存か、見積もり依存かを顧客が知っておくべきです。

復旧証明についても同様です。Cloud Temple の認定プラットフォーム、S3 冗長性、バックアップアーキテクチャは、一般的なホストよりも強力な出発点を作り出します。しかし、IaaS および S3 の責任マトリックスは、バックアップ計画の一貫性と定期的な復旧テストを繰り返し顧客に委ねており、Cloud Temple が相談される場合もあります。これは調達文言を変更すべきです。購入者は「バックアップは含まれていますか？」だけでなく、「誰が復旧計画を作成し、誰がテストを実行し、誰が結果を記録し、復旧が目標を達成できなかった場合に何が起こり、実際の復旧中にどのサポート階層が適用されるのか？」を尋ねるべきです。テストされていない復旧は、基盤となるストレージが適切に構築されていても、依然として願望に過ぎません。

したがって、TEMPLE Cloud Temple SAS の証拠グレードは、割り当ての「薄いフットプリント」という注意よりも優れているべきですが、それでも絶対的ではありません。公開記録は広範で、最新かつ具体的です。公式ページは、規制対象セクターポジショニング、フランスのオフィス、SecNumCloud と HDS の範囲、製品ファミリ、サポート階層、オブジェクトストレージアーキテクチャ、プライベートバックボーン設計、VPC および VM SLA 条件、ハウジングの物理的制限、AS33930 ルーティング、RPKI 有効性、エクスチェンジポイント、公開ステータスコンポーネントを特定しています。これは substantial なフットプリントです。欠けている証拠はより狭いですが決定的です。顧客固有の配置、各ワークロードの正確なファシリティ事業者の割り当て、予備在庫、サポートパフォーマンス履歴、復旧テスト結果、顧客集中度、メンテナンス通信、実際の退出実行です。

購入者にとっての実践的な結論は、TEMPLE Cloud Temple SAS を、依然としてワークロードレベルの証明を必要とする、信頼できるソブリンクラウド依存先として扱うことです。リージョン、アベイラビリティゾーン、コンピュートホストまたはクラス、ストレージクラス、S3 バケット、バックアップポリシー、VPC ゲートウェイ、インターネット出口、顧客回線、サポート連絡先、エスカレーションパスを記した図を要求してください。どのコミットメントが SecNumCloud 範囲でカバーされ、どれが HDS か、どれが通常のハウジングか、どれがプレビューか、どれが顧客所有かを尋ねてください。サービスクレジットがどのように請求され、何がカバーされないかを尋ねてください。ワークロードがどのように退出し、データがどのように消去され、キーがどのように扱われ、営業時間外のサポートがどのように振る舞うかを尋ねてください。

インフラ読者にとって、教訓はより広範です。ソブリンクラウドプロバイダーは、真に運用可能でありながら、依然としてキャパシティの平凡な物理に依存する可能性があります。TEMPLE Cloud Temple SAS は、認定フランスインフラ、認識可能なエンタープライズプラットフォーム、可視的なルーティング、3 つのアベイラビリティゾーンにわたるオブジェクトストレージ、フランスでのサポート、明示的な責任マトリックスという魅力的な組み合わせを販売しています。しかし、顧客は抽象的な「主権」を購入するのではありません。特定のテナント、ブレードクラス、ストレージ階層、ネットワークパス、チケット階層、メンテナンスカレンダー、退出アレンジメントを購入します。これらは、ホスト型キャパシティがラックイベント、アップストリームイベント、ハードウェア不足、サポートキュー、課金摩擦、移行圧力、プロバイダー契約の失敗を乗り切るかどうかを決定する部品です。