- 初期からAWSを支持していたが、*複雑な課金体系とプラットフォーム全体の複雑さなど、積み重なった不満により、もはやAWSを好まなくなった
- DynamoDBの高コスト、1ギガバイトあたり9セントに及ぶエグレス料金、内部データ移動への二重・三重課金などが、依然として高額で理解しにくいと見ている
- AWS BedrockでClaudeのテストと192コアマシンのベンチマークを行うために復帰したが、休眠状態だったアカウントの突然の活動により、セキュリティ侵害の疑い通知が発生してアカウントが停止された
- アカウント停止により、業務用のAWS WorkMailまで停止し、無料サポートプランの状態では4日間アカウント復旧が行われなかった
- AWSに残していたサービスまで全て移行し、完全に去るべきだという結論に至った
初期のAWS支持から離脱まで
- AWSがSQS、S3、EC2、SimpleDBを中心とした、より小さなサービス群だった頃から強く支持しており、メルボルンで米国のAWS担当者が来てAWSを紹介する最初のイベントを主催したこともあった
- クラウドコンピューティングは、スタートアップがデータセンターにシステムを設置・運用しなくても、数分で自前のコンピュータシステムを動かせるようにした大きな変化だった
- 約15年間AWSを強く信じてきたが、時間が経つにつれて不満な点が積み重なり、ある時点でAWSをもはや好きではなくなった
時間とともに積み重なったAWSへの不満
-
クライアントライブラリとPython移行
- AWSは最初の6年間、自前のクライアントライブラリを作らず、Pythonのような言語向けライブラリをコミュニティに実装させており、無償で時間を使うプログラマーに負担を押し付けているように受け取れた
- AWSがPython 2からPython 3へ移行するのにあまりにも長くかかったことも、大きな不満として残っている
-
DynamoDBとコスト体験
- DynamoDBを使った初日に75ドルの請求が発生し、コストだけでなくシステム自体も想像しうる最悪の形に感じられた
-
データ転送コストと複雑な課金
- AWSのデータ送信コストはかつてGBあたり20セントで、その後GBあたり9セントまで下がったものの、依然として非常に高いと見ている
- AWS内部システム間のデータ移動にも課金が発生し、場合によっては二重・三重課金のように感じられる構造があり、深く理解しないと課金の罠を避けにくい
-
IAMと全体的な複雑さ
- IAM（認証およびアクセス制御システム）は極めて複雑なシステム
- AWS支持者は、自前でLinux、ハードウェア、ネットワーク、セキュリティを運用するのは複雑すぎるのでAWSを使うべきだと言うが、AWS自体のほぼあらゆる領域も巨大な複雑さを持っており、結局は高価な専門家チームが必要だと見ている
-
AWS Lambdaとロックイン
- 「スケーラブルだ」という利点に魅了されたが、遅いコールドスタートと膨大な開発上の複雑さが問題
- 自前のWebサーバーと比べて実質的な利点はなく、欠点の方が多く、AWSから離れる際にLambdaが最も解体しにくい部分だったほどベンダーロックインが深刻だった
-
オープンソースプロジェクトとホスティング収益
- AWSは、Elasticsearch、Redis、MongoDBのようなプロジェクトが複製・収益化を望まない意思を示していたにもかかわらず、OpenSearch、Valkey、DocumentDBを推し進めたと見ている
- それらのコミュニティや企業が市場を作った後でAWSがホスティングサービスの収益を持っていき、その結果としてSSPL、Elastic License、RSALのような防御的ライセンスやsource-availableモデルが増えたと見ている
AWSを離れた後に残していた一部サービス
- AWSへの愛着がなくなった後、全てをAWSの外へ移し、アカウントもほぼ全て閉じた
- ただし当時、実際に適切な解決策だと考えた一部サービスだけは残していた
- ドメインはRoute53に、一部バックアップはS3に、業務用メールはAWS WorkMailに残していた
- AWS WorkMailには12か月以内にサービス終了の通知が出ている
AWSにしばらく戻った理由
- 最近の研究とテストのためにAWSに再びログインした
- Claude/AnthropicがAWS Bedrockでどれほどうまく動くかを確認しようとしたが、Claude Code基準では動作は同じでも遅く、Anthropicのサブスクリプションよりはるかに高い
- 手元で最も速い自宅機材は20コアCPUと32GB RAMだったため、コードが192コアと1TB RAMの機材でどれほど速く実行されるかをベンチマークしようとした
- 約1か月前のAWS Bedrockテストは問題なく終わり、テスト後は全て停止した
- AWS Bedrockはプライバシーが必要なら有用かもしれないが、コストのため、今後ClaudeをAWS Bedrockで再び使うことはないだろう
EC2 Spotテスト中に発生したアカウント制限
- その後、192コアのEC2 Spotインスタンスを起動して約3時間テストしていたところ、AWSから「Suspected security breach of your account」というメールを受け取った
- ほぼ休眠状態だったアカウントが突然高価なコンピューティング資源を使い始めたことが、AWS内部のセキュリティ警告をトリガーした可能性があると見ている
- AWSがユーザーを保護しようとする目的自体は理解でき、前向きに評価している
- しかしAWSはアカウントを停止または制限し、その結果、AWS WorkMailとして使っていた主たる業務用メールアカウントが動かなくなった
- もはや誰もメールを送れず、どのAWSリソースも作成できなくなり、本来行いたかったテストも続けられなくなった
サポート対応と遅延
- AWSサポート通知に返信して、アカウントはハッキングされておらず、問題や課金異常もないと伝えたが応答はなかった
- プレミアムサポートを使っていなかったため、AWSが示した24時間の応答時間を待つ必要があり、3日経ってもAWSサポートから返答は来なかった
- AWSフォーラムに助けを求めた後、メールの指示に従い、Webではなくチャットを使うよう助言を受けた
- パスワード変更、アクセストークン削除、請求履歴確認など、求められた対応を全て実施し、チャット接続まで約30分待った後、AWS担当者と長時間会話した
- 担当者は納得したように見え、関連する内部チームに対応を依頼すると言ったが、24時間経っても制限は解除されなかった
- 8時間後にフォローアップした際も、「待ってほしい」という返答しか得られなかった
あらためて確認された結論
- アカウントが制限されてから4日が過ぎた時点でも、大きなマシンで試したい作業は残っており、そのために再び「quota」リクエストを出さなければならないことを心配するようになった
- 業務用メールシステムは依然として動いていない
- 今回の復帰体験は、AWSを去った理由を再確認させるものであり、AWS WorkMailを離れ、Route53のドメインも移して、二度と戻るべきではないと判断した
- 過去にAWSから離しておいた点は非常に幸運だったが、信頼して残していたメールシステムがAWS復帰の過程で停止し、実質的な被害につながった
- AWSがいつかアカウント制限を解除するかもしれないが、それがいつになるかは分からない
1件のコメント
Hacker Newsのコメント
数年前、ある会社に加わって開発チームを任され、3か月以内に製品を出せと言われたのだが、AWSで新しいマシンを追加しようとしてみると、価格がUIに表示されない構造そのものが敵対的で搾取的な関係のサインのように見えた
スペック表と価格表を別々に開いて照らし合わせる必要があり、過去の経験から見ても、こういうサインを見てなお離れないなら、その後の結果は自分の責任だと思った
そこで DigitalOcean のアカウントを作り、すべて移行したうえでCI/CDもそちらにデプロイするよう設定し、残りの2か月は製品に集中して、約束より1か月早くリリースした
昔、川辺に穴を掘って川とその穴をパイプでつなぎ、魚が自分から罠に入っていく映像を見たことがあるが、最小抵抗の経路を選び、ミスを取り返さない態度は、あの魚のような結末に行き着く秘訣だという印象が強く残っている
まだ料金で驚かされたことはない
以前、AWSのインターンを終えたジュニア開発者を採用したことがあるが、夏の間にプロダクト担当やデザイナーの助けなしで一人で作ったダッシュボードを見せてくれて、本当にひどかった
一部の開発者はプロダクト/UX感覚が良いが、大半はUXが致命的に弱いので、意図的というより、単にUX文化が悪かった可能性が高い
AWSは良いが万人向けではなく、Herokuのようなサービスとベアメタルの中間あたりで、多くの運用を抽象化しつつ、スケールアーキテクチャの制御権もある程度与えてくれる
つまりクラウド提供者としてのAWSはスケールには役立つが、最も安くて単純な構成を作るための道具ではない
VC資金があり成長を掲げるならAWSは安全な選択になり得るし、アクセラレータ経由の2年間のスタートアップクレジットのおかげで、最初の18か月はインフラ予算より構築に集中できる
ブートストラップやインディー開発者なら、負担可能で単純なものを選べばよく、HetznerやDigitalOcean で十分うまく回る
Amazonは価格情報を簡単に確認することに少し摩擦がある状態を望んでいるのだろうが、主因はConwayの法則のように見える
AWSは今もなお自分たちの組織図を製品として外に出している
コスト比較のためにタブを2つ開くのが面倒なら、AWSだけでなくすべてのクラウド提供者を避けたほうがいいかもしれない
NATゲートウェイ、CloudFront、S3、自動スケーリング、ロードバランサー が入ってくると、コスト計算は正確な科学というより芸術に近くなる
こうしたものを使わないならAWSを使う理由はあまりなく、安価なVPS提供者はたくさんある
OpenSearchとValkeyだけを見るなら、「AWSがforkを作ってライセンス変更を引き起こした」という説明は完全に逆だ
AWSは上流プロジェクトがライセンスを変えたあとで初めてforkを作ったのであり、特に Valkey は元Redisコア開発チームのメンバーたちが作ったものだ
AWSがフルマネージドサービスを提供して彼らを迂回したので、この件ではプロジェクトを作った側に立つことになる
基本的には AWSが彼らの飯の種を奪った のであり、ライセンスを変えざるを得なかった
そうすればオープンソースチームにはそれなりの資金になるかもしれないし、製品改善にもリスクなく貢献できるようになるのではないかと思う
彼らは Valkey を経験して当然だ
JBossとMarc Fleuryのこともまだ覚えている
そこがまさに核心だ
クラウドサービスとセルフホスティングの間を何度か行き来してきた
最初は Vercel を使い、プロジェクトがNext.jsだったので体験は悪くなかったが、ユーザー100人にも満たないプロジェクトに月20ドル必要で、性能要件の低いサービスとしては高く感じた
その後、HetznerとCoolifyで自前サーバーを組んだが、CoolifyはオープンソースなのでVPS費用だけで済み、月5ドルでもPostgreSQLインスタンスとWebサーバーを動かせた
しかしPostgreSQLとRedisの保守には依然として手間がかかり、Dockerコンテナ内にあっても、サービス間でシステム変数や環境変数を受け渡しするのが面倒だった
そこで後には Cloudflare Workers、D1 Database、Cloudflare KV に移行し、Worker内からそのまま呼び出せるので環境変数の受け渡しが不要になった
ローカル開発体験も良く、価格も妥当なので、その後もCloudflare製品群全体を使い続けている
基本的な フルスタックアプリとファイル配信 がずっと単純で、AWSはセルフホスティングよりもさらに難しくなっている
PostgreSQLで困る唯一のことは、新しいメジャーバージョンへ移るときに多少のマイグレーション作業が必要なことくらいだ
サービス間でシステム変数や環境変数を渡すことが、Dockerのせいでむしろ難しくなっていたのかも気になる
メールを許可するには必要なバインディングを設定しなければならないが、コンソールでは設定もできず、Wranglerが設定したあとも見えないように思えた
筆者が DynamoDB を嫌っているのは意外だ
自分が一番好きなAWSサービスのひとつで、可用性が高く、運用負担がなく、使うたびにコストもかなり低かった
ただしデータモデルを事前に設計するために時間をかける必要があり、そのためにはサービスのドキュメントを読んで理解しなければならない
基本的には、優れた永続性とほぼ無限のテーブルサイズ拡張性を持つ比較的単純な キー・バリューストア として考えるべきで、SQLデータベースのように使おうとしてはいけない
プロトタイプコードで75ドルの請求書を作る最も簡単な方法は、JOINやGROUP BYのようなものを使うSQLデータベースとして扱うように雰囲気でコーディングすることだ
本当に輝くのは、小さな永続ストレージ用テーブルが1〜2個必要だがフルRDBMSは管理したくないとき、あるいは非常に大きなテーブル1つを単純な方法で問い合わせたいがRDBMSに合わせたくないときだ
気軽なキー・バリューストアをデータベースとして使ってはいけない
初回ロードのコストは約50ドルで、その後の維持コストは月10セント程度だった
こういう記事を見るといつも笑ってしまう
正しくもあり間違ってもいて、システムは「できるだけ単純に、しかしそれ以上に単純ではなく」作るべきだ
細部を雑に飛ばせると思うと、あとでより大きな面倒になる
IAM は単純に複雑だ
ユーザー、グループ、ロール、ポリシー、IDプロバイダ、OIDCを本当に単純に実装した例は思い浮かばない
以前、Kubernetes導入に「複雑すぎる」と反対した人が、結局Vault、Consul、systemd、Nomad、iSCSI、Ansible、Jenkins、Puppet、Bashと根性で、Kubernetesを粗悪で場当たり的に再発明して大量のミスをするのを見たことがある
ある機能は不要だと思っていても、結局必要になる
スタートアップで一人インフラ担当をしていた立場からすると、AWSの大半は学べる範囲内にあり、ひどい部分はたいてい避けられる
Lambdaが嫌いなら使わなければいいし、EKS、ECS、EC2 を使えばいい
1万フィート上空から見れば、それがすべてだ
IAMが優れているのは、外部にも内部にも同じように適用されるからだ
AWS内部のチームだからといって余計なアクセス権を持つわけではなく、特定サービスを実行するために顧客アカウント内で何かを行う権限が生じるなら、それは顧客がIAM信頼関係にサービスプリンシパルを入れてアクセスを許可したからであり、顧客はそれを確認して監査できる
たとえばLambdaにはLambdaロールがあるが、「我々はAWSだから自動的にアクセス可能」という理由でLambdaサービスがS3バケットを読める状態にはしたくないからだ
AWS内部のアクセスであっても、顧客が確実に見て制御できる
今では明らかな 標準 になっているものですら、多くの人はきちんと学ぶために時間を使うことを拒む
まともなインフラエンジニアが「節約するため」にOVH構成に2か月使ったら、単に FargateやRDS を使わなかったことで節約できる金額より高くつく
AnthropicやOpenAIのようなところについても、いつ同じ話が出始めるのか気になる
今のAIの流れはAWS初期と似た匂いがしていて、みんなが飛び乗ったあとで、簡単には切り離せない 大きな依存 を積み上げていたと気づくことになりそうだ
Lambdaは本当に素晴らしく、頭を悩ませず高速な反復サイクルでデプロイされたサービスを運用する最高の方法だと思う
必ずしもマイクロサービスに行く必要はないし、コードを何十億もの小さなリポジトリに分割する必要もない
サーバー内の状態をリクエスト間で共有できると期待しないなら、標準的なWebサーバーを Lambda に移せる
その分野で働いていないので、AWSはたまに個人の趣味プロジェクトで触るだけだが、毎回悪夢のようだ
実験用のカードゲームサーバーを1つ作りたいだけで、新しい金融機関を立ち上げたいわけではないのに、何もかもが明日には無限にスケールする準備をしていて、1,000人規模の組織とVC予算を前提にしているように見える
幸い Netlify のようなサービスが表面を覆ってくれるので、大げさなことをしなくて済む
いつかはIAMやVPNやその他よく分からないものを本当に学ばなければならないのかもしれないが、それまではAWSを触るたびに目が飛び出しそうになる
すべてのエンタープライズパターンを実装しなければならないわけではない
必要なものは一通りあり、価格も妥当だ
個人プロジェクトは結局コストしか重視しないので、AWSに意味のある売上をもたらせない
2023年以降、AWSでは技術人材が体系的に抜かれている
大規模レイオフや2回のPIPを通じてそうなっており、プリセールスやサポート側で優秀だった同僚は、AWSに残っていないことが多かった
その一方で、業務実績が最も曖昧な人たちが残り、昇進したのをよく見た
AWSは各自のリスクで使うもので、Paul Vixie が来て救ってくれるわけではない
かなり前から ElastiCache だけは特に癇に障っていた
RDSはスケーラビリティ、そこそこ最適化された設定、気にしなくてよいバックアップといった価値を足してくれるので、我慢してお金を払える
だがElastiCacheは付加価値がほとんどないのに、価格は搾取的に感じる
基本のRedisインストールと比べて、より遅く、最適化も甘く、安定性も低く、設定なしのRedisは複数DBをサポートするのにElastiCacheは1つしかサポートしない
スケーラビリティ改善は多少あるが、同等インスタンスでは素のRedisがElastiCacheをあまりに大きく上回るため、そうした改善が実際に必要なケースは非常にまれだ
AWSがAPIや完成度の面で大きく付加するものは多くなく、その一方でRedis/Valkeyは自分でホストするのが最も簡単なサービスのひとつだからだ