In Silico

クラウド

仮想マシン・コンテナ・サーバーレスの違いと使い分けを解説

2026/10/13 シリーズ「クラウド入門」 第5回 / 全6回

🤖 AIを使用して執筆

  • 仮想マシン・コンテナ・サーバーレス
  • 仮想マシン
  • コンテナ
  • サーバーレス
  • クラウド
  • AWS Lambda
  • Kubernetes
  • Docker
  • ハイパーバイザー
  • コールドスタート
  • FaaS
  • Firecracker
  • Amazon EC2
  • Azure Functions
  • Cloud Run
  • Xen
  • Borg
  • AWS Fargate
  • AWS
  • Azure
  • Google Cloud
目次
背景・問い・要点
背景

クラウドで機械を借りても、借りたのが仮想マシンであれば、OS に更新を当て、台数を増減させ、壊れたら作り直すのは利用者の仕事である。この仕事を事業者に任せる方法として、コンテナを動かすサービスや、コードだけを渡すサーバーレスのサービスが広まった。ただ、任せる範囲を広げるほど、利用者が守らなければならない制約も増える。本稿は、仮想マシン、コンテナ、サーバーレスの三つを、仕組みと歴史、任せる範囲と増える制約、実際の利用の記録の順に取り上げ、処理の形ごとの使い分けを説明する。

問い

仮想マシン、コンテナ、サーバーレスは何が違うのか。どの処理に、どれを使えばよいのか。

要点

仮想マシンを借りる、事業者が管理する環境でコンテナを動かす、コードだけを渡す（サーバーレス）の順に、OS の更新や台数の管理は事業者へ移るが、実行時間の上限や、呼び出しの間で状態を保つことを前提にできないことなどの制約が増える。どれを選ぶとよいかは、主に処理の長さと、呼び出しの頻度とその偏りによる。 標準的な AWS Lambda の関数は 1 回の実行が最大 15 分で、新しい実行環境を作るときには、起動の準備にかかる時間（コールドスタート）が足される。Azure Functions の 2019 年の実測では、アプリの 45% が平均で 1 時間に 1 回以下しか呼ばれていなかった。まばらに呼ばれる短い処理にはサーバーレスが合い、長い処理や、絶えず大量に流れる処理には、コンテナや仮想マシンが合うことが多い。

モデル・例示

図書館の三つの処理

※ この節の数値は説明のための仮定で、測定値ではありません。

市の図書館が、三つの処理をクラウドで動かしているとする。

  • 蔵書の検索サイト：開館中も閉館後も、市民が本を探しに来る。一日中、ひっきりなしに多くのリクエストが届く。
  • 本の表紙の写真の縮小：職員が新しく入った本の表紙を撮って置くと、一覧に出すための小さな画像を作る。写真が置かれるのは一日に数十回で、置かれない時間のほうが長い。
  • 貸し出しの集計：毎晩、その日の貸し出しの記録を集計し、統計を作る。処理には 40 分ほどかかる。

三つは、動く時間の長さも、呼び出しの頻度とその偏りも違う。表紙の写真の縮小をサーバーレスで動かすと、写真が置かれるたびに、次のことが起きる。

  1. 職員ストレージ1. 新しい本の表紙の写真を置く
  2. ストレージ職員2. 置けたと返す
  3. ストレージ縮小の関数3. 写真が置かれたことを知らせる
  4. 縮小の関数4. 動いている環境がなければ、起動の準備から始める
  5. 縮小の関数ストレージ5. 写真を読み、小さな画像を作って書き込む
※概念図（やりとり）：本文の手順を図式化したもの。

図書館の職員は、縮小の関数のためにサーバーを用意していない。写真が置かれたときだけ関数が動き、動いた時間の分だけ料金がかかる。その代わり、しばらく写真が置かれなかった後の最初の 1 枚では、関数の起動の準備にかかる時間（コールドスタート）が足される。毎晩 40 分かかる集計は、標準的な AWS Lambda の関数の実行時間の上限である 15 分を超えるので、そのままでは動かせない。

仮想マシン：機械を OS ごと借りる

