シャットダウンしても課金：3HCloud の統合インフラ検証

概況

3HCloud の最も興味深い提案は、1.50ドルの仮想マシン構成ではない。それは、クラウドインスタンス、レンタル物理サーバー、顧客所有のハードウェアが、顧客をハイパースケーラーのプロプライエタリスタックに強制することなく、ネットワーク、ブロックストレージ、管理、サポートを共有できるという約束である。
法的および運用上の境界は明確化が必要である。フロリダ州の記録によると、3HCloud LLC は 2020 年に設立された現存する企業であるが、同サービスが使用する自律システムは、より古い Newserverlife LLC に登録されたままである。公開届出書では両社の管理職が同一人物であるが、公開証拠からは正確な所有権、資産、責任関係は確立されない。
同プロバイダは、多くの小規模ホストよりも低レベルの運用詳細を公開している。シャットダウンしても VM の課金は停止せず、デタッチされたストレージは引き続き課金対象となり、スナップショットはプライマリストレージ上に留まり、スケジュールバックアップは自動的に整合性テストされず、帯域幅は時間平均速度で課金される。この率直さは有用だが、設計で回避すべき依存関係も明らかにする。
「100% 稼働保証」は、対象となる仮想リソースに対するサービス与信に裏付けられた契約上の目標であり、測定された 100% 可用性の証拠ではない。専用サーバー、ベアメタル、コロケーション、コントロールパネル、API、DNS、バックアップ、その他いくつかのコンポーネントは保証の対象外である。
3HCloud は、インフラを理解し、アンバンドル価格、OpenStack API、Fibre Channel ストレージ、エンジニア主導のサポートを重視するチームにとって経済的に魅力的となり得る。監査済みコンプライアンス、幅広いマネージドサービス、独立して実証されたマルチリージョンレジリエンス、厳密に指定されたサポート応答時間を必要とする購入者は、これを本番標準として扱う前により多くの作業が必要である。
決定的な調達テストは、障害時の移植性である。顧客は、3HCloud のポータルやサポートキューが利用できない場合に、コンピュートを再作成し、独立して保持したデータを復旧し、アドレッシングを保持または置換し、物理機器を移動し、運用できるか？

3HCloud のドキュメントで最も啓示的な制御は「サーバー作成」ではない。「シャットオフ」である。

多くのクラウドでは、顧客は最初の驚くような請求書を受け取って初めて、そのボタンの経済的意味を知る。3HCloud はそれを直接的に述べている。仮想サーバーは作成から削除まで課金され、SHUTOFF 状態にしても課金は停止されない。削除するとコンピュート課金は終了するが、システムボリュームも削除される。事前にデタッチしたネットワークポートは、そのパブリックアドレスを別のマシンのために保持できるが、そのポートにアタッチされた IPv4 アドレスは引き続き料金が発生する。追加のブロックボリュームは、デタッチしても課金が続く。これらは通常のインフラルールだが、それを明示することでサービスの真の単位が露呈する。顧客は「サーバー」を購入しているのではない。顧客は、永続的なコンピュート、ストレージ、ポート、アドレス、帯域幅、サポート支援インフラを、それぞれ異なるライフサイクルで組み立てているのである。

このアセンブリが、3HCloud のより大きな主張の基盤である。同社のプラットフォームに関する説明では、顧客は自身のハードウェア、3HCloud ベアメタルサーバー、クラウドインスタンスを 1 つのコンバージド環境に組み合わせることができるとしている。このアイデアは、低コスト VPS オファーよりも実質的である。企業は、バースト性の高いアプリケーションノードを仮想マシンとして、ライセンスドデータベースを専用ハードウェア上で、レイテンシに敏感なアプライアンスを自社サーバー上で、その 3 つの背後に共有ブロックストレージを配置して実行するかもしれない。ネットワーキングと運用がこれらのレイヤーを真にまたがるならば、顧客は周囲のすべての依存関係を変更することなく、ワークロードの配置を変更できる。

落とし穴もある。コンバージェンスは依存関係を除去するのではなく、再編成するのである。1 つのプロバイダのアドレッシング、ストレージファブリック、コントロールパネル、課金アカウント、サポートプロセスを共有するハードウェアの種類が増えるほど、それらの共有システムのいずれかが故障したり商業的にアクセス不能になった場合の結果は大きくなる。したがって、3HCloud は小型ハイパースケーラーとしても、従来型の格安ホストとしても評価されるべきではない。クラウド、ベアメタル、コロケーションの間の継ぎ目を使いやすくしようとしている小規模なインフラオペレータとして理解する方が適切である。その評価は、それらの継ぎ目が十分に文書化され、契約可能で、可逆的であるかどうかにかかっている。

1 つのネットワーク名の背後に 2 つのフロリダ企業

契約上の主体は第一層では明確である。3HCloud の利用規約は、プロバイダをフロリダ州ハリウッドの 2031 Harrison Street に所在する 3HCloud LLC と定義している。フロリダ州事業局の記録によると、3HCloud LLC は現存するフロリダ州有限責任会社であり、文書番号 L20000375976、2020 年 12 月 1 日に申請・発効。2026 年の年次報告書は 2026 年 1 月 28 日に提出された。記録では、Konstantin Kolosovskiy がマネージャー、Elena Kolosovskaya が正規メンバーとして指名されている。

ネットワーク上のアイデンティティはそれほど単純ではない。同サービスは自律システム AS49791 とルーティングセット AS49791:AS-3HCLOUD を使用している。しかしBGP.tools の現在のルーティングビューは、レジストリとルーティングデータに基づき、登録組織を Newserverlife LLC と識別しつつ、ネットワークウェブサイトとして 3hcloud.com を指している。本レビュー時点では、活性化された RIPE 割り当てネットワーク、43 のオリジネート IPv4 プレフィックス、14 の IPv6 プレフィックス、4 つの名前付きアップストリーム（Cogent、Kazakhtelecom、Hurricane Electric、Fiord）が表示された。これらの数値は変化する観測値であり、固定された容量表明ではない。

Newserverlife は単に類似した商号ではない。そのフロリダ州の企業届出には、別個の現存するフロリダ LLC が示されており、文書番号 L19000013202、2019 年 1 月設立。同社も同じ 2 名を管理職またはメンバーとして記載し、2026 年の年次報告書を同じ 1 月 28 日に提出している。これは共通の管理と運営上の関係の強力な証拠であるが、それだけで一方の企業が他方を所有していること、すべてのネットワーク資産が移転されたこと、あるいは Newserverlife が 3HCloud の義務を保証していることを証明するものではない。

別のネットワークディレクトリは、公開向けのアイデンティティを異なる方法で提示している。PeeringDB は AS49791 を組織名 3HCLOUD LLC で掲載し、ウェブサイトを 3hcloud.com、範囲をグローバル、ピアリングポリシーをオープン、自己申告トラフィックレベルを 20～50 Gbps としている。その組織と施設情報は 2024 年 8 月に最終更新された。PeeringDB は貴重な運用上の証拠であるが、エントリはネットワーク参加者によって提供されており、企業所有権や現在の容量の監査と誤認すべきではない。

