从 2024 年 11 月开始，Amazon Web Service (AWS) GameLift 开始支持完全托管的容器。Edgegap 和其他公司曾指出，该平台多年来一直缺乏原生容器支持（参见 Edgegap 之前的报道）。这使得开发人员能够使用容器（如 Docker 的容器），在 GameLift 的编排上部署其游戏服务器，以托管和扩展多人游戏服务器。

让我们来剖析一下，更重要的是，探讨引入容器是否足以有意义地改善多人游戏编排和玩家的在线游戏体验。

什么是用于多人游戏的 AWS GameLift 容器

通过使用与 GameLift 编排集成的 Amazon Elastic Container Service (ECS)，游戏开发人员可以管理波动的玩家负载并简化部署。

这种设置允许开发人员自定义游戏托管环境、实现自动扩展并处理多人游戏必不可少的复杂网络需求。

GameLift 还支持玩家對局配對和会话管理，并提供了优化玩家体验的工具。借助这种基于容器的架构，开发人员获得了运营灵活性，可以更专注于游戏玩法，而减少对基础设施的关注。

在用于多人游戏的 GameLift 上使用 ECS 容器时需要仔细关注什么

AWS GameLift 支持容器，但对于专注于降低托管成本和最大化玩家体验的游戏工作室，该设置的几个方面值得仔细权衡，即分配、扩展、区域分布、對局配對和集成复杂度。

分配

分配是指游戏服务器在虚拟机 (VM) 上占用了多少空间。虽然 AWS 确实记录了每个容器组的 vCPU 和内存分配，但游戏工作室需要付出巨大的集成努力，这意味着在实践中优化虚拟机的游戏服务器“填充”并最大化每个 vCPU 的使用率仍然可能是一个挑战。

这种经常被忽视的复杂性意味着工作室最终可能会为未使用的容量买单，并增加管理回填的 DevOps 成本。

GameLift 的架构还需要预热虚拟机以使容器准备好启动，这意味着必须始终保留一部分集群容量作为缓冲区。将此缓冲区设置得太低可能会导致长时间的轮候延迟，从而影响玩家体验。值得注意的是：根据 Edgegap 对 GameLift 定价的分析，GameLift 的默认缓冲区有记录为 10%（在发布前，请与当前的 AWS GameLift 文档确认，因为默认值可能会更改），一些工作室发现这低于他们应对多变或突发玩家需求所需的水平。流量不均匀的工作室通常会增加此值，这会提高运行其集群的实际成本。您可以使用 Edgegap 的计算器来比较在不同的流量场景下，缓冲区容量的选择如何影响整体托管成本。

如果服务器由于缓冲区配置错误而导致超载，玩家可能会遇到延迟和掉帧，这可能会损害工作室期望从专用服务器编排中获得的价值。

在 Edgegap，我们致力于让游戏开发人员能够优化其游戏服务器并细分其 vCPU 使用率，以降低其整体成本。

扩展

GameLift 的确实涵盖了容器集群的扩展，包括通过控制台或 SDK 进行基于目标的自动扩展。然而，对于希望优化容器集群扩展行为的工作室来说，在实践中仍有几个问题未得到充分记录，尤其是扩展如何与实例级别的容器预热相互作用。

如果容器在实例上预先启动，GameLift 如何确定何时进行扩展，因为容器已经消耗了实例资源？如果容器是动态部署的，在实践中有多快（垂直扩展），以及它如何在多个区域同时表现（水平扩展）？

Edgegap 提供动态容器部署，根据 Edgegap 的 2023 年性能基准测试，在该测试中，在 60 分钟内支持了多达 40 次的游戏服务器部署（截至撰写本文时）。AWS 是 Edgegap 的提供商之一，Edgegap 还利用 16 个提供商（截至撰写本文时）在其需要的位置垂直扩展您的游戏。

此外，根据 Edgegap 的自身测量，Edgegap 的“冷启动”服务器部署平均约为 3 秒（截至撰写本文时），这意味着玩家可以有更多的时间玩游戏，而减少等待游戏服务器部署的时间。与使用其他平台的开发人员通常报告的较长冷启动时间相比，这具有明显优势。

Edgegap 还会根据需求将您的游戏服务器部署到其全球 615 个以上的地点（截至撰写本文时）。虽然在 AWS 美东区域为美国东海岸的玩家进行扩展很有用，但游戏托管通常需要在全球范围内进行上下扩展，以便为全球玩家提供良好的在线游戏体验。

区域分布

公共云（包括 AWS GameLift）使用自动扩展、按实例计费的模型：您需要为每个区域的整个虚拟机付费，无论游戏服务器是否在上面积极运行。

许多 AA 和 Triple-I 工作室发现为了使延迟足够低，以确保其玩家群体获得良好的玩家体验，他们需要大约 10 个区域。您想要建立存在感（presence）的每个区域都是您需要配置并付费的独立单区域集群。