NIST（米国国立標準技術研究所）の 2011 年の指針は、仮想化を、ほかのソフトウェアが動く土台となるソフトウェアやハードウェアを模倣することと定義し、模倣された環境を仮想マシンと呼んでいる1。仮想マシンの中では、OS とアプリが仮想のハードウェアの上で動き、物理的な機械の上の複数の仮想マシンを、ハイパーバイザーが管理する1。ハイパーバイザーは、仮想マシンと物理的な CPU やメモリやディスクとの間を取り持ち、それぞれの仮想マシンが基本的には自分の資源にだけ触れるよう切り離せる（分離する）。ホストのファイルのような共有の資源に触れさせることもある1。

仮想マシンを借りる場合、OS から上は利用者が管理する。AWS は、Amazon EC2 の利用者の責任として、ゲスト OS（仮想マシンの中の OS）と、その上のソフトウェアの管理を挙げ、そこに更新とセキュリティの修正を含めている2。

仮想マシンの考え方は、クラウドよりずっと前からある。Popek と Goldberg は 1974 年、どのような計算機なら仮想化できるかの条件を論文にまとめた3。2003 年には、ケンブリッジ大学の Barham らが、普通のパソコンと同じ種類の CPU（x86）を積んだ機械の上で、手を加えた Linux を複数同時に動かし、仮想化しない場合と比べた性能の低下を数 % に抑えたハイパーバイザー Xen を発表した4。x86 はもともと完全な仮想化を前提に設計されておらず、Xen は動かす OS の側に手を加えることで、この制約を避けた4。AWS の初期の EC2 も Xen を土台にしていた5。2017 年の C5 以降の新しい種類では、Linux に組み込まれたハイパーバイザー（KVM）を基にした軽いハイパーバイザーと、処理を専用のカードに移す Nitro System を使っている5。

コンテナ：OS を共有し、アプリと部品をまとめる

コンテナは、仮想マシンとは別の方法で、複数のアプリを一つの機械に載せる。NIST の 2017 年の指針によれば、仮想マシンはハイパーバイザーによってハードウェアの水準で分離され、それぞれが完全な OS を持つ。コンテナでは、複数のアプリが一つの OS のカーネルを共有しながら、アプリどうしは分離される6。カーネルを共有するので、Linux の上では Linux 用のコンテナしか動かない6。AWS は、コンテナ化を、アプリのコードを、動かすのに必要なファイルやライブラリ（共通の部品のプログラム）と一緒にまとめて配る方法と説明している7。

NIST は、運用の面での仮想マシンとの根本的な違いの一つを、作ったコンテナを後から変えない使い方（イミュータブル、変更しないという意味）に見ている6。仮想マシンは、作った後も設定を変え、更新を当てながら使い続けることが多い。コンテナは、中身を変える必要があれば、変更を加えたコンテナを新しく作り、動いているものと入れ替える6。そのため、データはコンテナの外に置き、コンテナを入れ替えても消えないようにする6。コンテナの中のライブラリの更新も、更新した部品でコンテナを作り直して入れ替える。カーネルは共有しているので、その更新はコンテナを動かしている機械の側で行う。

その代わり、分離は仮想マシンより弱い。NIST は、コンテナもかなり強く分離されるが、カーネルを共有するので、ハイパーバイザーが仮想マシンを分離するほどのはっきりした境界にはならないと書いている6。

コンテナの考え方も、新しいものではない。FreeBSD の Jail は、一つの OS の中を区切り、管理者の権限が及ぶ範囲を区画の中に限る仕組みで、2000 年の FreeBSD 4.0 で入った8。NIST によれば、Jail のように OS 全体を区切る仕組み（OS コンテナ）は、Linux では 2008 年に LXC として使えるようになった。NIST は、これを、アプリとその部品をまとめるコンテナとは別のものとしている6。2013 年 3 月には、当時の dotCloud 社の Solomon Hykes が、社内で使っていた Linux のコンテナの仕組みを Docker として発表した9。2014 年 6 月、Google は、検索から Gmail まで社内のすべてをコンテナで動かし、毎週 20 億を超えるコンテナを起動していると書いたうえで、多数の機械にコンテナを配って動かす Kubernetes を公開した10。Google の社内でクラスタを管理してきた Borg は、2015 年に論文で説明され、その運用で得た教訓を Kubernetes の設計に生かしたと書かれている11。2015 年 6 月には、コンテナの形式の標準を作る Open Container Initiative が発足している12。

