ハクソク

世界を動かす技術を、日本語で。

AWSからベアメタルへ：AWSを離れることに関する質問にお答えします

208日前原文(oneuptime.com)

概要

  • AWSからBare-Metalへの移行で 年間120万ドル以上 のコスト削減を実現。
  • 可用性99.993%、顧客向けレイテンシ19%削減など運用面も向上。
  • 移行・運用コストは最小限 で、リソースの再投資も実施。
  • クラウドの利点 も活かしつつ、基盤は自社所有のコロケーションへ。
  • コミュニティからの質問に 実数値と実例 で回答。

AWSからBare-Metalへの移行がもたらした効果

  • MicroK8s + Ceph 構成で730日以上連続稼働、 可用性99.993% を計測。
  • フランクフルトに2台目ラックを設置、 DWDM冗長回線 でパリと接続し単一障害点を排除。
  • NVMeローカルストレージ 導入により、顧客向けレイテンシを19%削減。
  • 削減したコストで AIサーバー増設、LLMによるアラート要約や自動コード修正機能を強化（OneUptime）。
  • コミュニティからの質問（RI未利用？ラック冗長性？人件費？クラウド利用の最適解？）に対し、実数値で回答。

コスト削減の実態と比較

  • 年間$230,000の節約 は米国ならエンジニア1人分、世界的には2～5人分の給与に相当。
  • 現在は 年間$1.2M以上 の節約に拡大、今後も成長見込み。
  • Savings PlansやRI も検討済みだが、S3・帯域・Direct Connectの割引が限定的で、 ベアメタル比で76%以上安価。
    • Savings Plansはインスタンスのみ割引、帯域はAWS請求の22%を占める。
    • EKSの制御プレーン費用やNAT Gateway費用も自己運用で不要に。
    • 24/7稼働ワークロードのため、リザーブ率90%以上で最適化済み。

移行・運用コストと人的リソース

  • 初期移行は エンジニア1週間分 （SRE・プラットフォーム・DB担当で分担）。
    • インフラのコード化やバックアップ強化など、必要作業と重複。
  • 運用コストは 四半期あたり24時間 程度（パッチ適用・ファームウェア更新含む）。
    • AWS時代のコスト最適化やIAM管理と同等の作業量。
  • 現地作業は年2回以下 （主にディスク交換）、平均対応27分、現地常駐スタッフは不要。
  • 自動化 ：Talos・Tinkerbell・Flux・Terraformで構成管理、Kubernetesアップグレードも自動化。

冗長性・耐障害性の確保

  • 複数ラック構成、異なるDC・電力会社を利用。
    • フランクフルトに四分の一ラック増設、MicroK8s制御プレーンとCephプールを非同期レプリケーション。
    • 今後はTalosへ移行予定。
    • 4G/衛星回線 によるOOB管理経路も確保。
  • AWS側のフェイルオーバークラスタも維持、四半期ごとにカットオーバー訓練を実施。
    • DNSフェイルオーバーの遅延対策で Anycast+BGP を導入し、トラフィック切替を1分未満に短縮。

ハードウェアライフサイクルとCapEx管理

  • サーバは 5年償却、2×AMD EPYC 9654・1TB RAM・NVMe構成。
    • CPU飽和時に分析クラスターへ転用、新規購入で 40%/24ヶ月ごと にリフレッシュ可能。
    • OEM（Supermicro）から延長保証を購入、 コールドスペア3台常備。
    • 実際は7-8年稼働可能だが、保守的に5年計上。

マネージドサービス再発明の是非

  • 自社製品の移植性 維持が理由。OneUptime顧客もKubernetes上で自己運用。
  • ツールの成熟度 向上。MicroK8s→Talos、Argo Rollouts、OpenTelemetry、Cephダッシュボード等、すべてオープンソースで独自開発なし。
  • クラウド併用 ：Glacierによる長期バックアップ、CloudFront/Cloudflareでエッジキャッシュ、負荷試験用の短期AWS利用。
  • マネージドサービス は専門知識不足や独自機能が必要な場合に有効。

