ハクソク

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

AWSに戻ったが、なぜ離れたのかを思い出した

1日前原文(fourlightyears.blogspot.com)

概要

  • AWS初期からの熱心なユーザー体験の振り返り
  • 長年の信頼が徐々に失われた理由の具体例
  • サポートや複雑さ、コストに対する不満の詳細
  • AWSへの一時的な再利用とトラブル発生
  • 今後AWSを完全に離れる決意

AWSとの長い関係と失望

  • AWS初期 ：SQS、S3、EC2、SimpleDBなどが揃った時代からのユーザー体験
  • メルボルンでの初AWSイベント主催、米国からのAWS担当者を招待
  • クラウドコンピューティング革命 ：スタートアップが数分でシステム構築可能になった衝撃
  • AWSへの完全な信頼と熱狂、15年以上にわたる“信者”状態
  • 関係の変化 ：小さな不満が積み重なり、最終的に愛着が消滅

AWSへの不満点

  • 公式クライアントライブラリ不在 ：最初の6年間、コミュニティ頼りで開発負担を押し付け
  • Python 2からPython 3への移行の遅さ ：非合理的な対応
  • DynamoDBへの強い不満 ：コスト高・使い勝手の悪さ・システム品質の低さ
  • データ転送コスト ：初期20セント/GBから9セント/GBへ値下げも依然高額
  • 複雑な請求体系 ：内部データ移動で二重・三重課金、専門知識必須の“罠”多数
  • IAMの複雑さ ：認証・権限管理が極めて難解、全体的なAWSの複雑性の象徴
  • AWS Lambdaの問題点
    • スケーラブルの売り文句に惹かれるも、開発の複雑さ・ベンダーロックインが深刻
    • 従来のWebサーバー運用と比較して明確な利点が少ない
    • AWS Lambdaの解除・移行が最も困難
  • オープンソースプロジェクトへの強引な対応
    • Elasticsearch、Redis、MongoDBなどの意向無視でOpenSearch、Valkey、DocumentDBを展開
    • 結果としてSSPL、Elastic Licenseなどの防衛的ライセンスが普及
    • コミュニティや企業の努力を無視し、顧客関係を独占する姿勢
  • その他の不満多数 ：AWSを思い出すだけで気分が悪くなるほど

関係の終焉と部分的な継続利用

  • 突然の愛情喪失 ：ある日を境に完全にAWS離れ
  • ほぼ全サービスから撤退、Route53でドメイン管理、S3でバックアップ、WorkMailの限定利用のみ継続
  • WorkMailサービス終了通知 ：12ヶ月後に停止予定

AWS再訪とトラブル体験

  • AWS BedrockでClaude/Anthropicの動作テスト ：速度遅い上にコストが高い
  • ハイスペックEC2スポットインスタンスでのベンチマーク ：192コア・1TB RAMマシンでテスト
  • 突然のセキュリティアラート ：長期間休眠後の高額利用でアカウント制限
  • AWS WorkMail停止 ：ビジネスメールが利用不能に
  • サポート対応の遅さ ：プレミアムサポート未契約で返信遅延、フォーラムやチャットでも解決せず
  • 4日経過してもアカウント制限継続、業務やテストが進まない状態

最終的な決意

  • AWSへの信頼喪失を再認識、残りのサービスも完全にAWSから移行予定
  • AWSに再び期待しない教訓 ：Route53やWorkMailからも撤退を決意
  • 再訪が最後の失望体験となったことへの納得感

Hackerたちの意見

その分野で働いてるわけじゃないから、AWSにはたまに個人的な楽しみのプロジェクトで触るくらいなんだ。毎回、悪夢みたいだよ。実験的なカードゲームのサーバーを立ててるだけなのに、新しい金融機関を立ち上げるみたいな感じになってる。明日には無限にスケールする準備をしてるみたいで、スタッフは千人、予算はVCに支えられてるみたいな。幸いにも、Netlifyとか似たようなサービスがあって、全部を自分でやらなくて済むから助かってる。いつかIAMやVPN、他にも何かを学ばざるを得なくなる日が来るかもしれないけど、今は触るたびに目が飛び出るよ。

└

EC2やLightsailで生のVPSを立ち上げて、パブリックIPを与えればそれで終わりだよ。企業向けのパターンを全部実装する必要はないんだから。

└

20年前にHerokuがほとんどのウェブアプリに必要なことを完璧にやってのけたのには驚かされる。

└

Cloudflareに切り替えたら、すごく快適になった - 必要なものは全部揃ってるし、価格もリーズナブルだよ。

