Intrahost Solutions は生の速度よりホスティング継続性を重視

概要

Intrahost Solutions Ltd は、生の速度のベンチマークとしてではなく、継続性アカウントとして評価されるべきである。移行の苦痛とサポートの記憶が重要な場合、購入者は、プライベートクラウド、専用ホスティング、ハイブリッドインフラストラクチャ、コロケーション、またはパートナープラットフォームを実行するための信頼できる場所に対して支払いを行う。
同社の公式サイトhttps://intrahost.tech/には、プライベートクラウド、ハイブリッドインフラストラクチャ、ベアメタル専用ホスティング、コロケーション、パートナープログラム、EU 管轄、AS214124、複数国の施設参照、および主張されている 99.99%の稼働率サービスレベルが記載されている。これらは同社の主張であり、実際の稼働実績の独立した証拠ではない。
https://rest.db.ripe.net/ripe/organisation/ORG-ISL116-RIPEの公開 RIPE データは、Intrahost Solutions Ltd を、登録番号 HE 447614 のキプロスのローカルインターネットレジストリとして識別しており、https://rest.db.ripe.net/ripe/aut-num/AS214124の AS214124 レコードおよび RIPEstat のビューは、番号リソースとルーティングの証拠を示しているが、これらはあくまで証拠として扱われるべきであり、顧客サービスの品質を証明するものではない。
キプロスにおける代替手段は具体的である。購入者は、AWS Lightsail のようなハイパースケールクラウド、DigitalOcean のようなデベロッパークラウド、NetShop ISP や MVPS のような他のローカルまたはリージョナルホスト、リセラープラットフォーム、自社サーバー、または次のインシデントまで移行を延期するという一般的な中途半端な選択に移行できる。
私的な証拠があれば判断は変わるだろう。署名済みの顧客契約、インシデント後の維持率、サポート応答と復旧記録、実際の施設契約、上流側の請求書、バックアップ成功率、不正使用の負荷、サービスライン別の粗利益率、更新ショック後の解約率などである。

切り替えの決断は、金曜日に簡単には移行できないワークロードから始まる

Intrahost Solutions Ltd について考える最も有益な方法は、気軽に買い物をしているわけではない顧客から始めることだ。その顧客は、規制対象のアプリケーションを実行するキプロスのソフトウェア会社、欧州連合のデータ管轄権を求めるブローカー向けプラットフォーム、自社の顧客関係の下でインフラを再販しようとするマネージドサービスプロバイダー、あるいは 1 つのパブリッククラウドアカウントでは手狭になり、プライベート環境を望む企業かもしれない。請求書上の価格は重要だが、即座の決断は「何コア購入できるか」だけではない。「次の更新、移行、監査の質問、または停止を、運用負荷を悪化させることなく誰がこのワークロードを担うのか」である。

だからこそ、本記事で支払い単位とされるのは、ホスティング、クラウド、またはデータサービスの継続性アカウントなのだ。継続性アカウントには、コンピュート、ストレージ、ネットワーク到達性、IP アドレス指定、施設依存性、サポート応答、バックアップ期待値、不正利用処理、請求の明確性、移行支援が含まれる。Intrahost の公式サイトはそのような言葉で自らを表現している。同サイトは「エンタープライズインフラストラクチャ」と記載し、同社が EU 管轄下でオンプレミスクラウドソリューション、プライベートクラウド、ハイブリッドインフラストラクチャ、専用ホスティング、コロケーションサービスを提供していると述べている（https://intrahost.tech/）。また、マネージドサービスプロバイダー、システムインテグレーター、リセラー向けのパートナーチャネルの言葉も掲載されている。

したがって、最初の更新テストは実用的である。顧客がキプロスで本番アプリケーション、少数の顧客データベース、複数の仮想マシン、完全にリハーサルされたことのないバックアップスケジュール、そして不安を感じるほどには知識がある運用担当者を抱えていると仮定しよう。その顧客が Intrahost を検討している場合、購入の疑問は、より小規模なインフラプロバイダーが、管理不能な複雑さと厳格なコモディティパッケージという 2 つの最悪の選択肢を回避するのに十分な制御とサポートを提供できるかどうかである。すでに Intrahost を利用している場合、更新の疑問は、サポート関係、アドレス指定の継続性、移行回避が、同じワークロードを他に移せる場合でも、留まることを正当化するかどうかである。

代替手段は理論上のものではない。購入者はハイパースケールクラウドに移行できる。AWS Lightsail は、バンドルされた仮想サーバープランと予測可能な月額料金を提供している（https://aws.amazon.com/lightsail/pricing/）。開発者が多い購入者は DigitalOcean Droplets を選択できる。その料金ページ（https://www.digitalocean.com/pricing/droplets）では、シンプルなフラット料金と月額上限を強調している。ローカルまたはリージョナルな代替手段としては NetShop ISP があり、そのホームページ（https://netshop-isp.com.cy/）ではクラウドホスティング、専用サーバー、プライベートラック、ウェブホスティングを宣伝している。もう 1 つのキプロス拠点の VPS 代替手段は MVPS で、そのサイト（https://www.mvps.net/）では欧州 VPS ホスティング、キプロス VPS の利用可能性、KVM サーバー、非管理サポート境界、バックアップ、低月額料金を宣伝している。チャネル購入者は、プライベートインフラプロバイダーではなくリセラープラットフォームを選択できる。技術的に自信のある企業は、自社サーバーを購入またはコロケーションできる。リスク回避的な企業は、単に移行を延期し、現在のプロバイダーの欠点を受け入れ、次のインシデントが問題を強制しないことを期待できる。

Intrahost が重要となるのは、これらの代替手段が近いが不完全である場合である。ハイパースケールクラウドはスケール、ドキュメント、幅広いツール、調達の親しみやすさを提供するが、エグレスコスト、ポリシーの複雑さ、ローカルサポート記憶の少なさを課す可能性がある。ローカルホストはよりシンプルだが、Intrahost が主張する制御、ルーティング、パートナー対応に及ばないかもしれない。リセラープラットフォームは開始が速いが、顧客を基盤の施設やネットワークから 2 ステップ離してしまう。自社サーバーは制御を与えるが、電力、冷却、ライセンス、バックアップ、物理的セキュリティ、サポートを購入者の問題にする。移行延期は時間を節約するが、隠れた脆弱性も保存する。

