CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED のホスティング容量

概要

VNNIC の公開インターネットリソース会員リストには、2023年11月22日付で EDIGI-VN の下に Cong ty TNHH Truyen thong va Cong nghe Cloud Data が含まれています。APNIC のAS151872 の RDAP レコードは、ベトナムの EDIGI-VN を特定し、アクティブステータスと2023年11月16日の登録イベントを示しており、RIPEstat のwhois ビューは、英語名 CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED とホーチミン市の住所を示しています。
AS151872 はパブリックに到達可能です。RIPEstat のAS 概要は、2026年7月12日に AS がアナウンスされたことを示し、ルーティングステータスビューは、3つの IPv4 プレフィックス、4つの IPv6 プレフィックス、1,024の IPv4 アドレス、4つの IPv6 /48、すべての325の RIS IPv4 ピアとすべての322の RIS IPv6 ピアへの可視性、1つの観測されたネイバーを示しました。
現在のプレフィックスセットは運用上混在しています。RIPEstat のアナウンスドプレフィックスビューには、157.66.198.0/23、160.30.10.0/24、160.30.11.0/24、2001:df3:e4c0::/48、2001:df3:e8c0::/48、2401:9760::/48、2401:9920::/48がリストされています。APNIC のレコードは、これらのプレフィックスのいくつかを、EDIGI-VN ではなく、他のベトナムのラベルに結び付けています。
会社名が付された IPv4 ブロックは、現在の AS151872 の証明にはなりません。APNIC の203.145.46.0/23 RDAP レコードは EDIGI-VN と CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED を指名していますが、RIPEstat のプレフィックス概要は、そのブロックが AS150862、MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED によって発信され、AS150862 の RPKI チェックが有効であることを示しました。
公開証拠グレードは中程度～弱いです。ルート起点は稼働しており測定可能ですが、公開記録は、所有するデータセンタースペース、ラック数、予備ハードウェア、マルチサイトサービス、可視化された FPT パスを超えるトランジットの多様性、顧客移行権、修理期間を決定するサポート権限を証明するものではありません。

有用な事実は AS151872 であり、ブランド化されたクラウドマップではない

公開記録は、小さいながらも具体的な番号リソース ID から始まります。VNNIC のインターネットリソース会員リストには、EDIGI-VN の下に Cong ty TNHH Truyen thong va Cong nghe Cloud Data が2023年11月22日付で含まれています。APNIC のAS151872 RDAP レコードは、ハンドル AS151872、名前 EDIGI-VN、国 VN、アクティブステータスを示しています。RIPEstat のAS151872 の whois レコードは、これを CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED に拡張し、ベトナム、ホーチミン市、タンフー区、フータイン区、トアイゴックハウ338/22番地をリストしています。

これで、ルーティングされた自律システムレコードの背後にある企業を特定するのに十分です。しかし、クラウドプラットフォームを特定するには十分ではありません。AS レコードには公開施設リスト、キャビネット数、名前の付いたデータホール、公開されたリカバリリージョン、メンテナンスカレンダー、番号に紐づいたカスタマーフェーシングのサービスレベル保証はありません。ホスティング容量を購入する顧客にとって、その違いは重要です。登録された AS は、誰がルートを発信しているかを説明できます。しかし、サーバーがどこにあるか、どの配電ユニットが給電しているか、誰がリモートハンドアクセスを持っているか、何台の予備ディスクがサイトにあるか、顧客がプレッシャー下でデータを移動できるかを言うことはできません。

次の証拠層は現在のルーティングです。RIPEstat のAS 概要は、AS151872 が2026年7月12日にアナウンスされたことを示しています。ルーティングステータスビューは、2026年7月11日16:00 UTC のクエリ時間において、AS がすべての325の IPv4 RIS ピアとすべての322の IPv6 RIS ピアから可視であることを示しました。また、1つの観測されたネイバーも示しました。これは、古い会社のリストよりも強いシグナルです。ネットワークがグローバルルーティングテーブルに存在することを示しています。しかし、それでもルートの後ろにどの製品があるかを示していません。

これが、この会社を実証済みのデータセンター事業者ではなく、ホスティング容量の依存関係として評価すべき理由です。購入者は AS151872 を監視できます。購入者はそのプレフィックスへのルートをテストできます。購入者はルート起点認証、サポートエスカレーション、輸出条件を尋ねることができます。購入者ができないことは、公開 AS レコードを、CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED が特定の建物を所有している、特定のデータホールを管理している、またはセカンドサイトに予備容量を持っているという主張に変えることです。

アクティブなプレフィックスセットは本物だが、単純な所有権の証明ではない

RIPEstat のアナウンスドプレフィックスデータは、6月下旬から2026年7月12日の期間に、AS151872 の現在のリソースとして、157.66.198.0/23、160.30.10.0/24、160.30.11.0/24、2001:df3:e4c0::/48、2001:df3:e8c0::/48、2401:9760::/48、2401:9920::/48の7つをリストしています。BGP.Tools のAS151872 ページは、同じ大まかな形状を表示しました：3つの IPv4 プレフィックス、4つの IPv6 プレフィックス、1つのアップストリームと1つのピアがそのサービスから可視です。IPIP.NET のAS151872 ページも同様に、3つの IPv4 プレフィックス、4つの IPv6 プレフィックス、1,024の IPv4 アドレスを示しました。

