Hetzner OnlineとAS24940――低価格クラウドを支える高コストな運用規律

要約

RIPE NCCのRDAPはAS24940を有効なHETZNER-ASとして記録し、Hetzner Online GmbHを登録組織として示す。2026年8月5日のRIPEstatでは同ASNがアナウンスされ、94件のプレフィックス記録が観測された。これは公開ネットワーク識別の証拠であり、稼働率や顧客サービスの保証ではない。
Hetznerはデータセンター間接続、DDoS検知、バックアップ、スナップショット、対象を限定した99.9％の可用性条件を説明している。同時に、root／クラウド利用者自身が管理と安全確保を行い、バックアップと復旧確認を担うという境界も明示している。

Hetzner Online GmbHはクラウドサーバー、専用サーバー、ストレージなどを提供する。購入画面では、計算資源の月額が最も目立つ。しかし本番サービスの費用は、OSの更新、アクセス権、証明書、監視、バックアップ、障害対応、移行手順にも分散している。

AS24940は、その運用鎖を理解する入口になる。ASNはネットワークが他のネットワークと経路情報を交換するときに使う固有番号である。インターネット上の道路地図にある事業者番号に近い。番号が見えることと、利用者の注文やログインが成功することは別である。

本稿の問いは、Hetznerを単純に良し悪しで採点することではない。公開記録がどの範囲を証明し、サービス提供者と顧客の権限がどこで分かれ、障害時に誰が何を確認し、最終的にどの証拠で業務復旧を判断するかを整理することである。

掲載画像は、無地のネットワークラックを確認する技術者を描いた、BTW Media向けの写実的な生成画像である。Hetznerの従業員、設備、機器、顧客環境、実際の事故、性能、推奨を示すものではない。

AS24940の登録情報は何を確定するのか

この記事が結び付く対象は、公開済みのBTWディレクトリーにあるHetzner Online GmbHのCOMPANYエンティティである。事前確認時点ではArticleEntityの既存リンクはなかった。似た名称の別種エンティティはあるが、この記事の会社主体とは混同しない。

RIPE NCCのRDAP応答はAS24940をHETZNER-ASと記し、active状態にしている。登録組織と連絡役割にはHetzner Online GmbHが表示される。登録イベントは2002年6月3日、最終変更イベントは2026年6月30日とされる。

この記録は、固有性、連絡先、変更履歴を保つ台帳として有用である。経路問題や不正利用報告が起きたとき、曖昧なブランド名ではなく、登録された組織と役割に照会できる。

一方、RDAPは稼働中のネットワークそのものではない。全ルーター、光ファイバー、拠点、顧客、クラウド製品を掲載せず、容量、遅延、経路認可、可用性も保証しない。連絡先が常に直ちに応答することも証明しない。

したがって質問ごとに証拠を分ける必要がある。「誰がASNに登録されているか」はRDAP、「今朝どの経路が見えたか」は経路観測、「業務処理が成功したか」はアプリケーション記録で確認する。

強い統制は照合である。登録情報、社内資産台帳、RPKIの認可、BGP観測、運用連絡先が同じ現実を指しているか定期的に比べる。差異は攻撃の断定ではなく、移行、顧客関係、更新遅れ、設定誤りを調べる開始点になる。

2026年8月5日の経路観測

RIPEstatのAS概要は2026年8月5日、リソース24940をHETZNER-AS Hetzner Online GmbHと関連付け、announcedとした。つまり、その時点で経路収集系からAS24940の参加が観測された。

announced-prefixesの対象期間は7月22日から8月5日までで、94件のプレフィックス記録があった。内訳はIPv4が89件、IPv6が5件である。プレフィックスとはインターネットアドレスのまとまりを表す記法である。

94という数は顧客数、サーバー数、拠点数、回線数ではない。収集装置は特定の観測地点から経路を見るため、全利用者からの到達性を示さない。期間中ずっと同じ品質だったとも言えない。法的所有権やRPKIの完全性を直接決める数でもない。

それでも運用には役立つ。重要プレフィックスの起点が予想外のASNに変わったり、複数観測点から消えたりすれば、担当者は調査を始められる。アラートは判決ではなく、期待状態と実際の観測を照合する依頼である。

経営者がBGPの詳細を覚える必要はない。重要なドメインがどのアドレスとASNに依存し、異常時に誰が確認し、どの条件でHetznerへ連絡するかを決めておけばよい。

PeeringDBの広い地図を過大評価しない

PeeringDBの事業者管理プロフィールは、Hetzner Online、AS24940、hetzner.com、AS-HETZNERを示し、一般方針をopen、ネットワーク種別をContentとしている。IPv4とIPv6のプレフィックス数も記載するが、これはRIPEstatの期間限定観測と意味や範囲が異なる。

