例如，在 AWS 中，当我启动一个新的 EC2 实例时，它会加载一个新的 VM，然后使用容器映像填充 VM。这就是启动新 EC2 实例需要 60-90 秒才能启动的原因。
出于好奇，让 AWS 按原样运行主机有什么缺点，当用户想要“启动 EC2 实例”时，AWS 只是启动一个具有受限权限的容器，并且只允许用户访问那个容器？
好处是计算实例会很快启动。我还在学习云技术，所以我只是想知道有什么缺点。
不使用虚拟机可能更难分配 CPU 资源？结果，用户会互相争夺可用的CPU吗？或者可能存在一些安全问题？很想了解这一点。
容器通常只运行一个应用程序并且是不可变的，也就是说，更改不会在重启后保留。容器也没有自己的内核。
另一方面，虚拟机运行整个操作系统，包括内核、初始化脚本、系统守护进程等。并且存储通常在重启后保留。
虚拟机和容器有不同的用途——谷歌搜索“虚拟机与容器”之类的东西，互联网上有很多。
如果您想在 AWS 中将 Container 作为服务运行，而不必担心底层虚拟机，请查看AWS Fargate - 这正是您想要的。
希望有帮助:)
您的问题是，在某种程度上，向后看：EC2 不是碰巧使用虚拟机的通用托管解决方案；它是托管虚拟机的服务。因此，有几种方法可以解释您的问题。
为什么 EC2 不是为使用容器而设计的？
这个问题的答案可以从时间轴上推断出来：EC2 于 2006 年推出 beta 版，2008 年全面量产；Docker 直到 2013 年才公开发布，而 Kubernetes 是 2015 年。
容器技术在 EC2 推出时正在开发中——BSD 已经有“监狱”，Linux 有某种形式的命名空间隔离——但它并不是我们今天所熟悉的成熟生态系统。另一方面，虚拟专用服务器是一个成熟的概念——VMWare 在 2002 年明确推销 ESX 用于托管服务，Xen 虚拟机管理程序于 2003 年紧随其后，同年推出了Linode 。EC2 的创新是使用这种成熟技术按需启动虚拟服务器的系统。
为什么 EC2 没有从 VM 迁移到容器？
尽管在某些方面可以将容器视为“轻量级 VM”，但这并不是一个完整的描述，两者不可互换。虚拟机旨在给用户一种他们正在访问物理服务器的错觉，并可以完全控制整个系统；网络等资源以虚拟硬件的形式呈现，用户可以根据需要直接与之交互。容器呈现出更有限的抽象，应用程序通常与容器本身的配置绑定得更紧密，例如只转发特定的网络端口。
多年来，亚马逊增加了许多服务，但对于淘汰客户所依赖的旧服务非常保守。因此，他们确实提供了许多基于容器而非虚拟机的服务，例如ECS（弹性容器服务，2014 年推出）、Fargate（2017 年推出）和EKS（弹性 Kubernetes 服务，2018 年推出）；但如果用户仍在使用它，他们不太可能淘汰 EC2。
为什么用户还没有迁移到容器服务？
鉴于基于容器的云托管已经可用，为什么人们仍然选择使用 EC2 等基于 VM 的服务？
我认为有几个原因；想到的几个：
因此，尽管容器继续流行起来，但它们还没有完全取代虚拟服务器，而且可能永远也不会。因此，EC2 和类似的基于 VM 的云托管服务将继续存在。
安全绝对是一个原因。容器在它们和主机之间共享相同的内核。因此，它们不被认为是 100% 隔离的。
然而，云提供商也确实提供了容器。AWS 也这样做。我想容器比虚拟机便宜，但我没有检查过。
本质上，您要问的是一个更笼统的话题，VM 与容器；无论平台如何，都适用相同的优缺点。
容器有几种不同的方法，当前接受的答案似乎只考虑了 OCI 样式（类似 docker）的容器。还有许多其他类型的容器，例如 LXC 和 BSD jails，它们有不同的方法。
例如，LXC 可以轻松包含多个应用程序，并且默认情况下是可变的。它还具有初始化脚本和系统守护进程（systemd 等）。
CPU、RAM 和磁盘空间资源的分配可以通过容器轻松完成。
配置容器不是即时任务（但可以比“60-90 秒”更快），因为您仍然需要获取映像、提取并启动它。
安全性是我提到的所有容器解决方案的主要关注点，因为它们都共享一个内核。尽管采取了许多安全措施，但偶尔仍会发现漏洞。如果你和你的朋友有一个共享的服务器，并且你们都有容器，那么你可能会很安全，但是对于像亚马逊这样的大型供应商（有大量企业使用他们的服务）来说，这可能很重要安全问题。
例如，如果您查看AWS Fargate 网站，它指出其容器的许多资源没有共享，从这方面来看，它比传统的自托管容器更接近虚拟机：
我想指出的最后一个问题是兼容性。由于您对内核（也可能是您的系统调用）的访问受到限制，因此您无法执行某些任务，例如加载 dkms 模块或执行 sysctl 配置。并非所有应用程序都会在其中运行，但那些往往是例外而不是常态。
容器有很多有效的用例（类似 OCI 和类似 LXC），而且它绝对不是一个“万能的解决方案”。不必运行整个内核并进行其他类型的虚拟化（图形、音频、网络等）确实会减少很多开销，但也必须考虑使用容器的缺点，其中一些我已经在我的回答中提到。