本記事の証拠境界は意図的に厳格である。Intrahost 自身のウェブサイトは、公開された商業ポジショニングと企業主張を証明する。RIPE の公開データは、登録と番号リソースレコードを証明する。RIPEstat は、クエリされた時間枠における AS214124 の観測されたルーティング可視性を証明する。競合他社のページは具体的な代替案を証明する。これらの情報源のいずれも、Intrahost の実際の稼働時間、顧客数、収益、粗利益率、施設契約、サポート体制、インシデント後の顧客維持率を証明するものではない。

企業としての身元は商業的な深さよりも明確である

RIPE の組織レコードは、最も具体的な公開身元証拠である。https://rest.db.ripe.net/ripe/organisation/ORG-ISL116-RIPEのレコードには、Intrahost Solutions Ltd、国 CY、登録番号 HE 447614、組織タイプ LIR、リマソールの住所、電話番号、intrahost.tech ドメインのネットワーク運用メールアドレスが記載されている。また、組織に関連するロールとメンテナーの参照も示されており、組織レコードは 2024 年 9 月 20 日に作成され、2026 年 5 月 15 日に最終更新された。これはマーケティングプロファイルではなく、番号リソースレジストリの証拠である。

同社のウェブサイトは重要な身元詳細を繰り返し記載している。フッターには INTRAHOST SOLUTIONS LTD、リマソールの住所、登録番号 HE447614、ORG-ISL116-RIPE がhttps://intrahost.tech/に表示されている。同じサイトは商業的な連絡先を intrahost.tech ドメインにリンクし、インフラ問い合わせ、パートナー申請、ピアリングリクエストを提示している。サイトと RIPE データのこの一致は有用である。なぜなら、多くの小規模ホスティングブランドは法人への接続が難しいからである。このケースでは、会社名、登録番号、リソース組織ハンドル、AS 番号がすべて公開資料で確認できる。

あまり明確でないのは商業的な深さである。ウェブサイトは重大なインフラストラクチャの姿勢を主張している。プライベートクラウドプラットフォーム、ハイブリッドクラウドブリッジ、ベアメタル専用、コロケーションとハウジング、マルチホームネットワーク容量、キプロス、オランダ、フィンランド、ドイツにわたる施設参照、パートナープログラムである。しかし、公開サイトには監査済み会計、指名された顧客、公開されたステータス履歴、詳細な施設証明書、サポート要員数、ネットワークトラフィックグラフ、署名されたサービスレベル条件、公開価格表は示されていない。この欠如が主張を虚偽にするわけではない。それは、公開の投資家や購入者が商業的なストーリーを完全に立証されたものとして扱えないことを意味する。

身元証拠とサービス証拠の違いは中心的なものである。RIPE レコードは、Intrahost が番号リソースの背後にある組織として登録されていることを証明する。ウェブサイトは、Intrahost がインフラサービスを公然と販売していることを証明する。それだけで特定の顧客が一定のアップタイムレベルを受けていること、リストされた施設が Intrahost によって直接運営されていること、またはサポート範囲が顧客の期待通りに提供されていることが自動的に導かれるわけではない。購入者は継続性の約束を信用できるとみなす前に、契約の付属物、施設レター、エスカレーション条件、サポート時間、バックアップ設計、インシデント履歴の証拠を求める必要がある。

Intrahost はまた、ここでレビューされた RIPE レコードにおいて最近の公的リソースホルダーである。組織レコードは 2024 年 9 月に作成された。その IPv6 割り当てhttps://rest.db.ripe.net/ripe/inet6num/2a14:8300::/29は 2024 年 12 月 31 日に作成された。組織に関連付けられた IPv4 割り当てレコードには、2025 年 11 月 20 日作成のhttps://rest.db.ripe.net/ripe/inetnum/217.177.48.0%20-%20217.177.55.255、2025 年 11 月 21 日作成のhttps://rest.db.ripe.net/ripe/inetnum/194.1.136.0%20-%20194.1.143.255、2026 年 1 月 28 日作成のhttps://rest.db.ripe.net/ripe/inetnum/185.159.87.0%20-%20185.159.87.255が含まれる。これらの日付は、最近正式化されたリソースフットプリントを示唆しており、現在の名称での長いサービスの公開記録ではない。

この最近性は両面の意味を持ちうる。新しいまたは最近正式化されたインフラプロバイダーは、より柔軟で、より創業者主導で、初期の顧客により注意を払う可能性がある。また、ストレス下では実証されていない可能性もある。購入者は新しい公共の足跡を自動的に罰するべきではないが、それを評価に入れるべきである。適切な評価は割引だけではない。段階的な移行、より短い初期期間、より強力な退出権、本番カットオーバー前の検証済みバックアップ復元、どのサービスが所有、リース、再販、またはパートナー経由で提供されるかに関する書面による明確さを含む可能性がある。

ビジネスモデルは継続性と制御である

Intrahost の公開オファーは大量の共有ホスティング店頭ではない。サイトはプライベートクラウド、ハイブリッドインフラストラクチャ、専用ホスティング、コロケーションでリードしている。このポジショニングは、普通の共有ホスティングよりも制御を求め、単純なセルフサービス VPS よりも人間のアーキテクチャ関与を求める顧客を指している。経済的単位は、インフラがどこに位置し、どのように接続され、誰がサポートでき、アレンジが失敗した場合にどう移動できるかを制御する必要がある顧客アカウントである。

プライベートクラウドの経済は、プロバイダーが標準アーキテクチャを複数の顧客に再利用しながら、専用制御の感覚を販売できる場合に魅力的である。顧客は分離、予測可能なパフォーマンス、管理面、設計支援を求める。プロバイダーは反復可能なハードウェア、反復可能な仮想化、反復可能なストレージ、反復可能な監視、反復可能なサポート手順を求める。マージンは、契約価格に見合わないエンジニアリング時間を消費する単発の設計を避けることにかかっている。

ハイブリッドインフラストラクチャは販売を変える。顧客がプライベートインフラとパブリッククラウドのワークロード間の接続を望む場合、プロバイダーはサーバーだけを販売しているわけではない。ネットワーク設計、遅延管理、セキュリティ境界、運用所有権、およびオール・オア・ナッシングのクラウド依存を回避する方法を販売している。Intrahost のサイトはハイブリッドの言語を使用し、サービス説明でパブリッククラウド互換性に言及している。これは、機密性の高いワークロードを EU 管理の環境に保ちながら、バースト、分析、管理データベースのためにハイパースケールサービスを引き続き使用したい購入者にとって価値がある可能性がある。

