手册

将 IT 支出从前期大量硬件采购转变为按需付费模式。

→利用云的基于消费的模型。

原因: 这将资本支出 (CapEx) 转换为可预测的运营支出 (OpEx)，从而无需进行数据中心采购和管理。

了解云提供商和客户之间安全和管理职责的划分。

→提供商负责云*的安全*；客户负责云*中的*安全。客户始终拥有他们的数据、身份和端点。

原因: 在 IaaS 中，客户管理 OS 及以上。在 PaaS 中，提供商管理 OS，客户管理应用程序和数据。在 SaaS 中，提供商管理除数据和访问配置之外的所有内容。

参考↗

根据控制、租户和位置要求选择部署模型。

→使用公共云（共享基础设施）、私有云（专用基础设施，本地或托管）或混合云（公共云和私有云的组合）。

原因: 混合云是保留本地系统以满足法规/延迟要求，同时利用公共云实现可扩展性和现代服务的关键。私有云提供最大程度的控制。

根据所需的管理控制级别选择合适的云服务模型。

→IaaS（例如 Azure VMs）提供对 OS 的最大控制。PaaS（例如 Azure App Service、Azure SQL）专注于代码，而非基础设施。SaaS（例如 Microsoft 365）提供即用型软件。

原因: 权衡在于控制与便利性。随着从 IaaS 转向 SaaS，提供商管理更多的堆栈，从而降低了客户的运营负担。

处理动态、不可预测的流量高峰与计划的、持续的增长。

→使用弹性 (Elasticity) 进行自动扩展（横向扩展/收缩），以匹配实时需求。使用可伸缩性 (Scalability) 进行计划的容量增加（横向扩展/纵向扩展），以处理预期增长。

原因: 弹性是自动化和反应式的，非常适合突发工作负载以优化成本。可伸缩性是增加容量的更广泛概念，可以是手动或自动的。

防止区域内的组件故障与灾难性的区域性中断。

→使用可用区实现高可用性 (HA) 以应对数据中心故障。使用跨区域复制（例如 GRS）实现灾难恢复 (DR) 以应对区域性灾难。

原因: HA 旨在以最小的中断维持服务。DR 旨在在重大中断后恢复服务。HA 通常通过快速故障转移实现自动化；DR 通常涉及正式的恢复过程。

为需要特定合规性和数据驻留的政府实体部署资源。

→使用主权云，例如 Azure Government。

原因: 这些是物理隔离的 Azure 实例，由经过筛选的人员管理，旨在满足严格的政府合规标准（例如 FedRAMP、DoD）。

设计一个能够抵御数据中心故障的弹性应用程序。

→在单个 Azure 区域内的多个可用区之间部署资源。

原因: 可用区是物理上独立的数据中心，拥有独立的电源、冷却和网络。这在区域内提供了高可用性，同时避免了跨区域部署的延迟。

参考↗

将相关的 Azure 资源分组，以便进行统一管理、访问控制和计费。

→将应用程序的所有资源放置在单个 Azure 资源组中。

原因: 资源组是元数据的容器。删除资源组会删除其中的所有资源，使其成为关键的生命周期管理边界。

为工作负载选择合适的计算服务。

→VMs (IaaS) 用于完全控制。App Service (PaaS) 用于 Web 应用/API。Azure Functions 用于事件驱动的无服务器代码。AKS 用于容器编排。ACI 用于简单的容器实例。

原因: 选择取决于控制、管理开销和架构模式（例如，单体、微服务、事件驱动）之间的权衡。

运行需要自动扩展、服务发现和滚动更新的复杂容器化微服务应用程序。

→使用 Azure Kubernetes Service (AKS)。

原因: AKS 是用于全面容器编排的托管 Kubernetes 服务。当您需要集群管理和复杂的服务交互时，请优先选择 AKS 而不是 ACI。

运行一个用于短期任务（例如批处理作业）的单个简单容器，而无需基础设施管理。

→使用 Azure 容器实例 (ACI)。

原因: ACI 是在 Azure 中运行容器最快、最简单的方式。它是无服务器的，按秒计费，非常适合不需要编排的任务。

建立从本地数据中心到 Azure 的专用、私有、高带宽连接。

→使用 Azure ExpressRoute。

原因: ExpressRoute 不经过公共互联网，与通过互联网隧道的 VPN Gateway 相比，提供了更高的可靠性、安全性和更低的延迟。

参考↗

根据网络级别规则与应用程序级别规则将流量分发到后端 VM。