サーバーレス：コードだけを渡す

サーバーレスでは、利用者は機械も OS も扱わない。AWS は 2014 年 11 月、AWS Lambda をプレビューとして公開した13。Lambda は、サーバーを用意したり管理したりせずにコードを動かせるサービスで、サーバーの保守、台数の用意、規模の増減、修正の適用を AWS が行う14。料金は、使った資源の分だけかかる14。

カリフォルニア大学バークレー校の Jonas らは 2019 年の報告で、サーバーレスを、関数を実行するサービス（FaaS）と、データの保存などを担う裏側のサービス（BaaS）を合わせたものと定義した15。そのうえで、従来の使い方との違いを三つ挙げている15。

「サーバーレス」という名前について、同じ報告は、サーバーを使って計算していることに変わりはないので矛盾した名前だが、利用者はコードを書くだけで、サーバーの用意と管理を事業者に任せられるという意味で定着したのだろうと書いている15。

Azure と Google Cloud にも同じ種類のサービスがある。Microsoft は、Azure Functions をサーバーレスの仕組みと説明している16。Google Cloud の Cloud Run では、コードや関数やコンテナを、事業者が管理する環境で動かせる17。リクエストが来なくなると、Cloud Run は動いている台数を 0 台まで減らす。これを「ゼロまで縮む」という17。

サーバーレスとコンテナの境目は、製品の上でははっきりしない。AWS Fargate はコンテナを動かすサービスだが、AWS の技術者は論文の中で、Lambda と並ぶサーバーレスの計算サービスと呼んでいる18。

任せる範囲と、増える制約

利用者が管理する範囲は、仮想マシンかコンテナかだけでは決まらない。OS の更新や台数の管理を事業者に任せるサービスを使うかどうかで変わる。仮想マシンを借りる場合、事業者が機械を管理するサービスでコンテナを動かす場合、サーバーレスの関数を使う場合の三つを並べると、利用者が管理する範囲はこの順に狭くなる。Jonas らも、サーバーレスと、従来のサーバーを借りる使い方を一続きの両端とし、Kubernetes のようなコンテナを編成する仕組みをその間に置いている15。

この三つは、IaaS・PaaS・SaaS とは別の軸の分け方である。IaaS・PaaS・SaaS は、借りたサービスのどの層まで利用者が管理するかで分ける。仮想マシン・コンテナ・サーバーレスは、計算をどんな形で動かすかで分ける。二つの軸が交わるのは、OS を誰が管理するかという点である。NIST の定義では、OS を利用者が管理するのが IaaS、OS を含む基盤を利用者が管理しないのが PaaS である19。この定義に当てはめると、次のようになる。

動かし方NIST の定義に当てはめると
仮想マシンを借りるIaaS
自分の仮想マシンでコンテナを動かすIaaS（OS は利用者が管理する）
事業者が OS を管理する環境でコンテナを動かすPaaS
サーバーレスの関数を使うPaaS

SaaS では、出来上がったアプリを使うだけなので、どの形で動かすかを利用者が選ぶことはない。

任せる範囲が広がる代わりに、利用者が守らなければならない制約が増える。Lambda の場合、標準的な関数の 1 回の実行は最大 15 分、使えるメモリは最大 10,240 MB である20。AWS は、Lambda を、呼び出しの間で状態を保つことを前提にしない、短い計算のために作っていると書いている20。

起動の準備にかかる時間もある。関数の新しい実行環境を作るとき（しばらく呼ばれなかった後など）は、コードを取ってきて実行環境を整えるところから始める。これがコールドスタートである。AWS によれば、コールドスタートは典型的には呼び出しの 1% 未満で起き、長さは 100 ミリ秒未満から 1 秒を超えるものまである。呼ばれる頻度の低い関数ほど、コールドスタートは多くなる。この時間にも料金がかかる21。起動の時間をそろえたい場合は、あらかじめ環境を用意しておく設定を勧めている21。Cloud Run も、ゼロまで縮んだ後の最初のリクエストは、応答が遅くなることがあると書いている17。

