亚马逊云科技（AWS）已将其欧洲主权云服务（European Sovereign Cloud）推向全面可用，该服务在物理和逻辑上分离的基础设施上投资了78亿欧元。该服务现已在德国勃兰登堡州提供，旨在应对欧洲的监管要求以及对美国访问数据的日益增长的地缘政治担忧。尽管 AWS 强调，该云服务将完全由欧盟居民在新的德国母公司结构下运营，但关于这种分离是否真的能抵御美国政府的数据请求，仍存在重大疑问。

该基础设施使用分区名称 aws-eusc 和区域名称 eusc-de-east-1，完全独立于 AWS 的全球区域运行。所有组件，包括专用的 IAM、计费系统和使用欧洲顶级域名的 Route 53 名称服务器，都保留在欧盟境内。AWS 欧洲主权云有限责任公司（AWS European Sovereign Cloud GmbH）是一家成立的德国母公司，拥有三个子公司，分别负责基础设施、证书管理和就业，负责运营。欧盟公民Stéphane Israël担任总经理，与 AWS 德国和中欧副总裁Stefan Hoechbauer一起担任董事总经理。

一位将服务部署到欧洲主权云的 AWS 软件开发工程师证实了技术隔离在实践中的存在。该工程师在 Hacker News 上写道：

AWS 已经在欧洲主权云（ESC）和全球 AWS 之间建立了适当的界限。由于我在美国，我看不到 ESC 中的任何活动，即使是我们开发的服务。为了解决这个问题，我们必须与 ESC 中的工程师进行电话沟通……所有数据确实 100%保留在 ESC 中。

该工程师还警告要注意权衡，指出隔离“确实减慢了调试问题的速度。本来一两天就能解决的问题可能需要一个月。”

尽管存在这种技术隔离，从业者和分析师对法律保护提出了根本性的担忧。独立技术顾问 Sam Newman 在 LinkedIn 上写道：

除非我误解了美国的爱国者法案（这是可能的），否则新的欧盟 AWS 主权云服务并不能保护客户数据免受美国政府的访问。所以我不太确定这是为了什么，除了公司想要支付（我假设）溢价，让自己看起来像是在面对更不稳定的美国政权做些事情。

ICT 解决方案协调员 Marko Teklic 也表达了类似的担忧，他指出，根据外国情报监视法和CLOUD法案，AWS 作为一家总部位于美国的公司，仍然受美国对其欧洲业务的管辖。CLOUD 法案允许美国当局无论云服务提供商的物理位置如何，都可以要求云服务提供商提供数据。法院可以要求母公司提供子公司持有的数据，这可能使 AWS 欧洲主权云有限责任公司的独立结构在法律上不足。

Reddit 上的一位评论者概述了这种机制：

该法案适用于“所有在美国运营或在美国合法存在的电子通信服务或远程计算服务提供商。”法院可以要求母公司提供其子公司持有的数据。

一些人认为 AWS 的结构可能会提供保护。一位 Hacker News 用户建议，在欧洲的治理下，亚马逊可以告诉美国政府，欧盟员工拒绝遵守数据请求，因为这样做将违反欧盟法律。怀疑论者反驳说，AWS 可以通过向当地员工模糊命令或临时派遣美国员工到欧洲来绕过这一点。

从业者提出了 AWS 尚未回答的尖锐问题。S. Maud 在 Jeff Barr 的 LinkedIn 帖子上询问，如果美国政府针对存储在主权云中的军事行动数据发出 CLOUD 法案令状，AWS 是否会遵守。Sebastian Vogelsang 对远程干预提出了技术性担忧：

什么阻止了远程关闭开关？如果 AWS 公司或美国政府指示禁用这个基础设施，有什么技术或法律机制可以阻止这一点？软件堆栈是完全独立的，还是依赖于可能从欧盟外部撤销的许可证、更新或控制平面？

