要約

  • Cloud APAC の最も強力な公開識別子はAPNIC RDAP for AS132399であり、ASN はATICLOUD-AP、記述は SITA Cloud APAC、国は SG、登録者は国際航空通信機関 (SITA) と記載されています。
  • RIPEstat のAS 概要は現在、ホルダーをATICLOUD-AP - SITA Cloud APACとして報告し、ASN がアナウンスされていることを示しており、これは休眠レジストリオブジェクトよりも強力な証拠です。
  • 現在の公開ルーティングは依然として限定的です。RIPEstatルーティングステータスは 4 つの IPv4 プレフィックスを示し、IPv6 プレフィックスは見えず、1 つの観測されたネイバーを示しています。RIPEstatASN ネイバーは、見えるネイバーを AS15830 と識別しています。
  • アナウンスされているプレフィックスは可視であり、ルートオリジン検証チェックはポジティブです。RIPEstatアナウンスされたプレフィックスは 57.250.51.0/24、57.191.95.0/24、57.191.96.0/19、57.191.160.0/19 をリストしています。これらの 4 つのオリジンの RIPEstat 検証チェックは有効なステータスを返します。
  • SITA 自身の公開ページは、ワークロードが運用上重要である可能性を示しています。SITA は航空交通通信と情報技術を提供し、1,000 以上の空港で活動し、SITA Connectを航空関連拠点向けの管理接続として販売しています。
  • 公開記録は、Cloud APAC の背後にあるデータセンター、ラック数、サーバー所有権、サポートエスカレーションパス、バックアップ境界、顧客エクスポート手順、マルチサイトフェイルオーバー設計を特定していません。ネットワーク証拠のグレードは中程度です。現在の IPv4 ルーティングは可視で検証されていますが、顧客利用可能な復元力は未証明です。

クラウドの請求書は依然としてシンガポールのラックで終わる

クラウドサービスは抽象化として販売されます。リージョン、ポータル、管理リンク、アプリケーションホスト、サポートキュー、月額契約です。ユーザーにはアカウント、ヘルプデスク、IP アドレス、レイテンシターゲット、サービスダッシュボードが見えます。オペレーティングシステムにはより現実的なものが見えます。キャビネット内のサーバーまたは仮想マシン、ルーターポート、クロスコネクト、電力パス、冷却エンベロープ、ストレージプール、バックアップターゲット、アップストリームプロバイダー、そして顧客の期限前に変更を加えられる人々です。

これが Cloud APAC を読む有用な方法です。公開フットプリントは、パッケージカードとチェックアウトページを備えた小売り VPS 企業のようには見えません。これは、シンガポールでコード化されたネットワークおよびクラウドマーカーが SITA の航空交通技術環境内にあるように見えます。APNIC RDAP for AS132399は ASNATICLOUD-APを命名し、記述を SITA Cloud APAC、国を SG、登録者を国際航空通信機関 (SITA) と記録しています。RIPEstat のwhois ビューは同じ AS 名、記述、国、APNIC ソースに加え、AS15830 からのインポートとエクスポートのルートポリシー行を示しています。

これらの記録は公開識別子を固定するのに十分です。しかし、Cloud APAC を完全な顧客対応アーキテクチャとして扱うには十分ではありません。顧客は ASN だけから、サービスが所有ラック、コロケーション、リースベアメタル、仮想化クラスター、パブリッククラウドバックエンド、空港エッジアプライアンス、サプライヤー管理キャパシティのいずれを使用しているかを推測できません。また、同じプラットフォームが乗客処理、空港接続、カスタマーサービスシステム、内部アプリケーション、またはネットワーク制御インフラのみをホストしているかも推測できません。

この区別が重要なのは、SITA の広範な事業がカジュアルなインフラではないからです。SITA 自身のホームページは、同社が航空交通通信と情報技術の専門家であり、国際的な拠点、顧客、空港にプレゼンスがあると述べています。同社の会員ページは、SITA のネットワークによって 13,500 以上の業界サイトが接続されており、ほぼすべての航空会社と空港が SITA と取引していると述べています。同社の航空会社ページは、統合航空会社システムを旅客旅程の一部として位置付けています。クラウドまたはネットワーク要素がその世界にある場合、障害はチェックインカウンター、運航管理システム、手荷物処理ルーチン、空港接続、航空会社オフィス、およびそれらを稼働させ続けるサポートチームに影響を与える可能性があります。

したがって、正しい質問は Cloud APAC が存在するかどうかではありません。公開記録はルーティングされた ASN として存在することを示しています。正しい質問は、顧客アカウントの背後にあるキャパシティが、航空交通および地域エンタープライズユーザーが実際に必要とする方法で回復力があるかどうかです。ラックが電力を失った場合、どのサービスが移行しますか?アップストリームパスが失敗した場合、どの代替パスがトラフィックを運びますか?ハードウェアが在庫切れの場合、どのワークロードが待機しますか?サポートチェーンがタイムゾーンや法的エンティティをまたぐ場合、インシデントクロックは誰が所有しますか?顧客が移行する必要がある場合、アカウントまたはサプライヤー関係が問題になる前に、使用可能なデータをエクスポートできますか?