アクティブなプレフィックスに付与されたラベルは、運用のストーリーをより複雑にします。APNIC の157.66.198.0/23 RDAP レコードは、DAZITT-VN と DAZI MARCOM CO., LTD を特定し、EDIGI-VN ではありません。APNIC の160.30.10.0/23 RDAP レコードは、IPXO-VN と IPXO Technology Company Limited を特定します。APNIC の2001:df3:e4c0::/48は GENLOGIN-VN、2001:df3:e8c0::/48は CLEMAX-VN、2401:9760::/48は THCLOUD-VN、2401:9920::/48は再び DAZITT-VN を返します。

これらのラベルは、再販契約、顧客関係、施設関係を証明するものではありません。アクティブな AS151872 ルートセットに、公開レジストリ名が複数のベトナムのリソースラベルに属するプレフィックスが含まれていることを示しているだけです。クラウドおよびホスティング市場では、このパターンは、プロバイダーが委任されたリソースを発信する場合、顧客や関連会社がプロバイダーのルーティングプラットフォームを使用する場合、アドレス所有者がホスティング BGP を使用する場合、番号リソース管理とサービス運用が別々の手にある場合に発生する可能性があります。公開ルーティングは、どの説明がここに当てはまるかを判断できません。

調達への影響は明らかです：ルーティングされたアドレス数を所有するサーバー容量として扱わないでください。1,024の IPv4 アドレスと4つの IPv6 /48は、アドレス可能なネットワーク表面を示しますが、使用可能なコンピュート、ストレージ、サポート深度ではありません。購入者は、どのプレフィックスが自社のサービスに割り当てられるか、ルートとレジストリレコードに誰の名前が表示されるか、誰がルート変更を承認できるか、顧客が移行中にそれらのアドレスを保持、再番号付け、または交換できるかを尋ねるべきです。

EDIGI という名前のブロックが最大の注意点

最も強力な減速理由は203.145.46.0/23です。APNIC の203.145.46.0/23の RDAP レコードは EDIGI-VN を指名し、CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED を説明し、AS151872 の whois レコードで使用されているのと同じホーチミン市の住所を示しています。簡単に読むと、これを会社のプライマリ IPv4 ブロックと呼ぶでしょう。現在のルートテーブルはもっと狭いことを示しています。

RIPEstat の203.145.46.0/23のプレフィックス概要は、ブロックが AS151872 ではなく AS150862 によってアナウンスされていることを示しました。RIPEstat のAS150862 概要は、その起点を MAYTINHVPSTTT-VN - VPSTTT COMPUTER COMPANY LIMITED として特定します。RPKI ビューも現在の起点をサポートしています：203.145.46.0/23と AS150862は有効を返し、同じプレフィックスと AS151872は invalid_asn を返しました。

これは、EDIGI という名前のブロックが誤用、放棄、または利用不可であることを意味するものではありません。現在の公開ルート起点が、記事の残りの部分でテストしている会社の AS ではないことを意味します。ブロックは別のベトナムの事業者によって提供されている可能性があり、運用上の理由で移動されたり、顧客の取り決めで使用されたり、購入者のホスティング製品に関連しなくなったりする可能性があります。公開証拠はそれを判断できません。購入者に、EDIGI のレジストリラベルと AS151872 のサービスパスが同じものであると想定しないように警告できるだけです。

継続性計画にとって、この区別は重要です。顧客が203.145.46.0/23からアドレスを受け取る場合、インシデントパスは AS151872 の下の157.66.198.0/23や160.30.10.0/24のパスと異なる可能性があります。顧客が AS151872 のみを監視する場合、EDIGI ラベルのブロックを見逃す可能性があります。EDIGI ラベルのブロックのみを監視する場合、アクティブな AS151872 サービスを見逃す可能性があります。真剣なサービスレビューは、各カスタマーフェーシングプレフィックスについて、アドレスプール、起点 AS、ルート認証、サポート所有者、移行条件をマッピングする必要があります。

可視ネイバー1つがトランジットをスローガンではなくテストにする

公開ネイバー証拠は FPT を指しています。RIPEstat のASN ネイバービューは、AS151872 に1つの観測されたネイバー、AS18403 を示しました。RIPEstat のAS18403 概要は、AS18403 を FPT-VN - FPT Telecom Company として特定し、AS18403 whois レコードはベトナムの FPT Telecom Company を示しています。BGP.Tools も AS151872 のアップストリームおよびピアとして AS18403 を表示します。

これは有用な運用事実ですが、引き伸ばすべきではありません。パブリックルートコレクターは可視ネイバーを示すことができます。すべてのプライベートクロスコネクト、バックアップサービス、商用契約、ルートポリシーを示すことはできません。AS151872 には、このビューで公開されていない内部取り決めがある可能性があります。また、非常に薄いパブリックエッジを持っている可能性もあります。実用的な購入者の想定は、「冗長性がない」でも「FPT がすべてを回復力にする」でもありません。実用的な想定は、「可視のパブリックルートパスは FPT から始まるので、プロバイダーはそのパスが劣化または撤回されたときに何が起こるかを説明すべきである」です。

