サマリー
- Cloud.ir は CLOUD Asre Dadeha Asiatech に実際の小売面を提供しています。このサイトは、クラウドサーバー、VPS プラン、クラウドストレージ、CDN、クラウドスイッチング、クラウドデータセンターサービス、カスタマーパネル、公開価格、SLA を提供し、フッターにはウェブサイトが Asre Dadeha Asiatech に属することが記載されています。
- 物理的な基盤は製品言語よりも狭いです。Cloud.ir は、そのインフラストラクチャがイランの ASIATECH データセンター上にあると述べており、アバウトページによれば Cloud.ir はイラン暦1399年から運営され、20以上のクラウド製品を提供していますが、公開ページでは各顧客ワークロードの正確なラック、都市ごとの配置、電源トポロジー、復元テスト結果は特定されていません。
- ネットワークの証拠はコントロールプレーン層で強力です。RIPE RDAP は AS60077 を Asre Dadeha Asiatech の AT-CLOUD として識別し、RIPEstat は2026年7月12日に AS60077 が発表した18の IPv4 プレフィックスと14,080の IPv4 アドレスを示し、cloud.ir の DNS は AS60077 のプレフィックスにマッピングされていました。同じ RIPE ビューでは、AS60077 の左側のネイバーとして AS43754、ASIATECH Asiatech Data Transmission company が1つ観測されました。
- したがって、購入の問いはクラウド製品が存在するかどうかではありません。それは、特定の顧客が、ラック、アップストリーム、ハードウェア在庫、アカウントイベントが仮想サーバーを物理的依存に変える前に、配置、容量ヘッドルーム、独立したルート、バックアップの局所性、サポートエスカレーション、メンテナンス除外、請求の継続性、および退出権を確認できるかどうかです。
ストアフロントは公開されているが、インフラストラクチャの約束は依然として階層化されている
Cloud.ir は単なるブランドの飾りページではありません。Cloud.ir ホームページは、クラウドサーバー、クラウドデータセンターサービス、クラウドスイッチング、CDN、クラウドストレージ、クラウドドメイン管理、サービス価格ページ、サポートページ、顧客ログインパスを提供しています。同じページには、電話番号、メールアドレス、テヘランのオフィス住所、およびウェブサイトの素材および知的権利が Asre Dadeha Asiatech に属するというフッターステートメントが含まれています。このプロファイルにとって重要なのは、企業のアイデンティティがルーティングレコードだけでなく、ライブサービスの表面に結びついていることです。
アバウトページはサービスの歴史を追加します。Cloud.ir はイラン暦1399年に運営を開始し、20以上のクラウド製品を提供するイランを代表するクラウドサービスプロバイダーの1つになったと述べています。そこに記載されている製品グループには、コンテンツ配信、クラウドコンピューティング、クラウドセキュリティ、クラウドストレージ、クラウドネットワーキング、クラウドマーケットプレイスが含まれます。これらの主張は企業の声明であり、容量の独立した測定ではありませんが、基本的な商業的姿勢を明確にしています。CLOUD Asre Dadeha Asiatech は、自らの物理インフラを購入して運用したくない顧客にホスト容量を販売しています。
小売の提供は、検査するのに十分具体的でもあります。クラウドサーバーページは、顧客が迅速にクラウドサーバーを作成し、使用したリソースに対して支払い、リソースを変更し、ネットワーキングを構成し、IP アドレスを追加または変更し、リソースとネットワークの使用を監視し、クラウドファイアウォールを使用し、バックアップをスケジュールできると述べています。同じページでは、Linux、Windows、MikroTik サーバーオプションについて説明し、クラウドサーバー顧客向けのサポートはチケット提出により24時間利用可能であると述べています。購入者はこれらを、契約とテストの確認が必要な製品の約束として扱うべきですが、それでも一般的な「クラウド」という言葉よりも具体的です。
Cloud.ir の価格ページは、製品をさらに検査可能にします。AT-VPS-B2、AT-VPS-G1、AT-VPS-A2 などの VPS パッケージ名を、メモリ、CPU、ディスク、無料 IP アドレス1つ、ベーストラフィック、アドオン IP サポート、再構築サポート、IPv6 をパッケージカードに表示しています。また、メモリ、CPU、ディスク、IP、受信トラフィック、バックアップ階層などのクラウドサーバーリソースの時間単位のメータリングも表示しています。価格ページはエンジニアリング図ではありませんが、サービスのパッケージ方法を明らかにしています。顧客は、コントロールパネルが割り当てる前にどこかに存在しなければならない有限のコンピュート、ストレージ、アドレス、トラフィックユニットを購入しています。
同社はまた、同じインフラストラクチャを中心とした高レベルのサービスについて説明しています。クラウドデータセンターページは、安全で簡単なデータ管理、スケーリング、監視、仮想化、コンテナ化、スケジュールされたバックアップを提供しています。クラウドストレージページは、スケーラブルなストレージ、制御された共有、アクセスレベルの管理を提示しています。CDN ページは、国内、集中、国際モードでのコンテンツ配信について説明し、ユーザーリクエストは地理的により近いデータセンターの場所から処理されます。クラウドスイッチページは、クラウドサーバーとデータセンター間の管理された仮想ネットワーキングを提供します。各製品は、顧客が機器を所有する必要性を減らしますが、同時にプロバイダーの配置、ネットワーク設計、サポート判断への依存関係も導入します。
これが記事の残りの部分に役立つ枠組みです。CLOUD Asre Dadeha Asiatech は謎のシェルではなく、目に見えるサービス表面は下位層をテストする必要性を取り除きません。クラウドサーバーは、プロバイダーがすでに適切なホスト容量、ストレージ、パブリックアドレス、ネットワーク到達可能性、請求権限を持っている場合にのみ秒単位でプロビジョニングできます。CDN は、そのエッジが存在し、新鮮なコンテンツを持ち、十分なキャッシュとトランジット容量を持ち、顧客自身のサーバーがダウンした場合でもオリジンに到達できる場合にのみ、リクエストをより近いエッジにルーティングできます。バックアップは、プライマリワークロードを損傷した障害の外部で復元できる場合にのみ重要です。公開ページは提供を示していますが、それ自体ではプロダクション購入者が必要とするすべての回復力の主張を証明するものではありません。
物理的な基盤はイランの ASIATECH データセンター能力である
Cloud.ir の最も強力な物理的記述は明確です。そのクラウドインフラストラクチャは ASIATECH データセンター上に展開されています。クラウドサーバーページは、Cloud.ir クラウドサービスのインフラストラクチャが ASIATECH データセンターに展開されていると述べており、イラン最大のデータセンターネットワークであると説明しています。最新技術、ISO27001、TIA-942 Tier 2および Tier 3の主張、セキュリティシステム、安定したネットワーク接続、イランでの高帯域幅消費、AC および DC 電源サポートの使用を挙げています。クラウドデータセンターページは同じ ASIATECH データセンターの枠組みを繰り返し、Cloud.ir のデータセンターがイラン全体にわたり、クラウド移行を始める顧客にインフラストラクチャを提供していると述べています。
アバウトページも同様です。Cloud.ir のデータセンターはイラン全体に分散しており、そのインフラストラクチャはグローバルスタンダードの大規模で強力な施設をカバーする ASIATECH データセンター上にあると述べています。また、AC および DC サポートも挙げています。これらの主張は、サービスを純粋な小売抽象化から名前付き施設オペレーターの境界に移行させるため重要です。クラウドブランドは、無名の海外ハイパースケールリージョンではなく、ASIATECH のデータセンター資産とネットワークに依存しています。
企業ページ以外では、公開記録はこの資産に関する古いが有用なコンテキストを提供します。データセンター Dynamics は2017年7月、AsiaTech がテヘラン西部のミラードタワーに700平方メートルのデータセンターを開設したと報じました。その報告では、AsiaTech は2003年に設立された民間企業で、2013年にホスティング、専用サーバー、共有サーバー、コロケーションのライセンスを取得し、5つのデータセンターを運営し、イラン全土の430以上の町や都市を接続していると述べられていました。DataCenterMap は現在、テヘランにAsiatech Milad Tower データセンターとAsiatech Azadegan データセンターをリストしていますが、Milad Tower のスペックページには、容量、電力、コンプライアンス、セキュリティ、建物データは Asiatech から提供されていないと記載されています。
これらの外部参照は慎重に扱う必要があります。これらは ASIATECH が名前付きのテヘラン施設とより広範なデータセンタービジネスに関連していることを裏付けています。しかし、特定の Cloud.ir VM、CDN エッジ、ストレージバケット、バックアップコピーが2026年7月にどの施設でサービスされているかを証明するものではありません。また、2017年の施設の状態、ラック数、電源設計、顧客数が変わっていないことも証明しません。施設の履歴は実際のインフラストラクチャ企業の有用な証拠ですが、現在の配置マップではありません。
その区別は顧客にとって重要です。購入者は「イラン全体のデータセンター」と聞いて、同じアカウントから注文した2台のサーバーが別の建物に配置されると想定するかもしれません。そうではないかもしれません。同じホスト、1つのラック内の2台のホスト、1つの電源ユニットの背後にある2つのラック、1つの建屋内の2つのホール、またはメトロファイバーやアップストリームエッジがまだ収束している別々の建物に配置される可能性があります。逆に、プロバイダーは公開ページが開示するよりも優れた分離を提供している可能性があります。公開ページはその点を確定しません。顧客は、配置制御、アンチアフィニティルール、名前付きサイトまたはサイトコード、バックアップ場所、および各サービス階層について Cloud.ir が「データセンター」の意味を尋ねる必要があります。
電源と修理作業員も同じ質問の一部です。Cloud.ir は、クラウドを使用することで顧客が機器を購入しサーバールームを維持する負担を回避できると公平に言えます。それによって物理的なメンテナンスが消えるわけではありません。誰かがディスク、電源、ラインカード、メモリを交換しなければなりません。誰かが電気工事をスケジュールしなければなりません。誰かが発電機、バッテリー、冷却、火災システムをテストしなければなりません。誰かがアラートを受け取り、ラックに到達しなければなりません。顧客は ASIATECH の施設設計のすべてのプライベートな詳細を知る必要はありませんが、どの可用性の約束がラックイベント、電源メンテナンスウィンドウ、ストレージ障害、交換ハードウェアの不足を生き残るかを知る必要があります。
AS60077 は可視であり、親ネットワークが明らかな依存関係である
ネットワーク記録は CLOUD Asre Dadeha Asiatech に2つ目の具体的な基盤を与えます。RIPE RDAP はAS60077を AT-CLOUD として識別し、ORG-ADA42-RIPE を通じて Asre Dadeha Asiatech にリンクしています。同じ RDAP 応答には、テヘランの Miremad Street 住所にある Asiatech NOC の管理および技術連絡先、および Asiatech の虐待役割が含まれています。これは、実際の自律システムと運用連絡先チェーンのレジストリ証拠です。個々のサーバー、顧客、稼働時間を説明するものではありませんが、クラウドサービスが独自のネットワーク識別子を持つことを確認します。
RIPEstat のAS60077 の AS 概要は、ホルダーを「AT-CLOUD Asre Dadeha Asiatech」として報告し、2026年7月12日のクエリ時にアナウンスされていることを示しました。そのルーティングステータスビューは、AS60077 から見える18の IPv4 プレフィックスと14,080の IPv4 アドレスを示し、最初に観測されたプレフィックスは2014年に遡り、最新の観測はクエリ時でした。同じ RIPE ビューは、高い IPv4 コレクターの可視性と、その特定のステータス応答では見える IPv6 スペースがないことを示しました。
アクティブなサービスも AS60077 を指しています。RIPEstat のcloud.ir の DNS チェーンビューは、エーペックス名に対して193.151.157.174を返し、そのアドレスに対するネットワーク情報ビューは193.151.157.0/24と AS60077 にマッピングされました。これは、すべての顧客ワークロードが同じプレフィックス内で実行されていることを証明するものではありませんが、企業自身の公開ウェブプレゼンスがクラウド ASN から提供されていることを示しています。
依存関係はネイバーデータにあります。RIPEstat のAS60077 の ASN ネイバービューは、観測された左側のネイバーを1つ示しました：AS43754。RIPEstat のAS43754 の AS 概要は、そのネットワークを「ASIATECH Asiatech Data Transmission company」と名付けています。そのルーティングステータスビューは、同じクエリ時にはるかに大きなネットワークフットプリントを示しました：316の IPv4 プレフィックス、209,920の IPv4 アドレス、86の観測されたネイバー。構図は直接的です。クラウド ASN は可視ですが、その公開アップストリーム境界はより大きな ASIATECH ネットワークであるように見えます。
Looking-glass サンプルは、実際のパスで関係を可視化します。AS60077 のアナウンスされたプレフィックスの1つである193.151.128.0/22に対する RIPEstat のlooking-glass データは、AS43754 AS60077 で終わるパスを含んでいました。いくつかのグローバルサンプルは AS43754 の前のより早期のアップストリームも示しましたが、一貫したオリジン近くの依存関係は AS43754 のままでした。これは、同じ企業インフラグループに属するクラウドビジネスにとって驚くべきことではありませんが、その境界での障害が一度に多くのサービスに影響を与える可能性があるため重要です。
これは AS60077 が脆弱であることを意味しません。単一の可視アップストリーム関係は、親ネットワークがキャリア到達性、運用規律、そして背後に十分な冗長性を持つ場合、完全に合理的です。また、AS43754 が1つの外部パスしか持たないことも意味しません。RIPEstat は AS43754 の多くのネイバーを示しました。重要な点はより狭いです。公開 BGP 証拠は、AS60077 自体が AS43754 の外部で複数の独立したアップストリーム、別個の物理エントランス、別個のエッジルーター、独立したフェイルオーバーを持つことを証明しません。顧客は、Cloud.ir がさらなる分離の製品固有の証拠を提供しない限り、AS43754 を可視のアップストリーム運用境界として扱うべきです。
RPKI は別の質問に答えます。AS60077 によって発信された193.151.128.0/22に対する RIPEstat のRPKI 検証は、AS60077 をカバーするルートオリジン認証で有効なステータスを返しました。これはポジティブなルーティング衛生です。ルートオリジンの正当性をサポートします。トラフィック容量、ルート多様性、電力継続性、顧客分離品質、バックアップ回復可能性、サポート応答を証明するものではありません。RPKI 有効なルートでも、誤って撤回されたり、アップストリームによってフィルタリングされたり、クロスコネクト障害で分離されたり、サーバー側の停止で役に立たなくなったりする可能性があります。
インストールされた容量は、使用可能なクラウド容量と同じではない
クラウド購入者はリソーススライダーを見る傾向があります。オペレーターは在庫を見ます。CPU、メモリ、ディスク、バックアップスペース、パブリックアドレス、ファイアウォール状態、監視、ポート容量、ホスト消費電力、スタッフ時間はすべて、リソーススライダーが動作するサーバーになる前に整列しなければなりません。Cloud.ir の公開ページはそれらの要素の一部を明らかにするので有用ですが、在庫レベルは明らかにしません。
価格ページは、固定メモリ、プロセッサ、ディスク、トラフィック数量のパッケージをリストしています。また、バックアップスケジュールを含むクラウドインフラストラクチャの別個の時間単位コンポーネントもリストしています。これは、Cloud.ir がサービスを価格設定されたリソースプールとして販売していることを示すのに十分です。プール内のホスト数、フェイルオーバー用に予約されているホスト数、競合下で利用可能なディスクパフォーマンス、バックアップスペースが別のサイトにあるかどうか、損傷したインスタンスをどれだけ迅速に再作成できるか、ハードウェア不足の際にプロバイダーが大口注文を満たせるかどうかを示すには不十分です。
ネットワーク番号は外側の境界を提供し、サーバー数ではありません。RIPEstat のAS60077 のアナウンスされたプレフィックスリストは、最近のクエリ期間に18の IPv4 プレフィックスを示し、いくつかの/22、/23、/24の範囲を含んでいました。ルーティングステータスビューで見られた14,080の IPv4 アドレスは実際のパブリックアドレス容量ですが、アドレスは仮想マシンと等しくありません。一部のアドレスはルーター、ロードバランサー、ファイアウォール、ネームサーバー、顧客インスタンス、管理機能、予備プールに使用されます。単一のサーバーが複数のアドレスを使用できます。多くのサービスが1つのアドレスの背後に存在できます。未使用のアドレスは、満杯のコンピュートクラスターと共存できます。
同じ注意が Cloud.ir の IPv6 参照にも適用されます。価格ページは VPS パッケージカードに IPv6 を表示しています。ここで使用された RIPE ルーティングステータスクエリは、クエリ時に AS60077 の可視 IPv6 スペースを示しませんでした。これは製品に IPv6 が存在しないことを証明しません。IPv6 は別の取り決めを通じて提供され、特定のプランでのみ公開され、他のコレクターで可視であるか、サードパーティのルーティングサイトで異なる方法で表現される可能性があります。これは、ネイティブ IPv6 を必要とする顧客が、パッケージラベルのみに頼るのではなく、実際の割り当て、ルーティング、ファイアウォール動作、逆 DNS、バックアップ到達可能性、サポートエスカレーションをテストすべきであることを意味します。
Cloud.ir 自身の製品言語も、容量と回復力を分離しています。クラウドサーバーページは、リソースを即座に増減でき、1つのサーバーが利用できなくなった場合、データは自動的に別のサーバーから利用可能になると述べています。クラウドデータセンターページは、保存されたデータが複数のデータセンターに保持され、1つに問題が発生した場合でも他のデータセンターが接続性を維持すると述べています。これらは重要な主張です。また、精度が必要です。どのサービスがカバーされるのか？すべてのサーバータイプで自動転送なのか、それとも特定のストレージ層で保護されたデータのみか？デフォルトで2つのデータセンターが使用されるのか、それとも顧客が設定した場合のみか？バックアップはホット、ウォーム、またはコールドか？テストされた復旧時間はあるか？自動化が失敗した場合にクレジットは利用可能か？
これらの回答なしでは、購入者は「インストールされた」と「使用可能な」を分けて考えるべきです。インストールされた容量は、プロバイダーが所有またはリースするホスト、ラック、ストレージアレイ、リンク、アドレスの集合です。使用可能な容量は、ホストを過負荷にしたり、アドレスプールを枯渇させたり、配置ルールに違反したり、深夜に部品を交換するために1人の疲れた技術者に依存したりすることなく、顧客が今すぐ割り当てられるものです。Cloud.ir の公開ページは、価格設定されたクラウド製品と可視のネットワークを証明します。それらは、それを容量予約に変換するのに十分な情報を開示していません。
SLA は、障害がテストするまさにその点で約束を狭める
Cloud.ir はSLA ページを公開しており、これはリスク会話の一部を公開テキストに移すため、顧客にとって良いことです。ページの最も重要な部分は大きな稼働時間数値ではなく、制限事項です。ページは、稼働時間保証が通常の運用中のネットワークとクラウドサーバーの可用性にのみ適用されると述べています。顧客のサーバーソフトウェア、オペレーティングシステム、構成問題、クラウドサーバーに対するサービス拒否攻撃、中断または停止されたサーバー、ネットワークまたはホストサーバー以外の停止、および事前に通知されたメンテナンスまたは重要なパッチを除外します。
同じページは、平均修理時間または復旧時間を、プロバイダーと顧客間の合意に基づくサービスの復旧にかかる平均時間と定義しています。その後、不可抗力、顧客の機器、計画ダウンタイム、顧客要求による中断、法律または SLA 違反、未払い、司法またはセキュリティ当局からの命令を含む、罰則が発生しないケースをリストしています。これらの除外はホスティングでは珍しくありませんが、リスクを測定しようとする顧客にとって決定的です。これらは、多くの実際の停止を単純な稼働時間見出しの外に移動させます。
ソフトウェア障害を考えてみましょう。顧客の更新後にゲストオペレーティングシステムが壊れた場合、SLA テキストは、顧客が完全なサービス損失を経験しても、問題はプロバイダーの稼働時間保証の範囲外であることを示唆しています。Cloud.ir がアンマネージドコンピュートを販売した場合、それは合理的ですが、購入者には別の復旧権利（コンソールアクセス、レスキューブート、スナップショット、イメージエクスポート、ロールバック、再構築、明確なサポート境界）が必要であることを意味します。「クラウドサーバー」は、契約でそう定められていない限り、管理されたアプリケーションの継続性ではありません。
サービス拒否イベントを考えてみましょう。クラウドサーバーページは、クラウドファイアウォール制御と攻撃報告を促進しています。SLA ページは、クラウドサーバーに対するサービス拒否攻撃を稼働時間保証から除外しています。製品は依然としてトラフィックの緩和に役立つ可能性がありますが、顧客はすべての攻撃誘発の中断が補償を生み出すと想定すべきではありません。問題は実用的になります。ファイアウォールはどのトラフィック量を処理できるか、クラウドエッジで何がフィルタリングされるか、インスタンスに何が到達するか、攻撃中に誰がフィルターを変更できるか、いつ Cloud.ir が他の顧客を保護するためにターゲットを停止またはレート制限できるか。
請求を考えてみましょう。SLA の未払い除外は普通ですが、運用リスクは軽微ではありません。プリペイドウォレット、国内支払いの失敗、企業銀行カードの問題、請求紛争は、オペレーターがアカウントを解決する前にサーバーが停止された場合、インフライベントになる可能性があります。Cloud.ir をプロダクションで使用する企業は、何回のリマインダーが送信されるか、どのような猶予期間が適用されるか、停止後のデータ保持はどうか、スナップショットにアクセス可能かどうか、請求証拠が審査されている間にサポートが一時的にサービスを維持できるかどうかを尋ねるべきです。
公権力の命令を考えてみましょう。SLA は、司法またはセキュリティ当局によって引き起こされたダウンタイムは罰則の枠組み外であると述べています。これはプロバイダーに対する判断ではなく、地域性の問題です。ワークロード、バックアップ、サポートアカウントが1つの管轄区域内にある場合、顧客は法律やポリシーの命令が可用性、データアクセス、ドメインサービス、顧客コミュニケーションにどのように影響するかを理解する必要があります。回答は、国内のイランのウェブサイトには受け入れ可能であり、矛盾するコンプライアンス義務を持つクロスボーダーサービスには受け入れられない可能性があります。同じ物理的な地域性は、レイテンシにとって強みであり、ガバナンスにとって制約となり得ます。
したがって、SLA は購入者の質問をより鋭くします。Cloud.ir を弱くするのではなく、サービスの形状をより知らせることができます。顧客は、ネットワーク可用性、ホスト可用性、ゲストの健全性、ストレージ整合性、バックアップ復旧可能性、CDN 動作、アカウントステータス、法的制約を区別する必要があります。公開 SLA はそれらの層を1つの約束にまとめません。プロダクション購入者もそうすべきではありません。
CDN、ストレージ、クラウドスイッチングは、機能セットと同様に爆発半径を拡大する
Cloud.ir の CDN、ストレージ、仮想ネットワーキングサービスは、単一のオリジンサーバーへの負荷を軽減し、顧客により多くのアーキテクチャ選択肢を提供できるため有用です。また、依存関係マップをより広くします。CDN ページは、国内配信がローカルデータセンターを通じてリクエストに応答し、国内ユーザーに半額のトラフィックを提供できると述べています。また、ユーザーをより近いサーバーにルーティングし、コンテンツを圧縮およびキャッシュし、リクエストと応答を監視し、国別のアクセス制限、攻撃に対する保護について説明しています。これは実際の製品ストーリーですが、サイトをチェーンに変えます。DNS、CDN エッジ、キャッシュ状態、オリジン到達可能性、証明書処理、アカウント構成、サポートがすべて連携する必要があります。
オリジンサーバーが故障した場合、CDN はキャッシュされた静的コンテンツを提供し続ける可能性があります。また、古いコンテンツを提供したり、動的ルートで失敗したり、キャッシュミスが不健全なオリジンに当たったときにエラー率が増加したりする可能性があります。CDN エッジがアップストリーム到達可能性を失った場合、1つのリージョンのユーザーはエラーを見る可能性があり、他のリージョンではそうでない場合があります。アクセスルールが誤って構成された場合、地域性機能は可用性の問題になる可能性があります。顧客は、キャッシュパージ制御、オリジンシールド動作、ログ、フェイルオープンまたはフェイルクローズルール、証明書更新の可視性、そして CDN サービスが障害になった場合に DNS を移動する方法を必要とします。
ストレージ提供は異なるリスク形状を持ちます。クラウドストレージページは、サービスが容量をスケーリングし、ファイルを管理し、アクセスキーを管理し、ストレージをドメインに接続し、ファイルを共有し、アクセスレベルを定義できると述べています。また、データは複数のサーバーに分散して保護されると述べています。これは価値がありますが、ストレージの耐久性は外部から見えません。顧客は、サービスがオブジェクトストレージ、ブロックストレージ、ファイルストレージ、またはそれらの混合か、レプリケーションの意味、レプリカが1つの部屋か複数のサイトに存在するか、削除がどのように保護されるか、バージョニングが存在するか、キーがどのようにローテーションされるか、復旧がどのようにテストされるか、完全なエクスポートがどれだけ早く完了できるかを知る必要があります。
クラウドスイッチサービスも同様に重要です。クラウドスイッチページは、クラウドサーバーとデータセンター間の管理されたネットワーキング、トラフィックのルーティング、プライベートネットワークの作成について説明しています。また、障害時に利用可能な代替リソースを特定し、自動的に切り替えることができると述べています。このタイプの機能は、適切に実装されていれば手動復旧を減らすことができます。また、プライベートネットワークの誤構成が他の点では健全なサーバーグループを分離する場合、変更の単一障害点にもなり得ます。
より深いパターンは、機能が回復力の層であると同時に新しい依存関係にもなり得ることです。バックアップは、障害境界の外部に保存され、迅速に復元できる場合にのみデータを保護します。CDN は、オリジンが弱い場合にコンテンツが正しく提供される場合にのみオリジンを保護します。仮想ネットワーキングは、コントロールプレーンとスイッチングファブリックが健全である場合にのみ東西トラフィックを保護します。クラウドファイアウォールは、フィルター変更がプレッシャーの下で安全に行える場合にのみ顧客を保護します。顧客は、これらの機能が抽象的に存在するかどうかを尋ねるべきではありません。各機能が、ホスト、ラック、ルート、ストレージクラスター、アカウント、サポートキューがすでに障害しているときにどのように動作するかを尋ねるべきです。
地域性はスローガンではなく製品属性である
データ地域性は Cloud.ir から購入する最も強力な理由の1つです。会社のページは、クラウドインフラストラクチャをイランの ASIATECH データセンターに置き、CDN ページは国内配信オプションを強調し、ネットワーク証拠は公開クラウドサイトがイランの ASIATECH 親ネットワークを持つ AS60077 上にあることを示しています。イランのユーザーや企業にとって、これは低レイテンシ、国内支払いの調整、馴染みのあるサポート言語、ローカルトラフィック経済、そして物理的資産が対象ユーザーに近いプロバイダーを意味します。
しかし、地域性はサービスごとに定義される必要があります。仮想サーバーはイランで実行される一方で、メールリレー、管理コンソール、分析サービス、バックアップコピー、サポート添付ファイルは別の経路を取る可能性があります。CDN 製品は国内および国際配信モードを提供する場合があります。ストレージサービスは、それらのサーバーが別々の建物にあるかどうかを言わずに、複数のサーバー間でレプリケーションを行う場合があります。顧客は、会社の住所、トップレベルドメイン、自律システム名、または「イラン全体のデータセンター」というフレーズから、すべてのデータコピーの正確な場所を推測することはできません。
Cloud.ir 自身の顧客向けプロファイルのリージョン行は、IP 到達可能性がグローバルであり、クラウド顧客は動作するアカウントとネットワークパスがあればどこにでもいられるため、グローバルに設定できます。これは、同社がグローバルリージョンを運営していると言うのとは異なります。ここでレビューされた公開製品証拠は、イランのインフラストラクチャと ASIATECH の国内データセンター資産を最も強く指しています。顧客がイランのみのサービスを必要とする場合、コンピュート、ストレージ、バックアップ、ログ、サポートアクセスの地域性について書面による声明を求めるべきです。顧客が多国間の継続性を必要とする場合、Cloud.ir 自身がそれを提供するのか、それとも顧客が別のプロバイダーで構築する必要があるのかを尋ねるべきです。
地域性はインシデント対応も変えます。国内のイランのコンテンツサイトは、ほとんどのユーザーがそれらのパスの近くにいるため、Cloud.ir の国内 CDN 動作と ASIATECH 施設を好むかもしれません。国際的な SaaS ベンダーは、支払いアクセス、制裁エクスポージャー、外国ユーザーのレイテンシ、ルートフィルタリング、紛争解決、プレッシャーの下でのデータエクスポート能力を心配するかもしれません。公共セクターや規制対象ユーザーは、ローカル施設の制御を重視するかもしれませんが、誰がデータにアクセスできるか、スナップショットがどこにあるか、当局からの命令がどのように処理されるかについてより厳格な声明を必要とします。同じインフラストラクチャが、ある顧客には適していて、別の顧客には不適切である可能性があります。
実用的なテストは証拠です。カスタマーパネルで利用可能なリージョンとサイトの選択肢を尋ねてください。2つのインスタンスを別々の施設に配置できるか尋ねてください。スケジュールされたバックアップがどこに保存されるか尋ねてください。CDN ログとストレージメタデータがどこに保持されるか尋ねてください。サポートエンジニアが顧客のディスク、スナップショット、キー、コンソールにアクセスできるか、またどこからアクセスできるか尋ねてください。完全なエクスポートが、アカウントを別の長い請求サイクルでアクティブに保つことなく完了できるか尋ねてください。これらの質問に冷静に答えられるプロバイダーは、広範な地域性の言葉だけに依存するプロバイダーよりも信頼しやすいです。
主な障害経路は、ラック、ルート、ハードウェア在庫、アカウントステータス、移行を通る
顧客が計画すべき最も可能性の高い Cloud.ir の障害は、劇的な完全停止ではありません。それは、契約層の間にある部分的な障害です。VM は正常でもアップストリームルートが劣化している場合があります。ルートは正常でもストレージパフォーマンスが低下している場合があります。バックアップは存在しても復元スループットが遅すぎる場合があります。CDN は静的コンテンツに応答しても動的機能が失敗する場合があります。カスタマーパネルは到達可能でも支払いが再構築を妨げる場合があります。これらの中間状態こそ、顧客がサービスの背後に十分な運用詳細があるかどうかを学ぶ場です。
ラック経路は物理ハードウェアから始まります。ホスト障害は、共有ストレージ、予備のホスト容量、機能するオーケストレーションがあれば、うまく設計された VM を別のホストに移動できます。また、ローカルストレージ、ベアメタル割り当て、または非冗長コンポーネントが関与する場合、顧客を部品待ちにさせる可能性があります。公開 Cloud.ir ページは、ハイパーバイザープラットフォーム、ホストクラス、ローカル対共有ストレージの選択肢、予備ハードウェアポリシーを開示していません。顧客は、物理サーバーが故障したときに何が起こるか、どのサービスが自動的に再起動するか、どのサービスがチケットを必要とするか、同等のハードウェアでの再構築に保証された最大時間があるかどうかを尋ねるべきです。
アップストリーム経路は、AS60077 の AS43754 への可視依存から始まります。AS43754 がルートをフィルタリングしたり、エッジ問題を抱えたり、ポリシーを変更したり、広範なインシデントを被ったりした場合、顧客 VM が稼働していても AS60077 の顧客サービスが影響を受ける可能性があります。公開データは AS60077 の観測されたアップストリーム境界として AS43754 を示しているため、顧客は、クラウド ASN が別個の物理エッジルーター、AS43754 への複数のハンドオフ、直接の外部トランジット、最近のフェイルオーバーテストを持っているかどうかを尋ねるべきです。親ネットワークが多くのネイバーを持っていると言うだけでは十分ではありません。関連する質問は、クラウドエッジで何が起こるかです。
ハードウェア在庫経路は成長と修理に関するものです。時間単位のクラウド価格設定と即時スケーリングは、予備の CPU コア、RAM、ディスク、アドレス、スイッチポートがある場合にのみ役立ちます。キャンペーン、イベント、ローンチ、移行を計画している購入者は、容量を予約できるかどうか、大規模な増加に通知が必要かどうか、プロバイダーが追加容量を別の障害ドメインに配置できるかどうかを尋ねるべきです。より小規模な購入者は、より単純な質問を尋ねるべきです。現在のホストが故障した場合、サーバーを他の場所で再起動するのに十分な予備スペースがすでにありますか？
サポート経路は時間と権限に関するものです。Cloud.ir は、クラウドサーバー顧客がいつでもチケットを提出できると述べています。これは限定的な営業時間チャネルよりも優れていますが、顧客は依然としてエスカレーションターゲットを必要とします。誰が BGP ルートを変更できますか？誰がラック訪問を許可できますか？誰が削除されたバックアップを復元できますか？誰がアカウント停止を解除できますか？誰が法的またはセキュリティ命令を説明できますか？一次サポートチームがリクエストを転送することしかできない場合、修理時間にはすべての引き継ぎが含まれます。
移行経路は最終的な安全網です。顧客は、迅速に離脱できる場合、弱い証拠に耐えることができます。そのためには、最新のバックアップ、エクスポート可能なイメージまたはファイル、文書化された IP および DNS 変更手順、既知の TTL、請求紛争中も利用可能なアカウントアクセス、データを移動するのに十分な帯域幅が必要です。また、再現できないプライベートネットワークアドレス、エクスポートパスのないストレージ機能、他の場所で再現できない CDN ルール、ダウンロードできないスナップショットなどの隠れたロックインを避ける必要があります。公開 Cloud.ir ページは再構築、バックアップ、アカウント操作について説明していますが、完全な移植性条件は開示していません。プロダクションユーザーは、必要になる前にそれらを入手すべきです。
購入者が Cloud.ir に依存する前に確認すべきこと
最初の確認タスクは配置です。Cloud.ir は、どのサービスをどのイランの場所に配置できるか、場所が別個の建物、ホール、または論理ラベルか、2つのインスタンスを分離できるかを言えるべきです。答えが「クラウドが処理します」の場合、顧客は平易な言葉で障害ドメインの説明を求めるべきです。小規模プロバイダーは信頼性のためにハイパースケールの用語を必要としませんが、正直な境界は必要です。
2番目のタスクはネットワーク多様性です。AS60077 は可視で正当であり、AS43754 は実質的な親ネットワークです。それは良い出発点です。顧客トラフィックが AS43754 のエッジイベントを生き残れることを証明するのと同じではありません。通常のパス、バックアップパス、エッジルーター設計、DDoS 処理境界、RPKI およびルートフィルタリングプラクティス、Cloud.ir がインシデント中に顧客プレフィックスを一時的にアナウンスしたり、パブリックアドレスを移動できるかどうかを尋ねてください。ほとんどの VPS 顧客にとって答えは「いいえ」でしょうが、その質問は依存関係を明確にします。
3番目のタスクは復元証拠です。バックアップは製品機能としてリストされており、価格ページは毎週、3日、毎日のバックアップコンポーネントを区別しています。顧客は、スナップショットがどのようにスケジュールされるか、何がキャプチャされるか、何がキャプチャされないか、バックアップコピーがどこに保存されるか、どのくらい保持されるか、典型的な復元時間はどれくらいか、復元が別のサイトをターゲットにできるか、プロバイダーが最近の復元テスト結果を持っているかを尋ねるべきです。損傷した境界を離れられないバックアップは、狭いクラスの障害に対する保険にすぎません。
4番目のタスクはメンテナンスと除外です。SLA は、通知されたメンテナンスと重要なパッチを稼働時間計算から除外します。メンテナンスがどのように通知されるか、どのくらいの通知期間があるか、緊急作業が通常の通知なしで発生する可能性があるか、顧客がウィンドウを選択できるか、複数の顧客リソースが一緒にメンテナンスされるかを尋ねてください。メンテナンスウィンドウは悪くありません。不明確なウィンドウが悪いのです。
5番目のタスクはアカウント継続性です。未払いは SLA 罰則枠組み外であるため、プロダクション購入者はウォレット資金調達、請求タイミング、停止しきい値、異議申し立て経路、停止後のデータ保持を理解すべきです。これは特にイラン国外のチーム、調達遅延のあるチーム、支払いアクセスが1人に依存しているチームにとって重要です。請求の失敗は回避可能な停止になる可能性があります。
6番目のタスクは退出です。1つの小規模サーバーイメージをエクスポートし、1つのバックアップをクリーンなインスタンスに復元し、1つの DNS レコードを CDN から移動させ、1つのファイアウォールポリシーを他の場所で再作成し、時間を記録します。これらのテストは、明らかにするために大規模である必要はありません。これらは、プロバイダーの抽象化が顧客の回復に役立つのか、主に顧客の定着に役立つのかを示します。
運営テーゼ：実際のサービス、強力なネットワーク可視性、不完全な物理的証明
CLOUD Asre Dadeha Asiatech は、古いルーティングエントリのみを持つ企業よりも高い信頼レベルに値します。Cloud.ir はアクティブであり、サービスカタログは具体的で、価格ページは具体的なリソースパッケージを公開し、SLA は公開されており、RIPE レコードは AS60077 を AT-CLOUD Asre Dadeha Asiatech として公開ルーティングテーブルに配置しています。企業サイトの DNS は AS60077 を指しています。AS60077 は可視のアドレス資産を持ち、AS43754 への親ネットワーク依存性は隠されるのではなく観測可能です。
それがサービスを完全に透明にするわけではありません。公開記録は、顧客ワークロードの正確なデータセンター配置、利用可能なホスト数、予備ハードウェアの量、現実世界の復元時間、すべてのバックアップの場所、ルートの物理的多様性、クラウドエッジでのルートフェイルオーバー設計、顧客が紛争時に依存するアカウントおよび移行条件を示していません。Cloud.ir 自身のマーケティングは可用性とデータ永続性について強力な発言をしていますが、その SLA はカバーされる範囲に実用的な境界を引いています。
したがって、正しい読み方はバランスが取れています。製品は存在します。ネットワークは可視です。物理的依存関係は現実です。購入者は、イランのデータセンター近接性、ASIATECH の国内インフラストラクチャ、およびローカルのクラウドコントロールパネルの恩恵を受けるワークロードに対して、Cloud.ir を合理的に検討できます。同じ購入者は、クラウドラベルをマルチサイト回復力、ルート多様性、シームレスな退出の証明として扱うことを避けるべきです。これらは、取得し、テストし、文書化する必要があるエンジニアリングおよび契約上の事実です。
小規模なウェブサイトの場合、バックアップが独立しており、DNS を迅速に移動できるなら、残りの不確実性は許容できるかもしれません。高トラフィックのイランのメディアプロパティの場合、CDN と国内ホスティングは価値があるかもしれませんが、運用者はローンチ前にオリジン障害、キャッシュ動作、サポートエスカレーションをテストすべきです。規制対象またはクロスボーダーデータの場合、重要な質問は地域性、権限エクスポージャー、サポートアクセス、エクスポート権です。プロダクション顧客の場合、最終的な規律は同じです。クラウドサービスを購入しますが、その背後にあるラック、ルート、修理、移行のストーリーを監査してください。