この記事は、AWSを長年愛してきた開発者が、「やっぱりAWSはしんどい」と再認識するまでの話です。
しかも単なる愚痴ではなく、昔は心から推していた人が、どうして離反したのかがかなり生々しく書かれています。ここが面白い。
著者は、AWSがまだ小さかったころからの熱心な支持者でした。
SQS、S3、EC2、SimpleDB など、今ではおなじみのサービスが出始めた時代に「これは革命だ」と感じ、メルボルンで最初のAWSイベントまで開いたそうです。
当時のAWSは、スタートアップが自分でサーバーを買ってデータセンターに置かなくても、数分でシステムを立ち上げられるという、まさにゲームチェンジャーだった。ここは本当にその通りで、クラウドの初期インパクトって今では想像しづらいくらい強烈だったと思います。
でも、愛着が強かったぶん、失望もじわじわ効いてきたわけです。
著者は、人間関係の破綻にたとえていて、「最初は小さな違和感でも、積み重なるとある日突然、もう愛していないと気づく」と書いています。これ、かなりわかる話です。技術選定って、性能や機能だけじゃなく、日々の小さなストレスの総量で印象が決まることが多いんですよね。
著者は、AWSが長いあいだ公式の client libraries を整備せず、Pythonなどのライブラリを開発者コミュニティに任せていた点を強く批判しています。
要するに、AWS自身が便利にするための道具作りをあまりやらず、「みんなで頑張ってね」だったわけです。
これを美談として見る人もいますが、著者はかなり否定的です。個人的にも、プラットフォーム側が基本体験を整えないのは、ちょっと冷たいなと思います。
これも地味だけど痛い話です。
Python 2 と Python 3 は互換性の差が大きく、移行は面倒でした。AWSが対応を引きずったことで、開発者側が苦労したという見方です。
こういう「技術負債の押し付け」は、後からじわじわ効いてきます。
著者は DynamoDB をかなり強い言葉で批判しています。
DynamoDB は AWS の NoSQL データベースで、サーバー管理を気にしなくてよい反面、設計や課金の理解が難しいことがあります。
著者は試した結果、1日で 75ドル請求されたと書いています。
さらに、データの外への転送料金（egress）が高いことも問題視しています。egress とは、AWSの中から外へデータを出すときの料金です。クラウドではこういう「出すと課金」が効いてくるんですが、AWSはそれがかなり高い、というのが著者の不満です。
AWSの課金は、使った分だけ払う仕組みとしては便利ですが、その実態はかなり複雑です。
著者は、AWS内部でのデータ移動にまで課金されたり、同じデータが二重三重に課金されるように見えるケースがある、と不満を述べています。
ここはかなり重要で、クラウド費用の怖さは「見積もれないこと」にあります。料金表があるだけでは安心できないんですよね。実際、私はこういう「見えにくい課金」が一番やっかいだと思います。
IAM は AWS の認証・権限管理の仕組みで、誰が何にアクセスできるかを細かく制御します。
便利な反面、設定は非常に複雑です。著者はこれを「地獄のように複雑」とまで言っています。
これは誇張もあるでしょうが、方向性としては理解できます。IAM は慣れるまで本当にしんどい。
しかも著者が指摘するのは、AWSは“自分でサーバーを運用するより簡単”と売りながら、実はAWS自体のほうが複雑な面が多いという点です。これはかなり鋭い指摘だと思います。
AWS Lambda は、サーバーを意識せずにコードを動かせるサーバーレス実行環境です。
ただし著者は、起動の遅さや開発の複雑さを挙げ、本当に自前の web server より良いのか疑問だと述べています。
さらに重要なのは、Lambda を使い込むほど AWS から離れにくくなること。これがベンダーロックインです。
「乗り換えにくさ」は便利さの裏返しでもありますが、著者はかなり警戒しています。
著者は、AWSが Elasticsearch、Redis、MongoDB などの周辺で、コミュニティや企業が作った市場を横取りするように見えた、と批判しています。
その結果として、SSPL や Elastic License のような、いわゆる source-available 型のライセンスが増えた、という文脈にも触れています。
ここは難しい問題です。
企業側から見れば「AWSにそのまま商用化されると困る」、AWS側から見れば「ユーザーに良いサービスを提供しているだけ」とも言えます。
ただ、著者の感情としては、AWSはオープンソースの“果実”だけを取りに来る捕食者のように見える、ということです。かなり辛辣ですが、怒りの筋は通っています。
著者は、完全復帰したかったわけではありません。
戻った理由はあくまで調査目的です。
ここは実務的で、むしろ自然です。
AWSは嫌でも、「でかい計算資源を短時間だけ借りる」用途ではまだ強い。
著者もそこは認めています。
問題は、久しぶりに大きな EC2 spot instance を立ち上げて数時間試していたときに起きました。
AWSから「Suspected security breach of your account」というメールが届き、アカウントが制限されたのです。
AWSの立場から見れば、
というのは、かなり怪しい挙動です。
なので、セキュリティ検知自体は理解できますし、著者もそれ自体は評価しています。
ただし問題は、その後の対応です。
著者は指示に従ってパスワード変更、トークン無効化、請求確認などを行い、チャットでもやり取りしたそうです。
それでも、数日たっても制限解除されない。
このへん、読んでいてかなり胃が痛いです。
「安全のための保護」が、業務停止という形で自分に跳ね返るのは、クラウド依存の怖さそのものだと思います。
結論として著者は、
「やっぱりAWSから完全に離れるべきだった」
と再確認しています。
特に痛かったのは、昔なんとなく残していた AWS WorkMail や Route53 のドメイン管理です。
「ちょっと残しておく」が、そのまま依存の残骸になる。
これはクラウド移行で本当にありがちな話です。完全移行のつもりが、メールやDNSみたいな基盤だけ残ってしまうんですよね。そして、そこが一番の急所になったりする。
このブログ記事の面白さは、単に「AWSは嫌いです」と言っているのではなく、
「昔は大好きだった人が、時間をかけて失望し、最後に事故で決定的に離れた」
というドラマにあります。
技術選定は、最初の華やかさよりも、
みたいなものが、後から効いてきます。
AWSは今でも強力なサービス群を持っていますが、著者のように「便利さの裏にある複雑さと高コスト」を嫌う人がいても全然不思議ではない、と思います。
個人的には、この文章はかなり感情的だけれど、その感情の根っこにはちゃんと現実があります。
クラウドは魔法ではないし、むしろ大規模になるほど「誰が責任を持つのか」が見えにくくなる。
その意味で、この記事はAWS批判であると同時に、**“便利な基盤に人生を預けすぎると怖い”**という警告でもあるのではないでしょうか。