公開ルーティング証拠が証明すること

AS132399 は古いエントリではありません。RIPEstat のAS 概要は、ホルダーをATICLOUD-AP - SITA Cloud APACとして報告し、ASN がアナウンスされていることを示しています。RIPEstat のルーティングステータスは現在の IPv4 可視性も示しており、325 の RIS ピアが ASN を確認し、4 つの IPv4 プレフィックス、16,896 の IPv4 アドレスがあります。これは、観測されたルートがないレジストリ記録よりもはるかに強力なシグナルです。

現在のプレフィックスリストは具体的です。RIPEstatアナウンスされたプレフィックスは、最新の 2 週間のウィンドウで 57.250.51.0/24、57.191.95.0/24、57.191.96.0/19、57.191.160.0/19 をリストしています。RIPEstat プレフィックス概要チェックは、これらの 4 つのプレフィックスが AS132399 によって発信されていることを示しています。57.250.51.0/2457.191.95.0/2457.191.96.0/1957.191.160.0/19です。

レジストリの地理は混合しており、注意深く解釈する必要があります。57.191.95.0/24の APNIC RDAP は範囲SITA-SPC-SIN-addを国 SG で命名しています。57.191.96.0/19の APNIC RDAP はSITA-SPC-SIN-S1を国 SG で命名しています。57.191.160.0/19の APNIC RDAP はSITA-SPC-SIN-S2を国 SG で命名しています。ただし、57.250.51.0/24の APNIC RDAP は、より広い 57.250.0.0 から 57.250.255.255 の登録を返し、名前はSITA-SC-Infrastructure、国は BE、SITA エンティティです。

その混合はルートを信頼できないものにするわけではありません。しかし、国ラベルは完全なデータレジデンシーの証明として使用すべきでないことを意味します。プレフィックスはある国値で登録され、APAC ASN によって発信され、他の場所のインフラに使用され、グローバルキャリアを通じてルーティングされ、または複数の管轄区域にデータを保存するサービスに割り当てられる可能性があります。顧客にとって、レジストリの国コードは出発点です。拘束力のある事実は、契約、施設の場所、バックアップの場所、サポートチケットの場所、ログの場所、エクスポートパスです。

ルートオリジンの姿勢はポジティブです。57.250.51.0/2457.191.95.0/2457.191.96.0/1957.191.160.0/19の RIPEstat ルートオリジン検証は、チェック時に AS132399 に対して有効なステータスを返します。有効なルートオリジン検証はすべてのルーティングインシデントを防ぐわけではありませんが、オリジン設定ミスやハイジャックのリスクの重要なクラスを低減します。一部の小規模ホスティングネットワークが依然として不明または不完全な RPKI 姿勢を持つ市場では、これは意味のあるポジティブシグナルです。

最大の注意点は IPv6 です。RIPEstat ルーティングステータスは、チェック時に AS132399 の可視 IPv6 プレフィックスを示していません。APNIC whois 派生記録には AS15830 との IPv6 インポートおよびエクスポートポリシー行が含まれているにもかかわらずです。これはサービスの設計選択、未発表の IPv6 計画、コレクターの可視性の問題、またはこの ASN の下で可視 IPv6 を必要としない配信設計を反映している可能性があります。それでも顧客にとって重要です。Cloud APAC が最新のホステッドまたはマネージドサービスの一部である場合、デュアルスタック到達可能性、IPv6 フィルタリング、ルートオリジン認証、モニタリングは、IPv4 のみの公開ビューから推測するのではなく、直接回答されるべきです。

1 つの可視アップストリームは設計上の質問であり、評決ではない

ルートポリシーと観測されたネイバーの状況は同じ方向を指しています。RIPEstat のAS132399 の whois データは、AS15830 からのインポートを任意のものとして受け入れ、AS15830 へのエクスポートは AS132399 をアナウンスすると示しています。RIPEstat のASN ネイバービューは 1 つのユニークな可視ネイバー、AS15830 を示しています。RIPE RDAP for AS15830は AS 名を Equinix と識別し、Equinix Internet Access / Equinix Connect をグローバル IP トランジットプラットフォームとして説明しています。RIPEstat のAS15830 の AS 概要はホルダーを Equinix として報告し、PeeringDBは Equinix as15830 をネットワークサービスプロバイダーとしてリストしています。

Equinix はシンガポール向けネットワークにとって妥当で高品質なアップストリームコンテキストです。Equinix のシンガポールページは、ローカルデータセンターと相互接続のプレゼンスを説明しており、一般的なシンガポールデータセンターのページSG1 施設(Ayer Rajah)、SG3 施設を含みます。このコンテキストにより、Cloud APAC のルーティングパスが読みやすくなります。可視インターネットエッジは、未知の消費者 ISP ではなく、大規模な相互接続およびトランジットエコシステムに関連付けられています。