妥当な結論は限定的である。確認された事実：3HCloud LLC は現存するフロリダ企業であり、公開顧客契約で指名された事業体である。確認された事実：AS49791 はアクティブであり、ルーティングデータで Newserverlife LLC に登録されている。確認された事実：この 2 つのフロリダ事業体は指名された管理者を共有している。合理的な推論：3HCloud は、歴史的または法的に Newserverlife に関連付けられたネットワークリソース上に構築された、顧客向けクラウド事業である。未解決：どの事業体がネットワーク運用スタッフを雇用し、特定のアドレスブロックや機器を所有またはリースし、コロケーション契約を締結し、不正使用通知を受領し、ルーティングや施設の問題が 3HCloud の顧客に影響を与える場合の責任を負うのか。

これはサービスを却下する理由ではない。これは、調達に事業体マッピングを組み込む理由である。ビジネス購入者は、注文書、データ処理条件、SLA、不正使用対応、IP 割り当て権、および施設固有のスケジュールで、責任事業体を一貫して指名するよう要求すべきである。また、Newserverlife が下請け業者、関連会社、ライセンサー、または資産所有者であるかどうか、その関係が変化した場合に 3HCloud が AS49791 の運用を継続できるかどうか、そしてルートリーク、ハイジャック申し立て、または不正使用紛争の際に顧客がネットワーク運用機能に直接連絡できるかどうかを尋ねるべきである。ロゴよりも回答が重要である。なぜなら、ネットワークはコンバージドプラットフォームの共有制御ポイントの 1 つだからだ。

3HCloud LLC 自体が実際のインフラ契約を締結しているという独立した証拠が少なくともいくつか存在する。Monster Worldwide の破産手続きで提出された 2025 年のスケジュールでは、Harrison Street の住所にある「3HCLOUD」がマスターサービス契約と販売注文の取引相手として特定されている。より最近のSpiceProp VPS サービス契約は、その VPS テクノロジーとインフラが 3HCloud LLC によって提供されていると述べている。いずれの文書もサービス品質、収益規模、容量を実証するものではないが、どちらもプロバイダ自身のマーケティングを超えて、同社が第三者の契約コンテキストに登場していることを示している。

6 つの販売都市、5 つの観測施設、複数の異なるマップ

3HCloud の公開地理は、1 つのロケーションリストに縮小できない。なぜなら、同社自身の表面が境界を異なる方法で記述しているからだ。

現在の仮想サーバー作成ドキュメントは、選択可能なリージョンまたはアベイラビリティゾーンとしてワルシャワ、マイアミ、ダラス、マニラ、アルマトイをリストしている。クラウド製品ページは代わりにワルシャワ、ダラス、サンフランシスコ、マイアミ、マニラを説明している。価格ページは、マニラ、ダラス、マイアミ、ワルシャワ、サンフランシスコ、アルマトイの 6 都市名すべての帯域幅料金を公開している。一方、サイトのナビゲーションは 2026 年 7 月時点で専用サーバーを「近日提供」とラベル付けし続けていたが、専用サーバーのドキュメントはアクティブなチケットベースのサービスを説明している。これらの差異は、変化する容量、製品固有の可用性、または異なる速度で移動するページを反映している可能性がある。ライブ見積もりとポータルチェックがマーケティングマップよりも信頼性が高い。

独立したネットワーク証拠は、そのフットプリントの一部をカバーしている。PeeringDB は AS49791 を 3 つのメトロにある 5 つの施設で記録している。ワルシャワの ATMAN Warsaw-1 と Equinix WA3、マイアミの Digital Realty と Equinix MI1、サンフランシスコの 365 Main Street にある Digital Realty である。また、Equinix ワルシャワインターネットエクスチェンジでの 10 Gbps ポートも記録している。ダラス、マニラ、アルマトイがそのディレクトリにないことは、3HCloud がそこにサービスを提供していないことを証明するものではない。プロバイダはトランジット、パートナー、リースドネットワーク、リモートピアリング、または別の自律システムを介してサイトに到達できる。しかし、それは公に観測可能な AS49791 の施設マップが、6 都市の商業マップよりも狭いことを意味する。

施設運営者は有用な裏付けを提供している。Digital Realty のパートナーディレクトリは、3H Cloud をリストし、パートナーロケーションとしてサンフランシスコ、ダラス、マイアミを挙げ、利用可能なサービスの中にベアメタルを説明している。Atman の Warsaw-1 施設ページは、そのキャンパスを Grochowska Street 21a に置き、オンサイトエンジニア、複数のデータセンタービル、施設レベルの認証を備えたキャリアニュートラルなサイトと説明している。これらの情報源は、実際の施設関係またはプレゼンスの存在を裏付けている。それらは、3HCloud がどれだけのスペースや電力をリースしているか、どのホールに機器が設置されているか、または 3HCloud のすべてのサービスが建物運営者によって宣伝されているすべてのレジリエンス機能を継承しているかどうかを確立するものではない。

この区別は不可欠である。データセンター認証は、評価された施設と範囲に適用される。それは 3HCloud のクラウドコントロールプレーン、従業員の慣行、論理アクセス、バックアップシステム、カスタマーサポートプロセスを自動的に認証するものではない。同様に、パートナーディレクトリのリストは商業的なつながりを確認するが、専用ケージ、デュアルサイトアーキテクチャ、建物の所有権を確認するものではない。3HCloud は時折、サイトを「当社のデータセンター」と呼ぶ一方で、「パートナー施設」にも言及する。より正確な公開説明は、サードパーティのデータセンター環境全体にわたってインフラを運用しており、正確な所有権と運用上の分割はサイト固有の確認が必要であるということである。

ルーティングデータは別の層を追加する。BGP.tools は、AS49791 の下に、3HCloud、Newserverlife、および下流または顧客組織向けにラベル付けされたアドレス空間を含む、混在したプレフィックス記述のセットを示している。これは、自社クラウドと他のネットワークにサービスを提供するネットワークオペレータと整合している。また、ASN レベルのプレフィックス数が 3HCloud のリテールクラウドの規模として扱われるべきではないことも意味する。購入者は、グローバル AS から推定するのではなく、購入する正確なリージョンのオリジン ASN、アップストリームミックス、DDoS パス、ルートオブジェクトステータス、RPKI カバレッジ、施設ハンドオフを要求すべきである。

小規模ながら有用な運用上の痕跡がある。2026 年 6 月、OpenBLD フィルタリングプロジェクトはサンフランシスコで 3HCloud がサポートするサーバーの展開を報告した。これはプロジェクトの謝辞であり、管理されたベンチマークではないが、PeeringDB と Digital Realty のパートナーディレクトリに登場する都市での現在のサービス活動を裏付けている。マニラとアルマトイに関する公開証拠は、3HCloud 自身のドキュメントと価格設定により依存している。規制対象またはレイテンシに敏感な展開では、顧客は注文スケジュールで施設名、物理的な国、データレジデンシー、サポート境界、ネットワークルートを要求すべきである。