専用ホスティングはより具体的である。顧客は物理マシンまたは明確に専用のハードウェアエステートを取得し、通常、小さな VPS よりも高い分離性と予測可能なパフォーマンスを得る。プロバイダーはハードウェア調達、設置、交換、リモート管理、施設依存、スペアパーツ計画を担う。顧客は施設全体の負担を負うことなく制御を購入する。マージンは、利用率、調達タイミング、交換規律、サーバー価格を超えるサポート約束を避けることにかかっている。

コロケーションとハウジングはより多くの責任を顧客に移すが、プロバイダーには施設、電力、冷却、クロスコネクト、リモートハンズの義務を残す。Intrahost のサイトは、Tier III+ 施設での安全なラックスペースを記述し、顧客が自身のハードウェアを持ち込むことができると述べている。コロケーションの顧客は、機器を置く場所、電力とネットワークの継続性、スタッフが現場にいないときにサーバーに目や手を入れる能力のために支払う。購入者の代替は別のコロケーションプロバイダーだけではない。それは、社内サーバールーム、ホストから借りた専用サーバー、またはパブリッククラウドへの完全移行でもある。

パートナープログラムは別の経済層を追加する。Intrahost は、マネージドサービスプロバイダー、システムインテグレーター、リセラー向けにホワイトラベルインフラを提供し、卸売価格、パートナーエンジニアリングサポート、優先プロビジョニング、API ファーストの統合を提供すると述べている（https://intrahost.tech/）。これは重要である。なぜなら、リセラーアカウントは単一のエンドカスタマーアカウントよりも粘着性が高い可能性があるからである。MSP が複数のクライアントワークロードをプラットフォーム上に構築する場合、切り替えコストには、すべての下流のクライアント関係、すべての契約の約束、すべてのサポート記憶が含まれる。しかし、リセラーチャネルはリスクも生み出す。エンドカスタマーはリセラーを非難するかもしれず、リセラーは Intrahost を非難するかもしれず、基盤となるプロバイダーは販売プロセスで設定された期待を直接制御できないかもしれない。

これが継続性ビジネスを一文で表したものである：Intrahost は、複雑なインフラを、顧客が離れがたい反復可能なアカウントに変えることで収益を得ることができる。なぜなら、サポート履歴、アドレス指定、施設の熟知、プライベート構成、移行リスクが価値の一部になるからである。顧客が、より大きなクラウド、ローカルホスト、リセラープラットフォーム、または自社オフィス内の方が同じ制御がより安価で明確であると判断した場合、それは弱まる。

ネットワークリソース証拠は真剣さを支持するが品質は保証しない

AS214124 レコードは、Intrahost を公開ルーティングシステムに示しているため、有意義な証拠の一部である。RIPE の aut-num オブジェクトhttps://rest.db.ripe.net/ripe/aut-num/AS214124は、AS214124 を as-name "intrahost"、組織 ORG-ISL116-RIPE、AS39572、AS13335、AS60068 を含むインポートおよびエクスポート行、ステータス ASSIGNED、作成日と変更日とともにリストしている。レビューされたレコードでは、2024 年 9 月 27 日に作成され、2026 年 5 月 28 日に最終更新された。

RIPEstat は観測されたルーティングのコンテキストを追加する。AS 概要エンドポイントhttps://stat.ripe.net/data/as-overview/data.json?resource=AS214124は、ホルダーを"intrahost Intrahost Solutions Ltd"と識別し、クエリ時に AS がアナウンスされていることを示している。アナウンスされたプレフィックスエンドポイントhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS214124は、2026 年 6 月 23 日から 7 月 7 日までの間に可視な複数の IPv4 および IPv6 ルートをリストしており、185.159.87.0/24、194.1.136.0/21、2a14:8300::/29 および他のより具体的なルートが含まれている。ルーティング一貫性エンドポイントhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS214124は、公開ルーティングとレジストリレコードの両方に存在するプレフィックスと、同じようには可視でないレジストリルートの混合を示した。

その証拠は重要だが、過大解釈してはならない。AS 番号は顧客の幸福を証明するものではない。ルートオブジェクトは動作するバックアップを証明するものではない。可視のプレフィックスはキプロスの顧客からの低遅延を証明するものではない。インポートまたはエクスポート行は、特定の日付で有効な商業的上流契約を証明するものではない。レジストリとルーティングデータは、Intrahost が実際の公開ネットワークリソース表面を持っていることを証明する。それらは、個々のサーバー、プライベートクラウドクラスター、またはコロケーションキャビネットが主張されたパフォーマンス、セキュリティ、またはサポートレベルを満たしていることを証明するものではない。

RIPE データベースの条件はその境界を明示的にしている。条件ページhttps://docs.db.ripe.net/terms-conditions.htmlは、RIPE データベースが登録、ルーティングポリシー公開、運用調整の目的をサポートすると述べており、また RIPE NCC はデータベースデータの正確性、完全性、可用性を保証しないと述べている。つまり、公開 RIPE レコードは有用な証拠だが、監査報告書ではない。購入者はレコードをデューデリジェンスの一層として扱うべきである。

国フィールドにも注意が必要である。ここでレビューされた一部の Intrahost RIPE 番号レコードは国が NL を示している一方、組織の国は CY である。これは自動的に顧客サービスがオランダまたはキプロスであることを意味するわけではなく、最終的なワークロードの場所を示すものでもない。登録、ジオロケーション、施設、または割り当ての詳細を反映している可能性がある。Intrahost のサイト自体は CY、NL、FI、DE の施設を参照している。購入者は、どの施設がワークロードをホストするのか、どの法人がサービスを契約するのか、どのネットワークがアドレスをアナウンスするのか、バックアップがどこに保存されるのか、どのような国境を越えたデータ処理条件が適用されるのか、そしてどのサポートチームが対応するのかを尋ねるべきである。

ネットワークリソースは選択肢を生み出す。Intrahost が自身の AS とアドレス空間を制御または維持する場合、ルーティングを設計し、ピアリング要求を処理し、施設間でワークロードを移動し、顧客プレフィックスをサポートし、データセンター変更を通じた継続性を提供する能力が高まる可能性がある。これは、ネットワーク層に影響を与えられない純粋なリセラーに対する真の利点となり得る。その価値は、顧客が再番号付けなしの移行、IP レピュテーション管理、ルートポリシーの明確さ、DDoS 応答、またはマルチホーミングを必要とするときに現れる。コストは、ルーティング専門知識、レジストリコンプライアンス、上流手数料、不正利用デスク作業、公開レコードを正確に保つ運用負荷に現れる。