取得した交換接続APIには63件のレコードと49個の異なる交換点IDがあり、施設APIには23個の異なる施設IDがあった。公開上の接続面が広いことを示す手掛かりである。

ただし、同じ交換点に複数ポートがある場合もある。二つの施設が同じ都市光路、電源、上流に依存する場合もある。operationalという欄は、現在の空き容量、顧客の経路、物理的独立性、SLAを保証しない。

PeeringDBは計画と連絡の地図として使うべきで、性能監査として使うべきではない。顧客が冗長性を判断するときは、契約、現在のテレメトリー、経路テスト、事業者確認を組み合わせる。

仮想サーバーの下には電力と人がいる

Hetznerの文書は、ニュルンベルクに8、ファルケンシュタインに22、ヘルシンキに10のデータセンターがあると説明する。UPS、発電機、別電源経路、拠点間の冗長ダークファイバーにも触れ、特定のドイツ区間について少なくとも120 Gbit/sと記す。

これは事業者自身の説明であり、第三者監査ではない。それでもクラウドの物理層を考える材料になる。仮想マシンは物理ホスト、スイッチ、電源、冷却、光回線、外部事業者、現場作業に依存する。

「冗長」は対象を付けて読む。電源が二つあっても、すべての上流事故に耐えるとは限らない。光路が二つあっても、重要区間で同じ管路を通れば同時に切れる可能性がある。二地域にインスタンスがあっても、データやDNSが一つなら業務は切り替わらない。

購入者は秘密の配線図を求める必要はない。どの障害領域を製品がカバーし、残りを自社設計で補うか、切替後の容量は十分か、いつ実際に試したかを確認すべきである。

SLAの99.9％と利用者の停止時間

一般条件は、データセンターのネットワークについて年間平均99.9％を目指す経済的に合理的な努力を述べる。Cloud Server契約は各仮想マシンについて月間99.9％を対象とする。

Cloud Serverの可用性は、基盤ホストが稼働し、ハイパーバイザーがインスタンスを起動し、CPUやネットワークなどの活動が見える状態で定義される。保守、顧客設定、特定の攻撃、外部ネットワークなどの除外条件もある。

契約定義が満たされても、利用者の仕事が止まることはある。VMが動いていてもデータベースが壊れ、DNSが古い場所を指し、決済連携が失敗する可能性がある。「インスタンス活動あり」と「注文完了」は別の測定である。

補償は条件を満たす停止に対するCloud Creditsとして説明される。将来の料金を下げても、売上損失、待機人件費、緊急復旧、顧客対応を埋めない。企業はその差を自らリスク計算に入れる必要がある。

99.9％を単独で良い悪いと決めるのではなく、何を、どの期間、どの方法で測り、どの救済があるかを確認する。業務には別のエンドツーエンド目標が必要である。

管理者権限は顧客の自由と負担を増やす

Hetznerの条件ではroot／クラウドサーバーの完全な管理権限を顧客が持ち、管理と安全確保を顧客が担う。ソフトウェアや自動化を自由に選べる反面、更新、鍵、ログ、ファイアウォール、証明書、容量、脆弱性対応も自社で行う。

小規模組織では、一時的に作ったサーバーが重要化し、作成者の退職後に所有者不在となりやすい。大規模組織では、アカウントやAPIトークンが資産台帳より速く増える。どちらも、サーバーが応答している間は問題が見えにくい。

各本番サービスに責任者、支払アカウント、データ分類、依存先、警報先、復旧試験を紐付ける。削除保護やInfrastructure as Codeは有効だが、所有権、レビュー、秘密情報管理の代わりにはならない。

DDoS対策の外側にある障害

Hetznerは継続的なDDoS認識と悪性トラフィックの自動フィルタリングを説明する。大量通信による停止を事業者側で軽減できる重要な層である。

しかし、正当な利用増加でデータベースが詰まる、顧客ファイアウォールが正常通信を拒否する、アプリの不具合がループを起こす、DNSや証明書が失敗する、といった事象は別である。DDoS対策があることと、全停止原因が消えることは同じではない。

顧客側ではホスト、アプリ、外部到達性、実際の業務処理を別々に監視する。緊急時に誰がHetznerへ連絡し、誰が設定を変え、誰がロールバックを承認するかも決めておく。

バックアップは復元して初めて価値が分かる

文書は、オプションを有効にしたクラウドバックアップを日次のディスクコピー、保持枠を7件として説明する。スナップショットは顧客が作成し、削除まで残る。FAQでは、バックアップに削除保護を付けられず、サーバー削除時にバックアップも削除される一方、スナップショットは保護可能とする。