这里的结构性成本驱动因素不是带宽（请参阅本文末尾关于 AWS 2026 年 6 月带宽变更的说明），而是单区域集群中的整实例取整。因为 GameLift 是按实例收费，而不是按玩家或每个会话收费，所以一个服务少量会话的集群仍然需要支付完整的实例费用，而无论需求如何，小型区域都至少需要一台 VM 的最低配置。在多区域布局中，这种预留的单区域容量可能会使托管费用成倍增长，这远远超出了实际游戏会话的原始成本。Edgegap 的定价页面提供了直接对比。

粗略估计，Edgegap 对一款具有中等数千峰值并发用户规模的代表性撤离类射击游戏进行了比较建模，该游戏分布在 gen6 (c6i.4xlarge) 实例的大约 10 个区域。在 Edgegap 的模型中，按需付费方案的成本约为每月 20,600 美元，而在相同场景下，模拟的 AWS GameLift gen6 成本约为 27,600 美元，Edgegap 估计差异约为 34%。这些 AWS 数据是 Edgegap 使用 AWS 公布的按实例费率模拟的，而不是开具账单的 AWS 数据，仅用于说明目的：实际的 AWS 账单会因实例组合、Spot（竞价）或节省计划（Savings Plans）以及单区域取整而异。在 AWS 方面，主要的模拟成本驱动因素是单区域集群的整实例取整，而不是网络传输。

用于游戏服务器托管的新编排服务（如 Edgegap）改为采用按需付费模式。这意味着您只需在玩家玩游戏时（在部署期间）在全球范围内付费。这标志着与传统公有云编排所要求的预留容量定价模式相比，发生了一次有意义的转变。

此外，由于 Edgegap 接入了庞大的边缘网络，在该案例研究中，Edgegap 测得平均延迟降低了 58%（截至撰写本文时），相较于传统的公有云编排设置。

与對局配對 / 大厅一起使用

另一个考虑因素是您的對局配對系统或大厅需要挑选出最佳位置。您必须在您的對局配對系统中创建多个区域，并且如果您试图降低延迟（通过在 AWS 中添加区域），您的對局配對排队时间可能会变长，因为您将无法轻松进行跨区域對局。

Edgegap 的對局配對系统是默认情况下少有的具有原生基于延迟参数的對局配對系统之一（截至撰写本文时），这有助于您为玩家部署具有最低延迟的游戏服务器。

集成与使用的简便性

AWS 针对此设置的自主入驻文档涵盖了多本指南，其中包括 ECS、ECR、CodeBuild 和 CloudFormation 配置，这反映了建立生产就绪级容器集群所涉及的真正复杂性。

完成所有配置本身就是一项艰巨的任务，而且一旦集成工作完成，这仅仅只是个开始。您通常需要至少一名工程师或 DevOps 专业人员来监控和管理流量的起伏波动。

游戏服务器“准时（just in time）”的方法可以加载在部署期间完全自定义的数据（如用户生成的内容 (UGC)），从而避开了许多这类复杂性。例如，《费卢杰六日》（Six Days in Fallujah）在游戏服务器部署期间加载其程序生成的地图，同样的，HIBERWORLD 也会为其众多 UGC 开发的游戏类型和地图执行此操作。

容器对 AWS GameLift 来说足够吗？

对于当前正在使用 GameLift 且希望迁移到容器以获得更简化工作流的游戏，这对于他们的情况可能就足够了。

如果您想要一个更灵活的解决方案，让您能够以“即用即付”的准时制方式利用数百个地点，而无需自己管理基础设施，那么新一代的游戏服务器编排服务（包括 Edgegap）非常值得考虑。

关于 AWS GameLift 2026 年 6 月网络带宽变更的说明

在阅读任何成本对比时，需要考虑的一项重要定价更新：自 AWS 2026 年 6 月 15 日的更新起，第 6 代或更新版本（c6、m6、c7 和 m7 实例系列）的 Amazon GameLift 服务器实例将免费包含出站网络带宽，除中国以外的所有区域均适用。这适用于 Windows 和 Linux、竞价（Spot）和按需（On-Demand），无需任何承诺。AWS 官方发布的示例显示，在 1000 个并发玩家的 gen6 集群上，一旦从账单中扣除带宽费用，总成本可降低约 34%。

为了准确起见，有几点需要理清。这仅适用于 gen6 及更新的系列；较旧的系列（如 gen5 C5 系列）不包括在内，因此运行较旧实例类型的工作室仍会产生带宽费用。由于这一变化，在与 gen6 GameLift 集群进行成本对比时，不应将网络带宽视为 AWS 账单的一部分。对于 gen6 集群，相关的成本考虑因素是预留的单区域实例容量和整实例取整，而不是流出。有关最新详情，请直接参见 AWS 的公告和 GameLift 定价页面。这是一项有时效性的内容；我们建议随着 AWS 定价的演变进行定期重新审查。