Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
跳到主要内容

扩展 AWS Landing Zone

随着 AWS 扩展其全球基础设施，组织需要一种结构化的方法来将其云业务扩展到新区域。随着 AWS 推出新区域，组织正在寻求扩展其业务范围。本指南概述了扩展 AWS Organization 或 Landing Zone 的关键注意事项和最佳实践。

构建基础​

建立具有全面治理控制的强大云基础不仅是最佳实践，更是当今动态云环境中的关键必需品。从一开始就投入时间建立强大治理框架的组织，在扩展、适应和维护安全方面会处于更有利的位置。可以将其比作建造房屋：没有坚实的基础，任何添加或修改都会变得越来越危险和复杂。云治理控制，包括 Service Control Policies (SCPs)、护栏和合规框架，充当着确保云基础设施保持安全、合规和可管理的架构蓝图和建筑规范。在扩展到新区域时，已有这些控制使扩展过程更加精简和安全。组织通常会发现，事后改造治理控制比在初始设置期间实施它们要困难得多且资源密集得多。这种主动的治理方法不仅有助于防止安全事件和合规违规，还提供了在保持运营卓越性的同时适应不断变化的业务需求的灵活性。

组织优先方法与 Control Tower：关键区别​

在扩展到新区域时，客户根据其现有设置有两条主要路径。AWS Organizations 提供了一种手动但高度灵活的方法，允许对实施细节进行精细控制。此路径需要手动配置每个服务和自定义实施 Service Control Policies，但为特定需求提供了最大的灵活性。相比之下，AWS Control Tower 通过 Account Factory 以及预构建的治理控制和标准化护栏提供了更精简、自动化的方法。Control Tower 显著简化了多账户设置过程，但可能不如纯 Organizations 方法灵活。这些路径之间的选择通常取决于您现有的基础设施和特定的治理要求。

治理和安全控制​

在扩展到新 AWS 区域时，一个好消息是某些基础服务（如 CloudTrail 和 AWS Billing）会自动将新区域纳入其现有配置。CloudTrail 在配置为所有区域时，会在新区域对您的账户可用时自动开始记录 API 活动，无需额外设置。同样，AWS Billing 自动跨所有活跃区域合并成本，通过 AWS Cost Explorer 和 AWS Bills 提供统一的成本管理和报告。

然而，需要注意的是，虽然这些服务会自动适应，但其他安全和运营服务（如 Service Control Policies、GuardDuty、Security Hub 和 AWS Config）仍然需要明确的区域启用，以确保对扩展范围的全面覆盖。

访问控制​

AWS Identity and Access Management (IAM) 是那些"设置后即可忘记"的全球服务之一，在整个 AWS 范围内都能正常工作。当您扩展到新区域时，您现有的 IAM 用户、角色和策略已经准备就绪——无需额外配置！就像您的安全团队在您到达之前已经驻扎在新地点一样。您现有的 IAM 主体将自动拥有与其他区域相同的权限（假设您的策略不包含特定于区域的限制）。IAM 的全球特性是一个巨大的时间节省器，有助于在不断增长的 AWS 范围内维护一致的访问控制。请记住——虽然 IAM 是全球性的，但某些基于资源的策略和服务关联角色可能需要区域性考虑，因此请将其纳入您的扩展检查清单。

Service Control Policies​

如果您使用 AWS Control Tower，有一个好消息——内置护栏及其关联的 Service Control Policies (SCPs) 将在 Control Tower 中启用新区域后自动将其保护扩展到该区域。就像有一支自动部署的安全力量！然而，如果您使用自定义 SCPs（无论在 Control Tower 还是 AWS Organizations 中），您需要手动更新这些策略以包含新区域。这对于使用区域特定控制或允许区域声明的策略尤其重要。例如，如果您有一个明确列出允许区域的 SCP，您需要将新区域添加到该列表中，例如：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowedRegions",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotLike": {
                    "aws:RequestedRegion": [
                        "ap-southeast-2",
                        "ap-southeast-4"  // Adding Asia Pacific (Melbourne) region
                    ]
                }
            }
        }
    ]
}