したがって、最も強力な解釈はバランスが取れている。Intrahost は、そのインフラ主張の真剣さを裏付ける公開ネットワークリソースフットプリントを持っている。そのフットプリントは、顧客がプロバイダーがルーティング、サポート、インシデント応答を専門的に管理できると想定するため、期待を引き上げる。それ自体は、商業サービスが持続的な品質を持っていることを証明するものではない。

キプロスでの代替は具体的かつ近い

キプロスの購入者は閉じ込められているわけではない。ワークロードが小さな仮想サーバーに合い、購入者がローカル関係よりも予測可能性を重視する場合、AWS Lightsail は即座のベンチマークとなる。Lightsail はメモリ、vCPU、SSD ストレージ、転送を月額プランにバンドルしており（https://aws.amazon.com/lightsail/pricing/）、そのページでは予算編成をシンプルにし、静的 IP、DNS 管理、コンソールアクセス、API、SSD ストレージ、サーバー監視などの機能を含んでいる。これは、クラウドブランドの信頼を望み、セルフサービス運用に耐えられる購入者にとって強力な代替手段である。

DigitalOcean は、特に開発者や小規模ソフトウェアチームにとって、2 番目のハイパースケールに近い代替手段である。その Droplet の料金ページ（https://www.digitalocean.com/pricing/droplets）には、Droplet が月額 4 ドルから始まり、フラット料金と月額上限を使用し、アウトバウンド転送を含み、バックアップやスナップショットなどのアドオンを提供すると書かれている。既に Linux、Terraform、Docker、Kubernetes に精通している開発者は、小規模プロバイダーのアカウント関係よりも、DigitalOcean のドキュメントと予測可能なインターフェースを好むかもしれない。

ローカルまたはリージョナルホストの比較も同様に具体的である。NetShop ISP のホームページ（https://netshop-isp.com.cy/）は、クラウドホスティング、専用サーバー、プライベートラック、ウェブホスティングを宣伝している。そのサイトアーキテクチャは、キプロス関連の仮想サーバー、専用サーバー、コロケーション、ウェブホスティングのサービスエリアも視覚的に提示している。これはキプロスの購入者にとって近い代替手段である。なぜなら、一般的なクラウドだけでなく、インフラカテゴリと地域で競合するからである。Intrahost と NetShop を比較する購入者は、施設の場所、サポート時間、契約条件、移行支援、含まれるバックアップ、ネットワーク上流、リモートハンズ、価格透明性、プロバイダーが基盤サービスコンポーネントを所有またはリースしているかどうかを尋ねるだろう。

MVPS は異なる種類の代替手段である。そのサイト（https://www.mvps.net/）は、欧州 VPS ホスティング、キプロスを含む複数のロケーション、KVM 仮想化、即時配信、GDPR メッセージング、非管理サーバーのサポート境界、無料の手動および自動バックアップ、レビューされたページメタデータと構造化コンテンツにおける低い月額ユーロレベルのプラン価格を提示している。MVPS はプライベートクラウドやコロケーションプロバイダーと同じではないが、ワークロードが単に VPS または少数のサーバーである顧客にとっては実際の代替手段である。アーキテクチャレビュー、専用インフラ、またはパートナープログラムを必要としない顧客にとっては、低コストの VPS プラットフォームで十分かもしれない。

リセラープラットフォームの代替は近い。なぜなら、Intrahost 自体がパートナーチャネルをマーケティングしているからである。システムインテグレーターやマネージドサービスプロバイダーは、Intrahost、別のホスティングプロバイダーのリセラープログラム、または通常のセルフサービスアカウントと独自のサポート層を中心にホワイトラベルサービスを構築することを選択できる。経済性は異なる。リセラープラットフォームは、初期インフラコミットメントを削減し、リセラーが販売とサポートに集中できるようにする。しかし、他人の施設、コントロールパネル、IP レピュテーション、インシデント応答への依存も生み出す。Intrahost がこの比較で勝つのは、その卸売条件、エンジニアリングエスカレーション、プラットフォーム制御が代替案よりも優れている場合のみである。

自社サーバーの代替は見かけよりも高くつく。中小企業は物理サーバーを購入し、オフィスに設置し、ハイパーバイザーをインストールし、データをオンプレミスに保持できる。これにより月々のホスティングコストの一部を回避し、物理的制御を得る。しかし、電力、冷却、セキュリティ、バックアップ、スペアパーツ、監視、リモートアクセス、人員配置の義務も生じる。Windows Server がスタックの一部である場合、Microsoft はhttps://www.microsoft.com/en-us/windows-server/pricingで参照ライセンスを公開しており、Standard および Datacenter エディション、コアベースのライセンス、クライアントアクセスライセンス要件が含まれる。Linux が使用される場合でも、労働と継続性のコストは残る。サーバーの請求書は、自社維持の総コストではない。

移行延期の代替はしばしば最も強力である。企業は現在のホストが不完全であることを知っているかもしれないが、サーバーの移行は DNS の変更、データ同期、ファイアウォールルール、メール到達性チェック、アプリケーションテスト、ダウンタイム計画、顧客への連絡、バックアップ検証、スタッフの注意を意味する。誰も 1 週間の空き時間がない場合、企業は不満を抱えながらも更新する。この種の慣性は Intrahost が顧客を維持するのに役立つが、弱い満足度を隠すこともある。プロバイダーは、移行延期を忠誠心と混同すべきではない。次のサポートケースや停止が移行を不可避にする場合、アカウントは依然としてリスクにさらされている。

価格は実際には希少な運用注意への要求である

インフラの目に見える価格は表面に過ぎない。Intrahost はレビューされた資料で広範な公開価格表を公開していないため、購入者は AWS、DigitalOcean、NetShop、MVPS と直接行ごとに比較することはできない。このため、見積もりプロセスがより重要になる。真剣な見積もりは、コンピュート、ストレージ、帯域幅、バックアップ保持、サポート範囲、IP アドレス指定、施設所在地、クロスコネクト、リモートハンズ、オペレーティングシステムライセンス、移行支援、サービスレベル控除、不正利用作業、退出条件を分離すべきである。

プライベートクラウドの価格は 3 つの代替案に対してテストされるべきである。1 つ目は AWS、Azure、または別のプロバイダーを使用するハイパースケール設計である。クラウド設計は定常状態ではより高価かもしれないが、調達リスクを減らし、マネージドサービスへのアクセスを提供する可能性がある。2 つ目はより安価な VPS または専用サーバーアカウントである。これは低コストだが制御が少ないかもしれない。3 つ目は自社内またはコロケーションされた設計である。これは主権とハードウェア制御には優れているが、人員配置と復元力には劣る可能性がある。Intrahost の価格は、それが有用な中間を占める場合にのみ正当化される：十分な制御、労働を減らすのに十分なサポート、インシデントコストを回避するのに十分な信頼性、およびロックインの恐れを避けるための十分な柔軟性。