コンバージェンスはワークフローであり、製品ラベルではない

プラットフォームの 3 つのインフラモードは、始まり方が異なる。

仮想マシンは大部分がセルフサービスである。顧客はリージョン、オペレーティングシステムまたはカスタムイメージ、コンピュート構成、ボリューム、ネットワーク、認証方法を選択する。リージョン内の最初のサーバーは、IPv4 と IPv6 を備えた外部ネットワークの作成を促す。内部ネットワークと以前に作成されたポートをアタッチできる。コンピュート変更は再起動を引き起こし、約 1～2 分と文書化されている。カスタム CPU 対メモリ比はセルフサービスから外れ、サポートチケットに移行する。

専用サーバーは営業とサポート主導である。専用サーバードキュメントは、購入者にプロジェクトと技術要件を提出するよう指示し、その後、商用チームが見積もりを準備する。説明されているサービスには、インターネット接続、IPv4 と IPv6、オプションのプライベートネットワーキング、IPMI、故障部品またはサーバー全体の交換、24 時間技術サポートが含まれる。アクティベートされると、サーバーは同じコントロールパネルに表示され、IPMI セッション、SAN 接続の詳細、アタッチされた仮想ボリュームが確認できる。

顧客所有の機器は物流と、より目に見える物理的な依存関係を追加する。コロケーションのドキュメントは、サーバーまたはラックホスティング、リモートハンド支援、IPMI アクセス、SAN ボリューム、ネットワーク接続について説明している。ホストされたサーバーのために、3HCloud は 10 Gbps SFP+ リンクを 2 つの別々のスイッチに使用し、両側でリンクアグリゲーションを構成すると述べている。これは意味のある実装説明であるが、プロバイダの発言であり、注文されたサイトとハードウェアに一致させる必要がある。

したがって、コンバージェンスは、すべてのリソースが同一にプロビジョニングされることではない。そうではない。コンバージェンスとは、プライベートネットワーク、パブリックアドレッシング、ブロックボリューム、監視ビュー、顧客アカウント、課金、サポート関係など、いくつかの周辺システムがそれらを横断して持続できることである。企業は VM から始め、データベースを専用の HPE サーバーに移行し、Fibre Channel ストレージをアタッチし、後に自社のアプライアンスを同じ施設に設置するかもしれない。その価値は、各ステップでネットワークと運用プロセスの完全な再設計を回避することにある。

その価値は、インフラに堪能な顧客にとって最も強い。3HCloud のAPI ドキュメントは、プラットフォームが API ファーストモデルに従っていると述べ、ユーザーを OpenStack API と OpenStack Terraform プロバイダに案内する。1 つのアカウントで最大 10 人の API ユーザーを作成でき、生成されたパスワードは一度だけ表示され、アクセスは元に戻せない形で取り消すことができるが、過去のユーザー記録は残る。これにより、チームには使い慣れた自動化パスが与えられ、専有のコンソールのみのサービスよりも宣言型の構築がより現実的になる。

ただし、環境のすべての部分が自動化されるわけではない。プロバイダ自身のワークフローでは、標準外の VM 形状、専用サーバーの見積もり、スイッチ設定、一部の IPMI 認証情報、ポート 25 の解除、いくつかのネットワーク変更がチケットの背後に置かれている。専用サーバーナビゲーションの「近日提供」ラベルも、詳細な運用ドキュメントやサードパーティの Digital Realty リストと矛盾している。公正な解釈は、物理製品は見積もり主導であり、在庫に裏打ちされた即時展開カタログとしてではなく、選択的に利用可能である可能性があるということである。調達では、実際の在庫、交換在庫、プロビジョニングリードタイム、および障害後に一致するサーバーが利用できない場合の結果を尋ねるべきである。

OpenStack はある種のロックインを減らす

OpenStack は、3HCloud のベンダー非依存という主張の中で最も信頼できる要素である。それは顧客に、コンピュート、イメージ、ネットワーク、ボリュームのための広く使用されているインターフェイスを提供する。Terraform 構成は通常のコードリポジトリに保持できる。カスタムマシンイメージをインポートできる。顧客は、完全にプライベートな API を学習するのではなく、アップストリームの概念を使用して多くのリソースを理解できる。

同プロバイダは、詳細なVMware から OpenStack への移行ガイドも公開している。VirtIO の準備、イメージエクスポート、VMDK から RAW への変換、イメージアップロード、新しいアドレッシング、DNS カットオーバー、移行中に蓄積されたデータの移動の必要性をカバーしている。Windows については、より複雑なドライバと回復プロセスについて説明している。これは企業作成のガイダンスであり、特定の顧客の移行記録ではないが、VM の移動が互換性、イメージ、ネットワーク、データタスクのシーケンスであり、魔法のインポートボタンではないことを有益に認めている。

オープンインターフェイスは、コントロールプレーンのロックインを減らす。データ重力やサービス固有の状態を排除するものではない。Terraform ファイルは仮想ネットワークを再作成できるが、数テラバイトの Fibre Channel ボリュームを即座に転送することはできない。OpenStack イメージはプラットフォームを離れることができるが、パブリック IPv4 アドレスはそうではないかもしれない。ロードバランサーの構成は文書化できるが、そのサービスアドレスとヘルス状態には依然としてカットオーバープランが必要である。コロケーションされたサーバーは他の場所に出荷できるが、それにはアクセス承認、リモートハンド作業、梱包、キャリア回収、交換用接続が必要となる場合がある。

クラウド内であっても、リソースのライフサイクルの詳細は重要である。3HCloud は VM の構成を変更すると再起動されると述べている。ワークフローで説明されている通常の意味でのインプレースオペレーティングシステムの再インストールは提供しておらず、より安全な文書化されたアプローチは、必要なものを保存し、削除して再作成するか、イメージ、スナップショット、またはバックアップから復元することである。システムボリュームは、顧客が意図的にデータを保護またはエクスポートしていない限り、サーバー削除に結び付けられる。これらは管理可能な制約であるが、自動化にコンピュートだけでなくデータとアドレッシングが含まれる場合に限られる。

API 自体が依存関係である。SLA は明示的に API とコントロールパネルを除外している。アプリケーションがオンラインのままであっても、API が代替インスタンスを作成できない場合、稼働中のリソースの契約上の「可用性」は維持されるかもしれないが、顧客の回復プロセスはブロックされる。本格的な設計は、コマンドライン資格情報、現在のエンドポイント詳細、最後に確認されたインフラ状態、サポートエスカレーションルートを保持すべきである。また、Web ポータルが利用できない場合にどの操作が継続するかをテストすべきである。

ストレージは蝶番であり、集中点である