└

Azureを扱ったことがないなら、ただの悪夢だよ。

└

AWSはエンタープライズ向けで、個人プロジェクトには向いてない。個人プロジェクトは彼らにとって意味のある収益を生まないから、コストだけが重要なんだ。

AWSはオープンソースプロジェクトを踏みにじった - Elasticsearch、Redis、MongoDBのようなプロジェクトがクローンされてマネタイズされることを明らかに望んでいなかったにもかかわらず、AWSはOpenSearch、Valkey、DocumentDBを進めて、そういったコミュニティや企業が市場を築いた後にホスティングサービスのお金を奪った。その結果、SSPL、Elastic License、RSALなどの防御的ライセンスが生まれた。これは普通のユーザーを止めるためというより、AWSがオープンソースのインフラを部品として剥ぎ取るのを防ぐためのものだ。特にOpenSearchとValkeyに関しては完全に逆行している。AWSは上流プロジェクトがライセンスを変更した後にフォークを作ったので、フォークがライセンス変更を「もたらした」と言うのは本当に変だ。フォークはライセンス変更に対する反応だったから。特にValkeyに関しては、元のRedisコア開発チームのメンバーがValkeyを作ったんだ。

└

これらのプロジェクトの多くは、コア製品をオープンソースにして、その周りに高度なサービスやインストール、メンテナンス、フルマネージドサービスを提供するビジネスモデルで運営してる。AWSはフルマネージドサービスを提供することで彼らをバイパスしてたんだ。これに関しては、プロジェクトの人たちの側に立ってるよ。基本的にAWSは彼らのランチを奪ってた。ライセンスを変更せざるを得なかったんだ。

└

フォークがライセンス変更を「もたらした」と言うのは本当に変だ。フォークはライセンス変更に対する反応だったんだから。 でも、そのライセンス変更はAWSが上流プロジェクトにとって持続不可能な方法で彼らの仕事をマネタイズしていたことへの反応だったんだ。

└

もちろん、AWSはプロジェクトがライセンスを変更してAWSが彼らのコードでお金を稼ぐのを禁止するまでフォークを作らなかったんだ！これがポイントだよ。

└

たまに、AmazonがOSSソフトウェアのクリエイターやメンテナに、使用ごとに1セント支払ったらどれだけ痛手になるのか考えることがある（1時間ごと？）。OSSチームにどれだけの資金が提供されるのかも気になる。リスクなしで製品改善に貢献できるから。

└

「オープンソースプロジェクトの哲学には、初めてRedisにパッチを送った時に共感を失った。あるコミッターが自分のものとして取り上げて、メッセージには一切返信せず、自分の名前でパッチを当てたんだ。あいつにはValkeyがふさわしいよ。JBossやあのクソ野郎のMarc Fleuryのことも今でも覚えてる…」

クラウドサービスとセルフホスティングを何度か切り替えたことがあるんだ。

  1. Vercelフェーズ 最初のプロジェクトではVercelを使ったんだけど、Next.jsだったからそこそこ良かった。でも、ユーザーが増えてきたら、100人未満のプロジェクトでも月20ドル払わなきゃいけなかった。高パフォーマンスは求めてなかったから、このコストはちょっと高いと感じた。
  2. セルフホスティングフェーズ（Hetzner + Coolify） その後、Hetznerで自分のサーバーを立てて、Coolifyでデプロイするようになった。Coolifyはオープンソースで無料だから、VPSのコストだけで済んだ（5ドル/月でも十分だった）。PostgreSQLのインスタンスをデプロイして、ウェブサーバーも動かせた。でも、後になってもPostgreSQLやRedisのメンテナンスにはかなり手間がかかることに気づいた。Dockerでコンテナ化してたけど、管理は面倒だった。サービス間でいろんなシステムや環境変数を渡さなきゃいけなくて、本当に手間がかかった。
  3. Cloudflareフェーズ それで、Cloudflareに切り替えた。Cloudflare Workersを使えば、フルスタックアプリケーションをデプロイできて、D1 DatabaseやCloudflare KVを使ってRedisの代わりにもなる。これらの機能はWorker内で直接呼び出せるから、環境変数を渡す必要がないのがいい。さらに、ローカル開発の体験も素晴らしくて、価格もかなりリーズナブルだから、それ以来Cloudflareの全機能を使ってるよ。
└

そうだね、Cloudflareの提供はAWSから私が求めていたものそのものになった。基本的なフルスタックアプリやファイルをデプロイするのがずっと簡単になった。AWSは自己ホスティングよりもかなり難しくなったよ。