専用ホスティングの価格は利用率に対してテストされるべきである。半分アイドル状態のベアメタルサーバーはクラウドよりも高価かもしれない。安定した高使用率のワークロードを実行するベアメタルサーバーは、より安価で予測可能かもしれない。顧客は、ワークロードがバーストか、定常か、ストレージ負荷が高いか、帯域幅負荷が高いか、遅延に敏感か、コンプライアンスに敏感かを知る必要がある。Intrahost は、特注サーバーが低マージンのサポートシンクにならないように、ハードウェア償却、施設コスト、ネットワークコスト、サポートを価格設定する必要がある。

コロケーション価格は実際の所有権に対してテストされるべきである。顧客はしばしばハードウェア所有のコストを過小評価する。ハードウェア保証は期限切れになる。ドライブは故障する。ファームウェアは更新する必要がある。スタッフは移動するか、リモートハンズを信頼しなければならない。消費電力は予想以上に上昇する可能性がある。交換ハードウェアは利用可能でなければならない。バックアップはオフサイトテストが必要である。ネットワーククロスコネクトとトランジットは管理されなければならない。Intrahost がコロケーションを販売する場合、購入者は運用から逃れているわけではない。どの運用を顧客が保持し、どの運用をプロバイダーから購入するかを選択しているのである。

リセラー価格は顧客生涯価値に対してテストされるべきである。Intrahost をベースプラットフォームとして使用するマネージドサービスプロバイダーは、サポートチケット、請求、顧客獲得、バックアップ管理、インシデント対応後の利益を必要とする。卸売価格は重要だが、サポートエスカレーションとプラットフォームの明確さがより重要である。リセラーがインシデント中に明確な回答を得られない場合、リセラー自身のブランドが損なわれる。したがって、Intrahost は割引インフラだけでなく、運用上の信頼性を販売しなければならない。

すべてのサービスラインにわたる隠れたコストは、サポート記憶である。プロバイダーが顧客の環境、以前の移行、異常なルート、バックアップの例外、ビジネスカレンダーを知っている場合、サポートはより速くなる。その記憶には価値がある。また、次のプロバイダーはゼロから始まるため、切り替えコストも生み出す。Intrahost の機会は、顧客環境を十分に文書化して、スタッフが反復調査なしで対応できるようにすることで、サポート記憶を利益に変えることである。そのリスクは、サポート記憶が個々のエンジニアの頭の中にのみ存在し、人々が去ったりワークロードが増えたりした場合にサービスが脆弱になることである。

サポートの労働が継続性の約束の信頼性を決定する

インフラの購入者はストレス時にサポートを覚えている。営業ページはプライベートクラウド、ハイブリッドブリッジ、99.99%の稼働率と言うことができる。更新の決定は、仮想マシンが起動しない、顧客がバックアップ復元を必要とする、ルーティング変更が予期せぬ動作をする、施設のメンテナンスウィンドウが発表される、不正利用報告が届く、リセラーがステータス更新を求める 3 人の下流顧客を抱えている場合に何が起こるかによって形成される。サポートは、継続性の約束が実現されるか、マーケティングとして暴露されるかの場である。

Intrahost のサイトは、そのインフラプレゼンテーションで 24 時間 365 日のオンサイトエンジニアリングを主張し、パートナーエンジニアリングサポートの言語を使用している。それらの主張は、顧客が権限と文脈を持つ誰かに連絡できることを意味するならば価値がある。顧客がそれらを無制限のアプリケーションサポートと解釈する場合、リスクがある。プロバイダーは範囲を定義しなければならない：ネットワークと電力、ハードウェア、ハイパーバイザー、ストレージ、オペレーティングシステム、コントロールプレーン、バックアップ、顧客アプリケーション、サードパーティソフトウェア、セキュリティインシデント、データ復旧、移行は異なる責任である。線はインシデント前に明確にすべきである。

サポート労働にも単位経済がある。小さなプライベートクラウドアカウントは、すべてのアプリケーションの問題がエンジニアリング時間になった場合、不採算になり得る。コロケーションの顧客は、ハードウェアが信頼できない場合、多くのリモートハンズ要求を生み出す可能性がある。リセラーは下流の顧客を通じてサポート負荷を掛け合わせることができる。専用ホスティングの顧客は、ファームウェア、RAID、リモート管理、ネットワーク変更が関与する場合、上級スタッフを必要とする可能性がある。プロバイダーの利益は、良好な文書化、自動化、標準ビルド、明確なサポート層、異なるサービスレベルを必要とする顧客の早期発見にかかっている。

顧客にも責任がある。高い継続性を望む購入者は、バックアップを購入してテストし、復旧所有権を文書化し、アプリケーションの資格情報を利用可能に保ち、メンテナンスウィンドウを定義し、DNS と証明書の依存関係を記録し、不正利用連絡先を確認し、フェイルオーバーをリハーサルすべきである。プロバイダーはインフラを提供できるが、契約言語だけでテストされていないアプリケーションを復元力のあるものにすることはできない。Intrahost の最良の顧客は、共有責任を理解しているが、それを実行するのを助けられるプロバイダーを評価する人々であろう。

サポート品質を検証する私的事実は簡単である。Intrahost が緊急チケットに応答するのにどれくらいかかるか？インシデントが最初のエスカレーションで解決される頻度は？バックアップ復元が最初の試行で成功する頻度は？サポート範囲外のチケットの割合は？顧客がサービス控除を求める頻度は？停止後 90 日以内に解約する顧客の数は？上級エンジニアリングを必要とするリセラーエスカレーションの数は？公開資料はそれらの質問に答えていない。

市場の雑音は弱いシグナルとしてのみ有用である可能性がある。レビュー、フォーラムのコメント、ソーシャル投稿は、請求の驚き、非管理サポート境界、バックアップの不安、稼働時間の主張、ロケーションパフォーマンス、支払いの摩擦、遅延応答など、顧客が何を気にしているかを明らかにすることができる。しかし、そのような資料は自己選択的であり、代表的なパフォーマンスを証明することはできない。Intrahost 自体に関する信頼できるレビュー証拠がない場合、市場の雑音のより安全な使用法は一般的である：ホスティング顧客は、プロバイダーの責任と顧客の責任の境界が不明確な場合に不満を言う。Intrahost は、それを自社のサービスに関する確認された事実としてではなく、既知の市場ハザードとして扱うべきである。