软件信任问题超出了运营范围。虽然 Hacker News 评论者指出，AWS 的 Nitro 虚拟化团队设在柏林，但人们对更广泛的 AWS 软件堆栈仍然存在疑问。是否对后门进行过审计？在美国开发的代码是否包含了远程访问机制？

当被问及 AWS 欧洲主权云是否类似于 AWS 的中国区域时，首席云架构师 Ivo Pinto确认这是“甚至比 govcloud 更好的比较”。然而，有一个关键区别：AWS 中国通过独立的中国公司（Sinnet 和 NWCD）运营，而 AWS 欧洲主权云完全由 Amazon.com Inc.拥有。

CarMax 的 Eric Swanson 解释了这一服务的实际效果：

美国所有权和总部意味着，无论基础设施在哪里运行，美国法律仍然可以适用于提供商。主权云服务并不凌驾于爱国者法案之上。它们主要减少了在其他背景下的重叠：数据位置、运营控制、员工访问和客户管辖区。

在没有美国所有权的情况下寻求主权的组织可以在欧洲找到替代方案，包括德国提供商 Hetzner、法国提供商 Scaleway、瑞士提供商 Infomaniak，以及 StackIT by Schwarz Digits（Lidl 的母公司），许多在 LinkedIn 和 Reddit 上的评论者强调这些是真正的欧洲主权云选项。

该服务推出了大约 90 个 AWS 服务，计划通过在比利时、荷兰和葡萄牙的主权本地区域进行扩展。AWS 预计 7.8 亿欧元的投资将在 20 年内为欧洲经济贡献 172 亿欧元。

AWS 现在的竞争对手是微软和谷歌云与泰雷兹开发的 S3NS。Mark Surrow 在 LinkedIn 上指出，微软“不得不在法国法院直接承认”它不能保证欧盟客户的数据主权。一个根本性的问题仍然存在：任何美国所有的主权云能否在 CLOUD 法案和 FISA 下保护欧洲数据免受美国政府访问？在 AWS 回答这个问题之前，有严格主权要求的组织可能会寻找其他地方。

原文链接：

https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/

亚马逊云科技（AWS）已将其欧洲主权云服务（European Sovereign Cloud）推向全面可用，该服务在物理和逻辑上分离的基础设施上投资了78亿欧元。该服务现已在德国勃兰登堡州提供，旨在应对欧洲的监管要求以及对美国访问数据的日益增长的地缘政治担忧。尽管 AWS 强调，该云服务将完全由欧盟居民在新的德国母公司结构下运营，但关于这种分离是否真的能抵御美国政府的数据请求，仍存在重大疑问。

该基础设施使用分区名称 aws-eusc 和区域名称 eusc-de-east-1，完全独立于 AWS 的全球区域运行。所有组件，包括专用的 IAM、计费系统和使用欧洲顶级域名的 Route 53 名称服务器，都保留在欧盟境内。AWS 欧洲主权云有限责任公司（AWS European Sovereign Cloud GmbH）是一家成立的德国母公司，拥有三个子公司，分别负责基础设施、证书管理和就业，负责运营。欧盟公民Stéphane Israël担任总经理，与 AWS 德国和中欧副总裁Stefan Hoechbauer一起担任董事总经理。

一位将服务部署到欧洲主权云的 AWS 软件开发工程师证实了技术隔离在实践中的存在。该工程师在 Hacker News 上写道：

AWS 已经在欧洲主权云（ESC）和全球 AWS 之间建立了适当的界限。由于我在美国，我看不到 ESC 中的任何活动，即使是我们开发的服务。为了解决这个问题，我们必须与 ESC 中的工程师进行电话沟通……所有数据确实 100%保留在 ESC 中。

该工程师还警告要注意权衡，指出隔离“确实减慢了调试问题的速度。本来一两天就能解决的问题可能需要一个月。”

尽管存在这种技术隔离，从业者和分析师对法律保护提出了根本性的担忧。独立技术顾问 Sam Newman 在 LinkedIn 上写道：