→使用 Azure Load Balancer 进行第 4 层 (TCP/UDP) 分发。使用 Azure Application Gateway 进行第 7 层 (HTTP/HTTPS) 功能，例如 SSL 卸载和基于 URL 的路由。

原因: 当您需要根据 HTTP 标头、路径或主机名进行路由决策时，请选择 Application Gateway。对于非 HTTP 流量，Load Balancer 更简单、更快。

将全球 Web 流量路由到最佳后端，提供 CDN 缓存，并使用 WAF 进行保护。

→使用 Azure Front Door。

原因: Front Door 是一个全局入口点，在第 7 层运行，将全局负载平衡、CDN、WAF 和 DDoS 保护组合成一项单一服务。

存储海量的非结构化数据，例如图片、视频、备份和日志文件。

→使用 Azure Blob 存储。

原因: Blob 存储对于对象数据具有高度可扩展性和成本效益。它与 Azure 文件（用于 SMB 文件共享）和 Azure 磁盘存储（用于 VM 磁盘）不同。

根据数据的访问频率最小化存储成本。

→使用 Blob 存储访问层：热层（频繁访问）、冷层（不频繁访问）和存档层（罕见访问，长期保留）。

原因: 存档层存储成本最低，但访问成本和延迟最高（解冻需要数小时）。使用生命周期管理策略自动化分层。

选择数据复制策略以防范硬件、数据中心或区域故障。

→LRS（单个数据中心）、ZRS（一个区域内的可用区之间）、GRS（到次要区域）、GZRS（主区域中的 ZRS + 次要区域中的 LRS）。

原因: ZRS 可防止数据中心故障。GRS/GZRS 可防止区域性灾难。权衡是更高的成本以获得更大的弹性。

允许 VNet 中的 VM 访问 PaaS 服务（例如 Azure SQL 或存储），而流量不离开 Microsoft 网络。

→在 VM 的 VNet 中为 PaaS 服务创建专用终结点。

原因: 专用终结点为 PaaS 服务提供了来自您的 VNet 的私有 IP 地址，确保所有流量都通过私有的 Microsoft 主干网络而非公共互联网传输。

将本地 Windows 文件服务器迁移到可通过 SMB 协议访问的托管云服务。

→使用 Azure 文件。

原因: Azure 文件提供完全托管的文件共享，可由云或本地 VM 装载，直接替代传统文件服务器。

跨多个 Azure 订阅应用治理（策略、RBAC）和管理访问。

→将订阅组织成管理组层次结构。

原因: 管理组是订阅之上的范围。在管理组级别应用的策略和角色分配会被其中所有订阅继承。

参考↗

强制执行组织标准，例如限制部署到特定区域或要求所有资源都带有标签。

→使用 Azure Policy。

原因: Policy 对资源配置强制执行规则。这用于治理，而 RBAC 控制用户权限（操作）。

区分控制用户操作和控制资源属性。

→使用基于角色的访问控制 (RBAC) 定义用户可以执行的操作（例如，“参与者”可以创建 VM）。使用 Azure Policy 定义允许的配置（例如，“VM 只能是 D 系列大小”）。

原因: RBAC 关注“谁能做什么”。Policy 关注“允许什么”。它们协同工作以实现全面的治理。

保护关键生产资源免遭意外删除，即使是管理员也不例外。

→对资源或其资源组应用 `CanNotDelete` 资源锁。

原因: 资源锁会覆盖 RBAC 权限。所有者在明确移除锁之前不能删除被锁定的资源。`ReadOnly` 锁可防止任何修改。

对资源进行逻辑组织，以进行成本跟踪、自动化或所有权识别。

→将标签（键值对）应用于资源。

原因: 标签是用于跨资源组过滤和分组资源的元数据，可实现强大的成本分析和管理。

应用于资源组的标签未在其内部资源上显示。

→标签不会自动从资源组继承。每个资源都必须显式标记。

原因: 要强制执行标签继承，请使用具有“修改”或“DeployIfNotExists”效果的 Azure Policy 从父资源组追加标签。

估算未来的 Azure 成本与计算本地迁移带来的节省。

→使用定价计算器估算特定 Azure 服务的成本。使用总拥有成本 (TCO) 计算器比较本地成本与 Azure 成本。

原因: 定价计算器适用于全新部署或添加新服务。TCO 计算器用于构建迁移的商业案例。

跟踪当前的 Azure 支出、设置支出警报并发现节省机会。

→使用 Azure 成本管理。创建预算以在达到支出阈值时触发警报。

