Trek10 Team
Caylent Catalysts™
IoT
Connect, understand, and act on data from industrial devices at scale to improve uptime, efficiency, and reliability across manufacturing, energy, and utilities.
Go beyond lift-and-shift: Re-platform your AWS IoT Greengrass V1 apps to V2 with this guide covering key architectural changes and a starter migration plan.
This blog was originally written and published by Trek10, which is now part of Caylent.
That said, when AWS “strongly recommends” that customers migrate to AWS IoT Greengrass V2 (henceforth, V2), it is well worth the effort to understand what this entails and then draw a roadmap toward migration if your business has critical workloads running on Greengrass V1. Because AWS already provides a thorough “lift-and-shift” migration plan in their documentation, in this post I will instead focus on re-platforming a Greengrass V1 application to start fresh and fully leverage all the features that V2 has to offer. First, I will clearly delineate the architectural differences between V1 and V2, and then I will present a starter V1 to V2 re-platforming plan.
Differences in Architecture
Here’s what you need to know in a nutshell:
- Applications in V1 are made up of Lambda functions–to run application code–and connectors–pre-built modules used for local resource access, protocol translation, and interaction with external services. V2, by contrast, treats everything as a “Component”–be it a vendor-specific protocol translator, a machine learning model inferencing engine, or a local Lambda function.
Figure 1 - comparison between static application blocks in V1 and dynamic components in V2
- Communication in V1 happens using subscriptions, which are predefined paths to exchange data between Lambda functions, connectors, devices, and AWS IoT Core (through MQTT). Subscriptions are defined at the Greengrass Group level, and a new deployment must be released to add new subscription paths.
V2 overhauls this subscriptions-based mechanism by providing an Interprocess Communication (IPC) system. You may think of this as a data bus shared amongst all Components. Every Component can use the IPC interface to interact with any other Component so long as its authorization policy allows it. For example, a Component whose function is to read data from a sensor can then send its readings to the MQTT Broker Component which then relays the data up to AWS IoT Core.
Figure 2 - comparison of V1’s subscription-based communication and V2’s IPC system
- Deployments in V1 are an update to a Greengrass Group configuration. That is, you define the settings for the Greengrass Core device–Lambda functions, connectors, subscriptions, etc.–and then apply those settings as a deployment. Updating a Greengrass Group in V1 will update exactly one Greengrass Core device’s settings.
In V2, by contrast, deployments can be deployed to a single Greengrass Core device or to an AWS IoT Thing Group containing multiple core devices. A deployment in V2 is simply a collection of Components and their associated settings.
Figure 3 - comparison of V1’s groups and V2 deployments
The overall pattern here is moving away from having static and prescriptive architectures in V1 towards modularized, highly dynamic architectures in V2. There are a few other smaller changes that you may view in the official V1 and V2 differences guide, but the items above cover the fundamentals, plus a bit more.
Re-platforming Plan
To migrate your Greengrass application from V1 to V2, you may start off with the following steps:
- Define what you need your application code to do. Break down the functionality of each Lambda function in V1 and categorize it as a containerized application, script, sensor reading, data processing, or any other categories that make sense for your business use case. You’ll use this definition breakdown to…
- Decide how to architect the application in V2. The key thing to understand is that in V1 all application code was managed through local Lambda functions, whereas in V2 you can use Lambda functions, Docker containers, custom runtimes, and even native operating system processes! You’ll have to select which of these to migrate each of your V1 Lambda functions into.
If you need packaged applications (perhaps some that run both in the Cloud and at Edge), Lambda functions or Docker containers could be a good choice to port your code. If you need access to system resources or specialized libraries or applications (such as when you have sensor reading logic that relies on specific application drivers) a system process or custom runtime may be a better fit.
Each of these new application Components will likely need to communicate with each other or with the cloud, so the next step is to…
- Draw communication paths between all the new Components. Any subscriptions and data exchange with the AWS IoT MQTT broker are now to be adapted to use the IPC interface. Understand how the IPC works, and determine how you’ll modify your existing V1 application code to leverage it.
One key thing to note is the MQTT broker in V2 is a Component that must be configured to relay messages published locally by client devices to AWS IoT Core–this relay doesn’t happen automatically as it would under a V1 Subscription definition (revisit Figure 2 above).
- Develop your first Greengrass V2 deployment with the Components and IPC modifications achieved in steps 1-3. You can start testing it on one of your own Greengrass core devices–or you may set up a development environment on EC2. Once you’re comfortable with your re-architecture, you may begin installing Greengrass V2 on all your devices by following Step 1 in the V1 to V2 upgrade guide, and then releasing your new Components in a controlled (i.e. exponential or max-per-minute) fashion using the new AWS IoT Job configurations now made available to you in AWS IoT Greengrass V2.
What’s Next?
Once you’re done re-architecting your Greengrass application, you will want to begin setting up proper security policies for your client devices, Components, and Core devices, as well as establishing proper device management processes like CI/CD pipelines, deployment strategies, fleet monitoring, and incident response playbooks.
IoT
Trek10 Team
Founded in 2013, Trek10 helped organizations migrate to and maximize the value of AWS by designing, building, and supporting cloud-native workloads with deep technical expertise. In 2025, Trek10 joined Caylent, forming one of the most comprehensive AWS-only partners in the ecosystem, delivering end-to-end services across strategy, migration and modernization, product innovation, and managed services.
View Trek10's articlesLearn more about the services mentioned
Caylent Services
Managed Services
Reliably Operate and Optimize Your AWS Environment
Caylent Services
Infrastructure & DevOps Modernization
Quickly establish an AWS presence that meets technical security framework guidance by establishing automated guardrails that ensure your environments remain compliant.
Related Blog Posts
Setting Up AWS IoT Greengrass On Amazon EC2: Everything You Need To Know
How to properly configure an EC2 instance to run a Greengrass Deployment to use as a development environment.
IoT
The What, When, and Why of AWS IoT Greengrass
Run Lambda functions locally and save time and money by using this open-source solution for IoT devices.
IoT
Exploring AWS IoT Services - Part 2
Continuing a journey into AWS IoT, this post examines how to use IoT Core rules to format and route messages to destinations within the AWS ecosystem.
IoT