除非我误解了美国的爱国者法案（这是可能的），否则新的欧盟 AWS 主权云服务并不能保护客户数据免受美国政府的访问。所以我不太确定这是为了什么，除了公司想要支付（我假设）溢价，让自己看起来像是在面对更不稳定的美国政权做些事情。

ICT 解决方案协调员 Marko Teklic 也表达了类似的担忧，他指出，根据外国情报监视法和CLOUD法案，AWS 作为一家总部位于美国的公司，仍然受美国对其欧洲业务的管辖。CLOUD 法案允许美国当局无论云服务提供商的物理位置如何，都可以要求云服务提供商提供数据。法院可以要求母公司提供子公司持有的数据，这可能使 AWS 欧洲主权云有限责任公司的独立结构在法律上不足。

Reddit 上的一位评论者概述了这种机制：

该法案适用于“所有在美国运营或在美国合法存在的电子通信服务或远程计算服务提供商。”法院可以要求母公司提供其子公司持有的数据。

一些人认为 AWS 的结构可能会提供保护。一位 Hacker News 用户建议，在欧洲的治理下，亚马逊可以告诉美国政府，欧盟员工拒绝遵守数据请求，因为这样做将违反欧盟法律。怀疑论者反驳说，AWS 可以通过向当地员工模糊命令或临时派遣美国员工到欧洲来绕过这一点。

从业者提出了 AWS 尚未回答的尖锐问题。S. Maud 在 Jeff Barr 的 LinkedIn 帖子上询问，如果美国政府针对存储在主权云中的军事行动数据发出 CLOUD 法案令状，AWS 是否会遵守。Sebastian Vogelsang 对远程干预提出了技术性担忧：

什么阻止了远程关闭开关？如果 AWS 公司或美国政府指示禁用这个基础设施，有什么技术或法律机制可以阻止这一点？软件堆栈是完全独立的，还是依赖于可能从欧盟外部撤销的许可证、更新或控制平面？

软件信任问题超出了运营范围。虽然 Hacker News 评论者指出，AWS 的 Nitro 虚拟化团队设在柏林，但人们对更广泛的 AWS 软件堆栈仍然存在疑问。是否对后门进行过审计？在美国开发的代码是否包含了远程访问机制？

当被问及 AWS 欧洲主权云是否类似于 AWS 的中国区域时，首席云架构师 Ivo Pinto确认这是“甚至比 govcloud 更好的比较”。然而，有一个关键区别：AWS 中国通过独立的中国公司（Sinnet 和 NWCD）运营，而 AWS 欧洲主权云完全由 Amazon.com Inc.拥有。

CarMax 的 Eric Swanson 解释了这一服务的实际效果：

美国所有权和总部意味着，无论基础设施在哪里运行，美国法律仍然可以适用于提供商。主权云服务并不凌驾于爱国者法案之上。它们主要减少了在其他背景下的重叠：数据位置、运营控制、员工访问和客户管辖区。

在没有美国所有权的情况下寻求主权的组织可以在欧洲找到替代方案，包括德国提供商 Hetzner、法国提供商 Scaleway、瑞士提供商 Infomaniak，以及 StackIT by Schwarz Digits（Lidl 的母公司），许多在 LinkedIn 和 Reddit 上的评论者强调这些是真正的欧洲主权云选项。

该服务推出了大约 90 个 AWS 服务，计划通过在比利时、荷兰和葡萄牙的主权本地区域进行扩展。AWS 预计 7.8 亿欧元的投资将在 20 年内为欧洲经济贡献 172 亿欧元。

AWS 现在的竞争对手是微软和谷歌云与泰雷兹开发的 S3NS。Mark Surrow 在 LinkedIn 上指出，微软“不得不在法国法院直接承认”它不能保证欧盟客户的数据主权。一个根本性的问题仍然存在：任何美国所有的主权云能否在 CLOUD 法案和 FISA 下保护欧洲数据免受美国政府访问？在 AWS 回答这个问题之前，有严格主权要求的组织可能会寻找其他地方。

原文链接：

https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/

