[SEO Subhead]
This Guidance shows you how to set up an AWS IoT Greengrass deployment in a highly available cloud environment. It uses an Amazon CodeCatalyst blueprint and AWS Cloud Development Kit (AWS CDK) application to provision resources and a continuous integration/continuous deployment (CI/CD) pipeline for edge deployments. This Guidance also demonstrates how to set up the right permissions for accessing resources and token exchange and how to configure client device authentication.
Please note: [Disclaimer]
Architecture Diagram
[Architecture diagram description]
Step 1
Create a new project with the Amazon CodeCatalyst blueprint to prompt the creation of a new Git repository, preconfigured with the Guidance sample code and workflows to deploy to a designated AWS account.
Step 2
All changes in the Git repository outside the components directory will trigger Workflow 1, which builds and deploys all infrastructure-as-code (IaC) related to the architecture, using the AWS Cloud Development Kit (CDK) command line interface (CLI).
Step 3
Workflow 1 provisions the AWS IoT Greengrass Base stack using AWS CloudFormation. This stack includes an Amazon Simple Storage Service (Amazon S3) bucket for components artifacts, an Amazon Simple Notification Service (Amazon SNS) topic for notifications, and an Amazon EventBridge rule to subscribe to public IoT Greengrass-related API events.
It also includes custom resources for creating an IoT Greengrass service role and enabling Message Queuing Telemetry Transport (MQTT) topics using AWS Lambda functions.
Step 4
Workflow 1 also provisions the IoT Greengrass Deployment stack, which includes an IoT Thing Group for IoT Greengrass core device(s), an IoT Greengrass deployment (including components and other configurations) associated with the Thing Group, a token exchange AWS Identity and Access Management (IAM) role and IoT role alias for device authentication, and an IoT rule to publish Thing Group events.
Step 5
Changes committed to the components directory in the Git repository will invoke Workflow 2, which builds, tests, and publishes IoT Greengrass new component versions using the AWS IoT Greengrass Developer Kit (GDK) CLI and the AWS IoT Greengrass Testing Framework (GTF).
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.
-
Operational Excellence
AWS CDK, CloudFormation, and CodeCatalyst enable customers to build, test, and develop with IaC. IoT Greengrass helps customers with orchestrating Over the Air (OTA) deployments to core devices. These services allow for automated infrastructure provisioning and deployment pipelines included in the sample code. IoT Greengrass can distribute these deployment artifacts with a specified IoT Thing Group target.
-
Security
IAM defines role and permission policies for resources deployed in this implementation. Amazon S3 is configured with policies to restrict access to outside entities. Roles and policies defined within IAM and Amazon S3 are critical for implementing least-privilege access, which allows only the minimum level of permissions to access resources.
-
Reliability
IoT Greengrass provides an edge runtime that can continue operations even when an internet connection is unstable or unavailable. The CloudFormation stack deployments and IoT Greengrass deployments are configurable, including features such as rollback and incremental rollouts. If a deployment fails, you can use IoT Greengrass and CloudFormation to roll back the deployment and clean up resources associated with the failed deployment.
-
Performance Efficiency
The GDK CLI allows users to experiment and build any type of IoT Greengrass component and includes components to natively build and package components written in Python or Java in addition to configurations for components built in other languages or frameworks. CodeCatalyst provides an end-to-end DevOps experience, from tracking source code changes, to the building, testing, and deploying of artifacts at scale.
-
Cost Optimization
IoT Greengrass enables users to operate on the edge without a persistent connection to the cloud or continuous use of cloud resources. IoT Greengrass deployments are fully customizable to include only what devices need and limiting data transfers to only what is required. Limiting data transfer and using edge applications can help lower your monthly AWS costs.
-
Sustainability
CodeCatalyst uses automation to manage the lifecycle of your development and test environments and maximize the efficiency of your build resources. IoT Greengrass on the edge limits the utilization of resources in the cloud, reducing the workload’s environmental impact. Using CodeCatalyst to automate development lifecycles maximizes usage for build or test periods and minimizes waste when resources are idle.
Implementation Resources
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.
Related Content
[Title]
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.