帯域・DDoS対策・信頼性

  • 5Gbps 95パーセンタイル を2キャリアで契約、AWSの8倍安価。
  • DDoS対策は Cloudflare をフロントに配置。
  • 可用性はAWSより高水準 （730日99.993%、直近のAWSダウンタイムも回避）。

監査・コンプライアンス対応

  • SOC2 Type II・ISO 27001 認証を維持。
    • 物理管理はコロケーションのバッジログ・監視カメラ・四半期レビュー。
    • 変更管理はTerraform/Talosの証跡で監査対応。
    • 事業継続性は他DCへのフェイルオーバー訓練で証明。
    • 医療など規制分野では書類作業増だが、コロケーション標準資料で対応。

クラウド他社への移行検討

  • Hetzner・OVH・Leaseweb・Equinix Metal・AWS Outposts を比較。
    • ハイパースケーラーは計算資源は割安だが帯域コストが高止まり。
    • ヨーロッパの専用サーバは大規模Cephや冗長回線・SLAでコスト高。
    • Equinix Metalは最も近いが、オンデマンドベアメタルで25-30%割増。
    • 自社ハードウェア所有で 電力密度最適化・部品再利用 も可能、コロケーションが最適解。

日常運用の具体例

  • 週次 ：Kernel・ファームウェアパッチ、Cephヘルスチェック（平均1時間/週）。
  • 月次 ：Kubernetes制御プレーンのカナリアアップグレード（2時間/2名）。
  • 四半期 ：DR訓練・容量計画・キャリア監査（3名で12時間程度）。
  • 合計 約14時間/月、AWS時代も同程度だが作業内容が異なる（コスト監視・セキュリティ例外対応等）。

クラウドの活用範囲

  • Glacier で長期ログアーカイブ、 CloudFront/Cloudflare でエッジ配信、短期AWS環境で負荷試験。
  • 弾力性や地理的要件 が重要な場合はクラウドを選択。

クラウドが適切なケース

  • 利用パターンがスパイキー/季節変動型 でオートスケール可能な場合。
  • Aurora Serverless・Kinesis・Step Functions 等、運用負荷削減が価値となる場合。
  • KubernetesやCeph等の運用知見がまだ浅い 場合。
  • 初期はクラウドが最適、規模や独立性要求が高まればベアメタルも選択肢。

今後の展望

  • コロケーション移行向けのランブック＋Terraformモジュール を公開予定。
  • Talosの詳細解説記事 も準備中。
  • 追加質問はディスカッションスレッドで受付中。

関連リンク

  • OneUptime公式ブログ、Hacker News、Reddit等でさらなる議論。

Hackerたちの意見

面白い記事だね、ありがとう！OVHやHetznerの比較で忘れがちなのは、彼らのエントリーサーバーについてだよね。OVHのAdvanceラインやHetznerのAXラインみたいなやつ。これらのボックスにはいくつかの欠点があるんだ。例えば、OVHのAdvanceラインはECCメモリが付いてないから、データベースをホストするサーバーには最悪だよ。これは事故が起こるのを待ってるようなもんだ。AdvanceラインにはECCメモリを追加するオプションがないから、ScaleやHigh Gradeサーバーを使わなきゃいけなくて、これらは「手頃」とは言えないよね。HetznerはデフォルトでシングルPSUとシングルアップリンクが付いてくる。何も起こらなければ大丈夫かもしれないけど、信頼性の高いプライベートネットワークや10Gが必要な場合は、追加コストがかかるよ。

└

そうだね、デュアルPSUやECC RAMを提供している専用サーバープロバイダーもあるよ。ただ、例えば24コアのEpycに384GBのRAM、デュアル10Gネットワークだと月500ドルくらいはかかるけどね（他の例としてserversearcher.comにもっと小さいサーバーもあるよ）。

└

ECC RAMなしで動くソフトウェアってあるのかな？ほとんどの人気のデータベースは、メモリが壊れない前提で動いてると思うんだけど。

