レガシーとクラウドネイティブを比較するとき、多くの解説は「サービスの機能」から入る。S3とは何か、Lambdaとは何か、という説明である。
しかし機能の説明だけでは、「なぜこの設計になっているのか」という腹落ちが起きない。本稿では、AWSが公式に示す情報をもとに、レガシーとクラウドネイティブの間にある設計思想の違いを、機能ではなく前提の違いとして読み解く。
ページ構成
- 暗黙の上限と、明示的な上限
- 全体像
- ファイル：階層で辿るか、キーで指すか
- 計算：常駐させるか、呼ばれた時だけ動かすか
- データ：行で持つか、列で持つか
- ログ：サーバーに溜めるか、外に流すか
- 結論：操作の発想から、設計の発想へ
1. 暗黙の上限と、明示的な上限
レガシーの世界には物理的な上限があった。ディスク容量、メモリ、CPU、ネットワーク帯域。これらは暗黙のガードレールとして機能していた。ディスクが一杯になれば止まる。メモリが足りなくなれば落ちる。上限を意識して設計しなくても、物理が勝手に止めてくれた。
クラウドにはその物理的な上限がない。ストレージは容量無制限。計算リソースは同時に数千並列で動く。止めるものは、自分で決めない限り存在しない。
だからクラウドでは、「どこで止めるか」を自分で設計しなければならない。決めなければ、リソースは際限なく使われ、コストが発散する。実行時間の制限、保持期間の設定、処理量の上限——これらは全て「ここまで」という境界を明示的に設計する行為である。
レガシーでは上限は暗黙の前提だった。クラウドでは、上限は設計対象になる。
2. 全体像
この前提の違いは、AWSのいくつかの代表的なサービスに共通して表れている。
ここで誤解しやすいのは、「小規模だからレガシーでいい」という考え方である。これは規模の問題ではない。そもそも、自分が扱うデータの量を自分でコントロールできるか、という問題である。
アクセスログ、CDNログ、APIの呼び出し履歴——これらは利用者の数とアクセス頻度によって勝手に増えていく。「今は少ないから大丈夫」は何の保証にもならない。後から前提を変える移行コストは、最初から前提を変えておくコストよりずっと高い。
3. ファイル：階層で辿るか、キーで指すか
レガシーのファイルストレージは、ディレクトリを階層的に辿って目的のファイルに到達する。オブジェクトストレージ（S3）には、その階層構造が実体として存在しない。見えている「フォルダ」は表示上の見せ方であり、実体は1本のキー文字列である。
実はこの方式は珍しいものではない。Google Drive、Dropbox、iCloud——日常的に使っているクラウドストレージは、すべてオブジェクトストレージである。「フォルダ」に見えているものは、裏側ではフラットなキーとメタデータで管理されている。ファイルを少し編集して保存しただけで、ファイル全体がアップロードし直されるのを見たことがあるはずだ。それが、オブジェクトストレージが「部分更新ができない」という性質そのものである。
4. 計算：常駐させるか、呼ばれた時だけ動かすか
EC2（サーバー）は、OSを常時起動させ、その中でプロセスを常駐させる思想である。使っていない時間も含めて、動いている時間に対して課金される。
Lambda（関数）は逆に、「必要な瞬間だけリソースを借りて、終わったら返す」という思想である。
この違いは状態の持ち方にも表れる。サーバーは状態をディスクに保持できるが、関数は状態を持てない。状態を外部（S3やDynamoDBなど）に出すことが、関数をいくつでも同時に動かすための前提条件になる。
5. データ：行で持つか、列で持つか
RDBMSは行単位でデータを格納し、インデックスを使って特定の1行に高速に到達する。データレイク（S3+Athena）は列単位でデータを格納し、パーティションで読む範囲を絞り込んで集計する。
この違いは得意・不得意を生む。RDBMSは特定の1行をピンポイントで取得・更新するのが得意だが、数億行になると全件集計が遅くなる。データレイクは大量データの集計が得意だが、特定の1行だけを探して書き換えるという操作には向いていない。
データレイクでは、データは基本的に追記（イミュータブル）が前提になる。誤りがあれば、修正済みのデータで丸ごと置き換えるか、修正レコードを追記して後段の集計で最新を採用する設計にする。
6. ログ：サーバーに溜めるか、外に流すか
ログファイルはサーバーのローカルディスクに溜まる。サーバーが死ねば、ログも一緒に消える。複数サーバーを横断して見たければ、自分で集約する仕組みが必要になる。
CloudWatch Logsのようなログストリームは、サーバーの生死に関係なくログが残り、横断検索も最初からできる。YouTubeのライブ配信を思い出すとわかりやすい。「ファイルをダウンロードして再生する」のではなく、「流れてくるものをリアルタイムに受け取る」。ログも同じ発想で、流れてくるデータを受け取り、過去に遡って検索する。
7. 結論：操作の発想から、設計の発想へ
AWSを学ぶときの第一歩は、個々のサービスの使い方を覚えることではない。
レガシーの仕組みは「1台のマシンの中で完結する」という前提で設計されている。クラウドネイティブの仕組みは「マシンは無数にあり、いつ消えてもいい」という前提で設計されている。
この前提の違いを理解しないまま個々のサービスを覚えても、「なぜこうなっているのか」は腹落ちしない。