しかし、1 つの可視アップストリームは完全な冗長性と同じではありません。少なくとも 4 つのレイヤーを分離する必要があります。ルート多様性は BGP が複数のパスを持つかどうかを尋ねます。キャリア多様性は、それらのパスが独立した商用サプライヤーによるものかどうかを尋ねます。物理的多様性は、クロスコネクト、ミートミールーム、ルーター、電力回路、建物の入り口が共有障害を回避するかどうかを尋ねます。容量多様性は、最初のパスが失敗した後に生存パスが負荷を運べるかどうかを尋ねます。公開 BGP は最初の 2 つを示唆できます。最後の 2 つについてはほとんど語りません。

AS132399 の場合、公開ルートコレクターは現在 1 つの可視アップストリームを示しています。これは ASN が果たす役割には十分かもしれません。Cloud APAC が管理されたエンタープライズエッジ、内部クラウドセグメント、またはプライベート接続によって支えられたリージョナルフロントドアである場合、可視インターネットパスは全体の設計ではないかもしれません。顧客向けホスティングとして販売または依存されている場合、1 つの可視アップストリームは調達上の質問を提起します。顧客は、第 2 のインターネットトランジットパス、プライベート WAN ルート、クラウド相互接続、コールドスタンバイサイト、別個の DDoS パス、または手動フェイルオーバー手順があるかどうかを尋ねるべきです。

Equinix の存在は、微妙な調達ミスを生む可能性もあります。強力なアップストリームブランドを見ても、顧客が専用キャビネット、専用ポート、多様なハンドオフ、または直接の Equinix サポートを受ける権利があることは証明されません。顧客契約は SITA と結ばれ、ルートは Equinix を通り、ラックは Equinix 施設または他の場所にあり、運用チケットはサービスデスクを経由してからキャリアの手に渡る可能性があります。これらすべての取り決めは機能します。ただし、インシデントが発生する前に文書化される必要があります。

これは特に修理ウィンドウに当てはまります。プロバイダーは優れたアップストリーム接続性を持っていても、光学部品の故障、飽和したファイアウォール、変更フリーズ、アクセス制御の問題、ローカルスマートハンズの遅延、またはネットワークパス外のストレージ障害によって遅延する可能性があります。可視 AS パスは、パケットの行き先を顧客に伝えます。鍵を持っている人、スペアパーツを持っている人、ロールバック権限を持つ人、メンテナンスウィンドウをいつ破れるかを決定する人を顧客に伝えるわけではありません。

SITA の航空業界での役割は小さな障害の影響を高める

SITA の公開ページは、このインフラが通常の小規模ホスティング名よりも注意深く読まれるべき理由を説明しています。SITA のホームページは、同社を航空交通通信と情報技術の専門家と説明し、広範な空港と顧客リーチを示しています。同社のSITA Membershipページは、会員ベースに航空会社、空港、その他の航空エコシステム参加者が含まれ、13,500 以上の業界サイトが SITA のネットワークを通じて接続されていると述べています。同社のSITA Connectページは、750 以上の目的地、600 の事前接続された空港、SD-WAN、SASE グレードのセキュリティ、マルチクラウド接続、航空交通アプリケーションのサポートを備えた管理接続を販売しています。

これらは広範な製品および企業の主張であり、特定の Cloud APAC 施設図ではありません。それでも、Cloud APAC が登場する環境を説明するため重要です。航空交通は、航空会社、空港、地上ハンドラー、政府、手荷物システム、旅客処理システム、国境システム、サービスデスク、ネットワーク間の連携で機能します。その世界におけるリージョナルクラウドまたはネットワークノードは、小売りホストよりも公開向けウェブサイトが少ないかもしれませんが、運用上敏感である可能性があります。パケットパスは、チェックインワークステーション、運航管理ホスト、手荷物メッセージ、航空会社オフィス VPN、管理空港エッジ、クラウド管理プレーン、または監視チャネルをサポートする可能性があります。

SITA のService Managementページは、重要なサポートシグナルを追加します。ITIL 準拠のサービス管理スイート、24 時間 365 日の可用性、プロアクティブな監視、空港および航空会社の運用ニーズのサポートを説明しています。About Usページは、SITA Service Management が SITA Global Services によってサポートされ、年中無休のサポート、グローバルカスタマーサービス、大規模な専門家労働力を提供すると述べています。これらの声明は企業レベルでは安心感を与えますが、Cloud APAC 固有の質問には答えません。どのチームが AS132399 のインシデントを所有し、どのチームがデータセンターの手を所有し、特定の顧客ワークロードにどのようなサービス目標が適用されるのか?