3HCloud のアーキテクチャが最も特徴的になるのはストレージにおいてである。同プロバイダは、SSD Lite（1000 IOPS、100 MB/s）から SSD Ultra（25,000 IOPS、750 MB/s）までの 5 つの公開パフォーマンスクラスでブロックボリュームを販売している。現在の表示価格は 1 GiB あたり月額 0.01 ドルから 0.10 ドルである。これらは製品仕様と価格ポイントであり、独立して測定された持続的パフォーマンスではない。購入者は、I/O サイズ、読み取り/書き込みミックス、バースト挙動、レイテンシパーセンタイル、キューの深さ、ノイジーネイバー制御、および制限がボリュームごとに適用されるかストレージプール全体に適用されるかについて尋ねるべきである。

仮想マシン向けに、3HCloud はホスト障害後にインスタンスを別のコンピュートノードで再起動しながらデータへのアクセスを保持する方法として、外部 Fibre Channel ストレージを売り込んでいる。これは妥当なアーキテクチャであり、唯一のディスクが 1 つのホストにローカルな VM に対して真の利点である。しかし、公開ドキュメントはスケジューラポリシー、回復目標、クォーラム設計、コントローラレイアウト、またはフェイルオーバーテストの履歴を公開していない。この声明は、概念実証中に検証すべき企業の主張として扱われるべきであり、独立して確立された回復保証として扱われるべきではない。

物理的な側面はより具体的である。Fibre Channel ガイドは、分離されたストレージトラフィック、World Wide Name、マルチパス操作、A および B とラベル付けされた 2 つのファブリックについて説明している。専用サーバーまたはコロケートされたサーバーは、複数のパスを通じてボリュームを認識できるため、スイッチまたはポートの障害がストレージアクセスを除去するとは限らない（ホストが正しく構成されている場合）。VMware ESXi インストールガイドは、HPE サーバー、iLO、3PAR ディスク、サポートによるリンクアグリゲーション変更の支援、マルチパスチェックについて説明するところまで踏み込んでいる。これは、ハイブリッド提案が運用レベルで実装されているという貴重な証拠であるが、1 つのガイドがすべてのリージョンで同じハードウェアや冗長性を使用していることを証明することはできない。

共有ストレージは架け橋であると同時に爆発範囲でもある。これにより、データはコンピュートホストの障害を生き延び、異なる種類のサーバーに提示されることができる。しかし、仮想マシン、レンタルベアメタル、顧客所有のハードウェアがすべて同じストレージシステム、ファブリック、ゾーニングプロセス、または運用チームに依存する場合、ストレージインシデントは、コンピュート分離が作り出すことを意図した境界を越える可能性がある。デュアルファブリックはパス障害を緩和するが、それだけではコントローラ欠陥、ファームウェアエラー、管理ミス、破損したボリューム、施設停電、またはストレージ管理プレーンの喪失には対処しない。

3HCloud のスナップショットとバックアップの区別は異例なほど重要である。そのスナップショットドキュメントは、スナップショットがソースボリュームと同じハードウェア上に留まり、プライマリストレージが利用可能であることを必要とすると述べている。スナップショットはバックアップではないと明示している。この警告は文字通りに受け取られるべきである。スナップショットはクローン作成やロールバックには便利かもしれないが、ソースストレージシステムの喪失に対する独立したコピーではない。

バックアップドキュメントは、2 つ目の率直な警告を追加している。スケジュールされたバックアップは自動的なパフォーマンスと整合性チェックを受けず、顧客は定期的にリストアするよう助言されている。バックアップはボリュームに書き込まれたデータをキャプチャし、メモリ内にのみ存在する状態は含まない。それらは設定されたコピー数に従って保持され、ソースボリュームまたはサーバーが削除された後も残ることがある。したがって、サービスはメカニズムを提供するが、完全な回復保証ではない。

本番利用のために、未回答の疑問はアーキテクチャ上のものである。バックアップリポジトリはプライマリアレイとは異なる障害ドメインにあるか？同じ施設内か、別の 3HCloud リージョンか、または別のプロバイダか？バックアップはプロバイダ管理キーまたは顧客管理キーで暗号化されているか？顧客は 3HCloud を介さずにそれらをエクスポートできるか？1 つのボリュームとアプリケーション全体のテスト済みリストア時間は？ポータルがダウンしている場合にバックアップ API とメタデータは利用可能か？購入者は、損失がビジネスを脅かすデータのために、少なくとも 1 つの独立して管理されたコピーを維持すべきである。コンバージドストレージは共有されているからこそ便利である。独立した回復は、意図的に非コンバージドであるべきである。

ネットワーク料金は転送バイト数ではなく速度を測定する

3HCloud の帯域幅モデルは、より独創的な商業的選択の 1 つである。月間転送許容量のみを提示するのではなく、各時間帯における平均受信速度と送信速度を測定する。高い方の方向が顧客の専用しきい値を超えた場合、超過した Mbps にリージョン固有のレートが課金される。コントロールパネルはしきい値超過を表示し、顧客は追加料金を避けるために速度制限を課すことができる。ネットワークカードは、リソースをリージョンごとに集約し、クラウドと物理インフラを別々のカテゴリとして表示する。

このモデルは、高いしきい値を下回るバーストがあるワークロードにとって魅力的であり、ネットワークコストをオペレータが使用するキャパシティ言語で表現する。テラバイト許容量よりも直感的でない場合もある。短時間の高レート転送は、時間平均が低く抑えられれば安価になる可能性があるが、持続的なストリームは繰り返しの時間料金を生み出す可能性がある。非対称ワークロードは、両方向ではなく高い方の方向に対して課金される。チームは、単なる月間バイト数ではなく Mbps 時間をモデル化する必要がある。

公開説明は明確化が必要である。価格ページは、各 VM に超過前の 1 Gbps が含まれていると述べ、6 リージョンにわたる Mbps 時間あたりの料金を公開している。インターネットアクセスドキュメントは、ワルシャワ、マイアミ、サンフランシスコではデフォルトしきい値として 1,000 Mbps を示しているが、マニラでは 50 Mbps としており、その後、専用しきい値は必ずしも無料帯域幅と同じではないと注意している。ダラスとアルマトイはその例に含まれていない。これは含まれるポート速度、専用しきい値、現在のリージョンポリシーの違いかもしれないが、顧客が課金境界を推測する必要はないはずだ。注文では、リージョンごとに無料帯域幅、専用しきい値、物理ポート制限、超過レート、集約範囲を明記すべきである。

定額の上限なしオプションも公開されている。ダラス、マイアミ、ワルシャワ、サンフランシスコでは、2026 年 7 月の表示価格は 100 Mbps で月額 50 ドルから 10 Gbps で 2,000 ドルまでであり、マニラとアルマトイはより高いリージョンレートである。これらの数字は、3HCloud が安価なコンピュートを宣伝しながら、ネットワーク容量を独自の経済層として扱う理由を示している。また、ワークロードの形状を決定的にする。軽度に接続された開発 VM とストリーミングオリジンは、同じ CPU プランを使用しても、根本的に異なるプロバイダ経済性を持つ可能性がある。