└

これらの懸念は誇張されてるよ。私は20年間、HetznerやOVHなどで運営してきたけど、その間に問題は2回だけ。15年くらい前にサーバーのPSUが故障したのと、数年前にOVHのデータセンターが火事になってサーバーがダウンしたことがあった。その他のハードウェアの問題は一切なかったよ。あなたの経験は違うかもしれないけど。

こんなに反発があるなんて驚きだよ… AWSはめっちゃ高いからね。AWSだけでシステムやサービスを構築するケースは、みんなが思ってるよりも珍しいと思う。もしかしたら、俺がただの老害で雲に向かって叫んでるだけかもしれないけど（冗談だよ）、いつから人々はベアメタルサーバーの運用を忘れちゃったんだろう？ > 「私たちは730日以上、99.993%の可用性を測定していて、先週起きたAWS全域のダウンタイムも逃れました。」これは自慢にはいいね。彼らがCloudFlareを通じてDDoS保護を使っているから、その依存関係はあるけど、その場合、DNSやインバウンドは確かにフルタイムの仕事になることに100%同意できるよ。マイクロサービスやデータベースを運用するのは全然そうじゃない。もしチームがスケーリングなどで常に監視・調整しているなら、問題は設計にあるんだ。ホスティングじゃない。小さな会社が毎時ビリオンの重いリクエストを処理しているわけじゃないなら、AWSが高すぎるって賭けてもいいよ。

└

著者が指摘しているように、AWSは再現したくないいくつかのこと（CloudFrontみたいな）を提供できるけど、他のほとんどのことについては君が正しいよ。AWSは結局、提供されるものに対して非常に高いんだ。驚きのある複雑な請求書も、コスト管理を頭を抱える経験にしてしまう。

└

このトピックに対する異なる見解の大部分は、人々がクラウドプロバイダーに管理業務を押し付けることで節約できる労力やお金をどのように見積もるかに起因しているんだ。そしてこの点について、人々は全く異なる結論に至ることが多い。要求もかなり異なるし、HNでの議論はしばしばHAや多くのスケーリングオプションが必要だと仮定しているように見えるけど、それは普遍的に正しいわけじゃない。

└

直接的なコストは簡単な部分だよね。もっと厄介なのは、今やAWSのやり方で物事を進めることがキャリアに依存している技術者のスタッフを育てているってこと。彼らはAWS認定を受けて、AWSの「Well Architected Way」でシステムを構築することを保証し、自分で考える代わりに、AWSのロックインソリューションを売り込むためのサウンドバイトやセールスアーギュメントを使うんだ。 （「アプリを失敗に対して非常に強靭にしましょうか？はい、複数のリージョンで運用することはAWSの請求書を大きくしますが、ダウンタイムはずっと少なくなります。この技術的な話を見てください、これが証明です」）もちろん、AWSのロックインサービスは、標準的なものの過剰請求と比較して安く見えるように価格設定されているんだ。もしあなたがそれらに移行するためにエンジニアリングの努力やIaCコーディングの努力を費やすなら、この「節約」は再びAWSクラウドエンジニアリングの努力に使われて、あなたのクラウドエンジニア組織が大きくなり、重要になっていくんだ。（例えば、アプリをコンテナからLambdaに移行したり、データベースをPostgreSQLからDynamoDBに移行したりすることなど）

└

「もしかしたら私はただの老害かもしれないけど（ダジャレじゃないよ）、いつから人々はベアメタルサーバーの運用を忘れたんだろう？エンジニアを“商品化”する方法だよ。自社運用や混合インフラの方が、やり方さえ分かればもっと良くて安くできる。でも、経験豊富な人が必要で、大手コンサルに雇われた新卒が“クラウドの専門家”として売られても上手くいかない。」

└

「これに対する反発がこんなに多いことに驚いてるけど、実はそうでもない。よくあることみたいだ。ここやRedditでAWSを使わない話題が出ると、突然現れる人たちが他の選択肢を提案する人を叩き始めるんだ。正直、これが有料の宣伝みたいに感じ始めてる。」