サポート境界はインフラの実際の一部です。クラウドおよびホスティングの障害では、難しい問題は多くの場合、何かが壊れていることを特定することではありません。難しい問題は、適切な権限を持つ人が迅速に行動することです。ルートにはキャリアチケットが必要になる場合があります。サーバーにはケージ内の手が必要になる場合があります。仮想クラスターにはストレージフェイルオーバーが必要になる場合があります。顧客は DNS 変更が必要になる場合があります。セキュリティインシデントにはファイアウォールルール、アカウントロック、フォレンジックホールド、またはバックアップ隔離が必要になる場合があります。大規模な航空サプライヤーでは、サポートチェーンは成熟しているかもしれませんが、製品、地域、重大度、契約によってセグメント化されている可能性もあります。

したがって、顧客にとっての実践的な質問は「SITA にはサービスデスクがあるか?」ではありません。実践的な質問は「私の Cloud APAC サービスには、必要なエスカレーションパスが含まれているか?」です。重大度レベル、最初の応答目標、復旧目標、時間外パス、Equinix または他の施設オペレーターに連絡する権限、顧客のメールがダウンした場合の通信チャネル、および事後報告書の基準を明記する必要があります。世界最高のサービスデスクでも、顧客の特定のアカウントがエスカレーション取り決めの範囲外にある場合は役に立ちません。

シンガポールは強力なハブであるが、厳しい電力制限がある

Cloud APAC の SG 国マーカーとシンガポール名のプレフィックスは、このサービスを魅力的でありながら制約のある市場に位置付けています。シンガポールはアジア太平洋で最も重要な相互接続ハブの 1 つであり、稠密なキャリア、クラウド、エンタープライズエコシステムを備えています。だからこそ、シンガポールのネットワークエッジは、航空、金融、物流、地域エンタープライズワークロードにとって価値があります。主要な海底ケーブルシステム、地域のクラウド需要、多国籍企業の本社、東南アジア全域の空港業務に近い場所にあります。

同じ強みが希少性を生み出します。シンガポールのGreen Data Centre Roadmapは、同国が短期的に少なくとも 300 MW の追加データセンター容量を提供し、さらにグリーンエネルギー導入を通じて提供することを目指していると述べています。IMDA はこれを持続可能なデジタルインフラとエネルギー効率を中心に位置付けています。この政策コンテキストは、シンガポールの容量を使用するプロバイダーにとって重要です。クラウド経済はラック経済だけではないからです。電力、冷却、土地、規制、持続可能性、ハードウェアリフレッシュの経済です。

Cloud APAC の場合、公開証拠は施設を特定していません。Equinix ルートコンテキストは Equinix を関連するトランジットおよび相互接続リファレンスにしますが、Cloud APAC サーバーが特定の Equinix 建物にあることを証明するものではありません。SINと名付けられた APNIC プレフィックスは、シンガポール向けのネットワークリソースを示唆しますが、ラック、ケージ、キャビネット、データホール、または電力供給を特定しません。顧客は依然として施設の声明を必要とします。プライマリサイト、セカンダリサイト、バックアップサイト、管理プレーンの場所、データレジデンシー境界、サプライヤーアクセス取り決めです。

ここで、設置容量と利用可能容量が異なります。プロバイダーはアドレススペースとアップストリームを持っていても、障害が発生したクラスターを退避させるための十分なスペアコンピュートがない場合があります。キャビネットはあっても、成長のための十分な電力ヘッドルームがない場合があります。バックアップリポジトリはあっても、地域インシデントに対する十分な復元帯域幅がない場合があります。単一の十分に接続された施設はあっても、実用的な代替サイトがない場合があります。大規模データセンターオペレーターとの契約はあっても、アクセスウィンドウ、リモートハンズキュー、または変更承認によって制約される場合があります。

シンガポールの政策環境は、これらの質問をより具体的にします。追加のデータセンター容量がエネルギー効率とグリーンエネルギー導入に結びついている場合、新しいラックのコストと可用性は、顧客の成長、更新価格、移行オプションに影響を与える可能性があります。管理キャパシティを購入する顧客は、プラットフォームがシンガポールに拡張ヘッドルームを持っているか、オーバーフローが別の国に行くか、バックアップストレージがシンガポールを離れるか、将来のハードウェアリフレッシュがローカリティの約束を変更するかを尋ねるべきです。

データ主権にも、プロダクションラックの場所よりも多くのレイヤーがあります。サービスはアプリケーションデータをシンガポールに保存する一方で、ログ、監視メトリクス、サポートチケット、請求記録、設定バックアップ、スナップショットが他の場所にある場合があります。SITA のグローバル運用フットプリントはサポートカバレッジの強みになる可能性がありますが、データマップをより重要にします。シンガポールレジデンシーまたは APAC ローカリティを重視する顧客は、プロダクションデータ、バックアップ、ログ、テレメトリ、チケット、管理者アクセス、サブコントラクターアクセスのマップを要求する必要があります。

ホステッドキャパシティは通常の経路で障害が発生する

