This Guidance demonstrates how you can configure an optimized order process that delivers what your consumers want and when they want it, also referred to as a "perfect order." An important part of the perfect order is the "last mile." This means delivering the product right to the consumer's front door. Getting the last mile right takes careful planning across the whole supply chain, which this architecture is built for. From the upstream order to the delivery, you can use this architecture to design a perfect order process that makes sure products are ready to ship on time, through optimized routes, with fleets tracked, and consumers notified.

Please note: [Disclaimer]

Architecture Diagram

[Architecture diagram description]

Download the architecture diagram PDF 

Well-Architected Pillars

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.

  • We recommend integrating and deploying changes using AWS and DevOps practices when configuring this Guidance. For example, AWS CodeBuild, AWS CodeCommit, and AWS CodeDeploy can be used to manage versions and deployment strategies. We also recommend using an AWS Cloud Development Kit (AWS CDK) which helps manage deployment through code in a controlled environment across accounts. This infrastructure as code approach helps with versioning, testing, and deployment automation. By leveraging AWS, DevOps tools, and CDK, you can deploy changes easily, rollback failed deployments, and provision resources reliably and repeatably across environments. This enables a robust continuous integration and continuous delivery (CI/CD) pipeline for safe, efficient updates to the architecture.

    Read the Operational Excellence whitepaper 

  • Several AWS services were used in this architecture to make sure communication and data are secure. For core communication between services, we used Amazon Cognito and AWS Identity and Access Management (IAM). This allows you to authenticate and authorize access for both people and machines. All service-to-service communication is authenticated with Amazon Cognito and authorized using IAM roles. For storing data, we used DynamoDB, Neptune, Amazon S3, and Lake Formation. These services encrypt data both when stored and when moved between services. By building in security with AWS from the start, you can ensure sensitive information is protected.

    Read the Security whitepaper 

  • This Guidance follows AWS best practices for a serverless architecture. The core processing service is Lambda, provisioned using concurrency limits. To enable decoupled services, Amazon SQS and Amazon SNS are used. For observability, AWS metrics and logging services like Amazon CloudWatch, AWS X-Ray, and AWS CloudTrail are used. All backend logs and metrics from transactions and services are streamed to CloudWatch. By adhering to AWS serverless architectures, such as using Lambda for processing, and implementing AWS observability services, you can build a robust and scalable serverless system that is cost-effective, high-performing, and secure.

    Read the Reliability whitepaper 

  • The AWS serverless services used throughout this Guidance scale continuously and usage is metered in milliseconds, optimizing costs. Since AWS manages the services, overall resource consumption is reduced too. The serverless architecture enables automatic scaling, resilience, cost optimization, and high performance. The on-demand nature of serverless computing allows you to only pay for exactly what you need while AWS handles provisioning and managing resources behind the scenes. This is ideal for workloads that are event-driven, inconsistent, or unpredictable.

    Read the Performance Efficiency whitepaper 

  • This Guidance uses serverless services, the building blocks of AWS. Since AWS manages the infrastructure behind the services in this architecture, you avoid having to setup and maintain servers yourselves. This saves you money on operations and administration. You only pay for what you use. There are no charges when the services are idle. Using these ready-to-go components, optimized for fast processing and sharing, means your costs stay low and your productivity stays high.

    Read the Cost Optimization whitepaper 

  • This architecture promotes sustainability in a few key ways. First, it utilizes AWS serverless services that scale up and down based on demand, meaning the services only use the resources required at any given time. You don't have to overprovision idle or wasted capacity.

    Second, the AWS infrastructure is designed for optimal energy efficiency and sustainability. AWS data centers use advanced cooling systems and renewable energy sources to reduce environmental impact. By running your architecture on AWS, you benefit from its carbon-efficient operations.

    Third, the serverless model means you aren't purchasing and maintaining our own hardware. AWS manages the physical servers and resources on your behalf. This avoids manufacturing new hardware unnecessarily and extends the useful lifecycle of existing equipment.

    Finally, the automation enabled by AWS lets you easily delete and recreate resources when needed. This supports rebuilding fresh, optimized environments while minimizing persistent resource usage.

    Read the Sustainability whitepaper 

Implementation Resources

A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.

The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.

Open implementation guide
Open sample code on GitHub

Related Content

[Subject]
[Content Type]

[Title]

[Subtitle]
This [blog post/e-book/Guidance/sample code] demonstrates how [insert short description].

Disclaimer

The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.

References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.

Was this page helpful?

 Feedback