157.66.198.0/23のルッキンググラスデータは、観測されたパスで Telstra、PCCW、Lumen、または他のグローバルキャリアなどのアップストリームを経由して、AS151872 で終了するパブリックコレクターパスを、一般的に AS18403 を通して示しました。これは通常のグローバル到達性です。AS151872 が各リモートキャリアから直接購入していることの証明ではありません。カスタマーフェーシングの質問はローカルのままです：どのパスが施設からパケットを運ぶか、どの機器がそれを終端するか、誰がそれを修理するか？

ホスティングサービスにとって、トランジットの多様性は、適切なレイヤーで分離されている場合にのみ意味があります。2つのアップストリーム名は、同じラックに同じルーターを介して入り、同じ電力供給に依存し、同じ建物のミートミールームを共有し、ルートポリシーを変更するために同じサポートキューを必要とする場合、役に立ちません。逆に、単一のパブリックアップストリームは、サービスがシングルホーム明示的に価格設定され文書化されており、顧客に退出パスがある場合、低リスクのワークロードには許容できる場合があります。リスクは単独性自体ではありません。リスクは、公開証拠が可視ネイバーを1つしか示していないのに、顧客が多様性を購入したと信じることです。

RPKI は有効と不明に分かれる

ルート起点検証は、さらに別の混合証拠の層を追加します。RIPEstat の RPKI チェックは、AS151872 の160.30.10.0/24に対して有効、AS151872 の160.30.11.0/24に対して有効、2001:df3:e4c0::/48に対して有効、2001:df3:e8c0::/48に対して有効、2401:9760::/48に対して有効を返しました。157.66.198.0/23に対して不明、2401:9920::/48に対して不明を返しました。

不明は無効ではありません。パブリック検証ビューが、チェック時にその起点とプレフィックスをカバーするポジティブなルート起点認証を見つけられなかったことを意味します。多くの小規模ネットワークでは、このステータスは依然として一般的です。重要なホスティング容量を購入する顧客にとっては、それでも意味のある質問です。アップストリームやピアが厳格なルートフィルタリングを実施する場合、不明なステータスは障害動作を変更する可能性があります。ルートリークやハイジャックが発生した場合、認証された起点はフィルタリングと診断を容易にします。

関連する標準はこの会社を認定しません。何を尋ねるかを説明します。RFC 6811は BGP プレフィックス起点検証を定義します。RFC 7454は BGP フィルタリングとルーティングセキュリティの運用慣行を説明します。MANRSはルートフィルタリング、アンチスプーフィング、調整規範を枠組みします。APNIC のリソース認証ページは APNIC 地域の RPKI を説明します。

顧客はプレフィックスごとのルート認証ステートメントを求めるべきです。どのカスタマーフェーシングプレフィックスに有効な ROA がありますか？どれが意図的に不明のままですか？誰が認証を作成または変更できますか？プロバイダーは無効なルート起点状態をどの程度迅速に修復できますか？小さなホスティングプロバイダーでも、これらの答えが明確であれば信頼性があります。ライブルートと不明確な認証を持つプロバイダーは、アップストリームポリシーの変更中に顧客を露出させる可能性があります。

ホーチミン市の住所はラックの場所ではない

会社の住所は公開レコードに一貫して表示されます。RIPEstat whois は、AS151872 についてベトナム、ホーチミン市、タンフー区、フータイン区、トアイゴックハウ338/22番地をリストしています。APNIC の EDIGI という名前の203.145.46.0/23レコードは同じ住所を示しています。MaSoThue の税コードミラーもベトナムの会社名、税コード0318010419、英語名、トアイゴックハウの住所をリストしていますが、登録住所に対して否定的なステータスを報告しています。このページはビジネスインフォメーションミラーであり、公式のネットワークレジストリではないため、そのステータスフィールドは検証するためのシグナルとして扱うべきであり、完全な運用判断としては扱いません。

否定的なステータスシグナルがなくても、住所をデータセンターマップとして読むべきではありません。登録事務所、管理連絡先、税務住所、ルート連絡先、商業住所は、顧客ワークロードを保持するラックとは別の場所にある場合があります。小さなクラウドまたはホスティングプロバイダーは、サードパーティの施設で機器をコロケーションするか、別のプロバイダーからベアメタルノードをレンタルするか、顧客またはパートナーのプレフィックスを発信するか、サーバーをリモートで管理する場合があります。これらの取り決めは自動的に悪いものではありません。それぞれが修理パスを変更します。

顧客がベトナムローカルのサービスを購入する場合、各レイヤーがどこにあるかを尋ねるべきです：プロダクションコンピュート、ストレージ、バックアップ、監視、サポートレコード、課金レコード、管理アクセス、エクスポートステージング。「ホーチミン市」という住所だけでは十分ではありません。顧客は、プロダクションがホーチミン市にあるのか、別のベトナムの都市にあるのか、キャリア施設のリースラックにあるのか、別のプロバイダーの仮想化環境にあるのか、それとも混在しているのかを知る必要があります。

