要約
- 1 Cloud Lab s.r.o. は活動中のスロバキア企業であり、現在のサービスストアフロント、2025年のサービス収益 EUR262,866、有形固定資産純額 EUR125,593 を有しています。これらの事実は実際の事業運営を裏付けていますが、特定のデータセンターサイトの設置容量、所有権、エンジニアリング設計を確定するものではありません。
- レガシーAS20949 名である INCOSOFT は、インターネットレジストリで依然として企業に紐づいていますが、RIPE の測定によれば、AS20949 は 2023年7月以来、可視のアドレス空間を発信していません。1 Cloud Lab および ColoCall 名に関連する他のシステムは引き続きアクティブであるため、AS20949 単独では現在の顧客到達性の適切な代理指標にはなりません。
- ストアフロントは、大まかにウクライナおよび欧州連合のロケーションと表示された IaaS、プライベートインフラ、VPS、ベアメタル、バックアップスペース、ネットワークアクセス、DDoS 保護、Kubernetes を販売しています。欧州の施設を公に命名しておらず、サイトごとの容量在庫を公開しておらず、電力およびキャリアパスを特定しておらず、テスト済みのクロスサイト復旧結果を示していません。
- 標準契約条件は、商業上の約束に重要な制限を設けています。定量化された可用性コミットメント、サービス credit スケジュール、復旧目標を一切含まず、第三者の通信チャネルに対する責任を否認し、支払い不履行時の停止および後の削除を認めています。購入者は、バックアップ、可搬性、請求継続性、エスカレーションを管理的詳細ではなくエンジニアリング上の依存関係として扱うべきです。
古いネットワーク名は企業全体を表すわけではない
INCOSOFT はネットワークラベルとして残存しています。AS20949 の RIPE 登録では、自律システムはINCOSOFTと呼ばれ、関連組織は 1 Cloud Lab s.r.o. です。結果として得られる複合名はレコードの発見に有用ですが、複数の異なる事実（レガシールーティング ID、スロバキアの法人、商用サービスブランド、1 Cloud Lab または ColoCall 名を使用するより広範なネットワークリソースセット）を1行に圧縮しています。
法人の方が日付を特定しやすいです。スロバキアの商業登記は、1 Cloud Lab s.r.o.、会社番号 52 335 267 が 2019年6月6日に設立されたことを記録しています。登録住所は 2024年10月にブラチスラバ・カルロバ・ヴェスの Staré Grunty 3546/7A に変更されました。登録活動には、コンピュータサービスおよびコンピュータデータ処理に関連するサービスに加え、より広範な取引および管理活動が含まれます。RIPE NCC メンバーページも同じブラチスラバの所在地を示し、サービス対象地域としてスロバキアとウクライナを特定しています。
この継続性は重要ですが、どちらの住所も機械室の場所を証明するものではありません。企業の本社は、顧客ラックを収容せずに管理、郵便、契約機能を収容できます。1 Cloud Lab のウェブサイトは、自社をブラチスラバのデータセンターと説明し、コンフィギュレーターで EU ロケーションを提供していますが、その施設の番地を公開していません。規制対象またはレイテンシに敏感なデータがどこに保存されるかを決定する顧客は、建物、国、運営会社、許可されたフェイルオーバーロケーションを明記した契約スケジュールを依然として必要とします。
スロバキア企業自体よりも長い運営系譜の証拠もあります。サイトの企業歴史は、ColoCall データセンターが 2000年3月に設立され、同年8月に最初の顧客にサービスを提供したと説明しています。現在の 1 Cloud Lab ホームページは、20年以上にわたって機器とクラウドを管理してきたと述べています。これらの記述は、サービス運営およびブランドファミリーの伝統を説明するものであり、スロバキアの有限会社が 2000年に存在したと読むべきではありません。この区別はデューデリジェンスにおいて特に重要です。経験はチームまたは関連するウクライナ事業者に存在する可能性がある一方、契約上の責任は請求書に記載されたエンティティに帰属するためです。
顧客が実際に注文できるもの
サービスカタログは小規模プロバイダーとしては広範です。メインストアフロントは、クラウドインフラ、プライベートクラウドインフラ、ベアメタルサーバー、クラウドサーバー、バックアップスペース、Kubernetes に加え、クラウドディスク、ネットワークチャネル、DDoS 保護を掲載しています。その注文ページでは、多くのサービスでウクライナまたは欧州連合を選択できます。この組み合わせにより、1 Cloud Lab はローカルホスターとリージョナルインフラリセラーの間に位置付けられます。コンピュート、ストレージ、接続性をパッケージ化すると同時に、購入者がプロセッサクラス、メモリ、ディスク媒体、帯域幅を選択できる十分なハードウェア詳細を公開しています。
IaaS コンフィギュレーターは、CPU、RAM、HDD、SSD、NVMe 容量のプール、仮想ネットワーク、パブリックアドレス、ファイアウォールルール、バックアップスペースを提供します。最大1日でのプロビジョニングを宣伝しています。プライベートインフラページはさらに進み、1顧客専用の専用物理コンピュートノードと、フォールトトレランス用の予備サーバーを含むと説明しています。Intel E5、Intel Gold、Platinum、AMD Rome、Milan プラットフォームを提供し、ローカルおよび共有ストレージの選択肢があります。
これらの詳細は、カタログに存在する容量と障害に耐えられる容量の間の重大な違いを露呈します。ローカル NVMe は、仮想サーバーを1つのコンピュートノードにバインドし、移行不可と説明されています。共有クラウドストレージは、より柔軟な移動を可能にすることを目的としています。最速のローカル媒体を選択する購入者は、したがって一般的なクラウドラベルが示唆する復旧特性を放棄する可能性があります。プライベートインフラで提供される予備ノードは、電源が入り、ケーブル接続され、互換性があり、監視され、定義された時間内に障害ノードのワークロードを引き継げる場合にのみ意味を持ちます。公開ページは、オーケストレーション方法、受入しきい値、再構築時間、顧客間で保持される容量量を開示していません。
ベアメタルコンフィギュレーターも同様に具体的かつ曖昧です。Supermicro プラットフォーム世代、ECC メモリ、ローカルドライブ、RAID または HBA コントローラー、IPMI アクセス、帯域幅、オプションのバックアップスペースをリストし、準備期間は1〜3日とされています。利用可能な世代は、古い Intel E5 システムから新しい Intel スケーラブルプロセッサ、AMD Rome、Milan に及びます。この範囲は、特に価格に敏感なワークロードにとって商業的に有用ですが、スペアパーツの計画を中心に据えます。障害が発生したマザーボード、RAID コントローラー、ドライブは、ウェブページが製品ファミリーをリストしているからといって復旧するわけではありません。復旧は、該当サイトの互換性のある在庫と、それを取り付ける権限のある技術者に依存します。
仮想サーバーについては、VPS 注文ページは、1時間以内のプロビジョニング、選択可能なディスククラス、スナップショット、ファイアウォールルール、基本サポートを宣伝しています。より詳細なクラウドサーバーページは、ストレージが顧客データの2つのコピーを保持し、クラウドシステムは予約され地理的に分散されていると述べています。また、スナップショットは毎日スケジュールされるか手動で作成できると述べています。これらは有用なサービスクレームですが、いくつかの変数を未解決のままにします。レプリカが別々のラック、ホール、建物、または国を占有するかどうか、両方のコピーがコントロールプレーンを共有するかどうか、スナップショットがクラッシュ整合性かアプリケーション整合性か、復元がどの程度の頻度で実行されるか。
バックアップスペースサービスは、FTP、FTPS、SFTP、SCP、rsync をサポートし、選択可能な転送速度と、1 Cloud Lab ネットワーク外のトラフィックのオプションを提供します。これは比較的可搬性のあるアクセス方法のセットです。それでも、バックアップが独立しているという証拠にはなりません。本番サーバーとバックアップリポジトリが施設、電源システム、管理資格情報、またはストレージコントローラーを共有する場合、1つのインシデントが両方に影響を与える可能性があります。顧客は、リポジトリの物理的な場所、不変性制御、保存ルール、復元スループット、削除動作を確認してから、それを災害復旧コピーと呼ぶ必要があります。
最新のサービス追加は Kubernetes です。Kubernetes 注文ページは、ウクライナまたは EU のクラスターを提供し、インフラはウクライナのデータセンターで稼働していると説明しています。別のKubernetes 説明は、ウクライナのインフラは地下にあり、Tier III レベルのエンジニアリング信頼性を満たしていると述べています。サイトの 2025年9月の発表は ColoCall を指名し、注文を colocall.net に誘導しています。これらのページは積極的にメンテナンスされたオファーを示していますが、ロケーションがストアフロントの言語やドメインから推測されるのではなく、注文ごとに指定されなければならない理由も示しています。
財務諸表は活動、資産、外部依存を示す
最新のスロバキアの財務諸表は、マーケティング言語だけよりも強力な運営の証拠を提供します。公式の財務諸表登録エントリは、会社設立以来の年次提出書類をリストしています。2025年財務諸表は、2026年7月7日に提出され、売上高 EUR262,866 を報告し、すべてサービスからの収益として計上されています。税引後利益 EUR31,331、総資産 EUR255,257 を報告しています。
貸借対照表はまた、年末時点の有形固定資産純額 EUR125,593 を示しています。構築物 EUR22,395、動産および動産コレクション EUR103,198。これは物理的な設備を保有するビジネスと一致します。ラック数、サーバー数、データセンター所有権を推測するには十分ではありません。会計カテゴリは資産を集約し、それらがどこに設置されているか、担保に入っているか、機器が1つまたは複数のロケーションにサービスを提供しているか、構築物のラインが技術施設を表すかを特定しません。
年々の変動は文脈を追加します。サービス収益は 2024年の EUR317,742 から 17.3% 減少し、税引後利益は EUR55,741 から 43.8% 減少しました。総資産は 10.3% 増加しましたが、有形固定資産純額は EUR144,094 から 12.8% 減少しました。銀行預金は EUR115,025 に増加しました。これらの変化は単独では窮迫や拡大を証明するものではありません。これらは、設備ベースが減価償却されており、報告された収益が年ごとに大きく変動する可能性がある、収益はあるが控えめなビジネスを描写しています。
コスト構造は、レジリエンスにとってさらに有益です。購入サービスは 2025年に EUR188,549 で、サービス収益の 71.7% に相当し、材料、エネルギー、その他の非貯蔵供給品は EUR9,152 でした。計算書は人件費を記録していません。これは、誰もサービスに従事していないことを証明するものではありません。取締役、請負業者、関連会社のスタッフ、サプライヤーが他の見出しの下で労働力を提供する可能性があります。これは、経済活動の多くがスロバキア企業の外部から購入したサービスに存在し、大規模な給与計算にはないことを示しています。
ホスティングプロバイダーにとって、これは所有権の境界の手がかりです。施設スペース、電力、トランジット、リモートハンズ、ハードウェアメンテナンス、ライセンス、軽減容量、関連会社間サービスはすべて購入サービスとして表示される可能性があります。プロバイダーはそのようなモデルで確実に運営できますが、その継続性は部分的にその契約の継続性です。リース紛争、未払いのキャリア請求書、利用できない請負業者、または変更された関連当事者契約は、顧客向けの仮想マシンが技術的に健全であっても、顧客に影響を与える可能性があります。
短期負債はその境界を理解する必要性を強化します。2025年の計算書は、EUR131,208 の流動負債を示し、これには買掛金 EUR37,982、株主または団体に対する債務 EUR91,469 が含まれます。銀行借入は報告されていません。これらの数字は破綻の予測ではなく、会社は相当な現金を保有していました。それらは、顧客が、どの重要な資産と契約がスロバキアエンティティに属し、どの資産が関連事業者に属し、どの資産が無関係の施設またはキャリアによって供給されているかを特定すべき理由を示しています。継続権は、契約がこれらの依存関係を明示的にマッピングするときに最も強力になります。
ルーティング証拠は静かなレガシーASN をアクティブネットワークから分離する
自律システムはデータセンターではなく、データセンターは独自のルートを発信する必要はありません。それでも、ルーティングの可視性は、主張されたネットワーク ID が現在パブリックアドレス空間を運んでいるかどうかをテストするための数少ない独立した方法の1つです。この場合、それは解釈を実質的に変更します。
RIPEstat の AS20949 の現在の概要は、ホルダーを "INCOSOFT 1 Cloud Lab s.r.o." と特定していますが、システムはアナウンスされていないとマークしています。そのルーティングステータスデータは、最後に観測されたルートが 2023年7月25日の 193.108.236.0/23 であったと述べています。2026年7月12日時点で、326の IPv4 または 322の IPv6 RIPE RIS ピアのいずれも AS20949 を認識しておらず、アナウンスされたアドレス空間はゼロでした。Hurricane Electric のAS20949 レコードは、独立して、2023年7月26日以降、グローバルテーブルに表示されていないと述べています。
登録自体は消えていません。RIPE whois データは、AS15497、AS25521、AS29442 を指名するポリシーエントリを保持し、割り当てステータスを保持しています。登録と運用は異なる状態です。割り当てられた番号は、そこからのルートがパブリックインターネットに到達しない間もレジストリに残ることができます。顧客にとって、実際的な質問は、AS20949 が紙の上に存在するかどうかではなく、購入したサービスが実際にどの ASN とプレフィックスを使用するかです。
他の 1 Cloud Lab に関連するネットワークはアクティブです。RIPEstat は AS206110 を1 Cloud Lab s.r.o. と特定しています。2026年7月12日には、1,024 アドレスをカバーする 5つの IPv4 プレフィックス、RIPE の IPv4 コレクター間での完全な可視性、および1つの観測されたネイバーを示しました。この単一ネイバーの観測は、測定時点でのスタブ状のパブリックトポロジを示唆しています。すべての顧客が1つの物理ルートしか持たないことを証明するものではありません。プロバイダーは内部リンク、他の発信元、別のネットワークから供給されたアドレスを使用する可能性があるためです。しかし、実際のサービス接続を尋ねる価値があるようにします。
AS15497は、RIPEstat によって "Colocall 1 Cloud Lab s.r.o." と説明され、はるかに大規模でした。同日に、16,896 アドレスをカバーする 19の IPv4 プレフィックス、1つの IPv6 プレフィックス、37の観測されたネイバーがありました。AS12837は、ウクライナの "1 CLOUD LAB" LLC に登録され、9つの IPv4 プレフィックス、1つの IPv6 プレフィックスをアナウンスし、5つの観測されたネイバーがありました。これらのアクティブシステムは、ストアフロントのウクライナおよび EU サービスのモデルに適合しますが、名前だけでは、どの法人が各ラックを運営し、各顧客契約を担当し、各アドレスブロックを制御するかは確定しません。
したがって、主要な結論は「ネットワークは非アクティブ」よりも狭いものです。AS20949 はパブリック発信元として非アクティブですが、1 Cloud Lab および ColoCall 名の下でのサービス活動は他のリソースを通じて継続しています。顧客は、各サービスのロケーションの実際の ASN、プレフィックス、アップストリーム、施設を受け取るべきです。そのマッピングがなければ、ルート多様性の主張は、同じ物理ファイバー、ルーター、建物入口、またはアップストリーム組織に収束する2つの商業ラベルを誤って数える可能性があります。
ラックと電力が使用可能な上限を定義する
クラウド容量は分割可能な単位で販売されますが、その供給は分割不可能なオブジェクト（サーバー、ドライブシェルフ、スイッチ、クロスコネクト、電源回路、ラック）で到着します。設置容量と使用可能容量の差は、障害とピークのために保持される予備です。プロバイダーは100ユニットのコンピュートを所有し、競合なしでノード障害に耐えるつもりであれば、それよりもはるかに少ない量しか販売できない可能性があります。逆に、物理的上限に近いところまで販売し、ベストエフォートの復旧に依存することもできます。
1 Cloud Lab のプライベートインフラコンフィギュレーターは、フォールトトレランスのために1台の追加サーバーが含まれると述べています。これは予備問題の認識として歓迎すべきです。公開資料は、スペアが顧客専用か、顧客間で共有か、単に提案された部品表の一部かを述べていません。また、障害ドメインを明記していません。同じラック内の1台の追加ホストは、一部のサーバー障害から保護しますが、トップオブラックスイッチ、配電ユニット、冷却ゾーン、建物、またはアクセス不能な都市の障害からは保護しません。
クラウドページは、システムは地理的に分散され、ストレージは2つのコピーを保持すると述べています。地理は、1つのキャンパス内の2つの部屋、2つの都市、または2つの国を意味する可能性があり、それぞれ異なる保護レベルを提供します。2つの同期コピーは、コントロール障害を共有したり、一緒に破損したりすることもあります。サービスページは、障害ドメイン図、レプリケーション距離、クォーラム設計、最近のフェイルオーバー結果、またはサイト間のリンクが失われた場合の対処方法を公開していません。
電力も同様に、その不在を通じてのみ可視です。標準契約条件は、請負業者に電力供給と気候条件の維持を責任付けていますが、公開ページは、欧州ロケーションのユーティリティ供給、UPS トポロジ、発電機の自律性、燃料契約、またはテスト済みのメンテナンス取り決めを特定していません。ウクライナのオファーについては、地下サイトの記述は物理的保護を高いレベルで扱いますが、独立した電力の持続時間や長期にわたる混乱時の修理のロジスティクスは扱いません。
2025年財務諸表の材料、エネルギー、その他の非貯蔵供給品の EUR9,152 という行は、すべての顧客インフラの総電力コストとして扱われるべきではありません。リースまたはバンドルされた施設サービスは、電力費用の多くを購入サービスに入れる可能性があります。その会計上の可能性は、資産とサプライヤーの境界が重要であるもう1つの理由です。会社が電力込みでラックを賃貸する場合、施設運営者のメンテナンスおよび credit 取り決めは、顧客の可用性チェーンの一部になります。
ハードウェア在庫は、異なる方法で復旧を制限します。カタログは複数のプロセッサ世代、ディスクタイプ、コントローラーの選択肢に及びます。交換は、同じボード、メモリタイプ、ドライブインターフェース、ファームウェアがオンサイトにある場合に最も迅速です。部品を調達し、国境を越えて出荷し、移行を必要とするプラットフォームに置き換える必要がある場合、遅くなります。専用サーバーの説明は、障害が発生したリース機器は、サプライヤーを待たずに24時間365日体制で交換されると述べています。最大交換時間を約束していません。「最短時間」は、4時間の修理約束とは運用上異なります。
トランジット多様性は物理的切断を生き残らなければならない
通信チャネルページは、ワールドおよびウクライナの帯域幅、ファイアウォールルール、クリーントラフィック、インターネットエクスチェンジを介したプライベートピアリングを販売しています。また、プロバイダーのサイトで接続を提供し、顧客が別途輸送を手配することもできると述べています。これは有用な柔軟性ですが、いくつかの可能な責任境界を作り出します。1 Cloud Lab がサーバーとローカルポートを提供し、別の会社がメトロ回線、エクスチェンジがピアリングファブリック、1つ以上のアップストリームがグローバルルートを提供する可能性があります。
パブリック BGP レコードは、AS20949 に対して歴史的に複数の指名された関係を示し、AS15497 は現在多くの観測されたネイバーを持っています。どちらの事実も、特定の顧客の物理的パス多様性を証明するものではありません。2つのセッションは同じダクト内のファイバー上で実行できます。2つのキャリアは同じ卸売ネットワークから容量を購入できます。IPv4 と IPv6 は異なる可能性があります。DDoS サービスは、独自の障害が到達性を除去するスクラバーを介してトラフィックをリダイレクトできます。
DDoS ページは、ウクライナおよび EU のデータセンターで最大1テラビット/秒の攻撃の軽減を宣伝しています。古いニュース記事は1.2テラビット/秒を主張していました。これらはベンダーの声明であり、公開ページは軽減パートナー、スクラビングロケーション、顧客のポートに配信されるクリーントラフィック容量、カバーされる攻撃クラス、または迂回が失敗した場合のサービス credit を特定していません。購入者は、ヘッドラインの吸収容量と自身のアプリケーションで利用可能なクリーン帯域幅を区別すべきです。
適切な多様性テストは、建物入口、ミートミールーム、ルーター、長距離プロバイダー、アップストリーム ASN のレベルで A および B 側パスを尋ねます。また、両方のパスがメンテナンス中に完全な契約トラフィックを運ぶことができるか、ルートフィルターと RPKI 認証が最新か、プロバイダーが負荷下でフェイルオーバーを実行したかを尋ねます。いくつかの線があるインターネットマップは、1つの線を顧客影響なしに削除できることを示すメンテナンス記録と同等ではありません。
修理期間はサポートクレームを結果に変える
連絡先ページは、営業時間 10:00 から 18:30 を示し、当直シフトとテクニカルサポートが24時間365日稼働していると述べています。これは関連する可用性クレームです。それは、スタッフの深さ、毎時の言語、エスカレーションの役割、オンサイトプレゼンス、または重要度レベルに付随する応答および復旧目標を開示していません。
小規模インフラプロバイダーは、顧客が経験豊富なエンジニアに直接連絡できるため、優れたサポートを提供できます。また、サービス復旧に必要な知識やアクセスを少数の人が保持する場合、集中リスクに直面する可能性もあります。財務諸表に人件費がないことは、スタッフモデルを正当なデューデリジェンスの質問にしますが、サービスの質が低い証拠ではありません。答えは、契約エンジニアまたは関連事業者が雇用するスタッフかもしれません。重要なのは、インシデントが重複したり、施設への輸送が制限されたりした場合に、顧客契約がそれらの可用性を確保するかどうかです。
したがって、いくつかの障害経路は労働力に収束します。故障したドライブは、誰かが正しいベイと交換品を特定する必要があります。故障したルーターは、コンソールアクセスを必要とする場合があります。バックアップ復元は、ストレージ管理者を必要とする場合があります。顧客の移行は、古いプラットフォームと新しいプラットフォームの両方を同時に利用可能にする必要がある場合があります。これらのタスクが同じ当直エンジニアに依存している場合、ハードウェアの名目上の冗長性は依然として人的ボトルネックに直面する可能性があります。
サービス資料は有用なリモートメカニズムを示しています。IPMI はベアメタルで提供され、PXE ブートが物理サーバーに導入され、パネルは一部の設定変更を許可します。リモートコントロールは移動時間を短縮しますが、障害が発生したハードウェア、ケーブリング、または電力に対する手作業を置き換えるものではありません。また、アクセスセキュリティの質問を提起します。管理インターフェースは、分離、強力な認証、ログ記録、およびメインの顧客ネットワークがダウンしているときにアクセスするためのテスト済みの方法を必要とします。
購入者にとって、修理のコミットメントは測定可能であるべきです。応答時間は復旧時間ではありません。チケットは5分で確認できますが、互換性のあるコントローラーが翌日到着します。有用な契約は、重要度、確認、回避策、修理、スペアパーツの在庫前提、メンテナンス通知、エスカレーション連絡先、補償を特定します。これらの詳細は、公開標準契約条件では定量化されていないため、存在する場合は注文固有のサービススケジュールで取得する必要があります。
請求は可用性の一部である
インフラは、電気的にだけでなく管理的にも障害が発生する可能性があります。標準契約条件は、最初の請求書が公共契約の承諾を構成し、一部のコンフィギュレーターに表示されるより短い時間にもかかわらず、サービスを提供するために最大7営業日を認めると述べています。毎月の請求書は8銀行日以内に支払期日が到来します。全額または一部の不払いは、請負業者にサービスを停止するか契約を終了することを許可します。
条件はまた、請負業者が提供するドライブ上の顧客情報が、契約終了後、または不払いやその他の違反による停止から15日後に削除される可能性があると認めています。文言は、顧客の復旧ニーズに合わせた猶予期間を約束していません。したがって、請求書の配信失敗、銀行審査、請求金額の紛争、買掛金担当者の変更は、インフラインシデントになる可能性があります。顧客は、冗長な請求連絡先を使用し、更新と請求ステータスを監視し、破壊的行動の前に技術的エスカレーションが発生することを確認する必要があります。
責任は鋭く制限されています。請負業者は、条件に従い、電力、気候、および提供する機器の動作状態に対する責任を受け入れます。グローバルインターネットおよび接続先の第三者の通信チャネル、ならびに幅広いカテゴリの顧客および第三者損失に対する責任を否認します。文書は、アップタイム率、サービス credit スケジュール、復旧時間目標、復旧ポイント目標、計画メンテナンス許容、またはサポート重要度テーブルを明記していません。
契約はまた、いずれかの当事者が少なくとも15暦日前の通知で終了することを許可しますが、EU データ法は現在、データ処理サービス間の切り替えについてより詳細な期待を設定しています。データ法は2025年9月12日から適用されています。そのクラウド切り替え規定は、エクスポート可能なデータおよびデジタル資産をカバーする書面による条件、最大通知期間、移行期間、移行後の取り出し、その他の事項を要求しています。2027年1月12日からは、規制の条件に従い、切り替え手数料も撤廃されます。
これは単なる法務起草上のポイントではありません。可搬性は復旧メカニズムです。仮想ディスクが独自のインターフェースを介してのみ利用可能で、スナップショットをエクスポートできず、出力容量が小さすぎる、または大規模データセットのコピーに数週間かかる場合、顧客は迅速に脱出できません。1 Cloud Lab のバックアップサービスの標準プロトコルは有用ですが、公開条件は、仮想マシン、ネットワーク、ファイアウォールルール、スナップショット、オブジェクトストア、Kubernetes 状態のエクスポート形式を列挙していません。出口テストは、代表的なワークロードの転送を計時し、宛先で起動することを確認する必要があります。
データロケーションには名前付きサイトが必要であり、地域トグルでは不十分
ウクライナ/EU セレクターは商業的にシンプルですが、データガバナンスの決定には不十分です。「EU」は施設ではなく、別の国のサポートスタッフがシステムにアクセスできるかどうか、バックアップが国境を越えるかどうか、フェイルオーバーが選択されたロケーションの外にデータを移動するかどうかを顧客に伝えません。「ウクライナ」は管轄区域としてより具体的ですが、依然として複数の物理的および運用リスクを含んでいます。
標準契約条件には、短いデータ処理セクションが含まれています。請負業者は、顧客から委託された個人データを受け入れ、機密を保持し、適切な技術的、組織的、IT 対策を実施すると述べています。条件は、サブプロセッサー、処理場所、侵害通知のタイミング、監査証拠、返却形式、詳細な削除方法を指定していません。これらの項目は通常、より完全なデータ処理契約およびサービススケジュールに属します。
一般データ保護規則は、管理者が十分な保証を提供するプロセッサーを使用することを要求し、物理的または技術的インシデント後に個人データの可用性とアクセスをタイムリーに復元する能力を含む適切なセキュリティを要求します。特定のアーキテクチャを自動的に準拠インフラに変えるわけではありません。購入者は依然として制御をリスクに適合させ、契約上のコミットメントを取得し、処理が発生する場所を確認する必要があります。
NIS2 指令は、別途、クラウドコンピューティングおよびデータセンターサービスプロバイダーをデジタルインフラの対象範囲で特定し、エンティティが国内実施の下で範囲内にある場合にサイバーセキュリティリスク管理措置を求めています。この文脈は、明確な法人および施設マップの価値を高めます。スロバキア企業とウクライナ運営の間で共有されるブランドは、地域的な回復力をサポートする可能性がありますが、インシデント報告、サプライチェーン管理、および事業継続のための正確な責任も必要とします。
したがって、各注文について、顧客は4つのロケーション事実を取得する必要があります。プライマリコンピュートがどこで実行されるか、すべてのレプリカとバックアップがどこにあるか、管理者がどこからアクセスできるか、各コンポーネントを供給する法人はどれか。これらの事実は、通常運営中だけでなく、メンテナンス中や緊急フェイルオーバー中も真実であるべきです。
1つの依存関係が失敗するとどうなるか
最も可能性の高い障害は、1つの劇的なイベントではなく、連鎖です。ローカル NVMe デバイスが故障した物理サーバーを考えてみてください。サーバーはそのノードに固定されているため、ライブマイグレーションは利用できません。エンジニアは障害を診断し、互換性のある在庫を見つけ、デバイスを交換し、データを復元する必要があります。最新のコピーが同じサイトのバックアップスペースにある場合、ラックまたは電力インシデントが両方に影響を与えた可能性があります。別のサイトにある場合、復旧速度はトランジット容量に依存します。請求紛争中にアカウントが停止された場合、コピーへのアクセスは技術的な質問ではなく商業的な質問になる可能性があります。
ルート障害は別の連鎖を生み出します。顧客プレフィックスは、AS20949 ではなく、AS206110、AS15497、AS12837、またはプロバイダー割り当てスペースを介して運ばれる可能性があります。復旧パスは、どのネットワークがルートを発信するか、別のアップストリームがそれを受け入れるか、有効な認証が存在するか、代替物理回線がまだ電力が供給されているルーターに到達するかに依存します。歴史的なポリシーエントリだけでは不十分です。インシデントの前に現在のサービス接続がわかっている必要があります。
施設障害はより広範囲です。コンピュートとストレージのコピーが1つのサイトを共有する場合、両方が停止する可能性があります。2番目のサイトが存在するが予約コンピュートがない場合、データは安全でもアプリケーションは利用できません。コンピュートは利用可能でも IP アドレスが移動できない場合、顧客は DNS 変更とキャッシュ待ちを必要とする可能性があります。2番目のサイトが別の管轄区域にある場合、復旧はロケーションコミットメントと競合する可能性があります。「地理的に分散」というフレーズは、これらの選択のいずれも解決しません。
サポート障害は、他のすべてのイベントを長引かせる可能性があります。24時間連絡可能は貴重ですが、復旧にはアクセス、権限、専門知識が必要です。同じエンジニアが電力アラーム、ルート変更、ハードウェア交換を処理している可能性があります。重要なサービスを持つ顧客は、エスカレーションが各サイトにローカルかどうか、ネットワークチームと施設チームが別々かどうか、スロバキアの契約会社が関連事業者に連絡できない場合に誰が行動できるかを知る必要があります。
最後に、プロバイダー契約の障害はコンポーネント障害よりも長続きする可能性があります。スロバキアの財務諸表における購入サービスの高いシェアは、第三者および関連当事者契約が経済的に重要であることを意味します。施設リース、キャリアアカウント、ライセンス、サポート契約が終了した場合、サーバーが壊れていなくてもワークロードは秩序立った移動を必要とする場合があります。したがって、契約の可搬性と定期的に実行される顧客の出口は、可用性エンジニアリングの一部です。
誰が影響を受けるか
即時のユーザーは、中小企業、開発者、オンラインサービス、および地域ホスティング、直接サポート、または低コストハードウェアを求める機関である可能性が高いです。設定可能なベアメタル、ウクライナの接続性、EU 配置、使い慣れたバックアッププロトコル、またはグローバルクラウドの一般的なサポートキューではなくエンジニアと話す能力に惹かれる可能性があります。
これらの顧客はまた、内部レジリエンスが低い場合があります。小規模企業は、便利なため、本番アプリケーション、バックアップ、DNS、メールを1つのプロバイダーに置く場合があります。ソフトウェアチームは、2つのストレージコピーが災害復旧に等しいと想定する場合があります。規制上の理由で EU ロケーションを選択する組織は、公開資料が正確なサイトとフェイルオーバー地理を明記していないことに気付かない可能性があります。サービスが失敗すると、下流のユーザーはアクセスできないウェブサイト、停止したトランザクション、利用できないレコード、または遅延した通信を経験します。
影響は契約顧客を超えて広がる可能性があります。ホストされたドメインと API は他のビジネスをサポートし、バックアップリポジトリは個人データを保持する可能性があり、Kubernetes クラスターはパブリックサービスを実行する可能性があり、専用サーバーはレガシーアプリケーションの唯一のコピーである可能性があります。不正使用処理とルートセキュリティもより広いインターネットに影響を与えます。これが、プロバイダーの控えめな収益がすべてのテナントにとって控えめな結果を意味しない理由です。
顧客にも責任があります。ベアメタルページは、ユーザーがデータを正しく配置し、バックアップを保持する必要があると明示的に述べています。プロバイダーは、顧客がデータベースをクワイエスしない場合、アプリケーションを整合させることはできません。また、施設レベルの予備ノードは、1つの IP アドレスをハードコーディングしたり、障害が発生したサーバーにのみ暗号化キーを保存したりする顧客を救済することはできません。レジリエンスは共有されますが、プロバイダーは顧客が自身のレジリエンスを設計できるように、その部分について十分に開示する必要があります。
信頼できる復旧設計は4つの層を分離する
1 Cloud Lab のサービスミックスでは、復旧はコンピュート、ストレージ、ネットワーク ID、管理アクセスを分離することから始めるべきです。2つの仮想マシンを異なるホストに配置することは有用ですが、両方のホストが同じストレージアレイ、スイッチ、電源供給に依存している場合、コンピュート層のみを保護します。2つのストレージコピーを保持することは有用ですが、両方のコピーが1つのコントローラーを介して管理されるか、同じアカウントでアクセス不能になる場合、データ層のみを保護します。2番目のキャリアは有用ですが、アプリケーションが生存サイトで起動できない場合、到達性のみを保護します。
コンピュート層では、宣伝されている追加のプライベートインフラノードは、その目的を開示されるべきです。ホットスペアの場合、プロバイダーはワークロードがどれだけ迅速に再起動するか、ソフトウェアライセンスがそれに従うかを述べるべきです。アクティブクラスターメンバーの場合、プロバイダーは1つのノードが故障した後に残る容量を述べるべきです。通常すべてのノードを80%使用率で消費する顧客は、すべてのコンポーネントが設計通りに機能していても、障害を吸収する余地がない場合があります。アドミッションコントロールは、生のサーバー数ではなく、使用可能容量を決定します。
ベアメタルは異なる約束を必要とします。スペアシャーシは、必ずしも顧客のドライブ、コントローラー、ネットワークカード、ファームウェアを受け入れるとは限りません。最も信頼できる取り決めは、文書化された交換クラスと、起動可能なオフホストコピー、テスト済みの再構築シーケンスを組み合わせます。レガシープラットフォームの場合、プロバイダーはどの部品がローカルに保持され、いつ代替が移行になるかを特定する必要があります。IPMI を使用する顧客はまた、本番ルーティング障害が復旧コンソールを奪わないように、管理ネットワークへの別個の強力に保護されたルートを保持する必要があります。
ストレージ層では、スナップショットとバックアップは別々のジョブを必要とします。ローカルスナップショットは不良アップデートからの高速ロールバックを提供しますが、ソースアレイの障害ドメインを共有する可能性があります。レプリケートディスクは、デバイス障害後もアプリケーションを実行し続けることができますが、削除や破損を複製する可能性があります。別のサイトに保持され、復元によってテストされた別途認証されたバックアップは、より広範なイベントに対処します。したがって、ストレージが2つのコピーを保持するという公開クレームは、出発点であり、完全な保護設計ではありません。
転送速度は、復旧の物理的限界を設定します。持続的な1ギガビット/秒リンクで10テラバイトを移動するには、プロトコルオーバーヘッド、競合、検証の前に22時間以上かかります。100メガビット/秒では9日以上かかります。したがって、バックアップコンフィギュレーターの選択可能な伝送速度は可用性の決定です。顧客は、夜間コピーウィンドウのバックアップ帯域幅だけでなく、復旧目標に合わせて復元帯域幅をサイジングし、引用されたレートがサイト全体のインシデント中に利用可能であることを確認する必要があります。
ネットワーク層では、最もクリーンな設計は、1つのプロバイダー発信プレフィックスをアプリケーションへの唯一のパスにしないことです。規模に応じて、顧客はプロバイダー独立アドレッシング、2番目の DNS エンドポイント、外部トラフィックマネージャー、または事前設定された代替サイトを使用できます。各オプションにはコストと時間制限があります。小規模顧客はプロバイダー割り当てアドレスに合理的に留まることができますが、DNS の TTL、証明書の依存関係、および代替エンドポイントを公開するために必要な手順を知っておく必要があります。
管理層は最後の依存関係です。アカウント資格情報、暗号化キー、DNS 制御、復旧手順は、ホストされたサービスが利用できない場合でも利用可能でなければなりません。パスワードマネージャー、メール、ID プロバイダーがすべて障害環境内で実行されている顧客は、サポートに対して認証できない可能性があります。1 Cloud Lab の24時間連絡可能クレームは、顧客が帯域外の連絡方法を持ち、プロバイダーが利用不能なシステムに依存せずに許可された緊急要求を検証できる場合に、より有用になります。
クロスサイト復旧は、1つの演習で4つの層すべてを組み合わせる必要があります。代表的なアプリケーションがプライマリロケーションで停止され、データが他の場所で復元または昇格され、ネットワークアクセスが変更され、オペレーターが独立した管理パスを通じて接続し、ユーザーが結果を検証します。テストはまた、移動を逆転させる必要があります。プライマリサイトに戻ることは、離れることと同じくらいリスクがあるためです。これが、地理的分散の一般的な主張を信頼できる顧客成果に変える証拠となるでしょう。
信頼を高める証拠
運用証拠は、薄い公開名が最初に示唆するよりも強力です。ライブストアフロント、最近のサービスローンチ、アクティブなスロバキア企業、年次財務提出書類、有形資産、LIR メンバーシップ、および関連するネットワーク ID の下での可視アドレススペースがあります。これは単に死んだウェブサイトに付随する休眠登録ではありません。
証拠が施設固有ではないため、信頼は強いとまではいきません。決定的なアップグレードは、欧州およびウクライナのサイト、その運営者、および各サービスに責任を負う法人を指名する現在のサービススケジュールまたは保証パックです。ラックまたはホールの障害ドメイン、ユーティリティおよび発電機設計、キャリア入口、アップストリーム、予約コンピュート、ストレージレプリケーション境界、バックアップ地理、リモートハンズカバレッジを特定する必要があります。認証クレームは、一般的なティアラベルではなく、指名されたサイトと現在の範囲に関連付ける必要があります。
設計の散文よりも運用証明が重要です。有用な証拠には、最近の発電機および転送スイッチテスト、顧客中断なしで実行されたメンテナンス、サンプルハードウェア交換記録、ネットワーク外部から観測されたルートフェイルオーバー、およびセカンダリコピーからのアプリケーションの完全復元が含まれます。結果は、経過時間、データ損失、例外、および低下中の利用可能容量を明記する必要があります。
商業的証明も同様に重要です。完全なサービス契約は、アップタイムおよびサポート目標、メンテナンス通知、エスカレーション、サービス credit、サブプロセッサーおよびロケーションリスト、インシデント通知、データエクスポート形式、取り出し期間、削除方法、および出口時の支援を追加する必要があります。顧客は、それが重要になる前に、代表的なワークロードでこれらの条件をテストする必要があります。
それまでは、適切な証拠グレードは中程度です。1 Cloud Lab は、現在のビジネスと物理的機器の信頼できる兆候を持ち、その運営名に関連するアクティブなネットワークが可視です。しかし、公開記録は、部外者が顧客サービスを請求書から法的運営者、ラック、電力チェーン、トランジットパス、スペアパーツ、バックアップコピー、テスト済み復旧まで追跡することを許可しません。ホストされたインフラにとって、そのトレースは、注文できる容量と修理期間を通じて信頼できる容量の違いです。