【AWS re:Invent 2025】 ロックインを前提にしたクラウド設計の考え方

「Evaluating architectural trade-offs: Cloud patterns for flexibility（ARC321）」を現地で聴講しました。

ロックインや将来のスイッチングを意識しながら、アーキテクチャの判断に迷っている人向けのセッションです。

ロックインは「避けるべきリスク」ではない

一般には、ロックインは悪いものとして語られがちです。
しかしこのセッションでは、ロックインを善悪で判断すること自体が誤りだと、はっきり否定していました。
設計判断は、ロックインがあるかどうかではなく、「その選択が生む価値が、スイッチングコストに見合っているか」で評価すべきだ、というのがこのセッションの趣旨でした。

判断フレームワークは価値×スイッチングコスト

セッションでは、サービス選択を以下のように捉える考え方が示されていました。 「AWSネイティブかどうか」は判断軸ではありません。価値とコストを分解して考えられているかどうかが、すべてです。
私なりに表にまとめていました。

以下の図は、スイッチングコストを「将来の話」として切り離すのではなく、今の意思決定に織り込んで評価すべきだ、という考え方を示しています。

具体例：EC2上にDBを立てる判断は、本当にロックイン回避か

セッションの内容にはありませんが、よくある例を挙げて自分なりに考えてみます。

実務では、「マネージドDBはロックインが怖い」「OSSなら将来どこにでも移せる」 という理由で、EC2上にDBを構築する判断をよく見かけます。
しかし、この選択はロックインを避けているようで、実際には「人と運用」へのロックインを強めているケースが少なくありません。

EC2に自前のDBを構築する場合、Aurora/RDSを使った場合の違いを、価値とスイッチングコストの観点で整理すると次のようになります。

「単純だから」「どこでも動くから」という理由で自分たちで運用する構成を選ぶと、 非差別化領域の運用や失敗時対応を、人と手順で抱え込むことになります。 結果として、技術的には汎用的でも、運用や属人性に強くロックインされた構造になります。

このセッションを通して見えたこと

ARC321が伝えていたのは、 「Auroraを使え」「マネージドサービスを使え」という話ではありません。
アーキテクチャを考えるとき、このような選択をしたとします。

• 将来どのクラウドにも移れるようにしておくこと
• ロックインを恐れて、最初から機能を制限すること
• 最悪の場合に備えて、価値を犠牲にした設計を選ぶこと

その選択がどれだけの価値を生み、 どこにスイッチングコストを発生させているのかを分解して考えているでしょうか。

ロックインの有無ではなく、価値とコストを意図して選ぶべきです。 スイッチングコストを正しく理解したうえで、 必要であればロックインを選ぶ、という判断もあり得ます。

ロックインを恐れて価値を取り逃がすことの方が、はるかに大きなリスクです。 それが、このセッションの一貫したメッセージでした。

個人的な所感

同意はしつつも、今のところスイッチングコストをどう見積もればよいのか明確な指針があるわけではないので、納得しきれませんでした。

このセッションは、「ロックインを避ける設計」を選びそうになったときに、 一度立ち止まって考え直すための軸を与えてくれる内容でした。

この記事は私が書きました

河野 桂子

記事一覧

ヨシ！