└

「もしかしたら私はただの老害かもしれないけど（ダジャレじゃないよ）、いつから人々はベアメタルサーバーの運用を忘れたんだろう？“クラウド学習による無力感”という言葉を作るべきだね。」

└

AWSは高いかもしれないけど、バランスが大事だよね。オンプレミス（まあ、共有DC）にすると安くなるけど、オールラウンドなシステム管理者か専門家が必要になる。製品がシンプルでスケーラブルならうまくいくことも多い。多くの場所がこっそりこれを実現してる。ただ、複雑さがすごいことになってる現実も見てきたし、運用コストに焦点を当てると、低価格のコンポーネントで作られたサービスを管理するためにスキルの低いスタッフを雇うことになる。昔ながらの「自分でやるぜ！」の考え方が入ると、爆発的な影響範囲で高額なサービスクレジットを顧客に配ることになる。人間的な要因としては、チームが真夜中の会議に何度も呼ばれることになるよ。AWS/Azure/GCPの世界に100%満足してるわけじゃないけど、オンプレミスのスキルセットがますます希少で専門的になってきてるのが現実だね。良い人を雇うのは、すごく高くつくか、ユニコーンを探すような感じになることもある。

└

こんなに反発があるなんて驚きだよ… AWSはめっちゃ高いからね。反対意見より賛成意見の方が多い気がする。これらの話で気になるのは、確認バイアスが働いてることなんだよね。セルフホスティングやオンプレミスは、選ばれたケースでは意味があるけど、スタートアップチームがセルフホスティング戦略で無駄に時間を使ってる話を何度も見てきた。彼らは本来ビジネスを成長させるためにその時間を使うべきだったのに。失敗談の共通テーマは、セルフホスティングの本当のコストを見落としていること。サーバーをちょうど良くするためにかかる時間、ホスティングの管理、運営方法の議論、小さな問題への対処など、これらは積もり積もって大きな負担になるけど、注意して見ないと見逃しがちなんだよね。みんな、サーバーが届いてソフトウェアが動き出したときはハネムーン期を過ごす。お金を節約してるって自分たちを褒め合ってるけど、12ヶ月後には最後にサーバーをセットアップした人が新しい仕事に行ってしまって、チームがドキュメントと実際のサーバーの状態が合ってない理由を探ろうとしてる。プロジェクトマネージャーも振り返って、セルフホスティングにかかる時間が予想以上に多かったことに気づく。そういう話はあまり共有されないし、共有されても評価されない。地元のスタートアップシーンでは、セルフホスティングを諦めてAWSに移行した話が恥ずかしそうに語られることが多い。そういう話を書く人は少ないし、聞きたがらない人が多いからね。みんな、サーバーをセットアップしてうまくいくヒーローの話が好きなんだよね。トレードオフをしっかり考える必要があるけど、多くの人はそれができてない。自分の選んだ解決策が完璧だと思って、他の選択肢が悪いって思い込んでるんだ。

└

AWS（ソフトウェア開発業界のB2Bサービスの大半も含めて）は、サーバー管理をあまり気にせずに製品やビジネスの構築に集中できるから良いんだよね。ここでの問題は、他のビジネスでSaaSを使うのと同じで、営業追跡をExcelでやることもできるけど、数人以上で営業をやるとそれが大きなボトルネックになるのと同じように、管理しやすいインフラがないと同じことが起こるってこと。

└

私は大企業に属する小さな会社で働いてる。購買、IT、予算承認以外は完全に独立してる。CIをAWSで運用してるけど、いろんな理由で遅くて不安定（大きなC++プロジェクトのコンパイルとインスタンスタイプの圧力が原因）。それに高いしね。4ODインスタンスからオンプレミスのマシンに移行する計画を立てて、月に1000ドル節約できると予想してた。ビルドも早くなって、キャパシティの問題での失敗も減ると思ってた。オフィスには予備のワークステーションとラックがあったから、初期投資はゼロ。マシンをラックに接続したけど、インターネット接続がなかった。ITチケットを出したら、返信までに2日かかって、これは未承認のマシンでITにイメージを作ってもらう必要があると言われた。やり取りに4週間かかり、複数の会議と承認が必要だった。私の推測では、4人がこの件について10時間くらい議論してたと思う。AWSでは、Pythonスクリプトを書いて15分でWindowsインスタンスを立ち上げられるのに。