目的は、機密性の高いフロアプランを要求することではありません。責任の所在を特定することです。サーバーが故障した場合、誰がラックに入ることができますか？スイッチが故障した場合、誰が予備を所有していますか？電力メンテナンスが予定されている場合、誰が通知を受け取りますか？ルートを移動する必要がある場合、誰が BGP を変更できますか？公開会社住所はこれらの質問に答えず、それができない以上のことを要求されるべきではありません。

ホスティング容量は借用部分と運用部分の連鎖である

現在の AS151872 の証拠は、小さなホスティング容量チェーンのように見え、自己完結型のハイパースケールクラウドではありません。その区別は期待にとって重要です。小さなネットワークは、どの部分を所有し、どの部分をレンタルし、どの部分が顧客管理下にあり、どの部分がアップストリームプロバイダーにあるかを正確に把握している場合、優れたサービスを提供できます。それらの境界が隠されている場合、脆弱になります。

アドレススペースの証拠はすでに複数のラベルを示しています。DAZITT-VN、IPXO-VN、GENLOGIN-VN、CLEMAX-VN、THCLOUD-VN が現在の AS151872 発信プレフィックスに表示されます。EDIGI-VN は203.145.46.0/23に表示されますが、そのブロックは現在 AS150862 によって発信されています。ルーティング証拠は、AS151872 の公開ネイバーとして AS18403/FPT を示しています。会社ドメインの手がかりも不確実性を追加します：AS の連絡先は edigi.vn のメールアドレスを使用していますが、このレビュー中にhttps://edigi.vnへの直接リクエストは Cloudflare 521応答を返し、これは通常 Cloudflare がオリジンサーバーに到達できなかったことを示します。この観察は顧客サービスがダウンしていることを証明するものではありませんが、公開カスタマーフェーシングの文書に対する信頼を弱めます。

ホスティング経済学にとって、問題は会社がこれらの依存関係をどのように使用可能な容量に変えるかです。自社のサーバーをリースラックに保持していますか？別のプロバイダーの VPS やベアメタル在庫を再販していますか？サードパーティシステムのために顧客プレフィックスを発信していますか？他のベトナムのソフトウェアやクラウドラベルにネットワークサービスを提供していますか？公開データはこれらの質問を解決できません。どの顧客も「クラウド」という言葉を近道として避けるべきであることを示しています。

インストール容量は、紙の上に存在するものです：アドレス、AS 番号、アップストリーム到達性、ラックまたは契約。使用可能容量は、電力、冷却、ルートフィルタリング、故障ハードウェア、サポート応答、予備在庫制約を考慮した後、実際に顧客ワークロードを実行できるものです。リカバリ可能容量は、顧客の期限までに復元できるものです。パブリック AS は最初のレイヤーが存在することを教えてくれます。2番目や3番目は教えてくれません。

サポート労働は物理的な依存関係である

小さなホスティング環境では、サポート労働はインフラの一部です。顧客がルートを変更したり、ディスクを交換したり、コンソールを再起動したり、課金を解除したり、バックアップを取得したり、アップストリームと調整したりできる人またはチームに到達できない場合、ルートが可視のままでもサービスは失敗する可能性があります。したがって、AS151872 の現在のルート可視性は、サポート質問の始まりにすぎません。

公開レコードは、APNIC と RIPEstat を通じて管理および技術連絡先ハンドルを提供しますが、顧客エスカレーションマップを公開していません。時間外サポートが内部、外部委託、施設処理、アップストリーム処理、または別のホスティング事業者処理であるかどうかを示していません。アクティブな AS151872 プレフィックスと、現在 AS150862 によってルーティングされている EDIGI という名前の203.145.46.0/23ブロックの両方を同じサポートパスがカバーしているかどうかを示していません。課金ステータスが顧客がデータをエクスポートする前にサーバーを停止できるかどうかを示していません。

購入者にとって、適切な証拠は実用的です。プレフィックスごとのルート起点ステートメントを求めるサポートチケットを開いてください。顧客ポータルが利用できない場合に緊急サポートに連絡する方法を尋ねてください。顧客に代わって FPT または別のアップストリームに連絡する権限があるのは誰か尋ねてください。顧客が施設メンテナンスの通知を受け取れるかどうか尋ねてください。一般的なハードウェア交換、仮想マシンの復元、劣化状態での完全バックアップのエクスポートの最大時間を尋ねてください。

答えは控えめかもしれませんが、価格とワークロードがそれに一致すれば問題ありません。低コストの VPS サービスは、マルチリージョンエンタープライズクラウドを装う必要はありません。危険はミスマッチした依存関係です。顧客のアプリケーション、リセラーサービス、パブリックサービスワークロードが迅速な修理に依存している場合、顧客は書面によるエスカレーションとテスト済みリカバリを必要とします。請求書と IP アドレスだけでは不十分です。