この制約が、どれだけの処理に効くのか。Microsoft の Shahrad らは、Azure Functions で 2019 年 7 月の 2 週間に動いた、すべての処理を調べた22。平均で 1 時間に 1 回以下しか呼ばれないアプリが 45%、1 分に 1 回以下のアプリが 81% あった22。関数の半分は、平均の実行時間が 1 秒未満で、各社が報告しているコールドスタートの時間と同じ桁だった22。原典は、まばらに呼ばれるアプリが多いので、それらをすぐ動ける状態で待たせておく費用は、課金される実行時間に比べて法外に高くなりうると書いている22。逆に、平均で 1 分に 1 回以上呼ばれる 18.6% のアプリが、呼び出し全体の 99.6% を占めていた22。

Jonas らの報告も、サーバーレスの落とし穴として、費用の予測が難しいことと、特定の事業者から離れにくくなることを挙げている15。

処理の形ごとの使い分け

処理の形ごとに見ると、合う方式は次のように違う。

判断の主な軸は二つある。一つは処理の長さで、標準的な Lambda の関数では、1 回の実行が 15 分を超える処理をそのまま動かせない。もう一つは呼び出しの頻度とその偏りで、まばらで波のある処理ほどサーバーレスの、使った分だけ払う利点が大きくなり、絶えず大量に流れる処理ほど、常に動かしておく方式のほうが費用を見通しやすい。ほかに、分離の強さや、特定の事業者から離れにくくなることも、選ぶときの論点になる。

製品の名前でいえば、仮想マシンは AWS の Amazon EC2 などである23。事業者が機械を管理するコンテナの実行環境には AWS Fargate や Google Cloud の Cloud Run があり1817、サーバーレスの関数には AWS Lambda や Azure Functions がある1416。

制約は消えていくのか：2019 年の予測と、その後の報告

サーバーレスの制約が、どこまで本質的なものかについては、2019 年に同じ大学から出た二本の論文が、強調の置き所を違えて論じている。

カリフォルニア大学バークレー校の Hellerstein らは「一歩前進、二歩後退」と題した論文で、2018 年秋の Lambda を調べ、実行時間の上限や、関数どうしが S3 のような遅いストレージのサービスを通してしかやり取りできないことを挙げた24。そのため、関数はデータのところへ行くのではなく、データを関数のところへ運ぶことになり、当時のサーバーレスは、データを扱う仕組みの新しい開発には特に向かないと結論した24。ただし、開発者の自由より運用の柔軟さを優先するという考え方そのものは、クラウドの伸縮に欠かせないと認めており、挙げた課題を越えれば、クラウドの大きな可能性が開けるとも書いている24。

Jonas らの報告は、この論文を、自分たちの一部も加わった、課題と機会を論じる仕事として引いている（著者のうち 3 名が両方の論文に名を連ねる）15。Jonas らは、こうした問題は解決できるとし、サーバーレスがクラウドの計算の標準になり、従来の使い方の比重は下がると予測した15。費用についても、サーバーレスのほうが高くなる根本の理由はないので、料金の仕組みが変わり、ほとんどの処理がサーバーレスで同じかそれより安くなると予測している15。

その後、制約の一部は緩んだ。分離の強さと軽さについては、AWS の Agache らが 2020 年、分離は強いが重い仮想化と、軽いが分離の弱いコンテナのどちらかを選ぶという従来の見方に対して、軽い仮想マシンを作る Firecracker を発表した18。最初の Lambda は、関数の間をコンテナで、利用者のアカウントの間を仮想化で分離していた。論文の著者ら（AWS）は、2020 年の時点で、Firecracker が Lambda と AWS Fargate で月に数兆のリクエストを扱っていると報告している18。実行時間の上限も、一部で延びた。2026 年 10 月の AWS の文書では、標準の関数は Hellerstein らが調べた 2018 年秋と同じ 15 分のままである。一方、Lambda Managed Instances という使い方では、非同期の呼び出しなど一部の呼び出し方に限って、最大 90 分まで動かせる20。Lambda MicroVMs では、動いている時間と止めている時間を合わせて最大 8 時間の環境を使える25。標準の関数にも、途中の進み具合を記録しながら、最長 1 年にわたる多段の処理を続けられる Lambda Durable Functions という使い方が加わった25。