最も信頼できる Cloud APAC の障害経路は特別なものではありません。1 つ目はラックまたはプラットフォームの障害です。ホストノード、ストレージシェルフ、トップオブラックスイッチ、ファイアウォール、ハイパーバイザークラスター、電力回路、管理アプライアンスが障害を起こす可能性があります。サービスが仮想化されている場合、顧客はワークロードが別のノードで再起動するか、ストレージが複製されるか、スペア容量が予約されているか、再起動が負荷下でテストされているかを知る必要があります。

2 つ目はアップストリーム障害です。RIPEstat は AS132399 の可視ネイバーとして AS15830 を示しています。そのパスが唯一のパブリックインターネットルートである場合、BGP セッション、キャリアサービス、物理クロスコネクト、ルーターポリシー、または DDoS 保護パスの障害は、サーバーが健全であっても到達可能性に影響を与える可能性があります。プライベート航空ネットワークパスやパブリックコレクターが示さない第 2 のキャリアパスがある場合、顧客はそれがサービス設計に文書化されているのを見るべきです。そうでない場合、顧客はリスクを理解し、それに応じてワークロードをサイジングする必要があります。

3 つ目はハードウェア在庫障害です。クラウドおよびマネージドサービスの顧客がスペアパーツ棚を見ることはほとんどありませんが、それが修理時間を決定します。故障したディスク、光学モジュール、ルーターラインカード、ファイアウォールアプライアンス、電源、ストレージコントローラーは、診断が容易でも交換が遅い場合があります。制約のあるデータセンター市場では、リードタイムとアクセスウィンドウが重要です。顧客は、重要なスペアがどこに保管されているか、誰がそれらをインストールできるか、どの部品がベンダーサポートされているか、どの障害が修理ではなく移行をトリガーするかを尋ねるべきです。

4 つ目はサポート障害です。SITA の公開サポート資料は規模とプロセスを示していますが、特定の Cloud APAC 依存関係には名前付きのエスカレーションパスが依然として必要です。地域インシデントは、ネットワークエンジニアリング、施設運用、サービス管理、セキュリティ、アプリケーション所有者、顧客アカウントチーム、サードパーティのトランジットプロバイダーをまたぐ可能性があります。サービスが重要な場合、顧客はブリッジコールを誰が主導するか、ステータスがどのように伝達されるか、緊急変更を誰が承認できるかを知る必要があります。

5 つ目は請求またはプロバイダー契約の障害です。これは管理的に聞こえますが、実際にはインフラです。キャリア契約、施設アカウント、ソフトウェアサブスクリプション、サポート権利、顧客請求書がずれている場合、最悪のタイミングでサービスが停止または遅延する可能性があります。より大きな SITA 運用環境内に現れるプロバイダー名の場合、顧客は法的エンティティ、製品名、サービス説明、サポート権利、データ退出権がすべて一致していることを確認する必要があります。

6 つ目は移行障害です。顧客が離脱する必要がある日、サービスが移植可能かどうかを発見します。マシンイメージ、データベース、オブジェクトデータ、ログ、ファイアウォールルール、DNS レコード、アクセス制御設定、監視履歴をエクスポートできますか?IP アドレスを移動できますか、それとも再番号付けする必要がありますか?バックアップは標準形式で利用可能ですか?アカウントが停止、紛争、または終了した場合、クリーンな引き継ぎはありますか?テストされた出口パスがないクラウドサービスは、通常の週に良好に機能しても、依存関係の罠です。

復旧の証明はワークロードに一致しなければならない

復旧の表現はしばしば汎用的すぎます。サプライヤーはサービスがバックアップ、監視、または年中無休でサポートされていると言うかもしれませんが、これらの言葉は Cloud APAC が特定の顧客に実際に何を提供するかによって異なる意味を持ちます。ネットワークエッジ、管理仮想サーバー、プライベートクラウドノード、乗客向けアプリケーション、オフィス VPN、監視コレクターはすべて異なる方法で障害を起こします。復旧証拠は、顧客がどの部分が最初に戻り、どの部分が待つかを見ることができるほど具体的であるべきです。

ネットワークサービスの場合、復旧証明は到達可能性から始まります。顧客は AS132399 がどのように監視されているか、4 つの可視 IPv4 プレフィックスがどのようにチェックされているか、ルートが撤回された場合にどのアラートが発報されるか、AS15830 パスが低下した場合に誰が行動するかを見るべきです。サービスにプライベート航空接続性または別の非公開パスがある場合、顧客はそのパスが別個にテストされているかを見るべきです。公開ルートコレクターは ASN が可視であることを示せますが、個々のサイト、ファイアウォールゾーン、または顧客トンネルが正しくフェイルオーバーしたかどうかは示せません。

