概要

  • 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 は、ディレクトリカードからはシンプルに見え、顧客が実際に何が機能する必要があるかを尋ねると複雑になるタイプのクラウド企業です。この名前は、フランスの事務所、コンプライアンス主張、ルーティングされた自律システム、公開サポート提供、公式ステータスページ、およびコンピュート、ストレージ、ネットワーク、物理ホスティング、責任境界を説明する技術文書を持つソブリンクラウドプロバイダーを指しています。これにより、弱い運用ステータスの読み取りを拒否するには十分です。ただし、すべての可用性や主権の主張を自己執行可能として扱うには不十分です。同社はホステッドキャパシティを販売していますが、そのキャパシティは依然として実際の施設スペース、電力、ケーブリング、ルート選択、ベンダープラットフォーム、サポート労働力、顧客設定、復元テスト、契約条件に依存しています。

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

より強力な公開証拠は、コンプライアンスと製品フットプリントです。Cloud Temple のコンプライアンス手続きページは、同社がインフラ向けに 2018 年から、マネージドサービス向けに 2022 年から ISO 27001 認証、ヘルスデータ活動向けの 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 IaaS（認定クラウド環境での VMware 環境）、ベアメタル（専用物理サーバー）、プレビュー段階の VM インスタンス（より共有型のクラウドスタイル仮想マシン）を説明しています。OpenSource IaaS の公開ドキュメントでは、Cisco UCS コンピュート、IBM Spectrum Virtualize および IBM FlashSystem ブロックストレージ、Dell ECS オブジェクトストレージ、Juniper ネットワーキング、専用コンピュートブレードとストレージボリューム、月額消費課金、リージョンおよびアベイラビリティゾーンの概念、バックアップ、レプリケーションオプション、API または Terraform 運用について説明しています。これは軽量なホスティングカタログではありません。それは物理的かつ運用上のスタックです。

スタックには特定の含意があります: 設置容量と利用可能容量は同じではありません。ページにはブレードクラス、ストレージクラス、接続性の数値が表示されますが、顧客は依然として、正確なクラスが希望するリージョンで利用可能か、別のホストを追加するためにハードウェア在庫が必要か、GPU ブレードにリードタイムがあるか、セカンドアベイラビリティゾーンに一致するストレージパフォーマンスがあるか、顧客のライセンスがライブフェイルオーバーを許可しているかを尋ねる必要があります。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、アベイラビリティゾーン間伝搬、文書化されたビューでの intra-AZ 遅延 3 ms 未満、inter-AZ 遅延 5 ms 未満、およびクラスターが必要なホスト設計を持つ場合にのみ機能する高可用性について説明しています。公開ドキュメントでは、アベイラビリティゾーンに 1 つのハイパーバイザーのみが含まれる場合、別のハイパーバイザーでの自動再起動は不可能であると指摘しています。これは、クラウドの約束をエンジニアリング現実に変える種類の文章です。顧客は認定プロバイダーからインフラを購入し、間違った形状を選択したり、セカンドノードを延期したりすることで、依然として脆弱なシングルホスト環境を構築する可能性があります。

ストレージも精度を必要とします。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 アドレッシング、ネイティブアンチ DDoS 保護、外部接続用ポート、専用回線製品向けの 2 つの多様化された光パス上の 1G/10G 回線およびプライベートリンクを提供すると述べています。インターネット概念ページは、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 日までのウィンドウで 8 つのアクティブなアナウンスを示しました: 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。

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

トランジットおよびピアリング証拠も有用ですが、注意深く読む必要があります。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 階層で異なる影響を与えます。課金または注文の障害は、プロビジョニングや拡張を遅らせる可能性があります。移行の障害は、プラットフォームが健全であってもワークロードを stranded にする可能性があります。これらのリスクはプロバイダーが弱いことを意味するものではありません。それらは、クラウド契約を魔法の抽象化としてではなく、インフラとして読む必要があることを意味します。

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

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

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

VPC SLAも同様に具体的です。VPC データプレーンには 99.99% の月間可用性、コントロールプレーンには 99.9% を提供し、非可用性のしきい値は 5 分です。Cloud Temple が管理する VPC コンポーネント（ルーター、プライベートネットワーク、外部ゲートウェイ、NAT、DNAT、フローティング IP）をカバーします。顧客のフィルタリングルール、不正なアドレッシング、接続されたコンピュートの障害、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 などの公共調達ルートに導いています。これは、アドホックな交渉を通じてインフラを購入できない組織にとってプロバイダーを採用しやすくするため重要です。また、回復力計画がフレームワーク条件、事前承認されたカタログエントリ、注文フォーム、最小コミットメント、公共調達のタイミングによって形成される可能性があることも意味します。公共購入者は、認定サービスをよりクリーンに注文できるかもしれませんが、後の容量拡張、緊急回線、プレミアムサポート変更、移行支援リクエストが同じ調達パスに適合するかどうかを知る必要があります。

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

オブジェクトストレージのエグレス料金なしの主張は、購入者に優しい条件の良い例ですが、その運用上の意味は状況に依存します。顧客が S3 互換アクセスを通じてすべてのオブジェクトをエグレス料金なしで回復できる場合、出口への商業的障壁は多くのハイパースケール契約よりも低くなります。しかし、数テラバイトまたはペタバイトを移動するには、依然として時間、帯域幅、アクセスキー制御、宛先容量、オブジェクト命名規則、保持ポリシーの認識が必要です。エンティティ Lock が有効な場合、顧客は自身のイミュータビリティの選択を尊重する必要もあります。エグレス料金がないことは、移行ウィンドウ、宛先設計、検証済みコピープロセスの必要性を排除するものではありません。

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

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

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

主権はまた、顧客がそれをアーキテクチャの代替として扱う場合、誤った完全性の感覚を生み出す可能性があります。認定されたフランスのプロバイダーは、特定の法的、運用的、セキュリティ上の懸念を軽減できますが、顧客のデータ分類、ルートフェイルオーバー、アプリケーションクラスタリング、テナント権限、キーローテーション、復元頻度、出口優先順位を決定することはできません。Cloud Temple の公開文書は、それらの項目の多くが顧客に残ることを異常に明確にしています。その明確さは良いニュースです。購入者に、本番前に分割を明示する機会を与えます。リスクは、購入者が証明書の見出しを読み、責任テーブルを無視することです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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