ハクソク

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

AWSからHetznerに移行し、90%のコスト削減を実現し、Ansibleを使用してISO 27001を維持しました

2025年6月21日原文(medium.com)

概要

  • AWS依存から脱却 し、ヨーロッパのクラウドへ移行した経験談
  • ISO 27001認証維持 とGDPR準拠のための戦略的選択
  • コスト90%削減 とデータ主権確保の実現
  • 移行で得た 技術的・組織的な教訓 の共有
  • 移行プレイブック や支援サービスの案内

欧州クラウド移行がISO 27001を容易にする理由

  • AWS中心のインフラ からの脱却決断
    • CLOUD ActやFISA による米国法域リスク
    • GDPR遵守 と顧客データ保護の必要性
  • コスト問題
    • 年間 24,000ドル のAWS利用料
    • 自社ニーズに合わない過剰投資 の見直し
  • 戦略的リスクの認識
    • 単一ベンダーロックイン による将来不安
    • 自社の持続的成長 のための選択肢検討

当社の背景と移行動機

  • デンマークのワークフォース管理企業 としての法的責任
    • ISO 27001認証 取得済み
    • 勤怠・給与データ の厳格な管理義務
  • AWSネイティブ設計 からの脱却
    • 法的要件を満たす独立インフラ への移行
    • 移行時の法令遵守重視

AWS離脱で失うもの・得るもの

  • 失うもの
    • LambdaやRDS などの統合サービスの利便性
    • 一元的なコンプライアンスツール による監査の容易さ
  • 得るもの
    • データ主権の確立 （GDPR対応強化）
    • コスト90%削減 （自己運用による予算最適化）
    • イノベーション促進 （独自の自動化・セキュリティ強化）

欧州クラウド移行の実践と教訓

  • Ansibleによるコンプライアンス自動化
    • ISO 27001 Annex A 各項目と設定を直接紐付け
    • 自己説明的な監査証跡 の実現
  • AWS並みの監視体制
    • Prometheus, Grafana, Loki の組み合わせで監視・可視化
    • 迅速なインシデント対応 を可能に
  • Security-by-Designの徹底
    • Ansible自動化 による堅牢なISMS構築
    • 開発者が守りやすいセキュリティ基盤 の実現

技術スタックと運用例

  • HetznerとOVHcloud への移行
    • Terraform でVPSプロビジョニング
    • Ansible でハードニング・デプロイ自動化
  • 主な構成要素
    • PostgreSQL運用（自動バックアップ・メトリクス収集）
    • 監視（Prometheus, Alertmanager, Blackbox）
    • ログ管理（Loki, Grafana Agent, S3互換ストレージ）
    • TLS自動化（Certbot, Docker, Ansible）
  • Cloudflare連携 による可用性・セキュリティ強化

ビジネス・戦略的インパクト

  • 米国法域リスクの最小化
    • 欧州ホスティング を営業上の強みとして活用
    • ブランド信頼性の向上
  • クラウドコストの90%社内還元
    • 予算の再配分 による事業成長加速

貴社にとっての移行戦略

  • 移行実現の可否・コスト・リスク評価
    • 現状AWSコストと欧州代替案の比較
    • ISO 27001・コンプライアンス上の注意点整理
    • 現実的な移行スケジュールと初期ステップ提案
  • 移行支援サービスの案内
    • CTO・創業者向け移行セッション の提供
    • LinkedInやCalendly経由での相談受付

まとめ・参考リンク

  • AWSから欧州クラウド移行の全体像・教訓
    • アーキテクチャ図・運用スニペット の共有も可能
    • 移行に関する質問や相談 も歓迎
  • 詳細記事・事例紹介

連絡先：Jacob Knobel（LinkedInまたはCalendlyにて）

Hackerたちの意見

よく言われる問題は、怪しい人たちによるHetznerのアドレスの汚染（AWSやCloudflareからの「出口」で対処できるかも）と、故障しやすいハードウェアを使っていることだと思うんだけど、その辺について何か懸念はあった？それと、Loki！長い範囲のクエリでのメモリ不足はどう対処してるの？代替案はあるの？

└

汚染については、ユーザー向けのすべてをCloudflareを通しているから、外部のユーザー（やボット）は直接HetznerやOVHのIPに接触しないよ。ファイアウォール（ufw + CloudflareのIPホワイトリスト）でIPを制限して、信頼できるソースだけがL4で接続できるようにしてる。故障やアップグレードについては、Terraformでプロビジョニングしてるから、置き換えや容量追加がすぐにできるし、予測可能なんだ。ハードウェアのメトリクスはPrometheusとnode exporterで監視して、早めに警告を受け取ってる。今のところ（9ヶ月経過）ハードウェアの故障はないけど、自動化と設計でリスクを軽減してる。アプリはほとんどデータレスで、データベースのための災害復旧も（頻繁にテストしてる）用意してるよ。Lokiについては、メモリ不足を以下のように対処してる： • 保持制限とインデックス保持を区別する • Lokiの設定とsystemdのリソース制限でクエリの同時実行数や最大メモリ使用量を調整する • Promtailスタイルのラベルと構造化ログを使って、クエリが早めにフィルタリングできるようにする • 本当に深い履歴検索が必要な場合は、オブジェクトストアのアクセスツールやバックアップのgrepを使ってオフロードする — Lokiは運用ログとニアラインとして扱っていて、アーカイブ検索エンジンではないんだ。