ホステッドコンピュートの場合、復旧証明はワークロード状態から始まります。サーバーが故障した場合、顧客は自動再起動、手動再構築、イメージ復元、アプリケーション復元、またはベストエフォート修理のいずれを購入していますか?復旧ターゲットには、オペレーティングシステム、接続ストレージ、ファイアウォールポリシー、証明書、アイデンティティ設定、監視チェック、ログが含まれますか?バックアップが仮想マシンを復元しても、ネットワークポリシーや DNS レコードが残っている場合、サービスはユーザーの観点から実際には復旧していません。

管理アプリケーションの場合、復旧証明には依存関係を含める必要があります。航空会社または空港システムは、アイデンティティプロバイダー、メッセージキュー、データベース、サードパーティ API、ローカルワークステーション、ネットワークトンネルに依存する可能性があります。アプリケーションサーバーのみの復元では、ユーザーが取引できないままになる可能性があります。顧客は、どのシステムが一緒に復元されるか、独立したクロックを持つもの、Cloud APAC の責任範囲外のものを特定する依存関係リストを要求する必要があります。

データの場合、重要な区別はバックアップと使用可能な復元の間です。バックアップは存在しても、古すぎる、遅すぎる、不完全、アカウント停止中にアクセスできない、間違った管轄区域に保存されている、または損傷した資格情報セットに結びついている場合、ビジネスに失敗する可能性があります。顧客は、最新の成功した復元テスト、最大のテスト済み復元サイズ、最新の失敗した復元、保持された復旧ポイント、削除プロセス、エクスポート形式を尋ねるべきです。シンガポールローカリティの場合、同じ証拠はバックアップコピーと復元ステージングエリアの場所を示すべきです。

インシデントコミュニケーションの場合、復旧証明には帯域外パスを含める必要があります。サービスがメール、カスタマーポータル、VPN、またはネットワークアクセスをサポートしている場合、同じチャネルが障害時に利用できなくなる可能性があります。SITA の公開サポート資料はグローバルサポートとプロアクティブ監視を指していますが、Cloud APAC 顧客は影響を受けるサービスを生き残るインシデントチャネルを依然として必要とします。それは電話ブリッジ、別個のポータル、事前に合意された緊急連絡先、または顧客運用ルームかもしれません。重要な点は、インシデントチャネルが壊れているものに完全に依存すべきではないということです。

顧客は部分的な障害の証拠も求めるべきです。大規模な停止は気づきやすいです。部分的な障害はより困難です。1 つのプレフィックスルートが低下する、1 つの空港サイトで高いパケットロスが発生する、1 つのデータベースレプリカが遅れる、1 つのストレージプールが満杯になる、1 つのサポートキューが誤ってルーティングされる、または 1 つのファイアウォールルールが復旧パスをブロックする。回復力のあるサービスには、顧客が症状から断片的に把握する前にこれらの部分的な状態を見つける監視があります。

最後に、復旧証明には決定パスを含めるべきです。障害時には、誰かが修理を待つか、ワークロードを移動するか、サプライヤーを呼び出すか、ルーティングを変更するか、バックアップから復元するか、顧客移行を開始するかを決定する必要があります。これらの決定は、商業的境界と変更管理習慣によって遅延する可能性があります。実用的な Cloud APAC 契約は、主要インシデントを宣言する権限、Equinix または他の施設オペレーターに連絡できる人、緊急ルーティング変更を承認できる人、顧客コミュニケーションを所有する人、サービスが復旧したことを承認する人を明記すべきです。その決定パスがなければ、技術的に回復可能なプラットフォームでも顧客の実際の期限を逃す可能性があります。

RPKI は役立つが、ルーティングセキュリティの完全な答えではない

Cloud APAC の現在のプレフィックスに対する有効な RPKI 状態は、重要なポジティブシグナルです。RFC 6811はルートオリジン検証を説明しています。これは、ネットワークがアナウンスされたオリジン AS がプレフィックスに対して許可されているかどうかを評価する方法です。実用的には、有効なオリジン検証は、特にアップストリームがフィルタリングを実施する場合に、偶発的または悪意のあるオリジンエラーを減らすのに役立ちます。

しかし、RPKI は完全な回復力管理ではありません。ルートが多様であることを証明しません。すべてのアップストリーム内でプレフィックスが正しくフィルタリングされていることを証明しません。パス操作、ルートリーク、容量枯渇、設定ミスのファイアウォール、または壊れたデータセンタークロスコネクトを阻止しません。また、顧客トラフィックに DDoS 保護、ルートダンピング手順、メンテナンス通知、緊急連絡先リスト、またはテスト済みロールバック計画があるかどうかも示しません。

RFC 7454は、オリジン検証を超えた運用 BGP セキュリティプラクティス(フィルタリングやルート管理の規律を含む)について議論しているため、有用なコンテキストです。MANRSは、ルーティングセキュリティをネットワークオペレーターによる運用上のコミットメントとして位置付けています。これらは Cloud APAC の認定ではありません。顧客が可視 ASN がどのように保護されているかを尋ねる際に使用すべき語彙です。