クラウドサービスプロバイダーの初期には、少数の高価値サービスを素晴らしい価格で提供していて、ベアメタルと競争できるコストで、しかもずっと簡単だったんだ。それが昔の話。今は状況が違う。クラウドサービスプロバイダーが支配的になった今、彼らは膨大で複雑なサービスやマイクロサービス、コントロールパネルなどを提供していて、常に管理していないとコストが制御不能になることがあるから、ベアメタルが多くのユースケースで安くなるんだ。

└

「彼らは少数の高価値サービスを素晴らしい価格で提供していて、ベアメタルと競争できるコストで、しかもずっと簡単だった。」これはAWSには当てはまらなかった。ポイントは「私たちは安い」じゃなくて「プレミアムでスケールを早くできる」だった。俺がクラウドサービスに初めて出会ったのは2010年か2011年頃だと思う。俺が当時働いていた会社が成長し始めて、共有ホスティングよりも良いものが必要になったから。AWSは「新しいけど高い」代替案として提案されて、CTOが高いけどAWSが必要だと経営陣を説得したんだ。必要に応じてサーバーを簡単に立てたり壊したりできるからね。帯域幅コストが当時のパッケージで一番高かったと思う。今、AWSなどで得られるパフォーマンスに対するコストを見てみると、同じように見える。得られないパフォーマンスに対して信じられないほど高い。サーバー管理の基本的なスキルが不足しているチームでない限り、専用インスタンスの方がいいよ。会社が本当に成長してインフラの管理が難しくなったら、専任の人を雇って次のステップを決めてもらうのがいい。

└

これだね。AWSが10個のしっかりしたコアサービスを提供していた頃は意味があってワクワクした。でも今は200以上のサービスの膨れ上がった混乱で（ほとんど誰も使わないサービスも多い）、その複雑さが頭痛や亀裂を生んでいる。AWSはあらゆるユースケースに対して中途半端な解決策を持とうとするのをやめて、基本的なことをいくつか本当にうまくやることに集中すべきだよ。

└

AWSのコントロールパネルに入るたびに（頻繁に行くけど）、なんか嫌な予感がするんだよね。ほんと、想像を超えるくらい複雑で無駄が多い。

└

反対に、"伝統的な" ホスティングやコロケーションのプロバイダーは、ビジネスを続けるためにもっと競争力のある価格を提供しなきゃいけないの？

└

私の知る限り、AWSのサービスで価格が上がったことは一度もないよ。これはおかしい。

この成功の核心はこれだと思う：>「私たちのワークロードは24/7で安定している。すでに90%以上の予約カバレッジがあったから、余ったバースト容量を“適正化”する余地はなかった。もし多くのコメントで言及されているようなバースト型のコンピュートプロファイルだったら、選択肢は違っていただろうね。正直、多くの場所に当てはまることだと思う、たとえ彼らが気づいていなくても。」

└

彼らの成功の核心は、最初に一つのデータセンターのラックで全てを運営して、運が良かったってことだと思う。信頼性のコストや手間が最初に必要ないと、人生はシンプルだよね。

「Equinix Metalが最も近かったけど、オンデマンドのベアメタルは私たちのCapExプランよりも25-30%高かった。彼らのグローバルな展開は魅力的だけど、短期間の拡張にはまだ使うかもしれない。> Equinix Metalサービスは2026年6月30日に終了予定です。」 https://docs.equinix.com/metal/