一方で、制約に当たって方式を変えた報告もある。Amazon Prime Video の技術ブログは 2023 年、動画の品質を監視する仕組みを、AWS Step Functions（複数の処理を順につなぐサービス）と Lambda で組んだ分散の構成から、一つのプログラムにまとめた構成へ移したと報告した26。最初の構成は早く作るには良い選択だったが、一部のサービスの使い方のせいで、想定の負荷の 5% ほどで規模の限界に当たり、処理の段階を移るごとにかかる料金も重かった26。一つのプログラムにまとめて Amazon EC2 と Amazon ECS（AWS のコンテナを動かすサービス）で動かした結果、基盤の費用は 90% 以上下がったという26。分散をやめて一つにまとめた変更でもあるので、この削減のすべてをサーバーレスかどうかの違いに帰すことはできない。同じ記事は、サーバーレスを使うかどうかは場合ごとに決めるべきだとも書いている26。

Jonas らの予測が当たるかどうかは、本稿で集めた資料では判定できない。言えるのは、制約の一部は緩んだものの、標準の関数の 1 回の呼び出しの上限と、呼び出しの間で状態を保つことを前提にできないことは変わっていない、ということである。処理の長さと呼び出しの頻度で合う方式が分かれるのは、今も同じである。そして、コンテナやサーバーレスを使うなら、データは計算の外に置くことになる。コンテナは作り直して入れ替え、サーバーレスの関数は呼び出しの間で状態を保つことを前提にできないからである。計算から切り離したデータを、どこに、どのような形で置くのかが、次の問いである。