AS132399 の場合、質問セットは単純です。すべてのアナウンスされたプレフィックスは現在のルートオリジン認証でカバーされていますか?どのアップストリームがルートオリジン検証とプレフィックスフィルターを実施していますか?AS15830 はパブリックインターネット到達可能性の唯一のアップストリームですか?パブリックコレクターに見えないプライベートルートはありますか?どの監視が撤回されたルート、部分的な到達可能性、または地域のパケットロスを検出しますか?誰がアラートを受信し、どのくらい迅速に行動できますか?BGP 更新にはどの変更管理ポリシーが適用されますか?

IPv6 に関するポリシーハイジーンの質問もあります。AS132399 が IPv6 ポリシー行を持ちながら可視 IPv6 アナウンスがない場合、顧客は IPv6 が意図的に不在なのか、別のネットワークを通じて提供されるのか、将来のフェーズで計画されているのか、互換性のために無効になっているのかを尋ねるべきです。現代の航空交通システムでは、IPv6 はすべてのワークロードにとって緊急ではないかもしれませんが、明確さは沈黙に勝ります。隠れた設計選択は、顧客が統合または移行中に発見したときにリスクになります。

Cloud APAC が障害を起こした場合、誰が影響を受けるか

公開記録が Cloud APAC を SITA に結びつけているため、影響を受ける人口は典型的な共有ホストとは異なる可能性があります。これには、管理接続を使用する航空会社、SITA ネットワークアクセスに依存する空港システム、共有アプリケーションに接続する地上ハンドラー、管理インターネットを使用する空港オフィス、運用メッセージを交換する旅行システム、SITA 管理のクラウドまたはネットワークサービスに依存するエンタープライズチームが含まれる可能性があります。正確な顧客リストは公開されておらず、推測すべきではありません。それでも、影響のクラスは明確です。

最初に影響を受けるグループは、エッジでの運用ユーザーです。空港デスク、航空会社オフィス、地上ハンドラー、リモートアウトステーション、ローカル技術チームです。接続性が失われた場合、これらのユーザーは遅い旅客処理、遅延した運用メッセージ、モバイルリンクによる回避策、手動調整、またはサービスデスクの混雑を経験する可能性があります。地域のクラウドまたはネットワークノードは、中央インフラ障害を多くのローカル症状に変える可能性があります。

2 番目に影響を受けるグループはアプリケーション所有者です。レイテンシが上昇し、DNS が変更され、アプリケーションセッションが切れ、またはフェイルオーバープランがネットワーク変更を必要とするまで、どの ASN がトラフィックを運ぶか気にしないかもしれません。彼らにとって重要な事実は、依存関係マップ、監視アクセス、サービスレベル目標、ロールバック手順です。Cloud APAC がブラックボックスの場合、アプリケーション所有者はアプリケーションのバグとネットワークまたは施設の問題を区別するのに時間がかかります。

3 番目に影響を受けるグループはセキュリティおよびコンプライアンス担当者です。彼らはデータがどこを移動するか、誰がアクセスできるか、どのログが保持されるか、サポート活動が管轄区域をまたぐかを知る必要があります。シンガポールのラベルが付いたプレフィックスはこれらの質問に答えません。グローバルサポート組織はインシデント対応を改善できますが、国境を越えたデータとアクセスの考慮事項を追加することもあります。顧客はネットワークローカリティをデータローカリティおよび管理者ローカリティから分離する必要があります。

4 番目に影響を受けるグループは調達および財務部門です。更新、拡張、または出口パスが不明確な場合、ホステッドキャパシティは財務的に脆弱になります。シンガポールのラックスペースまたは電力が不足している場合、弾力的に見えたサービスが計画上の制約になる可能性があります。顧客がイメージ、アドレス、設定をクリーンに持ち出せない場合、技術サービスが平凡であってもプロバイダーは交換が難しくなります。そのため、移行証拠は復旧レビューに属し、将来のオフボーディングの慌てに属しません。

5 番目に影響を受けるグループはエンド乗客および荷主ですが、間接的であり、ワークロードに依存します。このレビューでは AS132399 が特定の旅客処理システムを運んでいるという公開証明はないため、主張はより狭く留めるべきです。SITA の航空業界での役割は、インフラ障害の影響を高めます。テクノロジーが航空会社と空港の運用を支える場合、小さな停止でも行列、遅延した手荷物処理、手動デスク作業、または遅い復旧を通じて旅行者に見える可能性があります。

購入者は依存する前に何を確認すべきか

真剣な Cloud APAC レビューは、現在のサービスマップから始めるべきです。正確な製品またはアカウント、法的契約エンティティ、プライマリサイト、バックアップまたはセカンダリサイト、管理プレーン、オリジン ASN、顧客プレフィックス(ある場合)、サポート構造を特定する必要があります。サービスが SITA 自身の AS132399 を使用する場合、マップは 4 つの可視 IPv4 プレフィックスを示し、それらの役割を説明すべきです。サービスが別の SITA またはサプライヤーネットワークを使用する場合、マップは代わりにそれを名付けるべきです。