最小 VM はアンバンドリングを例示している。クラウド製品計算機は、1 vCPU、1 GB 共有インスタンスを月額 1.50 ドルと表示し、最小 16 GB SSD Lite システムディスクを 0.16 ドル、IPv4 を 1 ドル追加し、表示合計が月額 2.66 ドルとなる。IPv6 は無料である。価格は真に低いが、1.50 ドルの見出しは、それ自体で起動可能かつ公共に到達可能な構成ではない。ストレージパフォーマンス、バックアップストレージ、Windows ライセンス、ロードバランシング、持続的帯域幅は別個の決定事項である。

課金はリソースが削除されるまで続き、単なるアイドル状態では停止しない。課金ドキュメントは、使用量が時間単位であり、デフォルトのカードは通常、サイクル締め時（通常は月の 1 日と 16 日）または与信限度に達したときに請求されると述べている。これは合理的に透明性があるが、アカウントの衛生管理に規律を課す。孤立したポート、デタッチされたボリューム、保持されたバックアップ、忘れられたリソースはすべて、アプリケーション所有者がプロジェクトが終了したと考えた後も存続する可能性がある。

利用規約はワークロード制約を追加している。パブリックリレー、帯域幅再販、パブリックトンネル、プロキシソフトウェアは、トラフィックが高度に対称的で、別途合意された場合または適格な上限なしオプションを使用する場合を除き、規定の消費条件を超えて持続する場合、禁止される可能性がある。アウトバウンド TCP ポート 25 はデフォルトでブロックされ、チケットを通じて開くことができる。VPN、プロキシ、メール、CDN、ゲーム、またはデータ配信ワークロードを計画している購入者は、意図されたパターンが許可され、正しく価格設定されていることの書面による確認を取得すべきである。

「100%」が購入するもの

3HCloud のサービスレベルアグリーメントは、対象となる仮想リソースの 100% 可用性という目標を設定している。このフレーズは Web サイトで目立つが、契約はマーケティングの省略表現よりも狭くその意味を定義している。

保証は、有料の仮想サーバー、クラウドインスタンス、クラウドストレージ、および契約に明示的に含まれるその他のリソースに適用される。専用物理サーバー、ベアメタル、コロケーションには適用されない。また、3HCloud の Web サイト、DNS サーバー、API、コントロールパネル、支払い統合、ベータサービス、顧客バックアップも除外される。GPU の操作とパフォーマンスは一般保証の対象外であり、確認された GPU サーバーのダウンタイムは分単位で補償される。対象となる「インフラ」は、ホストノードとプロバイダバックボーンに接続されたネットワークポートの可用性を中心に定義されている。

これは、3HCloud が歴史的に 100% の稼働時間を達成した証拠ではない。このレビューでは、公的なインシデントアーカイブや独立して監査された可用性シリーズは特定されなかった。SLA は、適格な利用不可時間後の与信資格に関する約束である。利用規約は、中断のない、完全に安全な、またはエラーのない運用を別途否認し、適用法に従うことを条件として、ダウンタイムやデータ損失などの間接的損失を除外している。

与信スケジュールは有限である。リソース利用不可時間が 9 分未満の場合、2 時間の与信、10～59 分は 6 時間、60～119 分は 12 時間、120～239 分は 24 時間、240～419 分は 48 時間、420 分以上は 168 時間が与えられる。公開表は正確に 9 分を未割り当てのままにしており、明確化すべき起草上のポイントである。与信は影響を受けたリソースに対して計算され、そのリソースの月額費用を上限とし、現金ではなく繰り越され、排他的救済策として説明されている。

請求プロセスは顧客主導である。60 日以内に、明示的に補償を要求するチケットを提出しなければならない。3HCloud が停止を認識していても、その要求なしには与信は開始されない。同社は、障害が発生したかどうか、およびその期間を独自に判断する。顧客のログは参考証拠となる。3HCloud は、MTR または traceroute の出力、スクリーンショット、アプリケーションログを推奨している。

利用規約との実用的な緊張関係がある。同規約は、明示的な書面による許可なしに、サービスの可用性、セキュリティ、パフォーマンス、機能を監視したり、ベンチマークを行うことを禁止している。意図はおそらく、顧客が自社の本番システムを監視するのを止めることではなく、競合テストや悪用目的のベンチマークを制限することであるが、条文は字面上広範である。SLA は顧客に技術的証拠を保持するよう求めているため、購入者は、本番監視、レイテンシ監視、セキュリティスキャン、受け入れまたはキャパシティプランニングに使用されるベンチマーク活動について書面による許可を取得すべきである。

多くの除外事項は商業的に合理的であり得るが、アーキテクチャ上結果を伴う。事前通知の下での計画メンテナンスは、定義された条件下で除外される可能性がある。重大な脆弱性の緊急修復は、通知なしに除外される場合がある。顧客ソフトウェア、過負荷、構成の再起動、バックアップリストア、支払い滞納、DDoS 攻撃、および 3HCloud の制御外のサードパーティ技術も与信の対象外となる場合がある。100 Gbps を超える大規模 DDoS 攻撃または 4 時間以上続くものは、不可抗力として扱われる。インスタンスと最初のプロバイダホップ間の 0.5% を超えるパケットロスは調査をトリガーするが、3HCloud がインフラ障害を確認しない限り、自動的には与信されない。

したがって、救済策は、ほとんどの本格的なアプリケーションにとってビジネス上の影響よりもはるかに小さい。利用規約は、該当する請求に対する総責任を、過去 2 か月間の該当製品の料金に制限し、多くの形態の間接的または結果的損失を除外している。長時間の停止後の 1 週間のリソース与信は、象徴的には説明責任を果たすかもしれないが、失われたトランザクション、緊急移行、データ再構築の資金にはならない。SLA の正しい利用法は、調達のベースラインとエスカレーションプロセスとしてであり、冗長性の代替としてではない。

サポートはアーキテクチャの一部である

小規模なインフラプロバイダは、しばしば製品の幅ではなく人間で競争する。3HCloud は、顧客がチャットボットではなくエンジニアにアクセスできると述べ、そのサポートドキュメントは、チケットシステムを通じた 24 時間年中無休の技術サポートを説明している。チケットには、割り当てられたエンジニア、ステータス、履歴、添付ファイルが表示され、クローズ済みチケットはコメントによって再開できる。営業は、平日の米国東部時間で運営されている。

公開資料は、重大度レベル、初回対応目標、復旧目標、重大インシデントのための電話エスカレーション、または指名されたサービス管理の役割を指定していない。その欠如は重要である。なぜなら、サポートはいくつかの技術的パスに組み込まれているからである。専用サーバーのプロビジョニングはチケットから始まる。カスタム VM 比率にはチケットが必要である。一部のネットワークしきい値変更とポート 25 の解除にはチケットが必要である。ESXi の展開には、リンクアグリゲーションを設定するためのサポートが必要である。IPMI 資格情報は、インストール後にサポートを通じて届く。Fibre Channel ゾーニングや物理コンポーネントの問題が発生した場合、顧客はすべての層を単独で解決することはできない。