如果不进行这些更改，您的团队可能会疑惑为什么无法启动资源。请记住先在非生产环境中测试这些策略更新——我们始终希望将对客户的影响降到最低。

AWS Config​

与 Service Control Policies 类似，当您使用 AWS Control Tower 时，AWS Config 会获得 VIP 待遇——它会在 Control Tower 支持新区域后自动启用和配置。可以把它想象成 Config 获得了前往新区域的头等舱机票！规则、聚合器和记录器会自动出现。然而，如果您通过 Organizations 运行 AWS Config 而没有 Control Tower，您需要手动铺设这条路。这意味着您需要在新区域启用 Config、部署您的规则（别忘了自定义规则！），以及设置聚合器（如果您使用它们的话）。许多客户使用 CloudFormation StackSets 来自动化此过程。请记住，无论是自动还是手动，维护一致的 AWS Config 覆盖对于您的治理和合规需求至关重要！

更多安全服务​

让我们深入了解 AWS 安全服务以及扩展到新区域时需要了解的内容。与全球范围的 IAM 不同，大多数 AWS 安全服务需要区域性部署策略——可以把它想象成在您运营的每个地点开设新的安全办公室。

首先，让我们谈谈安全梦之队：GuardDuty、Security Hub、Macie 和 Detective。这些服务中的每一个都需要在新区域中明确启用。这不是"原样迁移"的情况——您需要有意识地启用每个服务。但有趣的是，对于 Organizations——您的委托管理员账户设置实际上是全球性的。一旦您将某个账户指定为安全服务的委托管理员，该账户就会在所有区域维持其特殊权限。

然而，仍然有工作要做。即使有委托管理员账户，您仍需要在新区域启用每个安全服务。例如，对于 Security Hub，您的委托管理员账户需要在新区域启用该服务，然后配置从成员账户聚合发现结果。GuardDuty 也是如此——虽然您的委托管理员指定会延续，但您需要在新区域启用威胁检测并相应地配置成员账户。

专业提示：许多构建者使用 AWS CloudFormation StackSets 或其他工具来自动化此区域启用过程。我们发现自动化是跨区域维护一致安全控制的关键。考虑创建一个"新区域安全引导"模板，用于启用和配置所有必需的安全服务——未来的您会感谢自己的！

别忘了区域聚合！如果您使用 Security Hub 或 GuardDuty 作为中央安全监控工具，您需要配置跨区域聚合以维护单一视图。好消息是，一旦您设置了委托管理员账户并在新区域启用了服务，将其添加到聚合配置通常只需几次点击。

获得可见性​

让我们谈谈一些经常被忽视但在扩展到新区域时需要注意的非常重要的服务。在规划区域扩展时，别忘了您的运营可见性工具——它们也需要关注。Resource Explorer，我们便捷的统一搜索服务，需要您将新区域添加到聚合器设置中，以维护所有 AWS 资源的合并视图。同样，IAM Access Analyzer，您的权限守护者，需要在新区域启用并添加到聚合配置中，以维护全面的权限洞察。别忘了 CloudWatch Logs！如果您使用跨账户、跨区域的集中式日志记录，您需要更新日志路由和复制设置以包含新区域。专业提示：许多构建者创建一个集中式日志账户，并使用 CloudWatch Logs 跨区域可观测性接收器来维护单一信息源。我们建议将这些聚合配置记录在您的区域扩展运行手册中——未来的您会感谢自己将所有这些步骤放在一个地方！

还缺少什么？​

