Differences between AWS Greengrass v1 & v2

Following are few notable differences of various features in Greengrass V1 & V2:

Greengrass Features	Greengrass V1	Greengrass V2
Greengrass Group	In GGv1, GG_Groups define following settings in AWS Greengrass Cloud Service. Local devices connectivity subscriptions with GG_Core Subscriptions for MQTT Topics: for local devices, GG Lambda functions Local Secrets	In GGv2, we have just Deployments Deployments are not necessarily done from Cloud, can be local Local deployments are mainly for testing purpose, but we can use Local deployments for TOTAL OFFLINE GGC functionality. Deployments Defines:      Settings/Configs for GGC      Dependencies between components      Receipes which defines IPC, MQTT Topics
Greengrass Core Modularity	Greengrass_v1 is a Single Package, containing all GG Software Almost all Features are installed by default with GG installation, even when you are not using them like: Stream Manager, Secrete Manager, Log Manager, etc… Very few features can be optinally installed as Connectors that are deployable independently.	In GGv2, GGC Nucleus is very minimal core which is a must install. All GGC features are available as Components, which can be deployed, as and when required. Stream Manager, Secrete Manager are all components, can be deployed independently.
Greengrass Lambda functions	In GGv1, everything related to Lambdas are defined in GG Group in Cloud Service like: Lambda Subscriptions, Access to local resources Lambda function is the main utility to create GG Core device Application. Few other options are:      Containers using Docker Application Deployment Connector      Connectors: either AWS provided pre-built connectors, which are very few and usable for very specific use-cases	In GGv2, everything related to Lambdas is defined in Recipes. Lambda functions are just like Components. Components either AWS-provided or your custom ones are the building blocks for GG_Core device application.
Greengrass Subscriptions	In GGv1, all Subscriptions are defined in AWS GreenGrass Cloud Service.	In GGv2, Subscriptions are managed by Components in Recipes, Authorization policies for MQTT topics, IPC, etc… are also defined in Recipes.
Local Resource Access	In GGv1, access to local resources is restricted, and managed in GG group settings in cloud. If any Greengrass component needs access to local resources like peripheral devices or folder access, it needs a configuration defined in Greengrass group settings. Lambda functions running in a Container environment needs association of local resorce access in it’s own configuration.	In GGv2, all components run as independent processes, with their own recipes, So access/restrictions to local resources is also maintained in their own recipes. Same is the case for Lambda functions running in containers, they maintain their own configuration settings for local resources. So essentially, No Global Group level local resource restrictions in GGv2 as such.
Greengrass Client devices	In GGv1, local devices, their subscriptions are required to be defined in GG_Group in cloud and then, GG group needs to be deployed. To remove devices from group, again GG_Group settings have to be changed and a new deployment needs to be done to GGC.	In GGv2, There’s No need to deploy group to add or remove local devices. Authorization policy only need to be re-defined/modified to remove access of local devices to Greengrass.
Greengrass MQTT broker	In GGv1, MQTT server/broker was part of GG core software.	In GGv2, MQTT broker is a component, Moquette broker MQTT bridge is another component, required for:      local devices to GGC communication      Mesaages between components on core device      Messgaes between IoT devices and AWS IoT core. Client device auth is another component required to:      Authenticate client devices & Authorize client device actions.
Shadow Service	GGv1 has it enabled by default. Need to use the Greengrass Core SDK in your Lambda functions.	In GGv2, Shadow Manager component needs to be deployed. Need to use the AWS IoT Device SDK V2 in Lambda functions, or in custom components.
Local MQTT broker Server Certificate Rotation	By default, this certificate expires in seven days. You can set the expiration to any value between 7 and 30 days. For certificate rotation to occur, your Greengrass core device must be online and able to access the AWS IoT Greengrass service directly on a regular basis. The core device downloads a new MQTT server certificate. If the core device is offline at the time of expiry, it does not receive the replacement certificate. Client devices cannot connect to the core device until the connection to the AWS IoT Greengrass service is restored and a new MQTT server certificate can be downloaded. Though Existing connections are not affected.	In GGv2, Greengrass core devices generate a local MQTT server certificate that client devices use for mutual authentication. This certificate is signed by the core device CA certificate, which the core device stores in the AWS IoT Greengrass cloud. The core device CA certificate expires after 5 years. The MQTT server certificate expires every 7 days by default, and you can configure this duration to between 2 and 10 days. The Greengrass core device rotates the MQTT server certificate 24 hours before it expires.

• if your v1.x applications use any of the following listed features, you won't be able to run them on the v2.0 software yet.
  • Stream manager telemetry metrics
  • The C and C++ Lambda function runtimes.
• Greengrass V1 Lambda functions on V2:
  • The following is the list of Greengrass features, which are used differently in V1 & V2, so if used with Lambda functions, the deployment and usage of Lambda functions needs modifications:
    • Stream Manager
    • Local Secretes
    • Subscriptions
    • Local Volumes and devices
    • Local Shadows
    • Access other AWS Services
• AWS IoT Connectors:
  • Few connectors are available as components in Greengrass_v2.
    • CloudWatch metrics component
    • AWS IoT Device Defender component
    • Kinesis Data Firehose component
    • Modbus-RTU protocol adapter component
    • Amazon SNS component
  • But some of the connectors are not available in Greengrass V2 and cannot be used anymore in GGv2:
    • Serial Connector
    • Docker application deployment connector - Deployment of containers is supported as a component.
• Connect V1 Greengrass devices:
  • AWS IoT Greengrass V2 support for client devices is backward-compatible with AWS IoT Greengrass V1, so you can connect V1 core devices to V2 core devices without changing their application code.
  • Deploy different Greengrass V2 components that facilitate discovery and communication between client abd core devices like:
    • To relay messages between client devices, the AWS IoT Core cloud service, and Greengrass components (including Lambda functions), deploy and configure the MQTT bridge component.
    • You can deploy the IP detector component to automatically detect connectivity information, or you can manually manage endpoints.