施設とサプライヤーへの依存が中心的なリスクである

Intrahost のサイトは、キプロス、オランダ、フィンランド、ドイツの施設と、Tier III+ の言語、N+1 の電力、冷却、ネットワーク、マルチホーム容量を参照している。これらは重大な主張である。また、最も重要なデューデリジェンスの質問を提起する：Intrahost が直接管理するもの、リースするもの、再販するものは何か？顧客はプロバイダーがすべての建物を所有する必要はないが、施設インシデント中に誰が運用権限を持つかを知る必要がある。

施設依存にはいくつかの層がある。電力と冷却は建物運営者に依存する。物理的セキュリティは施設に依存する。クロスコネクトプロビジョニングは、キャリアニュートラルな環境とその建物のプロセスに依存する。リモートハンズの品質は、スタッフの可用性とトレーニングに依存する。交換部品は在庫とサプライヤーアクセスに依存する。プロバイダーは優れた顧客サポートを持っているかもしれないが、施設パートナーによって制約される可能性がある。契約はそれらの依存関係がどのように処理されるかを述べるべきである。

ネットワーク依存も同様に層状である。AS214124 レコードは、RIPE ルーティングレコード内の上流または隣接 ASN とのルーティング関係をリストしている。RIPEstat のルーティング一貫性出力はまた、一部のインポートおよびエクスポート参照が公開ルーティングで可視であり、一部はクエリ時点でレジストリレコードにのみ存在したことを示した。賢明な結論は、プロバイダーからの現在のネットワーク設計なしに、単一の上流をミッションクリティカルとして指名することではない。賢明な結論は、Intrahost の公的リソース表面が BGP 運用、ルートポリシーの正確さ、上流接続に依存しているということである。

サプライヤー依存はネットワークと施設を超えて拡張される。サーバー、ストレージアレイ、スイッチ、光学機器、ファイアウォール、バックアップメディア、監視ツール、オペレーティングシステム、仮想化ソフトウェア、コントロールパネルはすべて依存を生み出す。ラックにマシンが並んでいるというインフラのイメージは単純すぎる。プライベートクラウドサービスは、ハードウェア、ソフトウェア、手順、スタッフ、サプライヤーのスタックである。顧客は、プレッシャーの下でそのスタックを管理するプロバイダーの能力を購入する。

これはキプロスにとって重要である。なぜなら、地理的および規制上のポジショニングがオファーの一部だからである。EU 管轄は、データ管理、GDPR 義務、または契約上の地理を懸念する顧客にとって価値がある可能性がある。しかし、法人の所在地、施設の所在地、バックアップの所在地、サポートアクセスの所在地、パブリッククラウドブリッジサービスの所在地は異なる可能性がある。主権のために Intrahost を選択する顧客は、データ所在地スケジュール、処理者条項、サブ処理者リスト、バックアップ地理を要求すべきである。

リスクは Intrahost に固有のものではない。すべてのインフラプロバイダーは依存関係の束である。違いは、小規模プロバイダーは顧客に近いがハイパースケールクラウドよりも多様化されておらず、ハイパースケールクラウドはより多様化されているがより個人的でない可能性があることである。Intrahost の競争上の課題は、サポートの注意、アーキテクチャの適合性、パートナーの柔軟性、管轄の明確さといった小規模プロバイダーの利点が、集中リスクと検証リスクを上回ることを証明することである。

不正利用、請求、アドレスレピュテーションは隠れたコストである

ホスティングプロバイダーは、決して望んでいないかもしれない顧客からのリスクを負う。公開サーバーは、スパム、フィッシング、マルウェア、資格情報の窃取、スキャン、スクレイピング、著作権侵害、ボットトラフィック、詐欺インフラ、またはリスクのあるコンテンツに使用される可能性がある。プロバイダー自身の行動がクリーンであっても、プロバイダーは苦情を処理し、正当な顧客のためにアドレスレピュテーションを使いやすく保たなければならない。その作業は高価であり、何かがうまくいかなくなるまで見えないことが多い。

Intrahost の RIPE レコードには、不正利用およびネットワーク運用の連絡先参照が含まれている。これは、不正利用の応答性が公開ネットワークオペレーターであることの一部であるため重要である。プロバイダーは、苦情を受け取り、責任のある顧客を特定し、問題が悪意のあるものか侵害された使用かを判断し、公正なプロセスを保持し、他の顧客を保護し、上流またはレジストリの期待を満たさなければならない。対応が遅すぎるプロバイダーは、上流の圧力とアドレスレピュテーションの損傷を招くリスクがある。対応が過度に早急なプロバイダーは、正当な顧客を不当に停止するリスクがある。

請求も別の継続性の問題である。インフラ契約には、月額サービス料金、セットアップ料金、帯域幅超過料金、IP アドレス料金、バックアップ保持、リモートハンズ料金、ソフトウェアライセンス、ハードウェア交換、サービス控除、早期解約、移行作業、税金が含まれる可能性がある。顧客が請求書を理解していなければ、更新の信頼は弱まる。リセラーが卸売コストを予測できなければ、自身の顧客価格設定が壊れる。自社サーバーの代替に隠れたライセンスコストがある場合、ホストオプションが最初に見えるよりも魅力的になるかもしれない。

アドレスレピュテーションはホスティングにとって特に重要である。クリーンな IP 範囲は、メール、API、顧客アクセスをサポートできる。汚れた範囲は、到達性の問題、ブラックリスト、顧客の苦情を生み出す可能性がある。公開の RIPE データはアドレスリソースを示すが、レピュテーションの健全性を証明するものではない。真剣な購入者は、不正利用履歴、修正プロセス、顧客分離、メールポリシー、DDoS 処理、異議のあるレポートのエスカレーション方法について尋ねるべきである。

ここで、小規模プロバイダーは迅速に勝つことも負けることもできる。規律ある不正利用処理を行うプロバイダーは、顧客と上流関係を保護できる。弱い管理体制のプロバイダーは、少数の悪質な顧客が多く善良な顧客を害することを許す可能性がある。不正利用作業のコストは販売見積もりではめったに見えないが、利益とサービス品質に影響を与える。Intrahost の公的リソースフットプリントは、この責任が現実のものであることを意味する。