亚马逊云科技最近宣布为S3 Tables引入两项新功能，第一项功能是新的智能分层存储类，该存储类能够根据访问模式自动优化成本，第二项功能是支持跨 AWS 区域和账户自动维护一致的Apache Iceberg表副本的复制功能，该过程无需手动同步。

智能分层存储类会将数据自动分配到最具成本效益的三个低延迟层级之一，即 Frequent Access、Infrequent Access 或 Archive Instant Access。据公司介绍，最后一种是最低成本的层级，比 Infrequent Access 层级便宜 68%。亚马逊云科技的主任开发者倡导者 Sebastian Stromacq 这样写到：

在无访问达 30 天后，数据会被移动到 Infrequent Access 层级，在 90 天后，则会迁移到 Archive Instant Access 层级，这一过程不会对应用程序造成影响或性能降低。

默认情况下，表使用标准存储类，但创建表时可以指定智能分层（Intelligent-Tiering）作为存储类，用户也可以在表存储桶级别配置默认存储类。用户可以将智能分层设置为表存储桶的默认存储类，如果在创建表时未指定存储类，那么表将自动存储在智能分层中。

用户可以利用AWS命令行界面（AWS CLI），通过 put-table-bucket-storage-class 和 get-table-bucket-storage-class 命令来更改或验证其 S3 表格存储桶的存储层级。相关命令如下所示：

aws s3tables put-table-bucket-storage-class \   --table-bucket-arn $TABLE_BUCKET_ARN  \   --storage-class-configuration storageClass=INTELLIGENT_TIERING# Verify the storage classaws s3tables get-table-bucket-storage-class \   --table-bucket-arn $TABLE_BUCKET_ARN  \{ "storageClassConfiguration":   {      "storageClass": "INTELLIGENT_TIERING"   }}

来自 Imperious Enterprise 的 AWS 架构师 Adefemi Adeyemi 在 LinkedIn 的帖子中指出：

大多数分析数据集在一段时间内是“热”的，但随后会逐渐“冷却”。借助 S3 Tables 的智能分层功能，你无需不断调整 Iceberg 数据的生命周期策略。该服务会根据访问模式自动将对象移至更便宜的存储层级，这对长期存在的数据湖来说是一大优势。

此外，S3 Tables 的复制功能可以帮助用户跨 AWS 区域和账户维护表格的一致性只读副本。当声明目标表格的存储桶时，服务会创建只读的副本表格，并以时间顺序复制所有更新，同时保持父子快照关系。这些副本表格将在源表格更新后的几分钟内得到更新，并支持独立于源表格的加密和保留策略。

Stromacq 说到：

用户可以通过Amazon SageMaker Unified Studio或任何兼容 Iceberg 的引擎（包括DuckDB、PyIceberg、Apache Spark和Trino）查询副本表格。

借助 AWS Management Console、API 或AWS SDK，用户可以创建和维护表格副本。此外，他们可以指定用于复制源表格的目标表格存储桶。当用户启用复制功能时，S3 Tables 会在这些存储桶中创建只读副本，使用最新状态进行回填，并持续监控更新以保持同步。

在同一篇 LinkedIn 帖子中，Adeyemi 指出：

对复制功能的原生支持让你能够快速创建只读副本，这些副本在几分钟内即可与源表保持同步，并且可作为 Iceberg 表进行查询。减少了自定义集成的工作量，让你有更多时间真正使用数据。

用户可以通过AWS Cost and Usage Reports和Amazon CloudWatch指标跟踪各访问层的存储使用情况。配置智能分层无需额外费用，用户仅需支付各层的存储成本。至于 S3 Table 的复制，用户需支付目标表格的 S3 Table 的存储费用、复制 PUT 请求的费用、表格更新（提交）以及复制数据的对象的监控费用。更多详情可参见定价页面。

原文链接：

 AWS Adds Intelligent-Tiering and Replication for S3 Tables

