AWSに戻ったら、なぜ自分が離れたのかを改めて思い知らされた

 (fourlightyears.blogspot.com)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • 初期の頃からAWSを支持していたが、クライアントライブラリをコミュニティ任せにしていた時期、Python 3への移行の遅れ、複雑な課金とIAM、AWS Lambdaのロックインなどが積み重なり、もはやAWSを好きではなくなった
  • DynamoDBを使った後、1日で75ドル請求され、データ送信コストはGBあたり20セントから9セントに下がったものの、内部データ移動にまで課金される仕組みは依然として高額で分かりにくいと感じた
  • AWSを離れた後、ほとんどのアカウントを閉じたが、Route53のドメイン、S3のバックアップの一部、AWS WorkMailは残しており、その後WorkMailが今後12か月以内に終了するという通知を受けた
  • 最近、Claude/AnthropicのAWS Bedrockでの動作確認と、192コア・1TB RAMのEC2 SpotテストのためにAWSへ再ログインしたが、Bedrockは動作自体は同じでもより遅く、Anthropicのサブスクリプションよりはるかに高いと判断した
  • 約3時間のEC2 Spotテスト中、Suspected security breach の通知の後にアカウントが制限され、業務用WorkMailメールとリソース作成が止まり、対応やチャットサポートの後も4日間制限が解除されなかったため、AWS WorkMailとRoute53まで移行することにした

初期のAWS支持から離脱まで

  • AWSがSQS、S3、EC2、SimpleDBを中心としたもっと小さなサービス群だった頃から強く支持しており、Melbourneで米国のAWS担当者を招いてAWSを広める最初のイベントを主催した
  • クラウドコンピューティングは、スタートアップがデータセンターにシステムを設置・運用しなくても、数分で自前のコンピューターシステムを動かせるようにした大きな変化だった
  • およそ15年間AWSを強く信じていたが、時間とともに不満な点が積み重なり、ある時点でAWSを好きではなくなった

時間とともに積み上がったAWSへの不満

  • クライアントライブラリとPython移行

    • AWSは初期の6年間、自前のクライアントライブラリを作らず、Pythonのような言語向けライブラリをコミュニティに実装させており、無償で時間を使うプログラマーに負担を押しつけているように受け取られた
    • AWSがPython 2からPython 3へ移るのにあまりにも時間がかかったことも、大きな不満として残った

  • DynamoDBとコストの体験

    • DynamoDBを使った後、1日の終わりに75ドルの請求が発生し、コストだけでなくシステム自体も想像しうる最悪の方式のように感じられた

  • データ転送コストと複雑な課金

    • AWSのデータ送信コストはかつてGBあたり20セントで、その後GBあたり9セントまで下がったが、それでもなお非常に高いと感じている
    • AWS内部のシステム間のデータ移動にも課金が発生し、場合によっては二重三重の課金のように感じられる構造があり、深く理解しないと課金の落とし穴を避けるのが難しい

  • IAMと全体的な複雑さ

    • IAMは認証とアクセスルールを扱うシステムだが、過度に複雑な構造だと受け止められている
    • AWS支持者は、自前でLinux、ハードウェア、ネットワーク、セキュリティを運用するのは複雑すぎるのでAWSを使うべきだと言うが、AWS自体のほぼすべての領域もまた巨大な複雑さを抱えており、結局は高価な専門家チームが必要だと見ている

  • AWS Lambdaとロックイン

    • AWS Lambdaはスケーラビリティを売りにしているが、起動の遅さと大きな開発上の複雑さを受け入れなければならなかった
    • 自前のWebサーバーを運用するのと比べて本当の利点はなく、欠点は多いと考えており、AWSを離れる際に最も元に戻しにくかった部分がAWS Lambdaだった
    • 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件のコメント

 