2 番目の文書は施設および電力の声明です。ラック所有、コロケーション、管理ベアメタル、パブリッククラウド、サプライヤープラットフォームのいずれかを明記すべきです。プライマリサイトとバックアップサイトが建物、キャンパス、電源、クロスコネクトパス、オペレーターを共有するかどうかを述べるべきです。1 つのラック、データホール、キャリアハンドオフ、ストレージプールが故障した場合に何が起こるかを説明すべきです。

3 番目の文書はルートおよびトランジットの声明です。AS132399 の場合、公開証拠は Equinix AS15830 を介した現在の IPv4 アナウンスを示しています。顧客は、それが唯一の公開パスか、プライベート航空ネットワークパスが存在するか、第 2 のプロバイダーがいるか、RPKI が実施されているか、DDoS 保護がインラインか、ルートインシデントがどのように検出されるかを尋ねるべきです。答えが「これを公開していない」なら問題ありません。契約下でも答えが得られない場合、リスクを受け入れるのは困難です。

4 番目の文書はバックアップおよび復元レポートです。バックアップスケジュールだけでは不十分です。顧客は、何がバックアップされるか、どこに保存されるか、プロダクション資格情報から分離されているか、どのくらい保持されるか、どのくらいの頻度で復元されるか、最後の復元テストがカバーしたもの、除外されたものを見るべきです。仮想サーバーの場合、イメージ、ボリューム、データベース、ファイアウォール状態を意味します。管理アプリケーションの場合、アプリケーションデータ、アイデンティティ、ログ、設定、依存関係を意味します。ネットワークサービスの場合、デバイス設定、証明書、ルーティングポリシー、ロールバックファイルを意味します。

5 番目の文書はサポートエスカレーションおよびコミュニケーション計画です。SITA の広範なサポート主張は価値がありますが、顧客のインシデントパスは明示的でなければなりません。重大度レベル、応答目標、復旧目標、ステータス更新頻度、緊急連絡先、時間外カバレッジ、キャリアエスカレーション、通常のメールやポータルアクセスが影響を受けた場合の通信チャネルを明記すべきです。また、事後報告書を誰が書き、どの証拠を含むかを述べるべきです。

6 番目の文書は移植性計画です。顧客はエクスポート形式、アカウント終了ルール、IP 再番号付けの影響、DNS 転送サポート、イメージエクスポート権利、設定エクスポート権利、ログ保持アクセス、データ削除証拠を尋ねるべきです。安全に離脱できないプラットフォームは単に粘着性があるだけでなく、継続性リスクです。

証拠グレードは中程度であり、狭い意味を持つ

Cloud APAC は、却下も過信も受けるべきではありません。公開ネットワーク証拠は、ライブルートのない薄いディレクトリ名よりも強力です。AS132399 は APNIC および RIPEstat ビューでアクティブです。現在の IPv4 アナウンスがあります。可視プレフィックスは具体的です。ルートは RIPEstat の RPKI チェックで検証されます。可視アップストリームは、既知のネットワークおよび相互接続プロバイダーである Equinix AS15830 です。SITA の公開資料は、大規模な航空技術コンテキストと成熟したサポートナラティブを示しています。

制限も同様に重要です。公開証拠は、カスタマーポータル、小売りホスティングカタログ、名前付きラック、施設所有権、ハイパーバイザークラスター、バックアップリポジトリ、復元テスト、スペアハードウェア、マルチサイトフェイルオーバー、DDoS アーキテクチャ、この ASN のサポートエスカレーション、またはデータ移植性手順を示していません。また、AS132399 の下での可視 IPv6 アナウンスも示していません。国コード SG とシンガポール名のプレフィックスは有用なローカリティシグナルですが、完全なデータ主権の保証ではありません。

だからこそ、適切なグレードは中程度です。ネットワークは不可視ではありません。現在の IPv4 証拠は意味があり、多くの小規模ホスティングエントリよりも技術的にクリーンです。しかし、証拠は信頼できるホステッドキャパシティに完全には達していません。重要度の低いサービスの場合、主要なアップストリームを介した現在のルーティングで十分かもしれません。復旧期限のある航空会社、空港、政府、物流、またはエンタープライズワークロードの場合、購入者は Cloud APAC を回復力のあるインフラとして扱う前に、欠落した運用証拠を要求する必要があります。

最終テストは単純です。Cloud APAC がより大きな管理 SITA サービス内のルーティングされた地域コンポーネントにすぎない場合、顧客はその管理サービスのサービスレベルマップを必要とします。クラウド、ホスティング、VPS、ベアメタル、マネージドサービス容量として販売または消費される場合、顧客は施設配置、トランジット多様性、サポートエスカレーション、復元パフォーマンス、移行権利の証明を必要とします。公開記録は会話を始めますが、復旧レビューを終わらせるわけではありません。