日次コピーでは、二回の間に更新されたデータを失う可能性がある。実行中DBには整合性の課題もある。暗号鍵や外部設定がなければ、ディスクがあってもサービスは戻らない。

保存場所にも境界がある。欧州のバックアップは通常同一ロケーション内の別データセンター、スナップショットはネットワークゾーンの規則に従うと説明される。米国やシンガポールの一部では同一データセンターとなる条件がある。別ホストは必ずしも別災害領域ではない。

一般条件は顧客に定期バックアップと提供サーバー外への保管を求め、技術文書も独立コピーを推奨する。事業者機能を一層として使い、別権限・別場所のデータを持つ設計が必要になる。

バックアップ方針は、対象、頻度、場所、削除権限、保持期間、最終復元成功日を答えるべきである。ジョブ成功はコピー作成の証拠で、復元演習は人が業務を戻せる証拠である。

障害を責任の地図で切り分ける

サーバーが応答しないとき、Hetznerは物理ホスト、仮想化、コアネットワークを操作し、顧客はOS、アプリ、ファイアウォールを操作する。最初にすべきことは責任争いではなく、どの層に失敗証拠があり、誰が次の行動権限を持つかを特定することだ。

ホスト障害なら、顧客は待機、切替、縮退を選ぶ。ディスク満杯なら、VMは活動していてもアプリは停止する。DNSが古ければ、新旧サーバーが健康でも利用者は誤った場所へ行く。鍵がなければバックアップは読めない。

アカウント侵害では、攻撃者が正規の管理画面を使う場合がある。多要素認証、限定トークン、監査ログ、削除保護、独立バックアップは異なる層を守る。

各重要サービスについて、事業者管理層、顧客管理層、共有境界、観測証拠、判断者、業務復旧テストを一枚にまとめると、事故時の往復を減らせる。

低料金と総コストを分けて考える

サーバー料金は比較しやすいが、運用費は人と時間に分散する。セキュリティ、監視、バックアップ、当番、復旧にサーバー代以上を使う場合もある。それは原材料を信頼できるサービスに変える費用である。

連携費はID、メール、決済、ストレージ、外部APIごとに増える。監督費はパッチ、権限、証明書、容量、演習で増える。障害費は失注、待機、緊急作業、顧客説明として現れる。移行費はデータ、秘密情報、ネットワーク、切替手順に残る。

総コストでは、インフラ請求に人員とツールを加え、故障頻度と影響を見積もり、独立コピー、代替容量、演習を含める。Hetznerが魅力的かどうかは、その合計と業務価値の比較で決まる。

導入前に答える質問

どの法人・アカウントと契約し、誰が復旧通知を受け取るか。SLAはどの対象を測り、どの除外と補償があるか。一次・二次系はどの故障領域を共有するか。バックアップはどこにあり、誰が同時削除できるか。

多要素認証、API権限、変更審査、削除保護は整っているか。監視は事業者状態、ホスト、アプリ、利用者処理を分けているか。DNS、証明書、決済、IDなど外部依存の責任者は誰か。独立データから別環境へ再構築する演習をいつ行ったか。

稼働後は、所有者不明リソース、古い鍵、期限超過バックアップ、失敗した復元試験、利用者エラー、予期しない経路変化、DNS変更を追う。「サーバー稼働」「アプリ応答」「業務確認済み」を別の状態として報告する。

実務上の結論

公開資料から、Hetzner Online GmbHとAS24940の明確なネットワーク識別が確認できる。RIPE NCCは登録を保存し、2026年8月5日のRIPEstatはASNのアナウンスと94件のプレフィックス記録を観測した。PeeringDBは広い相互接続・施設情報を事業者管理データとして示す。

Hetznerの文書は、拠点間接続、DDoS対策、バックアップ、スナップショット、対象限定の可用性を説明する。同時に、顧客がシステムを管理・保護し、バックアップし、業務復旧を確認する責任も明確にする。

非専門家向けの判断規則は単純である。登録は身元台帳、経路データは時間限定の観測、PeeringDBは自己管理地図、SLAは特定対象の契約、バックアップは復元まで未証明のコピーとして扱う。動くVMは、動く事業の一部にすぎない。

Sources

画像の出典

BTW Media向けに生成した写実的な編集画像。無地のデータセンター通路で、一般的なネットワーク技術者がラックを確認する場面である。組み込み画像生成ツールで作成した原画像を、場面を変えず1600×900のJPEGへ変換した。実在企業の施設、従業員、顧客、画面、ロゴ、専有システムは表していない。Hetzner Online GmbHの人員、設備、性能、事故、推奨を描写・示唆するものでもない。