This Guidance demonstrates how to implement and monitor two-way Open Platform Communication using AWS IoT Greengrass. Customers can collect and aggregate data from IoT edge devices to send and receive commands from the edge to the cloud.

Architecture Diagram

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.

  • This Guidance helps customers improve processes and procedures by helping them manage defective protocol converters and individual edge devices in the cloud. This helps with unification and standardization of OPC platforms. 

    Changes to the custom IoT Greengrass components can be deployed using the AWS IoT Greengrass Development Kit Command-Line Interface (GDK CLI).

    Read the Operational Excellence whitepaper 
  • This Guidance encrypts data at rest and in-transit. Data at rest is stored in an encrypted Amazon Simple Storage Service (Amazon S3) bucket, and data in transit is encrypted over the MQTT bridge using TLS. The Amazon S3 bucket, created with the GDK CLI, is made private by default and encrypted. Data is therefore private and encrypted at rest.

    IoT Greengrass uses a public key infrastructure (PKI) for authentication, using X.509 certificates to protect against network impersonators. IoT Greengrass policies and AWS Identity and Access Management (IAM) are utilized for authorization control.

    Read the Security whitepaper 
  • This Guidance is designed to handle intermittent connectivity by storing important data locally when there is no connectivity before sending data to the cloud when connectivity is restored. 

    AWS IoT Core progress events about each message are sent to Amazon CloudWatch for logging and the Device Shadow service documents are stored. 

    The GDK CLI can be used to seamlessly create, test, build, and publish IoT Greengrass deployments.

    Read the Reliability whitepaper 
  • IoT Greengrass is purpose-built for edge computing at IoT devices. Users can experiment with virtual machines and OPC emulators instead of physical IoT devices and OPC servers. For high-volume data ingestion, users can further optimize this Guidance with AWS IoT Core Basic Ingest.

    The location should be set to one's nearest region to improve performance and decrease latency. 

    Read the Performance Efficiency whitepaper 
  • Each OPC device is treated as its own device, and each device will handle its own computing before sent back to the cloud. This helps utilize the minimum required resources to meet the demand.

    Read the Cost Optimization whitepaper 
  • This Guidance utilizes only the required amount of hardware per IoT device. This allows customers to minimize the impact of their workloads by reducing the total resources required for them to run in AWS data centers.

    Read the Sustainability whitepaper 

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.

[Content Type]


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


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.

Was this page helpful?