本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
后续步骤
本指南描述了不同场景下的各种网络访问方法，并描述了每种架构的优缺点。你应该明白为什么选择网络接入方法不应该纯粹是技术方面的讨论。业务和技术之间的协调至关重要。以下后续步骤和建议可通过评估当前能力、分析市场需求和实施治理控制来帮助您评估和标准化您的网络架构策略。
评估当前架构和功能
根据相关数据源审查当前的网络架构，例如本指南中的自我评估框架、当前的监管要求和市场现状（包括客户和竞争分析）。例如，可以考虑使用 Well-A AWS rchitected
查看任何潜在的例外情况、一次性产品和历史产品决策。保持好奇，挑战他们，不要自动假设他们的有效性。几年前的客户要求可能不再有效。具有挑战性的假设为简化和降低架构的复杂性创造了机会。
简而言之，记录观察结果，以便组织中的不同角色可以访问和理解它们。捕捉当前状态与目标状态的不同之处、目标状态是什么、影响以及何时进行观测。记录这些信息有助于您的组织根据最新数据做出决策。
市场和客户分析
收集对市场趋势的见解。当前，消费者访问像你这样的SaaS产品的首选方式是什么？ 您还能在客户所在的地方与他们会面吗？ 客户群组或行为是否发生了变化？ 您的高管们是否将这艘船引向了新的市场、具有特定监管要求的地理位置或新的客户等级？ 您的业务或运营模式是否发生了变化？ 例如，您是否正在考虑为服务贴上白标？ 您的增长计划是否包括与合作伙伴合作，以便在客户与这些合作伙伴建立联系时向他们提供您的服务？
战略调整
当您了解当前的能力、当前的架构、市场和客户后，请召开战略协调会议。与相关的产品、业务和技术利益相关者一起质疑哪些要求仍然有效，哪些新要求需要考虑。通过删除不再需要的要求来寻找降低复杂性的机会。这不是委员会的设计；工程团队需要准备并拥有实际的架构和实施细节。但是，这次会议应该阐明为什么这是一组可以最大限度地为客户和组织带来好处的要求。
标准化
为了吸引客户，让每个人自由选择如何连接到您的服务可能很诱人。毕竟，任何解决方案在技术上都可能奏效，而且您可能还拥有管理和操作所有这些解决方案的专业知识和资源。在某种程度上，这可以很好地发挥作用，但是随着业务的扩展，它变得难以管理。您的可观测性堆栈需要支持来自多个解决方案的指标，而您的网站可靠性工程师也需要能够理解这些指标。每种连接方法都需要 up-to-date文档。需要根据您提供的每种访问方法对应用程序中的重大更改进行评估。您需要为每种访问方法编写和维护自动化和基础设施即代码 (IaC)。必须权衡不对服务访问进行标准化所产生的额外开销与您希望为客户提供的灵活性。
如果您需要北极星来指导您的决策，我们建议您进行标准化。客户与您提供的服务互动方式的标准化通常是您可以采取的最有影响力的措施来改善整个组织的许多成功指标。标准化使产品团队更容易了解您的服务的成本结构，并做出数据驱动的产品决策。在根据预定义标准开发、推出和运行的环境中，运营团队可以更轻松地解决问题并自动执行部分故障排除过程。它可以帮助您检测异常、意外行为或恶意行为者的行为。标准化还可以减少技术债务。工程团队测试和推出生产变更所需的周期更短。它还可以加快您的上市速度，提高自助服务入职成功率，并降低监管风险。
因此，我们建议您同时查看当今可能存在的任何一次性措施。量化您为支持现有客户所花费的运营周期数。将您的结果与历史数据进行比较，并评估您当前的方法是否适用于未来几年。每当需要偏离标准时，都要质疑这些要求背后的要求。评估影响，在眼前收益与长期承诺之间取得平衡。
如果定制不可避免但与您的标准相冲突，请考虑采用责任共担模式。在此模型中，您的产品在很大程度上不受所要求的更改的影响，并且自定义是在极简主义的专用环境中进行的。有关示例，请参阅一连接传输 VPC 架构节。
Governance
为了遵守监管要求和您自己的内部标准，管理至关重要。有了适当的治理，您就可以控制在何处以及如何执行标准。您还可以建立控制措施，以检测与标准的差异，并告知资源所有者必要的纠正措施。 AWS Organizations、AWS Config、AWS CloudTrail、和AWS Control Tower是许多可以帮助你在 AWS 服务 中管理和控制工作负载的工具中的一小部分 AWS Cloud。
重复
利用从最初的工作中吸取的教训，建立一个轻量级、可重复的流程，以便在将来保持一致。定义您需要从哪些角色那里输入数据、频率、数据的准确性、如何共享数据以及谁将对数据采取行动。