原因: 预算提供主动的支出通知，有助于防止成本超支。成本管理分析有助于识别支出异常和趋势。

降低可预测的、持续运行的工作负载（例如 VM 或数据库）的成本。

→购买 1 年或 3 年期的 Azure 预留实例或节省计划。

原因: 预留实例通过长期承诺，比即用即付定价提供显著折扣（高达 72%）。非常适合稳定状态工作负载。

以可重复、一致的方式部署 Azure 基础设施，并进行版本控制。

→使用带有 ARM 模板 (JSON) 或 Bicep 的声明性基础设施即代码 (IaC)。

原因: Bicep 是一种更简单、更简洁的领域特定语言 (DSL)，可转译为 ARM JSON，提供更好的编写体验和可读性。

使用 Azure 工具管理和治理在本地或其他云中运行的服务器。

→将非 Azure 服务器载入 Azure Arc。

原因: Azure Arc 将外部资源投影到 Azure Resource Manager 中，使您能够从单个控制平面使用 Azure Policy、RBAC 和监控来管理混合云和多云资产。

参考↗

为所有应用程序提供单一的、基于云的身份和访问管理解决方案。

→使用 Microsoft Entra ID（前身为 Azure AD）。

原因: Entra ID 是身份控制平面，为云端和本地应用程序提供单一登录 (SSO)、多重身份验证 (MFA) 和条件访问。

要求从不受信任的网络登录的用户进行 MFA，但从公司办公室登录的用户则不需要。

→配置 Microsoft Entra 条件访问策略。

原因: 条件访问充当“if-then”策略引擎。如果满足用户/位置/设备条件，则强制执行访问控制（例如要求 MFA）。

允许 Azure 资源（例如 VM 或 App Service）向另一个 Azure 服务（例如 Key Vault）进行身份验证，而无需在代码中存储机密。

→为资源分配托管标识，并授予其对目标服务的 RBAC 权限。

原因: Azure 自动管理凭据生命周期，消除了配置S文件或代码中机密泄露的风险。

安全地存储和管理应用程序机密、密钥和证书。

→使用 Azure Key Vault。

原因: Key Vault 为机密提供了一个集中式、硬件安全且经过审计的存储库，防止它们被硬编码到应用程序中。

持续评估云工作负载的安全状况，获取安全分数，并接收威胁保护。

→使用 Microsoft Defender for Cloud。

原因: Defender for Cloud 为 Azure、混合云和多云环境提供云安全态势管理 (CSPM) 和云工作负载保护 (CWP)。

在子网/NIC 级别过滤网络流量与为整个 VNet 集中过滤。

→使用网络安全组 (NSG) 进行基本的第 3/4 层有状态数据包过滤。使用 Azure 防火墙作为集中式、完全有状态的防火墙即服务，具备第 7 层过滤和威胁情报。

原因: NSG 简单且分布式。Azure 防火墙提供高级功能和集中式策略管理，通常用于中心辐射型拓扑。

通过默认关闭管理端口 (RDP/SSH) 来减少 VM 的攻击面。

→在 Microsoft Defender for Cloud 中启用即时 (JIT) VM 访问。

原因: JIT 按需为管理端口授予有限时间的临时访问权限，之后会自动关闭。这比永久开放端口更安全。

监控 Azure 基础设施的运行状况与应用程序代码的性能。

→使用 Azure Monitor 获取平台指标和日志。使用 Application Insights（Azure Monitor 的一项功能）进行应用程序性能管理 (APM)。

原因: Azure Monitor 收集基础设施数据（CPU、内存）。Application Insights 提供深入的代码级诊断（响应时间、依赖项、异常）。

接收有关 Azure 服务中断、计划内维护和健康建议的个性化警报。

→使用 Azure 服务运行状况。

原因: 服务运行状况根据您的订阅、区域和服务进行个性化，不同于公共 Azure 状态页。它用于 Azure 平台问题，而不是您自己的资源运行状况。

接收个性化的、可操作的建议以优化 Azure 资源。

→查看 Azure Advisor 建议。

原因: Advisor 分析您的配置和使用遥测数据，并在可靠性、安全性、性能、成本和卓越运营这五个支柱方面提供建议。

为企业中的所有 Azure 工作负载建立一个标准化、受治理且可扩展的基础。

→实施 Azure 登陆区域架构。

原因: 登陆区域提供了来自云采用框架的规定性框架，包括管理组结构、网络、身份和治理策略，以安全地加速云采用。