AWS の後方互換性と API の安定性 - 一度公開した API を廃止しない方針が生む信頼
AWS が一度公開した API を廃止しない方針を貫いている実績を、Azure のブランド変更や GCP のサービス廃止事例と比較し、API 安定性がエンタープライズにとってなぜ重要かを解説します。
API の安定性はインフラの安定性と同義である
クラウドサービスの上にシステムを構築するということは、そのクラウドの API に依存するということです。API が変更されれば、その上に構築されたすべてのシステムに影響が及びます。API の廃止や破壊的変更は、アプリケーションの改修、テストの再実行、デプロイの再計画を強いるものであり、企業にとっては予期しないコストとリスクの発生を意味します。AWS は創業以来、一度公開した API を廃止しないという方針を貫いています。2006 年に公開された S3 の基本的な API (PutObject、GetObject、DeleteObject) は、2025 年の今でもそのまま動作します。新しい機能は新しい API エンドポイントやパラメータとして追加され、既存の API は変更されません。この方針は、AWS のサービスが 200 を超える現在でも一貫して維持されています。
後方互換性の維持がもたらす実務上の価値
API の後方互換性が維持されることの実務上の価値は、見過ごされがちですが極めて大きいものです。第一に、既存システムの保守コストが低減されます。API が変更されなければ、動作しているシステムに手を加える必要がありません。「動いているものは触るな」という運用の鉄則を、クラウドプロバイダー側が保証してくれるのです。第二に、長期的な投資の保護です。CloudFormation テンプレート、CDK コード、Terraform の設定、CI/CD パイプラインなど、クラウドインフラの自動化に投資したコードが、API の変更によって無駄になるリスクがありません。第三に、技術的負債の抑制です。API の変更に追従するための改修作業は、新しい価値を生まない技術的負債の一種です。AWS の後方互換性方針は、この種の負債の発生を構造的に防いでいます。第四に、計画的なアップグレードが可能です。新しい API や機能が追加されても、既存の API は引き続き動作するため、移行のタイミングを自社の都合で決められます。プロバイダーの都合で強制的にアップグレードさせられることがありません。
Azure のブランド変更と API の変遷
Azure は API の安定性において、AWS とは異なる歴史を持っています。Azure の初期には Azure Service Management (ASM) という API 体系が使われていましたが、2014 年に Azure Resource Manager (ARM) への移行が始まり、ASM は段階的に廃止されました。この移行は、既存のスクリプトやツールの書き換えを必要とし、多くのユーザーに影響を与えました。Azure のブランド名の変更も頻繁です。Windows Azure から Microsoft Azure への改名 (2014 年)、Azure Active Directory から Microsoft Entra ID への改名 (2023 年)、Azure DevOps の前身である Visual Studio Team Services からの改名など、サービス名やブランドの変更が繰り返されています。ブランド名の変更は API の破壊的変更とは異なりますが、ドキュメント、トレーニング資料、社内の知識ベースの更新を必要とし、運用上の混乱を招きます。Azure の API バージョニングも複雑です。ARM API はバージョン付きで提供されますが、古いバージョンのサポート期限が設定されることがあり、定期的なバージョンアップが必要になるケースがあります。
GCP のサービス廃止の歴史
GCP の API 安定性に対する懸念は、Google 全体の「サービス廃止」の歴史に根ざしています。Google は消費者向けサービスにおいて、Google Reader (2013 年)、Google+ (2019 年)、Stadia (2023 年) など、多数のサービスを廃止してきました。この「使われないサービスは廃止する」という文化は、GCP にも影響を与えています。GCP では、Cloud IoT Core が 2023 年に廃止されました。IoT Core を利用していた顧客は、代替サービスへの移行を余儀なくされました。Cloud Domains も 2024 年に廃止が発表されています。GCP は近年、エンタープライズ顧客の信頼を得るために、サービスの廃止ポリシーを明確化し、廃止前の通知期間を設けるなどの改善を行っています。しかし、「Google はサービスを廃止する」という認識は根強く、エンタープライズの意思決定者がクラウドプラットフォームを選定する際の懸念材料となっています。AWS では、サービスの廃止は極めて稀です。利用が少ないサービスであっても、既存の顧客がいる限り維持する方針を取っています。この方針は短期的にはコストがかかりますが、長期的には「AWS を選べば、サービスが突然なくなることはない」という信頼を構築しています。
後方互換性を維持するための設計上の工夫
API の後方互換性を長期間維持することは、技術的に容易ではありません。AWS がこれを実現できている背景には、いくつかの設計上の工夫があります。第一に、API の設計段階での慎重さです。Working Backwards プロセスにより、API の設計は顧客のユースケースから逆算して行われます。リリース前に十分な検討が行われるため、後から「設計を間違えた」として API を変更する必要性が低減されます。第二に、拡張性を前提とした設計です。API のレスポンスに新しいフィールドを追加しても、既存のクライアントが無視できるよう設計されています。新しいパラメータはオプショナルとして追加され、デフォルト値が設定されます。第三に、バージョニングの戦略です。破壊的変更が必要な場合は、新しい API バージョンとして提供し、旧バージョンも並行して維持します。顧客は自分のペースで新バージョンに移行できます。これらの工夫は、Two-Pizza Team の自律性と組み合わさることで効果を発揮します。各チームが自分のサービスの API に対して完全な責任を持ち、後方互換性の維持を自チームの品質基準として内面化しています。 API 設計のベストプラクティスを学ぶには関連書籍 (Amazon) も参考になります。
まとめ
AWS の後方互換性方針は、2006 年の S3 API から 18 年以上にわたって一貫して維持されており、既存システムの保守コスト低減、長期投資の保護、技術的負債の抑制という実務上の価値を提供しています。Azure は ASM から ARM への移行やブランド名の頻繁な変更により、API の安定性で課題を抱えています。GCP は Google の「サービス廃止」文化の影響を受け、IoT Core の廃止などエンタープライズ顧客の信頼を損なう事例があります。クラウドプラットフォームの選定において、API の安定性と後方互換性は、機能の豊富さと同等以上に重視すべき要素です。