出典26件

  1. K. Scarfone, M. Souppaya, P. Hoffman「Guide to Security for Full Virtualization Technologies」NIST SP 800-125、2011年1月、2026年10月13日取得. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-125.pdf — 仮想化、仮想マシン、ハイパーバイザーの定義。 ↩ ↩2 ↩3

  2. AWS「Amazon EC2 のセキュリティ」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-security.html — ゲスト OS の更新とセキュリティの修正は利用者の責任。 ↩

  3. G. J. Popek, R. P. Goldberg「Formal requirements for virtualizable third generation architectures」CACM 17(7)、1974年7月、2026年10月13日取得. https://doi.org/10.1145/361011.361073 — 書誌のみ確認。 ↩

  4. P. Barham ほか「Xen and the Art of Virtualization」SOSP 2003、2026年10月13日取得. https://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf — 手を加えた OS を同時に動かすハイパーバイザーと、x86 と完全な仮想化。 ↩ ↩2

  5. AWS「The Nitro System journey」（The Security Design of the AWS Nitro System）2026年10月13日取得. https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-nitro-system-journey.html https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/traditional-virtualization-primer.html — 2017年の C5 からの KVM を基にしたハイパーバイザー。初期の EC2 の Xen の dom0 は primer の頁。 ↩ ↩2

  6. M. Souppaya, J. Morello, K. Scarfone「Application Container Security Guide」NIST SP 800-190、2017年9月、2026年10月13日取得. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf — カーネルの共有、イミュータブルな運用、分け方の強さ、OS コンテナとしての LXC。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  7. AWS「コンテナ化とは?」2026年10月13日取得. https://aws.amazon.com/jp/what-is/containerization/ — アプリとライブラリをまとめて配る方法。 ↩

  8. P.-H. Kamp, R. N. M. Watson「Jails: Confining the omnipotent root.」2000年、2026年10月13日取得. https://papers.freebsd.org/2000/phk-jails.files/sane2000-jail.pdf — OS の中の区画と FreeBSD 4.0。 ↩

  9. PyVideo「Lightning Talk - The future of Linux Containers」（PyCon US 2013）2026年10月13日取得. https://pyvideo.org/pycon-us-2013/the-future-of-linux-containers.html — 2013年3月15日の発表。 ↩

  10. Google Cloud Platform Blog「An update on container support on Google Cloud Platform」2014年6月10日、2026年10月13日取得. https://cloudplatform.googleblog.com/2014/06/an-update-on-container-support-on-google-cloud-platform.html — 社内のコンテナの規模と Kubernetes の公開。 ↩

  11. A. Verma ほか「Large-scale cluster management at Google with Borg」EuroSys 2015、2026年10月13日取得. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ https://research.google.com/pubs/archive/43438.pdf — Google の社内のクラスタ管理。運用の教訓を Kubernetes の設計に生かしたと §8。 ↩

  12. Open Container Initiative「About the Open Container Initiative」2026年10月13日取得. https://opencontainers.org/about/overview/ — 2015年6月22日の発足。 ↩

  13. AWS News Blog（Jeff Barr）「AWS Lambda – Run Code in the Cloud」2014年11月13日、2026年10月13日取得. https://aws.amazon.com/blogs/aws/run-code-cloud/ — プレビューの公開。 ↩

  14. AWS「AWS Lambda とは」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html — サーバーの管理なし、修正の適用、従量制の課金。 ↩ ↩2 ↩3

  15. E. Jonas ほか「Cloud Programming Simplified: A Berkeley View on Serverless Computing」UCB/EECS-2019-3、2019年2月10日、2026年10月13日取得. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf — 定義、三つの違い、両端と中間、落とし穴、予測、同僚の論文の位置づけ。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  16. Microsoft「Azure Functions の概要」2026年10月13日取得. https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-overview — サーバーレスの仕組み。 ↩ ↩2

  17. Google Cloud「Cloud Run とは」2026年10月13日取得. https://cloud.google.com/run/docs/overview/what-is-cloud-run?hl=ja — 事業者が管理する実行環境、ゼロまで縮むことと最初のリクエストの遅れ。 ↩ ↩2 ↩3 ↩4

  18. A. Agache ほか「Firecracker: Lightweight Virtualization for Serverless Applications」NSDI 2020、2026年10月13日取得. https://www.usenix.org/system/files/nsdi20-paper-agache.pdf — 軽い仮想マシン、Lambda と Fargate での利用。 ↩ ↩2 ↩3 ↩4

  19. IPA 訳「NIST によるクラウドコンピューティングの定義」2011年12月掲載、2026年10月14日取得. https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000buyd.pdf — IaaS と PaaS で利用者が管理する範囲。 ↩

  20. AWS「Lambda クォータ」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html — 最大 15 分（900 秒）と 10,240 MB、状態を保たない短い計算。 ↩ ↩2 ↩3

  21. AWS「Understanding the Lambda execution environment lifecycle」2026年10月13日取得. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html — コールドスタートの頻度と長さ、呼ばれる頻度の低い関数で多いこと、その時間の課金。 ↩ ↩2

  22. M. Shahrad ほか「Serverless in the Wild」USENIX ATC 2020、2026年10月13日取得. https://www.usenix.org/system/files/atc20-shahrad.pdf — Azure Functions の呼び出しの頻度とその偏り、実行時間。 ↩ ↩2 ↩3 ↩4 ↩5

  23. AWS「Amazon EC2 とは」2026年10月13日取得. https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/concepts.html — 仮想サーバーの起動。 ↩

  24. J. M. Hellerstein ほか「Serverless Computing: One Step Forward, Two Steps Back」CIDR 2019、2026年10月13日取得. https://www.cidrdb.org/cidr2019/papers/p119-hellerstein-cidr19.pdf — 2018年秋の Lambda の制約。 ↩ ↩2 ↩3

  25. AWS「What is AWS Lambda?」2026年10月13日取得. https://docs.aws.amazon.com/lambda/latest/dg/welcome.html https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html — Lambda MicroVMs の最長 8 時間の環境と、Durable Functions の最長 1 年の多段の処理。 ↩ ↩2

  26. Prime Video Tech（Marcin Kolny）「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」2023年3月22日、2026年10月13日取得（アーカイブ）. https://web.archive.org/web/20231230202019id_/https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 — 移行と費用。 ↩ ↩2 ↩3 ↩4

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。