本指南展示了 AWS Supply Chain Control Tower 如何提高关键业务系统的可见性。近乎实时地分析源源不断的数据流，为您的供应链确定切实可行的见解和预测性建议。
架构图
步骤 1
Supply Chain Control Tower（SCCT）依赖于物流合作伙伴等外部系统的数据输入，经常使用基于文件的集成。现代方法包括将数据发布/推送到使用 Amazon API Gateway（API Gateway）和 AWS Lambda 构建的安全 API。
第 2 步
包装消费品（CPG）企业依赖于关键系统来管理从原材料到生产能力的所有环节。可以使用多种集成方法与这些系统集成：Amazon EventBridge 用于在事件发生时交付事件，Amazon AppFlow 用于与 SAP 等系统进行一站式集成，还可用于仅可进行基于文件的集成的系统。AWS Transfer Family 可用于管理安全的文件传输，例如 SFTP 作业。
第 3 步
供应链中的各种设备也包含对 SCCT 至关重要的数据。联网设备可以使用 MQTT 协议通过 AWS IoT Core 传输消息。
第 4 步
在将数据推送到数据平台之前，可以使用 AWS DataBrew 和 AWS Glue 等服务对数据进行转换和标准化。Amazon Textract 可用于从图像/纸质文档（例如码头单据）中提取重要数据，然后将其摄入数据平台。
第 5 步
SCCT 的核心是您的数据平台，它将成为您数据的单一可信来源。该平台有许多合适的模式。
第 6 步
Amazon SageMaker 可用于构建、训练和部署专注于特定应用场景（例如 ETA 预测）的机器学习模型。
第 7 步
Amazon QuickSight 可以与 Amazon OpenSearch Service 一起用于实时分析，Amazon Athena 用于临时查询数据湖中的数据，Amazon Redshift 用于复杂的查询和视图。
第 8 步
QuickSight 可用于对数据平台中分析的数据进行可视化，从而为特定 SCCT 应用场景（已列出）创建可行的见解。
第 9 步
您的 SCCT 可以通过针对特定应用场景的微服务进行扩展。示例：通过 Amazon Lambda 查询来自Amazon DynamoDB 的传输位置数据，以便使用 Amazon Location Service 进行可视化。
第 10 步
利用 AWS Amplify 简化代码开发，利用 Amazon Cognito 进行身份管理，利用 Amazon CloudFront 分发内容，利用 Amazon Simple Storage Service（Amazon S3）存储静态资产，并结合 Amazon Route 53 DNS，共同创建一个可扩展、安全的无服务器前端。
第 1 步
Supply Chain Control Tower（SCCT）依赖于物流合作伙伴等外部系统的数据输入，经常使用基于文件的集成。现代方法包括将数据发布/推送到使用 Amazon API Gateway（API Gateway）和 AWS Lambda 构建的安全 API。
第 2 步
包装消费品（CPG）企业依赖于关键系统来管理从原材料到生产能力的所有环节。可以使用多种集成方法与这些系统集成：Amazon EventBridge 用于在事件发生时交付事件，Amazon AppFlow 用于与 SAP 等系统进行一站式集成，还可用于仅可进行基于文件的集成的系统。AWS Transfer Family 可用于管理安全的文件传输，例如 SFTP 作业。
第 3 步
供应链中的各种设备也包含对 SCCT 至关重要的数据。联网设备可以使用 MQTT 协议通过 AWS IoT Core 传输消息。
第 4 步
在将数据推送到数据平台之前，可以使用 AWS DataBrew 和 AWS Glue 等服务对数据进行转换和标准化。Amazon Textract 可用于从图像/纸质文档（例如码头单据）中提取重要数据，然后将其摄入数据平台。
第 5 步
SCCT 的核心是您的数据平台，它将成为您数据的单一可信来源。该平台有许多合适的模式。
第 6 步
Amazon SageMaker 可用于构建、训练和部署专注于特定应用场景（例如 ETA 预测）的机器学习模型。
第 7 步
Amazon QuickSight 可以与 Amazon OpenSearch Service 一起用于实时分析，Amazon Athena 用于临时查询数据湖中的数据，Amazon Redshift 用于复杂的查询和视图。
第 8 步
QuickSight 可用于对数据平台中分析的数据进行可视化，从而为特定 SCCT 应用场景（已列出）创建可行的见解。
第 9 步
您的 SCCT 可以通过针对特定应用场景的微服务进行扩展。示例：通过 Amazon Lambda 查询来自Amazon DynamoDB 的传输位置数据，以便使用 Amazon Location Service 进行可视化。
第 10 步
利用 AWS Amplify 简化代码开发，利用 Amazon Cognito 进行身份管理，利用 Amazon CloudFront 分发内容，利用 Amazon Simple Storage Service（Amazon S3）存储静态资产，并结合 Amazon Route 53 DNS，共同创建一个可扩展、安全的无服务器前端。
Well-Architected 支柱
当您在云中构建系统时，AWS Well-Architected Framework 可以帮助您了解所做决策的利弊。框架的六大支柱使您能够学习设计和操作可靠、安全、高效、经济高效且可持续的系统的架构最佳实践。使用 AWS 管理控制台中免费提供的 AWS Well-Architected Tool，您可以通过回答每个支柱的一组问题，根据这些最佳实践来检查您的工作负载。
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构，您应该遵循尽可能多的 Well-Architected 最佳实践。
-
卓越运营阅读《卓越运营》白皮书
通过仅利用 AWS 托管服务，每项服务都会向 Amazon CloudWatch 发布自己的指标集，客户可以在其中监控错误。
-
安全性阅读《安全》白皮书
对于面向公众的服务（例如用户界面），Amazon Cognito 用于保障对核心应用程序和服务进行安全访问，其中包括基于角色的访问控制。还通过适当的访问权限、身份验证和授权控制来保护已预置的 API 端点，以确保只有经允许的系统和用户可使用。对于其他 AWS 服务，利用基于角色的 AWS Identity and Access Management（IAM）访问控制来确保以最低权限访问各服务。
此架构中使用的 AWS 托管服务通过加密传输中数据来支持安全通信。在存储数据的地方（例如 Amazon Redshift 和 Amazon S3），静态数据也会得到加密。
-
可靠性阅读《可靠性》白皮书
此架构利用了默认情况下设计为高可用性的托管服务。某些服务（例如 Amazon Redshift）也可以配置为部署在多个可用区中。该架构中的每个组件都专门用于在发生灾难事件时维持可用性。AWS 托管服务专门用于跨越多个可用区。其他服务，例如 Amazon Redshift，也可以部署在多个可用区中。在可用区出现故障的情况下，部署的服务可以继续运行。
-
性能效率阅读《性能效率》白皮书
Amazon S3、Amazon Kinesis、AWS Glue 和 Amazon Redshift 等可扩展且高度可用的服务专为数据分析工作负载构建。
-
成本优化阅读《成本优化》白皮书
该架构采用无服务器优先的方法。无服务器服务会尽可能根据负载进行扩展，以确保您只需为使用的内容付费。此外，该架构还使用可以采用公用事业计费模式的 AWS 托管服务。
任何面向数据的架构都需要考虑数据传输。在此解决方案中，最大的数据量摄取自源系统，而源系统在入站方向通常不收费。AWS SFTP 文件传输功能、API Gateway 请求和 Amazon AppFlow 数据的数据传输费用按记录的服务定价收费。所有其他数据都保存在该区域内进行处理，以最大限度地减少传输费用。
-
可持续性阅读可持续性白皮书
AWS 托管服务有助于根据业务需求和流量扩大和缩小规模，并且本质上比本地解决方案更具可持续性。此外，所用的无服务器组件可实现基础设施管理流程的自动化，使其更具可持续性。
实施资源
提供了在 AWS 账户中进行实验和使用的详细指南。构建指南的每个阶段（包括部署、使用和清理）都将被检查，以便为部署做好准备。
示例代码为起点。它经过行业验证，是规范性但不是决定性的，可以帮助您开始。
免责声明
示例代码；软件库；命令行工具；概念验证；模板；或其他相关技术（包括由我方人员提供的任何前述项）作为 AWS 内容按照《AWS 客户协议》或您与 AWS 之间的相关书面协议（以适用者为准）向您提供。您不应将这些 AWS 内容用在您的生产账户中，或用于生产或其他关键数据。您负责根据特定质量控制规程和标准测试、保护和优化 AWS 内容，例如示例代码，以使其适合生产级应用。部署 AWS 内容可能会因创建或使用 AWS 可收费资源（例如，运行 Amazon EC2 实例或使用 Amazon S3 存储）而产生 AWS 费用。