データローカリティはコンポーネントごとに指定する必要がある

APNIC および VNNIC レコードでの VN の割り当ては、ベトナムの番号リソース ID をサポートします。顧客データがどこに保存されているかを証明するものではありません。データ主権とローカリティのために、顧客はコンポーネントレベルの回答を必要とします。プロダクションコンピュートはある場所、ストレージは別の場所、バックアップは別の場所、サポートアクセスは別の場所、課金レコードは別の場所にある可能性があります。ベトナムで発信されるルートは、それらの場所のいずれも自動的に決定しません。

ベトナムの法的および規制の文脈は、この区別を重要にします。個人情報、規制対象データ、公共部門のワークロード、決済データ、機密ビジネスレコードを扱う顧客は、どのデータが移動できるか、誰がアクセスできるか、終了時に何が起こるかを知る必要があります。公開 AS151872 レコードはそのいずれにも答えません。会社の Web サイトの可用性チェックはそのいずれにも答えません。EDIGI ラベルの203.145.46.0/23の不一致は、レジストリ名とルート起点が分離して存在できることを示すため、質問をより緊急にします。

適切なリクエストはローカリティスケジュールです。プロダクションディスクがどこにあるか、バックアップがどこにあるか、ログと監視データがどこにあるか、サポートチケットがどこにあるか、アカウントと課金レコードがどこにあるか、管理者がどこから接続できるかを記載する必要があります。また、それらの場所が契約上の保証、通常の運用慣行、またはプロバイダーの裁量であるかどうかを記載する必要があります。ベトナムのみのデータ処理を必要とする顧客は、AS レコードの国コードに頼るべきではありません。

ローカリティはリカバリにも影響します。プロバイダーは回復力のために別のサイトにバックアップを保持する場合がありますが、顧客はそれらのバックアップがローカル障害中に使用可能であり、復元によって管轄権、IP アドレス、レイテンシ、コンプライアンス証拠が変更されるかどうかを知る必要があります。プロバイダーはフェイルオーバーをサポートするために別のベトナムの AS または施設を使用する場合がありますが、顧客は誰がそのフェイルオーバーを制御するかを知る必要があります。ローカリティはラベルではありません。一連の運用事実です。

移行は依存関係の正直なテストである

ホスティングサービスをテストする最も明確な方法は、緊急時ではなく、意図的に、静かな状態で一度離れることです。これは、公開証拠が混合プレフィックスラベルと会社名ブロックの別個の現在の起点を示している場合に特に当てはまります。穏やかな条件下で小さなワークロードをエクスポート、再構築、再番号付けできない顧客は、危機的移行が遅くなると想定すべきです。

CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED の場合、移行テストにはデータだけでなくアドレスも含める必要があります。ワークロードが AS151872 によって発信された157.66.198.0/23、160.30.10.0/24、または160.30.11.0/24のスペースを使用している場合、顧客はそれらのアドレスを移動できますか？ワークロードが EDIGI-VN に登録されているが AS150862 によって発信された203.145.46.0/23のスペースを使用している場合、誰が変更を承認しますか？顧客が AS151872 の下で IPv6 /48スペースを使用している場合、ルート起点レコード、ファイアウォールルール、パートナー許可リストは文書化されていますか？

データエクスポートも同様に具体的である必要があります。顧客は手動介入なしにディスクイメージ、オブジェクトデータ、データベース、スナップショット、DNS 設定、ファイアウォールルール、アクセスログ、課金レコードをエクスポートできますか？コントロールパネルが劣化している場合、エクスポートを実行できますか？エクスポートはスロットリングされますか？キャンセル後、バックアップはどのくらい保持されますか？通常のアカウント所有者が利用できない場合、誰が緊急エクスポートを承認できますか？

答えはホスティング関係の経済的リスクを決定します。安価なホスティング容量は、プロバイダー割り当ての IP、文書化されていないバックアップ、遅いサポートの周りにキャプティブな依存関係を作成する場合、高価になる可能性があります。より小さなプロバイダーでも、顧客がきれいに移行できれば良い選択になり得ます。ポータビリティは忠誠心の欠如ではありません。顧客の災害復旧の証明です。

誰が障害を感じるか

AS151872 の可視顧客は、ベトナムのアプリケーション事業者、リセラー、中小企業、ソフトウェアサービス、代理店、システムインテグレーター、またはホスティングルーティングを使用する別のネットワークである可能性があります。エンドユーザーは CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED の名前を見ることはないかもしれません。彼らは遅いアプリケーション、到達不能なログインページ、バウンスメール、ブロックされた API コール、失敗したバックアップ、または失敗したアドレス許可リストに気付くでしょう。

障害パスは階層化されています。パブリックルートの問題は、現在の AS151872 のすべてのプレフィックスからの到達性を撤回する可能性があります。ローカルファイバーまたはアップストリームの障害は、AS18403 を介した到達性を劣化させる可能性があります。ラックの電力問題は、BGP は可視のままサーバーがダウンする可能性があります。ディスクまたはストレージプールの障害は、ルートは正常に見えるがデータは利用不可になる可能性があります。サポートのボトルネックは、技術的原因が判明した後もインシデントを延長する可能性があります。課金またはアカウントステータスの問題は、インフラが修復可能であってもリカバリをブロックする可能性があります。レジストリ名、ルート起点、顧客契約の間の不一致は、診断の最初の1時間を遅らせる可能性があります。