└

「Cloudflare Workersを好きになりたかったんだけど、技術的な理由があるに違いないけど、標準的なことをするためにWranglerプロジェクトを使わなきゃいけないのが、プラットフォームに縛られそうな感じがして嫌だった。メールを許可するために設定する必要があるバインディングは、Wranglerが設定した後はコンソールからは見えないし、実際に設定できないみたいだった。」

IAMの過剰設計には同意だな。ただ、AWSのことを考えると、これは設計というより進化の結果だと思う。進化って、ある程度の後方互換性を維持しなきゃいけないからね（人間が今でも卵を産む必要があるみたいな感じ）。 もう一つ、SaaS企業に時々起こるのは、AWSがちょっと怪しい方法でその製品のコピーを作ること。でも、これは技術的な問題じゃなくて、ビジネスモデルの問題だね。

数年前、ある会社に入って開発チームを引き継いだんだけど、3ヶ月でプロダクトを立ち上げるように言われた。彼らはAWSを使ってたから、アカウントにログインして、いくつかマシンを追加しようとしたんだ。そしたら目の前に、敵対的で虐待的な関係の兆候が見えた。新しいマシンを立ち上げるためのUIには価格が表示されてなくて、別の表で価格を調べなきゃいけなかった。その表にはスペックも載ってないから、2つの表を開いてスペックと価格を照らし合わせる必要があった。過去の経験から学んだことは、虐待的な関係の兆候を見たら、歩み去る選択肢があるのにそれをしないと、後のことは自分の責任だってこと。DigitalOceanのアカウントを作って、すべてを移行した。CI/CDを設定して、そこでデプロイするようにして、次の2ヶ月はそのプロダクトに集中して、約束より1ヶ月早くリリースした。数年前にオンラインで見た動画で、ある人が川の近くに穴を掘って、川と穴をつなぐパイプを設置していた。魚たちがそのパイプを必死に押し進んで罠に入る様子が印象的だった。抵抗の少ない道を選び、間違いから決して引き下がらないことが、あの魚たちのようになるレシピだと思った。その動画は強い印象を残した。

└

彼らはAWSを使ってたから、アカウントにログインしていくつかマシンを追加しようとしたんだ。そしたら目の前に、敵対的で虐待的な関係のサインが見えた。 > 新しいマシンを立ち上げるためのUIには価格が表示されてなかった。別のテーブルで価格を調べなきゃいけなかったけど、そのテーブルには仕様も載ってなかった。AWSを擁護するつもりはないけど、これが嫌いな理由としてはちょっと無理があると思う。だって、価格は予約済み、専用、スポット、オンデマンドインスタンスなど、いろんな要素によって変わるから。企業環境では、マシンを立ち上げるのにUIを使うのは正しいやり方じゃないと思うよ。インフラストラクチャをコードとして扱うべきで、プログラムを見るだけで何が動いているか正確に把握できるから。シンプルなテストにはUIを使うのがいいと思うけど、そのコストはしばしば（でも必ずではない）無視できるものだし。ジェフ・ベゾス、これ見てたら、ちょっとお金送ってくれ！

└

実際、AWSには結構いい価格計算機があって、まあまあのプリセットもあるけど（お願いだから「すべてのチェックを外す」ボタンをくれ！）、もちろん別のアプリなんだよね。アマゾンはこの価格情報を手に入れるのにちょっと手間をかけさせたいんだろうけど、主な理由はコンウェイの法則に関係してると思う。AWSはまだ自社の組織図を出してるから。

└

ある程度は同意するけど、AWSの価格設定はUIに表示される静的な数字から計算できるほど簡単じゃないってことを指摘したい。コストをクロスチェックするために2つのタブを開かなきゃいけないのが気になるなら、AWSだけじゃなくて、すべてのクラウドプロバイダーを避けた方がいいかも。NATゲートウェイ、CloudFront、S3、オートスケーリング、ロードバランサーなどを使うと、コストの計算は正確な科学というよりアートになるし。それを使わないなら、AWSを使う意味もないし、「安い」VPSプロバイダーはいくらでもあるよ。

└

「新しいマシンを立ち上げるためのUIには、価格が表示されなかったんだ。他の表で価格を調べなきゃいけなかったけど、スペックは載ってなかった。これは間違いだよ。マシンを選ぶとすぐに価格が表示される。AWSの社員じゃないけどね…」

└

「アマゾンのエンジニアリング文化って、エンジニア主導のプロダクト文化じゃないの？つまり、開発者がUXやフローを担当することが多いってこと。中には本当に得意な人もいるけど、大多数はUXがひどく下手だよ。言いたいのは、もしかしたら意図的だったのかもしれないけど、ただ悪いUX文化だったってこと。」