└

Lokiの良い代替案はVictoriaだよ。人気があって、パフォーマンスも高くて評判もいいけど、私たちはメンテナの規模と多様性を考えてLokiを選んだんだ。君の指摘はすごく妥当で、上に書いたように対処してるよ。

└

https://en.wikipedia.org/wiki/Sybil_attack 高いプロバイダーの利点の一つは、実質的なPoWメカニズムのおかげで良い評判を持っていることみたいだね。

└

（OPじゃないけど）：ロキの質問について：うちのプロジェクトも似たような問題があった。ロキの設定を色々いじってみたけど、彼らのブログを読んでわかったのは、推奨されているインデックス設定がデフォルトのヘルム（おそらく他のデプロイ設定でも）で使われているものとは違うってこと。再設定して、読み取り専用のインスタンスを追加し、他の推奨事項を実装したら、パフォーマンスがかなり良くなったよ。ただ、彼らの興味はクラウドサービスを買ってもらうことであって、オープンソースのものをそのまま使ってもらうことじゃないから、その点は覚えておいてね。

こっちも同じだけど、Azureを使ってる。約90%のコスト削減ができて、スタックもかなり似てる。企業が変なサービスの抽象化に依存させるための大きなクラウド戦略で、シンプルな運用の話が徐々に失われていってるね。

└

Azureがどうして安いのか詳しく教えてくれる？

私たちは主要なAWSの機能を自分たちで再構築したけど、そのコストは？ DIYスタイルのホスティングのコストを通常は除外するよね。それが一番高くつくことが多い。自分たちで育てたものに24時間365日のサポートを提供するのは、アマゾンに外注しなかったことで得た節約を大きく削ることになるだろう。 > 年間24,000ドルの請求は不釣り合いに感じた それはまともなDevOpsフリーランサーの1〜2ヶ月分の時間に相当するよ。もし開発者を安く雇っているなら、年間でFTEの約1/3になるね。そんな予算では24時間365日のサポートは受けられないよ。これでも意味があるかもしれないけど、君は全体の話をしていないね。開発時間を考慮に入れると、もっと地味な話になると思う。誤解しないでほしいけど、私も似たような動きを考えてるんだ。ただコスト削減のためじゃなくて、ビジネス上の理由（うちのドイツの顧客はアメリカのホスティング会社が本当に嫌いなんだ）でね。でも、これでコストと手間が増えるし、チームに強化が必要になるかも。CTOとして、私の時間は非常に貴重だから、これを自分でやるのが一番無駄な使い方だと思う。私の焦点は、会社と製品を良くすることにあるべきなんだ。君のテックスタックはいいと思うよ。私も経験済みだ。個人的には、Terraformはこういう小規模なセットアップにはオーバースペックだと思うし、YAGNIのカテゴリーにしっかり入るね。でも、Ansibleは好きだよ。

└

これ、私も気になってる。90%は素晴らしい数字だけど、機会コストはどうなるの？

└

誤解しないでほしいんだけど、実は似たような動きを考えてるんだ。コスト削減というよりはビジネス的な理由でね（うちのドイツの顧客はアメリカのホスティング会社があまり好きじゃないから）。新しいAWSのヨーロッパ主権クラウドができる予定で、アメリカから完全に独立してEUの法律や規制に100%準拠することが目標なんだ。

└

90%はいい感じだけど、実際の金額は少ない気がする。理由が二つあるんだけど、 - 数百万ドルのSVシードラウンドが本当のビジネスコストを歪めてるんじゃない？開発者の給料を含めると（少なくとも一人の従業員がいる場合）、$20kを節約するために努力する価値があるとは思えない。つまり、開発者の給料の1/5？でも、自己資金でやってるビジネスにとっては$20kは生死に関わるかも。 - 重要なのは、純収益に対する節約の割合だよね。ビジネスが突然50%も利益を上げるようになるなら、確かに価値がある。けど、AWSをやめて新しい（利益が出る）機能を作ることを考えると、コスト/ベネフィットの観点からは意味がないかもしれない。追記：簡単に「$20kを節約する代わりに$2MのARRに到達するのは簡単だよ」って言うのは簡単だけど、実際の世界ではそんなに単純じゃないし、$20kは$20kなんだよね。利益を考えずにただお金を使うというSVの考え方は、10000のスタートアップのうち1つを除いて完全に妄想だと思う。

└

年間$24,000の請求は不釣り合いに感じた >> それは、まともなDevOpsフリーランサーの1〜2ヶ月分の時間に相当する。開発者を安く雇っているなら、年間でFTEの約1/3だよね。それに、そんな予算で24時間365日のサポートは受けられない。絶対的な節約の観点では、24kの90%で、年間約21.6kの節約になる。いい金額だけど、その価格でSRE/DevOpsエンジニアを雇うことはできない。ヨーロッパでも、そういうエンジニアは年間70k以上の給料をもらってるから。個人的には、TCO（総所有コスト）は長期的には高くなると思う。なぜなら、今やソフトウェアスタックのあらゆる部分を彼らのインフラチームや担当者が管理しなければならなくなるし、時間が経つにつれて更新や破壊的な変更が増えていくから。だけど、彼らの成功を祈ってるよ。

Hacker Newsで議論の続きを見る