GN⁺ 5 시간 전
Hacker Newsのコメント

  • 数年前、ある会社に加わって開発チームを任され、3か月以内に製品を出せと言われたのだが、AWSで新しいマシンを追加しようとしてみると、価格がUIに表示されない構造そのものが敵対的で搾取的な関係のサインのように見えた
    スペック表と価格表を別々に開いて照らし合わせる必要があり、過去の経験から見ても、こういうサインを見てなお離れないなら、その後の結果は自分の責任だと思った
    そこで DigitalOcean のアカウントを作り、すべて移行したうえでCI/CDもそちらにデプロイするよう設定し、残りの2か月は製品に集中して、約束より1か月早くリリースした
    昔、川辺に穴を掘って川とその穴をパイプでつなぎ、魚が自分から罠に入っていく映像を見たことがあるが、最小抵抗の経路を選び、ミスを取り返さない態度は、あの魚のような結末に行き着く秘訣だという印象が強く残っている

    • Azureで気に入っている点のひとつは、個々の項目を作るたびに価格を過剰に押し付けてはこないが、高くなり得る項目にはだいたい 価格を表示するバランス があること
      まだ料金で驚かされたことはない
    • Amazonのエンジニアリング文化はかなり エンジニア主導のプロダクト文化 で、開発者がUXや導線まで責任を持つことが多いのではないかと思う
      以前、AWSのインターンを終えたジュニア開発者を採用したことがあるが、夏の間にプロダクト担当やデザイナーの助けなしで一人で作ったダッシュボードを見せてくれて、本当にひどかった
      一部の開発者はプロダクト/UX感覚が良いが、大半はUXが致命的に弱いので、意図的というより、単にUX文化が悪かった可能性が高い
    • 正しいやり方は、リリースを助けてくれるインフラ提供者 を選ぶこと
      AWSは良いが万人向けではなく、Herokuのようなサービスとベアメタルの中間あたりで、多くの運用を抽象化しつつ、スケールアーキテクチャの制御権もある程度与えてくれる
      つまりクラウド提供者としてのAWSはスケールには役立つが、最も安くて単純な構成を作るための道具ではない
      VC資金があり成長を掲げるならAWSは安全な選択になり得るし、アクセラレータ経由の2年間のスタートアップクレジットのおかげで、最初の18か月はインフラ予算より構築に集中できる
      ブートストラップやインディー開発者なら、負担可能で単純なものを選べばよく、HetznerやDigitalOcean で十分うまく回る
    • AWSにはかなりまともな 価格計算ツール と使えるプリセットがあるが、当然ながら完全に別アプリだ
      Amazonは価格情報を簡単に確認することに少し摩擦がある状態を望んでいるのだろうが、主因はConwayの法則のように見える
      AWSは今もなお自分たちの組織図を製品として外に出している
    • ある程度は同意するが、AWSの価格は、UIに出る静的な数字ひとつでいくら払うか計算できるほど単純ではない
      コスト比較のためにタブを2つ開くのが面倒なら、AWSだけでなくすべてのクラウド提供者を避けたほうがいいかもしれない
      NATゲートウェイ、CloudFront、S3、自動スケーリング、ロードバランサー が入ってくると、コスト計算は正確な科学というより芸術に近くなる
      こうしたものを使わないならAWSを使う理由はあまりなく、安価なVPS提供者はたくさんある

  • OpenSearchとValkeyだけを見るなら、「AWSがforkを作ってライセンス変更を引き起こした」という説明は完全に逆だ
    AWSは上流プロジェクトがライセンスを変えたあとで初めてforkを作ったのであり、特に Valkey は元Redisコア開発チームのメンバーたちが作ったものだ

    • この種のプロジェクトのかなり多くは、コア製品をオープンソースとして公開し、高度なサービス・導入・保守・フルマネージドサービスを提供するビジネスモデルで運営されている
      AWSがフルマネージドサービスを提供して彼らを迂回したので、この件ではプロジェクトを作った側に立つことになる
      基本的には AWSが彼らの飯の種を奪った のであり、ライセンスを変えざるを得なかった
    • そのライセンス変更自体が、AWSが上流プロジェクトにとって持続不可能な形で彼らの仕事を収益化したことへの対応だった
    • Amazonが自分たちが販売する オープンソースソフトウェア の作者やメンテナに、利用課金期間ごとに1セントずつでも支払ったら、どれほどの影響があるのか気になる
      そうすればオープンソースチームにはそれなりの資金になるかもしれないし、製品改善にもリスクなく貢献できるようになるのではないかと思う
    • Redisに最初のパッチを送ったとき、コミッタの一人が私のメッセージには返事をせず、そのパッチを自分の名前で入れてしまって以来、多くのオープンソースプロジェクトの哲学への共感が薄れた
      彼らは Valkey を経験して当然だ
      JBossとMarc Fleuryのこともまだ覚えている
    • AWSがそのプロジェクトのコードで儲けられないようライセンスを変えられたあとでforkを作ったのは当然だ
      そこがまさに核心だ

  • クラウドサービスとセルフホスティングの間を何度か行き来してきた
    最初は Vercel を使い、プロジェクトがNext.jsだったので体験は悪くなかったが、ユーザー100人にも満たないプロジェクトに月20ドル必要で、性能要件の低いサービスとしては高く感じた
    その後、HetznerとCoolifyで自前サーバーを組んだが、CoolifyはオープンソースなのでVPS費用だけで済み、月5ドルでもPostgreSQLインスタンスとWebサーバーを動かせた
    しかしPostgreSQLとRedisの保守には依然として手間がかかり、Dockerコンテナ内にあっても、サービス間でシステム変数や環境変数を受け渡しするのが面倒だった
    そこで後には Cloudflare Workers、D1 Database、Cloudflare KV に移行し、Worker内からそのまま呼び出せるので環境変数の受け渡しが不要になった
    ローカル開発体験も良く、価格も妥当なので、その後もCloudflare製品群全体を使い続けている

    • Cloudflareが提供する機能は、自分がAWSに求めていたものに近づいてきた
      基本的な フルスタックアプリとファイル配信 がずっと単純で、AWSはセルフホスティングよりもさらに難しくなっている
    • DockerがPostgreSQL管理を楽にしてくれたのか気になる
      PostgreSQLで困る唯一のことは、新しいメジャーバージョンへ移るときに多少のマイグレーション作業が必要なことくらいだ
      サービス間でシステム変数や環境変数を渡すことが、Dockerのせいでむしろ難しくなっていたのかも気になる
    • Cloudflare Workersを好きになりたかったし、技術的に良い理由もあるのだろうが、メール有効化のような作業に Wranglerプロジェクト を使わなければならないやり方は、プラットフォームにロックインされる一歩手前のように感じた
      メールを許可するには必要なバインディングを設定しなければならないが、コンソールでは設定もできず、Wranglerが設定したあとも見えないように思えた

  • 筆者が DynamoDB を嫌っているのは意外だ
    自分が一番好きなAWSサービスのひとつで、可用性が高く、運用負担がなく、使うたびにコストもかなり低かった
    ただしデータモデルを事前に設計するために時間をかける必要があり、そのためにはサービスのドキュメントを読んで理解しなければならない

    • DynamoDBは意図された使い方をすればかなり良い
      基本的には、優れた永続性とほぼ無限のテーブルサイズ拡張性を持つ比較的単純な キー・バリューストア として考えるべきで、SQLデータベースのように使おうとしてはいけない
      プロトタイプコードで75ドルの請求書を作る最も簡単な方法は、JOINやGROUP BYのようなものを使うSQLデータベースとして扱うように雰囲気でコーディングすることだ
      本当に輝くのは、小さな永続ストレージ用テーブルが1〜2個必要だがフルRDBMSは管理したくないとき、あるいは非常に大きなテーブル1つを単純な方法で問い合わせたいがRDBMSに合わせたくないときだ
    • DynamoDBやLambdaのような多くのサービスには 非常に特定のユースケース がある
      気軽なキー・バリューストアをデータベースとして使ってはいけない
    • 数年前にアプリを作ったとき、約5,000万件のレコード、月1万回程度の読み書き、インデックス1個を保存するDBが必要だった
      初回ロードのコストは約50ドルで、その後の維持コストは月10セント程度だった

  • こういう記事を見るといつも笑ってしまう
    正しくもあり間違ってもいて、システムは「できるだけ単純に、しかしそれ以上に単純ではなく」作るべきだ
    細部を雑に飛ばせると思うと、あとでより大きな面倒になる
    IAM は単純に複雑だ
    ユーザー、グループ、ロール、ポリシー、IDプロバイダ、OIDCを本当に単純に実装した例は思い浮かばない
    以前、Kubernetes導入に「複雑すぎる」と反対した人が、結局Vault、Consul、systemd、Nomad、iSCSI、Ansible、Jenkins、Puppet、Bashと根性で、Kubernetesを粗悪で場当たり的に再発明して大量のミスをするのを見たことがある
    ある機能は不要だと思っていても、結局必要になる
    スタートアップで一人インフラ担当をしていた立場からすると、AWSの大半は学べる範囲内にあり、ひどい部分はたいてい避けられる
    Lambdaが嫌いなら使わなければいいし、EKS、ECS、EC2 を使えばいい

    • 内部視点で見ると、IAMには何千ものオプションがあるが、本質は「このロールが何にアクセスして何をできるか（アクション+リソース）」と「誰がこのロールにアクセスできるか」だ
      1万フィート上空から見れば、それがすべてだ
      IAMが優れているのは、外部にも内部にも同じように適用されるからだ
      AWS内部のチームだからといって余計なアクセス権を持つわけではなく、特定サービスを実行するために顧客アカウント内で何かを行う権限が生じるなら、それは顧客がIAM信頼関係にサービスプリンシパルを入れてアクセスを許可したからであり、顧客はそれを確認して監査できる
      たとえばLambdaにはLambdaロールがあるが、「我々はAWSだから自動的にアクセス可能」という理由でLambdaサービスがS3バケットを読める状態にはしたくないからだ
      AWS内部のアクセスであっても、顧客が確実に見て制御できる
    • 「Xは複雑すぎる」と言って導入を止めた結果、結局Xを粗悪に再発明するというパターンは、技術やソフトウェアでは驚くほどよくある
      今では明らかな 標準 になっているものですら、多くの人はきちんと学ぶために時間を使うことを拒む
    • AWSがセルフホスティングより高いことはあり得るが、その差額はエンジニアリングコストの前では小さい
      まともなインフラエンジニアが「節約するため」にOVH構成に2か月使ったら、単に FargateやRDS を使わなかったことで節約できる金額より高くつく

  • AnthropicやOpenAIのようなところについても、いつ同じ話が出始めるのか気になる
    今のAIの流れはAWS初期と似た匂いがしていて、みんなが飛び乗ったあとで、簡単には切り離せない 大きな依存 を積み上げていたと気づくことになりそうだ

  • Lambdaは本当に素晴らしく、頭を悩ませず高速な反復サイクルでデプロイされたサービスを運用する最高の方法だと思う
    必ずしもマイクロサービスに行く必要はないし、コードを何十億もの小さなリポジトリに分割する必要もない
    サーバー内の状態をリクエスト間で共有できると期待しないなら、標準的なWebサーバーを Lambda に移せる

  • その分野で働いていないので、AWSはたまに個人の趣味プロジェクトで触るだけだが、毎回悪夢のようだ
    実験用のカードゲームサーバーを1つ作りたいだけで、新しい金融機関を立ち上げたいわけではないのに、何もかもが明日には無限にスケールする準備をしていて、1,000人規模の組織とVC予算を前提にしているように見える
    幸い Netlify のようなサービスが表面を覆ってくれるので、大げさなことをしなくて済む
    いつかはIAMやVPNやその他よく分からないものを本当に学ばなければならないのかもしれないが、それまではAWSを触るたびに目が飛び出しそうになる

    • EC2やLightsailで素のVPSを立てて、パブリックIPを付けて終わりでいい
      すべてのエンタープライズパターンを実装しなければならないわけではない
    • Herokuがほぼ20年前に、ほとんどのWebアプリに必要なものを本当に的確に押さえていたのは驚きだ
    • Azureを触ったことがなければ、AWSだけが悪夢のように感じられるかもしれない
    • Cloudflareに移ったが、本当に息がつけるようになった
      必要なものは一通りあり、価格も妥当だ
    • AWSは個人プロジェクトではなく エンタープライズ を狙っている
      個人プロジェクトは結局コストしか重視しないので、AWSに意味のある売上をもたらせない

  • 2023年以降、AWSでは技術人材が体系的に抜かれている
    大規模レイオフや2回のPIPを通じてそうなっており、プリセールスやサポート側で優秀だった同僚は、AWSに残っていないことが多かった
    その一方で、業務実績が最も曖昧な人たちが残り、昇進したのをよく見た
    AWSは各自のリスクで使うもので、Paul Vixie が来て救ってくれるわけではない

  • かなり前から ElastiCache だけは特に癇に障っていた
    RDSはスケーラビリティ、そこそこ最適化された設定、気にしなくてよいバックアップといった価値を足してくれるので、我慢してお金を払える
    だがElastiCacheは付加価値がほとんどないのに、価格は搾取的に感じる
    基本のRedisインストールと比べて、より遅く、最適化も甘く、安定性も低く、設定なしのRedisは複数DBをサポートするのにElastiCacheは1つしかサポートしない
    スケーラビリティ改善は多少あるが、同等インスタンスでは素のRedisがElastiCacheをあまりに大きく上回るため、そうした改善が実際に必要なケースは非常にまれだ

    • ElastiCacheは間違いなく セルフホスティング を検討する価値があるサービスのひとつだ
      AWSがAPIや完成度の面で大きく付加するものは多くなく、その一方でRedis/Valkeyは自分でホストするのが最も簡単なサービスのひとつだからだ