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