顧客基盤がモデルがスケールするかどうかを決定する

Intrahost のオファーはいくつかの顧客タイプにサービスできる可能性があり、それぞれ異なる経済性を持つ。プライベートクラウドの顧客は粘着性が高く高価値だが、要求が厳しいかもしれない。専用ホスティングの顧客は、ワークロードが安定していれば予測可能だが、ハードウェア障害に敏感である。コロケーションの顧客は、インストール後はタッチが少ないかもしれないが、インシデント中はリモートハンズと施設の期待が強烈になる可能性がある。リセラーの顧客は継続的なボリュームを生み出す可能性があるが、サポートの複雑さを掛け合わせる可能性がある。インフラ言語に惹かれた小さな購入者は、アカウントサイズに対して過剰な手取り足取りを生み出すかもしれない。

プロバイダーにはセグメンテーションの規律が必要である。制御を望むすべての顧客が専用インフラに対応できるわけではない。主権を求めるすべての顧客がコロケーションを必要とするわけではない。すべてのリセラーが下流のクライアントをサポートするのに十分な運用成熟度を持っているわけではない。すべてのプライベートクラウドの見込み客が、あらゆる設計が特注になれば収益性があるわけではない。良好な販売資格はサポートマージンを保護する。また、顧客が間違ったサービスを購入するのを保護する。

移行についても同じことが言える。移行支援は、ワークロードの移動が苦痛であるため、強力な獲得ツールになり得る。しかし、移行は期待のギャップも生み出す可能性がある。顧客はアプリケーションの修復、DNS のクリーンアップ、データベースの一貫性、メール到達性、セキュリティ強化を期待するかもしれない。プロバイダーはインフラのカットオーバーのみを価格設定しているかもしれない。Intrahost は移行範囲を注意深く定義すべきである：何がコピーされ、何がテストされ、何が除外され、どのようなダウンタイムが予想され、誰がロールバックを承認し、バックアップがどのように検証されるか。

最初のインシデント後の維持が鍵となる指標である。新しい顧客は移行が難しいために留まるかもしれない。成熟した顧客は、プロバイダーが有用であることを証明したために留まる。顧客が困難なサポートケースの後、Intrahost が明確にコミュニケーションし、サービスを復旧したために更新するならば、継続性のテーゼは強い。顧客が去ることが留まることよりも難しいという理由だけで更新するならば、アカウントは脆弱である。その違いは公開の RIPE データやウェブサイトのコピーには現れない。

製品市場適合性の問題もある。Intrahost のウェブサイトはエンタープライズのトーンを提示しているが、一部の公開競合他社は透明な低価格パッケージを使用している。AWS Lightsail と DigitalOcean はシンプルな価格を見えるようにしている。MVPS は低い VPS 価格を提示している。NetShop は幅広いカテゴリページを提示している。Intrahost のあまり公開されていない価格設定は、テーラードされたエンタープライズ取引には役立つかもしれないが、即座の比較を望む価格敏感な購入者を失う可能性がある。これは、Intrahost がコモディティのサインアップではなく、アーキテクチャ主導のアカウントを望む場合の意図的なトレードオフである。

理想的な Intrahost の顧客は、おそらく最も安い VPS を望む購入者ではない。それは、EU のロケーション、プライベートインフラ、パートナーサポート、ルーティング制御、コロケーションオプション、または純粋なハイパースケール依存からの移行経路を評価する購入者である。その顧客は、プロバイダーがそれを証明できるならば、継続性に支払うだろう。プロバイダーがエンタープライズ言語を伴うコモディティホスティングのように感じられるならば、去るだろう。

評価を変えるもの

Intrahost の公開ケースは現実的だが不完全である。同社は可視的なサイト、法人と RIPE の身元の整合性、公開 AS、公開ルーティング可視性、プライベートクラウド、専用ホスティング、コロケーション、パートナーインフラに適合するサービスメッセージを持っている。これは監視を正当化するのに十分である。ビジネスが持続的な顧客維持または強い利益率を持っていると結論付けるには十分ではない。

評価を変える最初の事実は、インシデント後の顧客維持である。Intrahost が停止、移行、バックアップ復元、サポートエスカレーションの後も顧客が留まることを示せれば、継続性は単なるポジショニングではない。それは機能している。最初の困難なイベント後に解約が増加するならば、モデルは獲得と移行の摩擦に過度に依存している可能性がある。

2 番目の事実はサポート経済である。チケット量、応答時間、解決時間、エスカレーション率、リモートハンズ需要、リセラーエスカレーション、アカウントあたりのサポートコストは、サービスが正しく価格設定されているかどうかを示すだろう。プロバイダーは、顧客がその注意に対して支払う場合、高タッチのインフラを良い利益で販売できる。コモディティ価格で無制限のサポートを長期間販売することはできない。

3 番目の事実は施設とサプライヤーの証明である。顧客またはアナリストは、実際の施設契約、冗長性文書、上流ネットワーク条件、メンテナンス記録、バックアップアーキテクチャ、監視範囲、インシデント報告を望むだろう。Intrahost のウェブサイトは強力な施設とネットワークの姿勢を主張している。契約証拠は、その姿勢のどれだけが直接制御され、どれだけがパートナー依存であり、ストレス下でどのように振る舞うかを示すだろう。

4 番目の事実は、サービスライン別の粗利益率である。プライベートクラウド、ベアメタル、コロケーション、パートナー再販は、それぞれ販売資料では魅力的に見える可能性がある。それらは異なる資本集約度、サポート負荷、解約リスクを持つ。各サービスラインが、ハードウェア、施設、帯域幅、ライセンス、サポート、不正利用作業、返金の後に正の貢献をしている場合、会社はより健全である。明確な戦略なしに、あるサービスラインが別のサービスラインを補助している場合、リスクが高い。

5 番目の事実は、アドレスと不正利用の健全性である。公開ルーティング可視性は有用だが、運用上の質問は、顧客がクリーンな到達性、安定したルート、使えるメールの評判、迅速な不正利用処理を経験しているかどうかである。良好なネットワークレコードがあるが不正利用管理が弱いプロバイダーは、顧客に損害を与える可能性がある。規律ある管理を行うプロバイダーは、番号リソース管理を競争上の優位性に変えることができる。

6 番目の事実は、リセラーの集中度である。パートナープログラムはスケールを生み出すことができるが、少数のリセラーが収益を支配しながらエンドカスタマーのリスクを隠す可能性がある。1 つのリセラーが多くのアカウントを持ち込み、その後去る場合、プロバイダーは 1 人以上の顧客を失う。リセラー契約が多様化され、十分にサポートされている場合、チャネルは堀になり得る。