クラウドは弾力性が重要な時に意味があるけど、ベアメタルはベースロードが支配する時に勝つよね。これが私の意見では、特にアプリケーション（データベースとかはもっと複雑だと思うけど）の核心だと思う。私が働いたところで、クラウド機能を使う意味があったのは一回だけなんだ（ここではちょっと曖昧にしておくけど）：非常にバーストする可能性があるステーションからのデータ取り込み。普段は毎日だいたい真夜中にステーションからデータを受け取っていて、普通のサーバーでも問題ないけど、たまに数週間ぶりにオンラインになるステーションや新しいステーションが接続されることがあって、その時はすごい負荷がかかるんだ。データを取得して解析して処理するのに短時間でね。長時間キューに入れておく代わりに、水平スケールで対応できたんだ。

あなたのワークロードによるよね。まさにその通り。大企業の小さなチームがクラウドプロバイダーとエンタープライズ契約（割引）を結んでいる場合、クラウドは非常に力強いものになる。クラウドでインフラを持つチームは、オンプレミスでその変更を通すのにかかる時間のほんの一部で、製品に利益をもたらす変更を行えるからね。これは、データベースやネットワーク、システム管理の理解が十分にあるチームがインフラを所有していることが前提だよ。こういうチームが複数あるなら、共通の設定や管理を提供する中央のクラウド支援チームがいると、チームが予算を超えたり、潜在的なセキュリティ脆弱性を作ったりしないようにするのに役立つ。スケールアップしたいスタートアップ？本当に注意深くすれば、クラウドに縛られることなくクラウドから始められるよ。もしくは、将来的に移行できるようにシステムアーキテクチャを設計することも大事だね。

他にもたくさんのポイントがある。クラウドが始まった頃は、隣接する製品やサービスで素晴らしい価値を提供してた。スケーリングは痛かったし、ベアメタルハードウェアを手に入れるのは時間がかかったし、プロビジョニングにも時間がかかった。データセンターの質も高くなかったし、ネットワークも冗長性がなかった。これらの問題は今はずいぶん少なくなった。2010年には、64コアのXeon CPUが8ソケットでしか手に入らなかったし、ソケットごとに最大8コアだった。それにNUMAの問題も無視してた。今では、ソケットごとに256コアが手に入るし、コアあたりの速度も少なくとも2倍になってる。昔は64台のサーバーが必要だったのが、今では1台に収まる。2030年には、100対1の比率に近づくんじゃないかな。サーバー上のソフトウェアも2010年に比べてずっと速くなったし、PHP、Python、Ruby、Java、ASP、さらにはPerlもね。全部を足し合わせると、2010年に比べて200対1か300対1の比率になっても驚かないよ。最新のZen CPUコアに追いつくOxideのバージョンが開発中だと思う。サーバーが足りないなら、いくつかのOxideラックで99%のインターネット企業の使用に対応できるはずだ。

AWSやハイパースケーラーについて直感に反するのは、新しいプロジェクトを始めるときにはすごく理にかなってるってこと。少しのVMとデータストレージがあれば、1、2日でスタートできる。でも、真剣なデータストレージやデータ転送の話を始めると、コストがめちゃくちゃ膨れ上がる。私の頭の中では、コスト曲線は時間とともに平坦になるはずなんだけど、現実はそうじゃないみたい。

FD: 私はAmazonで働いてるけど、キャリアの初めはサーバーの紙のリクエストを出して、返事が数ヶ月かかる時代だった。今は全然理解できない。彼らが提供するサービスの性質を考えると、できるだけ多くのマネージドサービスを使うリスクを取らないのは危険すぎる。k8sだけでも、すごく複雑なコントロールプレーンと、完全に静的でないと管理が難しいデータベースがあるからね。前の職場ではk8sを深く掘り下げて、自分でクラスターを管理してたけど、ほんとに脆弱だった。etcdにパッチを提供しなきゃいけなかったし、私はDBエンジニアじゃないのに。投稿を読み進めるうちに、未来の失敗ポイントが次々と見えてきた。他の側面として、トレードオフについての正直な評価がないように思える。すべてがうまくいく話で、デメリットやリスク評価が全然ないんだ。