亚马逊云科技推出了Amazon EKS Capabilities，这是一套完全托管的、Kubernetes 原生特性，旨在简化工作负载编排、AWS 云资源管理以及 Kubernetes 资源组合和自动化。这些能力现在已在大多数 AWS 商业区域普遍可用，它将流行的开源工具捆绑到一个托管的平台层中，减轻了工程团队的运维负担，并在Amazon Elastic Kubernetes Service（EKS）上实现了更快的应用程序部署和扩展。

EKS Capabilities 集成了许多 Kubernetes 用户已经依赖的三个核心组件：Argo CD、AWS Controllers for Kubernetes（ACK）和Kube Resource Orchestrator（KRO），并在 AWS 拥有的基础设施中运行它们，这些基础设施与客户集群抽象隔离。Argo CD 提供声明式的持续部署和GitOps工作流，允许直接从版本控制同步资源和应用程序。ACK 通过自定义资源扩展 Kubernetes，用于直接在 Kubernetes API 内管理 AWS 服务，如S3、DynamoDB和RDS。KRO 提供了一个简化的机制，用于创建和管理组合的自定义资源，帮助平台团队定义可重用的、更高层次的抽象，而无需手动处理复杂的控制器逻辑。

通过将这些能力作为托管的 AWS 资源而不是集群内的插件提供，EKS Capabilities消除了用户自己安装、补丁、扩展或更新基础 Kubernetes 工具的需求。AWS 处理扩展、维护、安全补丁和兼容性升级，使平台工程师和开发人员能够更多地专注于交付业务逻辑，而不是管理平台组件。实际上，团队继续使用熟悉的接口如kubectl、GitOps 工作流和声明式清单与 Kubernetes 一起工作；不同的是，持续部署和资源编排等核心服务由 AWS 作为 EKS 平台的一部分提供和维护。

这种转变与云原生运维的更广泛趋势相一致，在云原生运维中，托管服务越来越多地吸收了无差别的繁重工作，使组织能够更容易地扩展 Kubernetes 的采用。平台团队可以将常规的基础设施集成卸载到 AWS 托管的能力中，同时保留原生的 Kubernetes 工作流，应用程序开发人员则从统一、一致的能力中受益，这些能力跨越了集群，而无需投资于定制的平台工具。通过 EKS 控制台、AWS CLI、eksctl或其他自动化工具启用 EKS 能力。当将 Argo CD、ACK 或 KRO 等能力添加到集群中时，它将作为 AWS 资源出现，可以像其他 AWS 服务一样进行标记、管理和监控。权限通过 AWSIdentity and Access Management（IAM）配置，对于 Argo CD 单点登录等功能，支持与 AWS IAM 身份中心的集成。AWS 还自动分析破坏性变更，并对活动功能应用更新或补丁，减少管理开销。

虽然每个功能都是独立且可选的，允许团队只启用他们需要的功能，但它们共同为 Kubernetes 环境提供了一个连贯、可扩展的平台层，融合了应用程序部署、AWS 资源控制和自定义资源组合。这种方法旨在缩短交付时间，最小化操作摩擦，并帮助组织在开发、测试和生产环境中大规模采用 Kubernetes。

这次更新引起了云和 DevOps 社区的共鸣。在Reddit上，实践者强调了托管 Argo CD 支持和集成的 AWS 资源管理的便利性，这是尝试新功能的令人信服的理由，特别是对于那些寻求统一 GitOps 工作流和资源配置而不进行手动插件管理的团队。同时，一些观察者指出，尽管托管能力减少了设置工作，但它们仍然需要 Kubernetes 专业知识和仔细的成本考虑，因为采用规模扩大，成本也被质疑是一个潜在的问题，因为许多团队可能已经有自己管理这些的方法，并且看不到为这项新的 AWS 功能支付额外费用的好处。

随着企业继续在混合云和多云环境中采用 Kubernetes，Amazon EKS Capabilities 通过将运维最佳实践嵌入到服务本身，代表了降低平台复杂性和加速云原生应用程序交付的一步。

https://www.infoq.com/news/2025/12/aws-eks-workload-orchestration/