EDIGI という名前の203.145.46.0/23ブロックは、特定のダウンストリームリスクを追加します。顧客またはパートナーが APNIC データのためにそのブロックを「EDIGI」として記録しているが、現在のルート起点が AS150862 である場合、監視とインシデント連絡先リストは異なる方向を指す可能性があります。顧客は、どの連絡先がどのプレフィックスを担当するかを決定するために、障害が発生するまで待つべきではありません。

公開証拠はプロバイダーを完全に拒否する理由ではありません。サービスに依存する前にマッピングする理由です。ネットワークは存在します。現在可視です。いくつかのプレフィックスには有効なルート起点認証があります。未解決の質問は物理的かつ契約的です：ワークロードがどこにあるか、誰が修理するか、いくつのパスが存在するか、EDIGI という名前のブロックはどうなるか、顧客はどのように退出するか。

サービスに依存する前に検証する方法

最初の検証ステップは ID です。プロバイダーに、カスタマーサービスが AS151872、AS150862 の下の203.145.46.0/23、別のルーティングブロック、プライベートアドレス指定、または混在のいずれによって提供されるかを確認するよう依頼してください。回答を APNIC のAS151872および203.145.46.0/23レコード、RIPEstat のAS151872 ルーティングステータス、RIPEstat の203.145.46.0/23プレフィックス概要と比較してください。

2番目の検証ステップはトポロジです。プロダクション施設の種類、リカバリ施設の種類、パブリックトランジットパス、プライベート接続パス（ある場合）、アップストリームエスカレーションパス、メンテナンス通知プロセスを尋ねてください。プロバイダーはこれに答えるために機密性の高いラック座標を開示する必要はありません。顧客がシングルサイト、マルチサイト、シングルアップストリーム、デュアルアップストリーム、別の場所にバックアップ、またはサードパーティのコロケーションプロバイダーに依存しているかどうかを述べることができます。

3番目のステップはルーティングセキュリティです。プレフィックスごとの ROA ステートメントを要求し、RIPEstat の RPKI ビューと比較してください。160.30.10.0/24、160.30.11.0/24、いくつかの IPv6 /48の有効エントリはポジティブです。157.66.198.0/23と2401:9920::/48の不明エントリは説明されるべきです。203.145.46.0/23の有効な AS150862 ステータスも、顧客が EDIGI ブランドのサービスを期待する場合、説明されるべきです。

4番目のステップはリカバリドリルです。1つの代表的なワークロードをバックアップから復元し、別の環境に移動し、DNS またはパートナー許可リストを更新し、ログを確認し、データ整合性を検証し、経過時間を記録します。テストにサポートエスカレーションを含めてください。サポートパスが小さな計画移動を実行できない場合、大規模な緊急移動をきれいに実行できる可能性は低いです。

プロバイダーの境界にはプレフィックス行列が必要

顧客が要求できる最も有用な文書はプレフィックス行列です。機密性の高い内部図面を公開する必要はありません。各カスタマーフェーシングネットワークブロックを、そのレジストリラベル、ルート起点、ルート認証状態、アップストリームパス、サポート所有者、顧客影響に単純に接続する必要があります。AS151872 の場合、その行列は157.66.198.0/23、160.30.10.0/24、160.30.11.0/24、4つの可視 IPv6 /48、および現在 AS151872 の起点セット外にある EDIGI という名前の203.145.46.0/23ブロックから始まります。

行列はすべてのプレフィックスについて基本的な質問に答えるべきです：このルートが変更された場合、誰がそれを修正できますか？答えは CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED かもしれません。独自のアドレススペースを提供した顧客かもしれません。アップストリームまたは別のベトナムの事業者かもしれません。組み合わせかもしれません。パブリックルーティングは結果を見ますが、権限連鎖は見ません。ルート修復は技術的問題になる前に権限問題であることが多いため、顧客は権限連鎖を必要とします。

同じ行列は、プロダクション使用と予約または管理使用を分離する必要があります。プレフィックスはグローバルルートテーブルに表示されますが、管理インターフェース、テストホスト、顧客 NAT、メール、DNS、バックアップエンドポイント、監視プローブ、または有料の顧客ワークロードをまったく運ばない場合があります。顧客がパブリックアドレスブロックで容量を販売された場合、そのブロックが専用、共有、フィルタリング、ポータブル、交換可能かどうかを尋ねるべきです。また、契約中にレジストリラベル、ルート起点、または RPKI 状態が変更された場合に何が起こるかも尋ねるべきです。

