汚染については、ユーザー向けのすべてを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%は素晴らしい数字だけど、機会コストはどうなるの？

誤解しないでほしいんだけど、実は似たような動きを考えてるんだ。コスト削減というよりはビジネス的な理由でね（うちのドイツの顧客はアメリカのホスティング会社があまり好きじゃないから）。新しい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（総所有コスト）は長期的には高くなると思う。なぜなら、今やソフトウェアスタックのあらゆる部分を彼らのインフラチームや担当者が管理しなければならなくなるし、時間が経つにつれて更新や破壊的な変更が増えていくから。だけど、彼らの成功を祈ってるよ。

AWSに追い出されるリスクを考えると、これは理にかなってるよ。アメリカ政府がAmazonにアカウントを閉じるように強制する可能性もあるしね。アメリカはヨーロッパ（グリーンランド）に対して戦争を示唆しているから、アメリカとの接続を持つのは悪いアイデアだと思う。

自分たちで育てたものに24時間365日のサポートを提供するのは、アマゾンにアウトソーシングしなかったことで得た節約を大きく削ることになるだろう。なぜ人々がこの神話を広め続けるのか理解できない。これは主にAzure、AWS、GCPのマーケティング部門が推進しているものだ。真実は、クラウドプロバイダーは実際にはアプリに対して24時間365日のサポートを提供していないということ。彼らはインフラが非常に緩い定義の24/7で動いていることを保証するだけだ。正しく使っていて、たくさんのお金を請求されないようにするためには、専門家が必要だし、彼らとの統合が壊れないようにするためにも人が必要なんだ。そこにはあなたのロジックが含まれていて、壊れる可能性が高い部分だから。クラウドの請求書がTCOだという考えは完全にでっち上げで、実際にはその請求書が非常に高額であることが多いにもかかわらず。

AWSが（高価な）労働を必要としないというあなたの暗黙の前提は、単なる事実ではないよ。

それは、まともなサポートを受けるために1〜2ヶ月くらいかかるよね。彼らはヨーロッパにいるのかな？ここでは人件費が数倍安いし。 > 24時間365日のサポートを提供してるけど、ハードウェア自体は維持管理してないし、アマゾンが無料でDevOpsを提供してるわけじゃないよね。サーバーレスのものを主に使ってない限り、あんまり差はないかも。

$24kって、AWSの年間コストを単純に計算しただけじゃない？彼らがAWSで使っているサービスを設定するのに、どれくらいのFTE相当が必要だったの？年間の請求を$24kから$48kや$100kに抑えるためには、どれくらいのFTE相当が必要なの？

AWSの機能を100%再現するのは高くつくかもしれないけど、80%だけ必要ならどうする？AWSの設定やスキルを維持するための手間も考えなきゃいけないし、AWSのダッシュボードを使うことによる機会コストもあるよね。需要の大きさや多様性、ダイナミクスによってもかなり変わると思う。全ての釘が一番大きなハンマーの接触から得られるわけじゃないから。

ISO27001を厳格だとは思わないけど、ソフトウェアを使うならやるべきことがほとんどだからね。そういうことをやっている証拠を確認するのは厳格だと思う。SOC2の認証はそんなに多くの文書を必要としないし。

両方経験したけど、SOC2の監査は監査官との相性やその能力に依存しているように感じるから、むしろ「厳格な」ISO 27001の方が好きだな。監査される内容が広すぎて解釈の余地がありすぎるし、監査官があなたのコントロールについて説明する内容も簡単に曲げられちゃう。

Live Tail（tail -f ...でログを見るのと同じ機能）が有料だと知ったとき、思わず笑っちゃった。毎日ログを見るための最も基本的な機能が無料じゃないなんて。CWは本当に面倒くさい。

$2400だよ、$200じゃない。

ISO 27001に準拠しているなら、ワークロードのために単一サーバーのセットアップはできないし、ログやモニタリング用に別のサーバーが必要だよ。負荷に関係なく、この認証には複雑さが求められる。全ての従業員が毎日ログインするわけじゃないし、スケジューリングアプリの場合、多くの人は週に数回しかチェックしない。でも毎日じゃない。日次アクティブユーザー（DAU）は約10,000～20,000。ピーク時の同時接続ユーザーは忙しい時間帯で1,500～2,000くらい。ランダムな時間の平均同時接続ユーザーは50～150くらい。クラウドコストがかさむ理由は、リアルタイム機能の広範な利用や複雑な労働ルールがあって、アプリが多くのデータ処理を行い、最終的には給与システムに同期する必要があるから。例えば、シフトに割り当てられることは、ユーザーごとに異なる意味を持つ。面倒なボーナスが発生することもあって、そのボーナスはシフトの割り当て時と開始時にしか発生しないこともある。最後に、スケジュールの最適化は計算コストが高い。

このコメントは素晴らしいね。アップグレードプロセスは、ISO 27001の認証を取得したいなら、単に形式を整えるだけじゃなくて、開発やリリースサイクルをよりコントロールするために使うべき内部プロセスの一部だよ。AWS RDSはPostgresやMySQLのメジャーまたはマイナー版のアップグレードを行わないから、パッチ更新は自分で簡単にできるし、ISMSで思い出すのもそんなに時間がかからない。この記事の目的は、クラウドハイパースケーラーとヨーロッパのサーバーを比較することじゃなくて、AWSの外で自分で高度に規制された、準拠した、認証されたサーバーセットアップを管理する方法についてなんだ。多くの人がAWSインフラでISO認証を持っていて、それを取得したら二度とAWSを離れられなくなるからね。クライアントの需要がなくて、自分でインフラを更新する必要がないなら、ISO 27001の認証を取得せずにAWS RDSに任せてもいいけど、雇用法や金融などの規制業界で複雑なものを運営しているなら、もっと面白い課題やコントロールの必要性が出てくるよ。

Kamal、Dokku、CapRoverを見たけど、サーバー管理を抽象化したいならどれも素晴らしいツールだね。でも、HIPAA/ISO 27001に準拠したアプリには、全体のスタックでより高いコントロールと監査可能性が必要なんだ。Ansibleを使えば、サーバーのハードニングからDBのバックアップまで、全てをバージョン管理できるし、冪等で透明なプロビジョニングを確保できる。PaaS層が裏でどう設定しているかを逆解析する必要もないし、コンプライアンス要件を満たさないかもしれない不透明なデフォルトを心配する必要もない。これらのツールに問題はないけど、ISO認証を目指す気になったら、自分でやることが多くなって、逆に後退しているように感じるし、あまり価値を感じなくなる。魔法のスナップショットに頼るより、自分でDBのバックアップを取る方が好きだし、ISO要件に合わせた暗号化されたオフサイトストレージや災害復旧ポリシーと統合するのが簡単だから。これで環境を必要なようにロックダウンできて、驚きの動く部分がない。Kamal/Dokku/CapRoverのようなツールは、迅速で開発者に優しいデプロイに向いているけど、規制されたワークロードには、退屈で明示的、かつ監査可能なものを選ぶよ。