これは、チームが熟練しており到達可能な場合には強みとなり得る。小規模のオペレータは、サポートキューが製品ごとにセグメント化された大規模プロバイダよりも、コンピュート、スイッチ、SAN、施設の境界を越えて迅速に診断できるかもしれない。また、集中リスクにもなり得る。公開情報源は、ネットワーク運用チームとサポートチームの規模、その地理的カバレッジ、オンコールスタッフ、言語カバレッジ、従業員の離職率、特定の個人への依存度を確立していない。サポート障害を主張する根拠はなく、同様にハイパースケーラーのようなスタッフ深度を想定する根拠もない。

物理サービスは別の当事者を追加する。Atman と Digital Realty は建物とリモートハンド機能を運営しており、3HCloud は顧客向けサービスを提示している。故障した電源装置は、サーバーベンダー、3HCloud サポート、施設技術者が関与する可能性がある。ネットワークインシデントは、3HCloud、Newserverlife の登録ネットワークリソース、アップストリームキャリア、データセンターオペレータが関与する可能性がある。顧客は 1 つの説明責任のあるエスカレーションパスを必要とするが、その背後にあるハンドオフも理解すべきである。

概念実証では、スループットだけでなくサポートをテストすべきである。通常時間と不便な時間にチケットを開く。非破壊の IPMI セッション、模擬の故障ディスク手順、ルート変更エスカレーション、バックアップリストアを依頼する。エクササイズを悪用負荷テストにせずに、確認応答と解決時間を記録する。重大度マトリクス、インシデントコミュニケーションポリシー、根本原因分析ポリシー、メンテナンスチャネル、および商業契約書で指名された緊急連絡先を要求する。物理的な交換が重要な場合は、故障部品を交換するという一般的な約束ではなく、リージョン固有のスペアポリシーを尋ねる。

セキュリティ管理策は不均等に文書化されている

3HCloud のセキュリティストーリーは、ドキュメントが具体的になるほど強力になる。仮想マシンはイングレスおよびイグレスルールを持つセキュリティグループを使用し、デフォルトのイグレスルールは削除できる。専用または物理インフラには、ベータ版と明示された別個のデータセンターファイアウォールサービスがある。そのファイアウォールはステートフルであり、許可ルールなしで有効にすると一方的な着信トラフィックをブロックするが、そのドキュメントは発信トラフィックがフィルタリングされないと警告している。したがって、ファイアウォールを攻撃からの保護として広く説明するマーケティングは、製品固有の管理策に翻訳されるべきである。仮想ファイアウォールと物理境界ファイアウォールは同一の動作をしない。

IPMI アクセスも別の例である。IPMI ガイドは、管理インターフェイスが分離ネットワークを使用し、メインインフラに接続されておらず、一時的または永続的なソース IP ファイアウォールセッションを通じて公開されると述べている。クイックセッションは 3 時間続く。これは賢明な管理設計であるが、分離の主張はプロバイダ提供のままである。購入者は、資格情報の生成、ローテーション、ログ記録の方法、IPMI を開くポータルアクションが多要素認証でカバーされるかどうか、永続的な許可ルールが期限切れになるかどうか、サポート担当者のアクセスが記録されるかどうかを尋ねるべきである。

ネットワーク境界は、デフォルトでアウトバウンドのポート 25 をブロックする。これは一般的な不正使用対策である。ルーティングレコードは不正使用およびネットワーク連絡先を公開している。公開されていないのは、詳細なセキュリティ保証パッケージである。レビューされた資料では、3HCloud 固有の SOC レポート、ISO 証明書、侵入テストの概要、サブプロセッサーレジスタ、脆弱性開示ポリシー、または詳細なインシデント対応コミットメントは特定されなかった。そのような文書は秘密保持契約の下で入手可能かもしれないが、施設証明書をそれらの代用とすべきではない。

2024 年 7 月 29 日に発効したプライバシーポリシーは、幅広いカテゴリの個人情報、サービスプロバイダとの共有、保持基準、「合理的な」物理的、技術的、組織的保護策について説明している。完全なエンタープライズデータ処理フレームワークよりも、Web サイトとアカウント情報に言及している。規制対象データを扱う顧客は、データ処理契約、サブプロセッサーとロケーションのリスト、削除と返却手順、侵害通知のタイミング、法執行機関の要求に対するポリシー、暗号化の責任、監査権を要求すべきである。

利用規約は、ネットワーク、サーバー、アプリケーション、アクセスコードのセキュリティについて、顧客にかなりの責任を割り当てている。3HCloud が禁止された使用を疑う場合、またはトラフィックがホスト環境を脅かすと考える場合の一時停止を許可している。また、プロバイダは、規定のガイドラインに従って、マーケティングで顧客を識別し、使用されている製品や機能を開示することを許可している。機密保持要件を持つ組織は、沈黙を前提とするのではなく、公開の同意について交渉すべきである。

運用の品質を推測できる独立したレビューの量は非常に少ない。Trustpilot は、この調査中にわずか 2 件のレビューしか表示しなかった。いずれも招待によるものであり、信頼性を確立するにはあまりに少なく、選択バイアスの影響を受けやすい。あるレビュー担当者は肯定的なコロケーション体験を説明し、別のレビュー担当者は、不便な時間にベアメタルリカバリのために十分な一時ストレージを入手するためのサポートが必要だったと述べている。この逸話は独立して検証可能ではなく、一般化すべきではないが、調達上の疑問を示している。どのリカバリリソースがセルフサービスであり、危機の瞬間にどのキャパシティが人間を必要とするのか？

安価なコンピュートはエントリポイントであり、全体モデルではない

3HCloud の価格構造は、各インフラ入力を読みやすくするように設計されているように見える。コンピュート、ストレージ、パブリック IPv4、バックアップリテンション、ロードバランシング、ネットワーク容量は別々である。プライベート L2/L3 ネットワークと IPv6 は無料と記載されている。これにより、経験豊富なチームは、必要とするものに絞って支払うことができるが、その請求書を組み立て予測する作業がそのチームに委ねられる。

市場比較は一次元的ではない。DigitalOcean の Droplet 価格は月額 4 ドルから始まり、その 1 GB 製品ページはストレージと転送許容量を含む 6 ドルの構成を示している。DigitalOcean は 2026 年に Droplet を秒単位課金に移行した。Amazon Lightsailは、コンピュート、SSD ストレージ、転送を組み合わせた予測可能なバンドルを販売しており、ローエンドの IPv6 専用プランは 3.50 ドルからである。それらの見出し価格は 3HCloud の 1.50 ドルのコンピュートラインよりも高いが、異なるコンポーネント、エコシステム、サポートの前提を含んでいる。RAM と vCPU だけを比較すると、真のトレードオフが隠れてしまう。