混合した AS151872 の証拠はこれを特に重要にします。アクティブな AS には、パブリックレジストリ名が複数のベトナムのラベルに属するリソースが含まれており、EDIGI という名前の IPv4 ブロックは別の現在の起点を持っています。これは自動的に警告サインではありません。通常の運用委任かもしれません。しかし、通常の委任でも文書化が必要です。それがなければ、顧客は障害中に、ホスティングアカウント連絡先、AS151872 ルート連絡先、AS150862 事業者、アドレス所有者、またはアップストリームのいずれに電話すべきかを決定するのに何時間も失う可能性があります。

購入者はまた、カスタマーフェーシングアドレスがプロバイダーのアンチアビューズフィルター、ジオフェンシング、DDoS 軽減、送信メール制限、特別なルートポリシーによって保護されているかどうかを尋ねるべきです。これらの制御は価値がありますが、移行とインシデント対応を複雑にする可能性もあります。プレフィックス行列は、それらの隠れた制約を顧客がテストできる運用事実に変えます。

電力、予備、メンテナンスは BGP からは見えない

BGP はルートを可視にします。物理サービスを可視にするわけではありません。AS151872 はルートコレクターから完全に到達可能でありながら、単一のラック、スイッチ、ストレージノード、または電力回路が実際の顧客障害点である可能性があります。ルーティングテーブルは、サーバーが所有部屋、リースキャビネット、サードパーティコロケーション、レンタルベアメタル在庫、または別のプロバイダーの仮想化資産のいずれにあるかを公開しません。また、一般的なスペアパーツがサイトに保管されているかどうかも公開しません。

これは、ホスティング障害がしばしば通常の物理的制約から始まるため重要です。サーバーはディスクを失う可能性があります。トップオブラックスイッチは故障する可能性があります。配電ユニットはトリップする可能性があります。UPS メンテナンスウィンドウは冗長性を削除する可能性があります。施設はリモートハンドのスケジューリングを必要とする場合があります。交換部品は遅れる可能性があります。パブリック AS はこのすべての間アナウンスされ続けるかもしれません。外部からは、ルートは正常に見えますが、顧客のアプリケーションは利用不可です。

CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED の場合、公開レコードはラック数、データホール名、電力設計、ハードウェア在庫証拠を提供しません。正しい結論は、それらの要素が存在しないということではありません。顧客が直接尋ねなければならないということです。最低でも、プロダクション顧客は、自分のワークロードがシングルラックかマルチラックか、ストレージがローカルかレプリケートか、バックアップがオフラックかつオフサイトか、メンテナンスがすべてのカスタマーフェーシングサービスに同時に影響するかどうかを知るべきです。

サポート境界は物理的境界と交差します。会社が別の施設でスペースをリースしている場合、施設がアクセスとリモートハンドを制御する場合があります。別のプロバイダーからサーバーをレンタルしている場合、そのプロバイダーがハードウェア交換を制御する場合があります。BGP にアップストリームを使用し、コロケーションに別の当事者を使用する場合、ルート障害と電力障害は完全に異なるエスカレーションパスを必要とする場合があります。良いプロバイダーはこれらの依存関係を管理できますが、顧客は障害後にのみそれらを発見すべきではありません。

顧客は実用的な形で証拠を要求すべきです：サンプルメンテナンス通知、顧客サービスティアごとの冗長電力の説明、一般的なハードウェアの交換目標、バックアップ保持場所、最近の復元演習。これらは壮大なエンタープライズ要求ではありません。長い修理期間を許容できないワークロードにサービスが適切かどうかを決定するために必要な最小限の事実です。

課金とアカウント状態はインフラ障害になり得る

記事のタイトルはラック、トランジット、修理時間に言及していますが、アカウント状態は同じリストに属します。ホスティングサービスは技術的に正常でありながら、請求書が争われている、管理者が退職した、パスワードリセットパスが失敗する、アビューズチケットがアカウントをロックする、サービス停止がバックアップへのアクセスをブロックするために顧客が利用不可になる可能性があります。小さなホスティングプロバイダーは、商業的権限と技術的権限が同じ小さなチームに集中している場合、特に露出する可能性があります。

公開証拠は、CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED が停止、アカウントリカバリ、削除、アビューズレビュー、緊急エクスポートをどのように処理するかを開示していません。その欠如は想定で埋めるべきではありません。購入者は、顧客が誤って支払いを逃した場合、不正レビューがトリガーされた場合、侵害されたサーバーに対してフィッシング苦情が提出された場合、または指名されたアカウント所有者がインシデント中に利用できない場合に何が起こるかを尋ねるべきです。答えは、顧客がまだバックアップを取得できるかどうか、停止が DNS、ルートアナウンスメント、コンソールアクセス、サポートに影響するかどうかを述べるべきです。

EDIGI という名前のブロックは別の管理上の質問を追加します。APNIC レコードのために顧客文書に203.145.46.0/23が表示されるが、現在のルート起点が AS150862 である場合、顧客はそのブロックのアドレスの商業ステータスをどのエンティティが制御するかを知る必要があります。サービスが停止された場合、誰がルート可視性を復元する権限を持っていますか？顧客が去る場合、誰が再番号付けまたはクリーンアップを調整しますか？アビューズ苦情がある場合、誰がそれを受け取り、誰がそれを閉じることができますか？

