ベンダーロックイン・ポータビリティ べんだーろっくいん・ぽーたびりてぃ
簡単に言うとこんな感じ！
特定のクラウドサービスに深く依存して、別のサービスに移りにくくなる状態がベンダーロックイン。ポータビリティはその逆で、どこにでも持っていける設計のこと。移行コストと利便性はトレードオフなんだよ。
ベンダーロックイン・ポータビリティとは
ベンダーロックイン（Vendor Lock-in）とは、特定のクラウドベンダーが提供する独自機能・サービス・APIに強く依存した結果、別のベンダーへの移行が困難・高コストになる状態を指します。たとえばAWS固有のDynamoDBやLambdaを多用したシステムは、AzureやGCPへの移行に大規模な改修が必要になります。
ポータビリティ（Portability）とは、システムやデータを異なるクラウド間・環境間で容易に移動・利用できる性質です。コンテナ（Docker）やKubernetesのような標準化された技術は、ポータビリティを高めます。
ロックインを恐れてクラウドの便利な固有機能を一切使わない設計は現実的ではありません。「どこまでのロックインを許容するか」をビジネス要件に基づいて意識的に判断することが重要です。
ロックインの種類
| ロックインの種類 | 説明 | 例 |
|---|---|---|
| 技術的ロックイン | ベンダー固有のAPIや技術に依存 | AWS固有のDynamoDBクエリ |
| データロックイン | データの取り出しが困難・高コスト | データ転送費（エグレスコスト） |
| プロセスロックイン | 運用・管理プロセスがそのベンダー前提 | AWS CLIのスクリプト |
| コントラクトロックイン | 長期契約や大量割引で乗り換えコストが高い | 3年Savings Plans |
ロックイン度の高低
| 低ロックイン（ポータブル） | 高ロックイン（固有依存） |
|---|---|
| EC2（汎用VM） | AWS Lambda（FaaS） |
| MySQL on RDS | DynamoDB（NoSQL独自） |
| Kubernetes（EKS） | ECS（AWS固有オーケストレーション） |
| S3互換オブジェクトストレージ | S3 Select（独自クエリ） |
歴史と背景
1970〜80年代のメインフレーム時代から、IBMやDECなどの独自アーキテクチャへの依存は問題でした。2000年代のSAPなどERPパッケージでも同様の議論がありました。
クラウドでは2010年代前半、AWS一択という状況への懸念からマルチクラウド戦略が注目されました。2014年にDockerが普及し、2017年頃からKubernetesが事実上の標準になったことで、コンテナを使ったポータブルな設計が現実的になりました。
2022年以降は、生成AIサービス（AWS Bedrock・Azure OpenAI・Vertex AI等）の登場でAI機能のロックインという新しい問題も浮上しています。
ロックインとポータビリティのトレードオフ
関連する規格・RFC
| 規格 | 内容 |
|---|---|
| ISO/IEC 19941 | クラウドコンピューティングの相互運用性とポータビリティ |
| TOSCA（OASIS） | クラウドアプリケーションのポータブルな記述言語 |
| OCI（Open Container Initiative） | コンテナイメージ・ランタイムの標準仕様 |
関連用語
- マネージドサービス — 利便性とロックインのバランスを考える起点
- 責任共有モデル — クラウド選択の判断に影響する概念
- Well-Architected Framework — ロックインリスクを考慮した設計指針
- マルチアカウントネットワーク設計 — マルチクラウド設計の応用