└

「Azureのいいところの一つは、アイテムを作成する際に、個々のアイテムの横に価格をいちいち表示して圧倒されることがないところだね。でも、高額になりそうなものには常に価格を提示してくれる。いいバランスだと思うし、今のところ料金に驚かされたことはないよ。」

└

「このプロジェクトは3ヶ月のタイムラインがあって、クラウドリソースのプロビジョニングにクロスチェックで1、2時間余分にかかったってこと？実は、専用の計算機ページやプロダクトページの方が好きなんだ。そうすれば、請求の仕組みがもっとわかるから。これにこだわるのは変なことだと思うよ、特に開発者のリーダーやマネージャーとしては。」

└

「これが唯一の正しいやり方だと思う：あなたを支援してくれるインフラプロバイダーを選ぶこと。AWSはいいけど、全員に合うわけじゃない。Herokuのようなサービスとベアメタルの間に位置していて、メンテナンスをかなり抽象化しつつ、スケーリングアーキテクチャに対するある程度のコントロールを提供している。つまり、クラウドプロバイダーとしてはスケールするのを助けるけど、最も安くてシンプルなセットアップを作るためではない。VCマネーがあって成長をアピールするなら、AWSは安全な選択かも。アクセラレータープログラムを通じて提供される2年間のスタートアップクレジットがあれば、インフラ予算にあまり悩まされずに最初の18ヶ月を構築できるし、支出を最適化し始める前に良い予測ができるようになる（その後は、良い予測ができるようになるしね）。もしブートストラップで独立した開発者なら、手頃なものを選んでシンプルなものを選ぶべきだよ。HetznerやDOなんかで十分だよ。」

ずっと気になっているのがElasticacheなんだ。RDSにはお金を払うけど、それは価値があるから。スケーラビリティ、適切に最適化された設定、バックアップも心配いらないしね。でもElasticacheは価格が高くて、ほとんど価値がない。遅いし、最適化もされてないし、安定性も欠けてる。さらに、バニラのRedisインストールと比べてサポートするDBも1つだけ。スケーラビリティの改善はあるけど、バニラのRedisがElasticacheを圧倒的に上回るから、必要になることはめったにない。

AWSは2023年以降、技術スタッフが系統的に減少している。大量解雇やパフォーマンス改善プランの2サイクルを通じてね。多くのスキルを持った仲間がプレセールスやサポートにいることが多いけど、AWSにはいないことが多い。一方で、経歴があいまいな人たちが残されて昇進している。AWSを使うなら自己責任でね、ポール・ヴィクシーは君を救ってくれないから。

今でもなんでみんなAWSが好きなのか理解できない。複雑すぎるし、ダークパターンだらけで、他の選択肢と比べてもそんなに良くないと思う。

著者がDynamoDBを嫌ってるのに驚いた。実は私のお気に入りのAWSサービスの一つなんだ。可用性が高くて、運用オーバーヘッドもないし。使うたびにコストもかなり少なかったけど、データモデルを設計するのに少し時間をかける必要があるし、それにはサービスのドキュメントを読んで理解することが必要だよ。

└

まさにそれを言いにこのスレッドに来たんだ。追加したいのは、DynamoDBは使い方を理解していれば結構いいってこと。比較的シンプルなキー・バリューのストレージで、持続性が高く、テーブルサイズも無限にスケールするから。絶対にSQLデータベースとして使おうとしない方がいいよ。プロトタイプコードで75ドルの請求書を作る一番の方法は、JOINやGROUP BYを使ってSQLデータベースのように扱おうとすることだと思う。あるいは、2歳の子供が使うようなAIツールの理解度で無心にコードを書いてしまうこと。DynamoDBが本当に輝くのは、1つか2つのシンプルで比較的小さなテーブルの持続的ストレージが必要で、フルRDBMSを扱いたくないときだね。あるいは、1つの信じられないほど大きなテーブルを比較的シンプルにクエリしたいときで、RDBMSにそのデータを収めたくないときだ。

└

「同じことを言いたい。数年前にアプリを作ったんだけど、約5000万レコードを保存するためのDBが必要で、月に約1万回の読み書きがあった。最初にロードするのに50ドルくらいかかって、その後は維持費が月に10セントみたいな感じだった。」

請求の罠は、資本があってクレジットカードに信頼を置ける人以外には大きな痛手だよね。もちろん、これはAWSに限った話じゃないけど…。