7 番目の事実は、移行の変換とロールバックである。何件の見込み客が正常に移行するか？何件がロールバックするか？データ損失、DNS 遅延、アプリケーションの非互換性、メール到達性が、移行後のサポートを生み出す頻度は？移行は、継続性が最も明確に販売される場所である。また、弱い手順が可視化される場所でもある。

最初の証明期間は 1 事業年度である

最近の公的リソースフットプリントを持つ企業にとって、最も公正な商業テストは 1 つのベンチマーク日ではない。それは 1 事業年度である。1 年は、更新、ソフトウェアアップデート、少なくとも 1 つのメンテナンスウィンドウ、課金サイクル、不正利用報告、顧客オンボーディング、顧客退出、バックアップチェック、通常のスタッフ離職を含むのに十分な長さである。また、弱い運営習慣が文化になる前に修正できるほど短い。

最初の証明期間はオンボーディングから始まるべきである。Intrahost に移行する顧客は、書面によるサービスマップを受け取るべきである：何がどこで実行され、どのアドレスが割り当てられ、誰が DNS を制御し、バックアップがどのようにスケジュールされ、サポートに何が含まれ、誰が変更を承認でき、緊急アクセスがどのように機能し、顧客が去りたい場合に何が起こり、各ワークロードをどの施設または国がホストするか。この文書は官僚主義ではない。それは最初のインシデントが再発見の演習になるのを防ぐ運用記憶である。

2 番目の証明点は最初の計画された変更である。ホスティングプロバイダーは何も変わらないときは強そうに見える。有用なテストは、カーネル更新、ハイパーバイザーパッチ、ストレージ拡張、新しいクロスコネクト、ファイアウォール変更、顧客移行、バックアップ復元、または計画された電力イベントである。プロバイダーは範囲、予想される効果、ロールバック計画、完了ステータスを伝えるべきである。顧客が問題の後でのみ運用変更について知る場合、継続性の約束は弱まる。

3 番目の証明点は最初のサポートの曖昧さである。多くのインシデントは明確な所有者なしで始まる。障害は顧客アプリケーション、オペレーティングシステム、仮想化層、ストレージ、ルート、ファイアウォール、DNS、上流プロバイダー、施設、または支払い状態にあるのか？Intrahost の価値が最も高いのは、その境界を迅速に診断し、回避的に聞こえずにそれを伝えられる場合である。顧客はプロバイダーがすべての層を所有する必要はない。顧客が必要とするのは、プロバイダーが責任のある層を十分に速く特定し、インシデントが拡大し続けるのを止めることである。

4 番目の証明点は最初の請求の驚きである。インフラ請求は、バックアップ、帯域幅、IP アドレス指定、リモートハンズ、ライセンス、サポート範囲が追加されると複雑になる可能性がある。顧客が料金に異議を唱える場合、プロバイダーはそれを契約ライン、使用記録、または承認された変更まで追跡できるべきである。クリーンな請求は解約を減らす。なぜなら、技術的関係が信頼の紛争になるのを防ぐからである。混乱した請求は逆を行う：それはすべての更新を去る機会に変える。

5 番目の証明点は最初の退出要求である。自社のサービスに自信があるプロバイダーは、退出を不可能にしてはならない。データエクスポート、アドレス返却、バックアップ引き渡し、ハードウェア除去、リモートハンズ料金、最終請求を事前に定義すべきである。逆説的に、明確な退出権は、ロックインの恐れが低いため、顧客が契約する意欲を高めることができる。Intrahost の継続性アカウントは、サービスが良いために留まることが選ばれ、去ることが不明確であるためではない場合、より信頼できる。

その最初の年の終わりに、顧客はより真剣な判断を下すことができる。Intrahost は運用負荷を減らしたか？サポートは環境を覚えていたか？ネットワークは約束どおりに動作したか？バックアップはテストされたか？請求書は理解可能だったか？インシデントは明確に伝えられたか？プロバイダーは問題から学んだか？答えが「はい」であれば、Intrahost は安価な VPS プロバイダーが簡単に奪えない利益を獲得した。答えが「いいえ」であれば、顧客は次の更新がもう 1 年の慣性を生み出す前に、移行の価格を付けるべきである。

結論：継続性こそが証明すべき製品である

Intrahost Solutions Ltd は、ディレクトリ内の単なる名前以上のものである。公開記録は、キプロスの法人、RIPE 組織ハンドル、可視の AS、アナウンスされたプレフィックス、およびインフラ制御を販売するライブの商業サイトを結び付けている。同社は、プライベートクラウド、ハイブリッドインフラストラクチャ、専用ホスティング、コロケーション、パートナーサポート、EU 管轄、AS214124 を中心としたネットワーク姿勢を主張している。これらの主張は、安価な VPS 以上のものを望む購入者にとって関連性がある。

経済的な質問は、Intrahost がその関連性を耐久性のある継続性アカウントに転換できるかどうかである。顧客は、最初の見積もりが魅力的だったという理由だけでプライベートクラウド、専用ホスティング、コロケーションを更新するわけではない。プロバイダーが移行の苦痛を回避し、インシデント中に対応し、バックアップを理解可能に保ち、不正利用をクリーンに処理し、アドレスとルーティングの信頼を維持し、請求を予測可能にし、次の変更が危機にならないという自信を顧客に与えたために更新するのである。

代替手段のセットは具体的で規律がある。ハイパースケールクラウドは利用可能である。デベロッパークラウドも利用可能である。ローカルおよびリージョナルホストも利用可能である。リセラープラットフォームも利用可能である。社内サーバーも利用可能である。移行延期は常に利用可能である。Intrahost は、サポート記憶、EU 管轄、リソース制御、インフラ柔軟性の組み合わせが、それらの各代替手段よりも選ばれる価値がある理由を示さなければならない。

現在の公開証拠は、慎重なテーゼを支持している：Intrahost は、購入者が生の速度よりも継続性に支払う場合に重要である。証拠はまだ、テーゼを決定的にする私的事実を証明していない。それらの事実が利用可能になるまで、正しい判断は却下でも祝福でもない。Intrahost は、監視すべき現実のキプロスインフラプロバイダーであり、信頼できる公開リソース証拠と、ホスティング経済が常に現実になるポイントでテストされなければならない継続性のストーリーを持っている：移行、サポート、バックアップ、不正利用、施設依存、最初の重大なインシデント後の更新である。