3HCloud の専用 CPU 形状も安価であり得る。公開されている 2 vCPU、8 GB 汎用 VM は、ストレージとアドレッシングを除いて月額 16 ドルである。経済的な問いは、専用が顧客の予想されるワークロード下で一貫して割り当てられた物理コアリソースを意味するかどうか、そしてストレージとネットワークの動作が予測可能なままであるかどうかである。購入者は、プランラベルに依存するのではなく、書面による許可を得て、時間の経過と障害イベントにわたって自身のアプリケーションをベンチマークすべきである。

コンバージドモデルは、クロスセルと保持の機会を生み出す。顧客は安価な VM から入り、より高性能なストレージを追加し、帯域幅を予約し、ロードバランサーを購入し、物理サーバーをレンタルし、最終的にハードウェアをコロケートするかもしれない。これらの層が真に移行の労力を削減するのであれば、顧客は利益を得る。3HCloud は、共有ネットワーク、ストレージ、サポートの依存関係が離脱をより複雑にするため、アカウントの価値が成長するにつれて利益を得る。これは不適切なロックインメカニズムではなく、統合インフラの通常の経済学である。出口費用が隠されているか、インターフェイスが移植可能でない場合にのみ問題となる。

小規模プロバイダはまた、容赦のない投入コストに直面する。トランジット、施設電力、リモートハンド、パブリック IPv4、スペアパーツ、サーバーメモリ、ストレージアレイは、顧客向けブランドが小さいからといって安くはならない。2026 年 5 月、より大規模な低コスト競合の Hetzner は別のサーバー価格と製品調整を発表し、ハードウェア調達プレッシャーを挙げ、プロビジョニングとメンテナンスをより効率的にするために構成を標準化した。教訓は Hetzner よりも広い。透明な低価格は、プロバイダが購入、稼働率、サポートコストを管理下に置ける場合にのみ持続可能である。

3HCloud 自身の答えは、きめ細かな課金、選択的な物理プロビジョニング、オープンソースソフトウェア、およびより狭いマネージドサービスカタログであるように見える。ターゲット顧客が運用スキルを持ち込むのであれば、何百ものハイパースケーラーサービスを再現する必要はない。しかし、エラーのマージンは薄い。寛大なネットワークしきい値、人間のサポート、スペアハードウェア、エンタープライズストレージにはすべてコストがかかる。購入者は、引用された価格がプロモーションか永続的か、更新と価格変更の仕組み、ハードウェアセットアップ費用が適用されるかどうか、サーバーが交換またはリサイズされた場合の価格への影響を調べるべきである。利用規約は、記載されたプロセスの下での通知による価格変更を許可しているため、長期的な予測可能性は最終的には公開計算機ではなく注文書から得られる。

競合は 3 つの異なるカテゴリーである

純粋な仮想インフラについては、3HCloud は開発者向けクラウドや地域の OpenStack プロバイダと競合する。DigitalOcean、Akamai Connected Cloud、Vultr、OVHcloud、Hetzner、および多数のローカルオペレータが、迅速な VM 作成、API、比較的読みやすい価格設定を提供している。それらの利点には、より多くのリージョン、より幅広いマネージドサービス、より大規模なサポート組織、より豊富なステータス履歴、より大きなコミュニティが含まれるかもしれない。3HCloud は、低いアンバンドル価格、専用 CPU オプション、Fibre Channel ストレージ、物理インフラへのパスで対抗する。

ベアメタルについては、在庫が豊富な専用サーバー企業やハイパースケーラーのベアメタルインスタンスと競合する。主要なテストは、コンポーネント仕様、在庫、セットアップ時間、リモート管理、交換在庫、契約期間に移行する。ここで「近日提供」ラベルは商業的な警告である。特注の専用サーバーが運用されていても、購入者は即時または標準化された可用性を想定すべきではない。

コロケーションについては、代替案は施設から直接またはより大規模なマネージドコロケーションプロバイダから購入することを含む。3HCloud の潜在的な利点は集約である。少数のサーバーを持つ顧客は、1 つの関係の下でインターネット、IP スペース、スイッチ設定、SAN ボリューム、リモートハンド、クラウド隣接性を提供するプロバイダを好むかもしれない。欠点は、顧客と建物の間に追加の商業的および運用層が存在することである。購入者は、サービスの移動、キャリアの変更、または機器の引き取りを希望する場合に、どの権利が存続するかを知っておくべきである。

最も強力な代替案は、名前付きベンダーではなく、アーキテクチャ上のものである。スタックを分割する。移植可能な VM をあるクラウドに、バックアップを別のクラウドに、物理機器を直接のコロケーション契約の下に、DNS を独立したプロバイダに置く。このアプローチは、相関するプロバイダリスクを削減するが、統合とサポートの負担を増加させる。3HCloud は、多くの顧客が 1 つの技術的に一貫した運用境界を好むだろうと効果的に賭けている。購入者のタスクは、どの依存関係を収斂させる価値があり、どれを意図的に分離したままにすべきかを決定することである。

出口は設計であり、キャンセルメールではない

3HCloud の OpenStack の使用は、VM 定義とイメージのための信頼できる出口ルートを生み出すが、秩序ある出口はサービスが健全な間に構築されなければならない。

コンピュートについては、Terraform または同等の宣言、cloud-init、構成管理、イメージビルド指示、外部依存関係のインベントリを保持する。定期的にプラットフォーム外でイメージを作成しテストする。すべての重要なボリュームのフォーマット、エクスポート方法、時間、出力コストを確認する。スナップショットが移植可能であると想定してはならない。3HCloud はそれが同じプライマリストレージ上に存在すると述べている。

データについては、別の管理および障害ドメインに 2 番目のコピーを保持する。ボリュームの復元だけでなく、アプリケーションの整合性のある回復をテストする。実際に達成された RPO と RTO を記録する。ベアメタルまたはコロケーションに Fibre Channel を使用している場合、ファイルシステム、マルチパス、boot-LUN、ゾーニング構成を文書化し、システムが異なるストレージにアタッチできるようにする。完全なデータセットを利用可能なネットワーク経由でコピーするのにどれくらいの時間がかかるかを把握する。

ネットワーキングについては、移植可能な構成と移植不可能なアイデンティティを区別する。プライベートサブネットとセキュリティルールは再作成可能である。プロバイダー割り当てのパブリックアドレスには、通常 DNS またはルーティングカットオーバーが必要である。デタッチされたポートは 3HCloud 内部でアドレスを保持する可能性があるが、それは別のオペレータへの移植性を意味しない。移行前に DNS の TTL 値を低くし、代替イングレスパスを維持し、アドレス空間が顧客所有であるか、書面による取り決めの下でアナウンスできるかを尋ねる。

物理機器については、契約はアクセス、リモートハンド、デラッキング、梱包、発送、未払い残高、ハードウェアを回収する顧客の権利を定義すべきである。公開利用規約では、3HCloud は終了後に顧客データを保持する義務を負わず、回収責任は顧客にあると述べている。また、3HCloud は顧客の同意なしに自身の権利と義務を譲渡できる一方で、顧客の譲渡を制限している。交渉された物理サービススケジュールは、一般的なクラウド条件よりも具体的であるべきだ。