在跳入新区域之前，让我们谈谈您的 AWS 服务清单——它比听起来更有趣。从成功的区域扩展反向思考，您需要创建 AWS 服务使用范围的全面评估。不要只考虑明显的服务——当然，我们已经介绍了组织服务、安全和合规工具、监控和日志配置，您也了解 EC2 和 S3。但那些几个月前设置的 Route 53 健康检查、AWS Backup 计划或 AWS Private Certificate Authorities 呢？创建一个包含核心基础设施和支持服务的服务检查清单。专业提示：使用 AWS Resource Explorer 或 AWS Config 来帮助发现您当前使用的所有服务——您可能会发现一些被遗忘的宝藏！对于每个服务，记录它是全球性的、区域性的还是需要特定的区域配置。这个评估将成为您的扩展手册，确保您在跨区域维护一致功能的同时避免"哎呀，我们忘了那个服务"的情况。请记住，一个规划周密的区域扩展就是一个成功的区域扩展！

关于 Landing Zone 的话题​

让我们深入了解 AWS landing zone 的概念以及主区域的重要作用——这对于管理多区域部署的人来说是至关重要的知识！

可以将您的 AWS Landing Zone 视为您的云总部，主区域作为您的总办公室。当您首次设置 AWS Control Tower 或实施自定义 Landing Zone 解决方案时，您需要选择一个主区域——这个决定比许多人意识到的更为重要。就像插上一面旗帜说"这是我们核心配置所在的地方！"

在您的主区域中，Control Tower 及其管理组件等关键服务会安营扎寨。这包括 Account Factory 配置、审计日志存档、部署流水线和其他基础服务。当您将 Landing Zone 扩展到新区域时，您实质上是在开设分支办公室，同时将总部保留在原始主区域。新区域继承治理控制并可以完全使用，但主要配置和管理组件保留在主区域中。

这就是有趣的地方——说有趣，其实是有挑战性的！移动 Landing Zone 的主区域不像更改默认 AWS 控制台区域那么简单。更像是在保持业务正常运行的同时将公司总部搬到新城市。您需要退役和重新部署核心服务、重新配置日志聚合、重新构建组织配置，以及可能重建自动化流水线。许多这些服务，如 Control Tower 的配置数据、审计日志和 AWS Organizations 管理，都与主区域紧密耦合。

让我们描绘一下移动主区域通常涉及的内容：

  • 在当前主区域退役 Control Tower
  • 重新配置核心账户结构
  • 退役和重新部署 IAM Identity Center 配置
  • 重建日志和审计架构
  • 重新部署自动化和流水线配置
  • 重新构建跨账户和跨区域服务配置
  • 迁移历史数据和存档

这就是为什么选择主区域是那些"量两次、切一次"的决定之一。我们建议选择符合长期地理战略和合规要求的主区域。虽然扩展到新区域很简单，但移动 Landing Zone 的主区域是一项重大工作，需要仔细规划和执行。

专业提示：在设计 Landing Zone 时，彻底记录您的主区域依赖关系。即使您从未计划移动它，了解这些关系也将帮助您在扩展到新区域时做出更好的架构决策。请记住，您的主区域选择不会限制您在其他区域运营的能力——它只是您 AWS 环境的控制中心。

结论​

总之，将您的 AWS Landing Zone 或 Organization 扩展到新区域需要深思熟虑的规划和对 AWS 服务区域行为的全面理解。我们涵盖了关键方面：从基础治理控制和安全服务到运营可见性工具和 Landing Zone 注意事项。请记住，虽然一些服务（如 IAM 和 CloudTrail）会自动拥抱新区域，但其他服务需要明确的启用和配置。您的扩展之旅应以详尽的服务清单和对 Landing Zone 主区域影响的清晰理解为指导。通过遵循这些最佳实践和注意事项，您将能够在不断扩展的 AWS 范围内维护一致的安全性、合规性和运营卓越性。成功的关键在于充分准备、理解特定服务的要求以及维护强大的治理基础。随着 AWS 继续扩展其全球基础设施，这些原则将作为您未来区域扩展的指南针。