これらの質問は不信の兆候ではありません。これらは回復力の一部です。請求猶予期間、アビューズエスカレーション、緊急連絡先、アカウント所有者移行、データエクスポート権限を説明できるプロバイダーは、顧客に管理上の障害から回復する方法を与えます。これらの詳細をバックオフィスの些細なこととして扱うプロバイダーは、ルートコレクターに決して現れない障害に対して顧客を露出させます。

最も安全な顧客の姿勢は、技術パスと並んで緊急商業パスを文書化することです。技術パスは、誰がパケット、サーバー、バックアップを復元できるかを示します。商業パスは、誰が書類問題が復元をブロックするのを防ぐことができるかを示します。両方ともサービスが重要になる前に知られるべきです。

何が証拠をアップグレードするか

会社またはカスタマーフェーシング製品ページが公開ルーティング事実を販売されているサービスに接続すれば、証拠は実質的に強くなります。最も価値のあるアップグレードは、プレーンなサービスマップです：AS151872 の役割、203.145.46.0/23の役割、アクティブな顧客プレフィックス、アップストリーム、プロダクションロケーションタイプ、リカバリロケーションタイプ、サポート所有者、バックアップロケーション、エクスポート方法。キャビネット番号や機密性の高いセキュリティ詳細を公開する必要はありません。どの公開レコードが依然として顧客にとって重要であるかについての曖昧さを除去する必要があります。

2番目のアップグレードは、現在のルート制御証拠です。これには、すべてのアクティブプレフィックスの公開または顧客提供の ROA 計画、157.66.198.0/23および2401:9920::/48の不明な RPKI ステータスの説明、EDIGI という名前の203.145.46.0/23ブロックの有効な AS150862 起点の説明が含まれる可能性があります。目的は表面的なルーティング衛生ではありません。目的は、インシデント中にルート変更を診断可能にすることです。

3番目のアップグレードは、相互接続または施設プロファイルです。AS151872 の PeeringDB API クエリは、このレビュー中に公開ネットワークプロファイルを返しませんでした。PeeringDB の欠如は否定的な評決ではありません。多くの小さなプロバイダーと顧客ネットワークは公開プロファイルを持っていません。しかし、プロファイルまたは同等のカスタマーフェーシング文書は、交換ポイント、施設、トラフィックポリシー、サポート連絡先を述べることができます。これは顧客がパブリックトランジットとプライベートまたは施設レベルの回復力を区別するのに役立ちます。

4番目のアップグレードはリカバリ証明です。プロバイダーはバックアップが存在すると主張できますが、より強力な証拠は、何が復元されたか、どこに復元されたか、どのくらい時間がかかったか、どの依存関係が失敗したか、顧客が何をしなければならなかったかを述べる復元レポートです。プレフィックスラベルが混在するホスティングサービスの場合、そのレポートにはアドレス変更、DNS 更新、ファイアウォール変更、許可リスト更新を含める必要があります。顧客は、リカバリがサーバー操作のみであるか、本格的なネットワークおよびデータ操作であるかを知る必要があります。

最後に、公開 Web フットプリントはより明確にできます。チェック時に edigi.vn ドメインが Cloudflare 521応答を通じて利用不可であったのは、一時的なシグナルにすぎませんが、顧客に現在のサービス条件、ステータス、サポートチャネル、製品境界を読む簡単な場所を残しません。安定した公開サポートおよびステータスページは、それ自体で回復力を証明するものではありません。依存関係の運用を容易にします。

証拠グレード

証拠グレードは中程度～弱いです。純粋なシェルレコードよりも強い理由は、AS151872 が現在可視であり、3つの IPv4 プレフィックス、4つの IPv6 プレフィックス、測定可能なグローバル到達性を持っているからです。また、いくつかの有効なルート起点レコードもあります。VNNIC と APNIC は EDIGI-VN リソースラベルと会社を特定し、パブリックルートコレクターは一貫して AS151872 をアクティブとして示しています。

弱い側面も同様に重要です。公開証拠は、所有施設、リースラック、ラック数、電力設計、予備ハードウェア、サポートカバレッジ、顧客契約、製品ページ、リカバリ目標、データエクスポート条件を特定しません。PeeringDB のAS151872 の API クエリは公開ネットワークプロファイルを返さなかったため、施設、交換ポイント、ピアリングポリシーを提供しません。アクティブルートセットには、他のレジストリラベルのプレフィックスが含まれています。EDIGI という名前の203.145.46.0/23ブロックは現在 AS150862 によって発信されており、AS151872 ではありません。連絡先メールに関連付けられた公開 Web ドメインは、チェック時に正常な公開サイトを提供していませんでした。

結論は狭いです：CLOUD DATA TECHNOLOGY AND COMMUNICATION COMPANY LIMITED は測定可能なベトナムのルーティングフットプリントを持っていますが、公開研究は自己完結型のクラウドプラットフォームを証明していません。顧客は、重要なワークロードを配置する前に、プレフィックス、ラック、ルート、サポート所有者、バックアップロケーション、退出パスごとに検証する依存関係としてサービスを扱うべきです。