運用については、ポータル外の連絡ルートを保持する。SLA はポータルと API を除外しているため、顧客はログインやチケット作成が利用できない場合に重大度 1 のインシデントを開く方法を知っておくべきである。現在の資産リスト、シリアル番号、ラックまたは施設の参照、IP 割り当て、サポート連絡先、請求書と注文書のコピーを保持する。統合インターフェイスは通常の運用では便利だが、出口計画にはその背後にあるものの独立した記録が必要である。

調達テストは悪い日を再現すべきである

従来の機能比較は、プラットフォームが多くの有用なプリミティブをカバーしているため、3HCloud を優遇するだろう。より良い評価は、コンバージェンスが重要になると想定される瞬間を再現することである。

第一に、法的およびネットワークマップを確立する。AS49791 リソースの所有権またはライセンス、不正使用対応、継続性の権利を含む、3HCloud LLC と Newserverlife LLC の間の関係について署名入りの説明を取得する。注文書、SLA、データ処理契約、請求書、施設スケジュール全体で契約主体を一致させる。

第二に、リージョンを特定する。正確なサービスの物理施設、国、オリジン ASN、アップストリーム設計、DDoS 対応、無料帯域幅、専用しきい値、ポート速度、現在の容量を尋ねる。なぜ公開リストがサンフランシスコとアルマトイで異なるのかを解決する。レジデンシーやレイテンシ要件があるワークロードに対して、「グローバル」という一般的な回答を受け入れない。

第三に、VM ライフサイクルをテストする。Terraform で作成し、顧客イメージから再構築し、リサイズし、ネットワークポートを保持し、安全に削除し、別のリージョンで再作成する。各アクション後にどのリソースと料金が存続するかを確認する。アカウントのクォータ、API ユーザー制限、ポータル依存関係が自動化計画に適合することを確認する。

第四に、ストレージの障害と復旧をテストする。合意されたベンチマークで公開ボリュームクラスを測定する。スケジュールされたバックアップを新しいボリュームにリストアし、そこからサービスを起動する。そのバックアップが物理的にどこに存在するかを尋ねる。Fibre Channel について、一方のパスの喪失をテストし、マルチパス動作を確認する。図から答えを前提とせずに、コントローラとファブリックのフェイルオーバーテストの証拠を要求する。

第五に、セルフサービスとサポートの境界をテストする。カスタム VM 形状、専用サーバーの見積もり、ファイアウォール変更、IPMI セッション、ネットワークエスカレーションを要求する。応答品質とエンジニアが行動しなければならないポイントを記録する。ワークフローがそれらに依存する場合、重大度と応答のコミットメントを交渉する。

第六に、全体的な請求をモデル化する。システムボリュームとデータボリューム、保持されたバックアップ、IPv4、該当する場合は Windows ライセンス、ロードバランサー、時間帯域幅超過、定額キャパシティ、リモートハンド、物理設定を含める。アイドル状態の月、トラフィックスパイク、リストア、移行をモデル化する。見出しの VM 価格は、永続的なコンポーネントが含まれた後に初めて有用になる。

第七に、契約文言を運用に対してテストする。SLA の与信テーブルの 9 分間のギャップを明確にする。本番監視と受入ベンチマークの許可を取得する。どの製品が与信の対象となるか、どのように与信が要求されるか、エンタープライズ注文が責任、データ返却、公開権を変更するかどうかを確認する。

最後に、部分的な出口を実行する。1 つのイメージと 1 つの意味のあるデータセットをエクスポートし、別の場所でそれらを再作成し、DNS を変更し、経過時間を文書化する。顧客所有のハードウェアについては、移動が計画されていなくても、アンインストールと回収の手順を入手する。透明性で真に競争するプロバイダは、出口パスを理解可能にすることを厭わないはずだ。

注目すべき点

最も重要な短期的な注視点は、3HCloud がその物理製品の公開境界を正規化するかどうかである。詳細な専用サーバー、IPMI、SAN、コロケーションのドキュメントは機能しているサービスを示唆しているが、メインナビゲーションは依然として専用サーバーが近日提供予定としている。標準化された在庫、明示的なリージョン別可用性、公開されたプロビジョニング条件は、興味深い特注機能をより評価可能な製品に変えるだろう。

第二は、アイデンティティの明確さである。AS49791 の Newserverlife 登録と 3HCloud の顧客契約は、正当な歴史的およびグループ構造上の理由で共存し得る。その関係を公に説明することで、回避可能なデューデリジェンスの摩擦を減らし、ネットワークの説明責任を理解しやすくするだろう。

第三は、運用の証拠である。公的なステータス履歴、インシデントコミュニケーション基準、リージョンレベルのアーキテクチャ記述、セキュリティ保証資料、テストされた復旧指標は、幅広い信頼性の形容詞よりも価値があるだろう。施設認証と 3HCloud 自身の管理範囲の明確なマッピングも同様である。

第四は、ハードウェア、メモリ、電力、トランジットのコストが変動する中で、低価格モデルが永続的であり続けるかどうかである。3HCloud のきめ細かな価格は、顧客が何を購入しているかを確認できるため、強みである。また、リージョンしきい値、製品ページ、または契約条件が乖離した場合に、同社を精査にさらすことにもなる。これらの表面を同期させ続けることは、製品の一部である。

3HCloud の提案は不合理ではない。法人は現存し、ネットワークは可視化され、サードパーティの施設ディレクトリはフットプリントの一部を裏付け、ドキュメントはランディングページの概念以上の十分な運用詳細を含み、外部文書は同社が顧客およびベンダー契約に参加していることを示している。証拠は、同社を現実の、技術的に野心的な小規模プロバイダとして扱うことを支持する。

それは、すべてのマーケティング上の主張を確立された事実として扱うことを支持するものではない。公開記録は、監査されたサービスパフォーマンス、セキュリティ管理策、スタッフの深度、インシデント履歴、正確な企業間の責任、宣伝されているすべてのリージョンの物理的基盤については薄い。100% という表現は与信メカニズムであり、測定値ではない。コンバージドアーキテクチャは、仮想インフラと物理インフラの間の摩擦を減らすことができるが、ストレージ、ネットワーキング、サポートのリスクを集中させる可能性もある。

それにより、有用で企業固有の結論が残る。3HCloud は、OpenStack API、ポート、アドレス料金、帯域幅しきい値、ブロックボリュームティア、Fibre Channel パス、物理サーバー制御といった構成要素を確認したいエンジニアリングチームにとって最も説得力がある。その透明性は、その機械的レベルで最も強い。購入者は、それらのメカニズムを厳密にテストすることでそれに報いるべきであり、商業的および組織的境界も同様に可視化するよう要求すべきである。シャットダウンボタンは依然として課金するが、少なくともドキュメントはそう述べている。より大きな問いは、シャットダウン後もオンのままであるすべての依存関係を、名前を挙げ、測定し、移動できるかどうかである。