AWS Public Sector Blog

Deploying mission-critical edge applications with AWS IoT Greengrass in disconnected environments

AWS branded background with text "Deploying mission-critical edge applications with AWS IoT Greengrass in disconnected environments"

Modern warfare has evolved into a data-driven domain where success often depends on the ability to collect, process, and act on information faster than adversaries. Whether it’s processing sensor data, coordinating autonomous systems, or enabling tactical communications, the edge has become a critical battlefield where decisions are made in real time.

This evolution is particularly evident in autonomous vehicle operations, where edge computing enables real-time decision-making for unmanned ground vehicles (UGVs), autonomous aircraft, and maritime systems. These platforms must process vast amounts of sensor data and make split-second decisions locally, even when cloud connectivity is unavailable.

However, military operations frequently occur in disconnected, degraded, intermittent, and limited (DDIL) bandwidth environments where traditional cloud-connected applications fail to meet operational requirements. Edge applications must continue functioning autonomously during disconnected periods while seamlessly synchronizing data when connectivity is restored. This hybrid operational model presents unique challenges for both application deployment and updates.

The ability to rapidly deploy and update these edge applications can mean the difference between mission success and failure. As threats evolve and new capabilities are developed, organizations need a reliable, secure, and efficient way to push updates to edge devices—even in challenging network conditions.

In this post, we explore how AWS IoT Greengrass helps organizations to meet these challenges head-on.

We demonstrate how to build a resilient edge application architecture that operates effectively in DDIL environments and supports rapid update deployments. Through practical examples, we explore how IoT Greengrass components create a flexible, maintainable, and secure edge deployment pipeline—designed for even the most demanding operational environments.

Solution overview

IoT Greengrass extends Amazon Web Services (AWS) capabilities to edge devices, enabling local processing, messaging, and data caching with seamless cloud synchronization. This distributed computing framework allows devices to operate autonomously even when disconnected from the cloud, making it ideal for DDIL environments.

AWS Greengrass supports three primary communication patterns:

  • AWS IoT Core topics – Cloud-device messaging using Message Queuing Telemetry Transport (MQTT), ideal for reporting device status, metrics, and mission-critical data to cloud services
  • Local MQTT – Device-to-device communication at the edge, perfect for local sensor networks or tactical data exchange
  • Interprocess communication (IPC) – Internal component messaging within an IoT Greengrass core, enabling modular application design

For example, an autonomous ground vehicle fleet might use:

  • Local MQTT for real-time sensor fusion and vehicle-to-vehicle coordination
  • IPC for processing LiDAR (light detection and ranging) data and running autonomous navigation algorithms
  • AWS IoT Core topics for mission updates and fleet management when connected

IoT Greengrass manages components through a sophisticated deployment mechanism that can help with version control, dependency management, and secure updates. Components can be deployed individually or as part of a larger solution, with rollback capabilities if issues arise. This enables rapid capability updates while maintaining operational stability.

Our solution uses several key IoT Greengrass components:

  • EMQX MQTT broker – Provides robust local message queuing and routing
  • Client device auth – Manages secure device authentication and authorization
  • Bridge component – Enables seamless message routing between local and cloud endpoints
  • IP detector – Facilitates dynamic device discovery in tactical networks
  • Disk spooler – Provides reliable message persistence during disconnected operations
  • AWS Lambda runtime – Enables consistent code execution across cloud and edge for publishing and processing events

For example, autonomous vehicle application components might include a sensor processing pipeline that handles raw sensor data ingestion and fusion. A navigation controller manages autonomous navigation and path planning. A mission manager coordinates vehicle behaviors and mission objectives, and a safety monitor maintains operational safety parameters.

Our solution demonstrates this architecture through a Cursor-on-Target (CoT) processing pipeline. The following diagram gives a high-level view of the architecture. Team Awareness Kit/Tactical Assault Kit (TAK) is not deployed during this walkthrough. However, the Lambda function that processes the messages and forwards them to TAK is. If you want to test with TAK, deploy TAK separately and specify the TCP port and host name of your TAK instance using the AWS CloudFormation parameters.

Edge side:

  1. Local Lambda function generates local COT messages and posts to the IoT Greengrass IPC message bus.
  2. Locally deployed AWS Lambda processor (using the same code as the Lambda function running in the cloud) processes the message messages from the IPC queue and pushes it into TAK.
  3. The IoT Greengrass bridge component relays the messages from the Greengrass IPC and local MQQT message buses to the AWS IoT Core message buses so other integrations can be developed.
  4. If the device is disconnected from the internet, messages destined for IoT Core will be cached locally until connectivity is restored.

Cloud side:

  1. AWS Lambda running in the AWS Cloud processes messages from AWS IoT Core and pushes to TAK deployed in the cloud.
  2. Additionally, any data published to the AWS IoT Core message bus will also be relayed to the edge devices when they are connected to the internet. Messages will be cached if the edge device is offline, they will be sent once connectivity is restored.

For example, Autonomous Vehicle Operations:

Edge side:

  • Sensor fusion component for processing LiDAR, radar, and camera data
  • Local path planning and obstacle avoidance
  • Vehicle-to-vehicle coordination for convoy operations
  • Cached mission parameters and navigation data

Cloud side:

  • Fleet-wide mission planning and coordination
  • Machine learning model updates for improved autonomy
  • Operational analytics and vehicle health monitoring

Figure 1. Architecture diagram

The true power of this architecture becomes apparent when examining how it handles both connected and disconnected operations. During periods of stable connectivity, CoT messages flow seamlessly between the edge and cloud environments. Edge devices maintain their local situational awareness while simultaneously feeding data to cloud services, enabling a comprehensive operational picture that spans both tactical and strategic levels.

However, military operations often face communications challenges. When network connectivity to the cloud is disrupted, the system smoothly transitions to autonomous operation. Edge components continue their local processing uninterrupted, and therefore tactical units maintain their situational awareness through local TAK servers. Rather than losing valuable data generated during these disconnected periods, the disk spooler component temporarily stores messages that would normally be sent to the cloud.

When connectivity is restored, the system automatically begins synchronizing this cached data with cloud services. This process happens transparently, requiring no manual intervention, updating the broader operational picture with all relevant information from the disconnected period. This resilient operation pattern provides both tactical and strategic decision-makers with the most complete and up-to-date information possible, given the network conditions.

This robust architecture effectively bridges the gap between edge and cloud operations, providing consistent functionality across the full spectrum of connectivity scenarios commonly encountered in military operations.

Prerequisites

To deploy the solution, make sure you have the following prerequisites:

  • An AWS account with administrative access
  • AWS Identity and Access Management (IAM) permissions to create and manage:
    1. AWS IoT Core resources
    2. IoT Greengrass deployments
    3. Lambda functions
    4. IAM roles and policies
    5. CloudFormation stacks
  • One of the following edge devices:
    1. A physical or simulated edge device running Ubuntu 24.04. For example, Amazon Elastic Compute Cloud (Amazon EC2) can be used to host a simple Linux instance that can be onboarded as an IoT Greengrass core device.
    2. 1 GB RAM minimum (2 GB recommended)
    3. 2 CPU cores
    4. 10 GB available disk space
    5. openjdk-21 or later (e.g. the package openjdk-21-jdk)
    6. Docker Engine 19.03.0 or later (e.g. the package Docker.io)
    7. Unzip (e.g. the package unzip)
    8. Pip3 (e.g. the package python3-pip). For example:
      apt update ; apt install -y openjdk-21-jdk Docker.io python3-pip unzip
    9. Internet connectivity for initial setup and component deployment

The solution uses several AWS services that might incur charge, including AWS IoT Core message charges, AWS IoT Greengrass deployments, Lambda invocations, and data transfer costs. Typical monthly costs for a development environment are minimal, but for accurate and up-to-date production deployment estimates, refer to AWS Pricing Calculator.

It takes approximately 30–45 minutes to set up the solution and 15–20 minutes to deploy it.

Solution walkthrough

In this next section we walk through the steps required to setup the IoT Greengrass deployment, onboard a new IoT Greengrass core device and validate the solution outcome.

To deploy components using AWS CloudFormation, follow these steps:

  1. Download the sample template from GitHub.
  2. Navigate to the AWS CloudFormation console.
  3. In the left navigation pane, choose Create stack, then choose With new resources (standard).
  4. Under Specify template, choose Upload a template file, then choose Choose file and select the downloaded template.
  5. Choose Next.
  6. Enter stack name: greengrass-deployment.
  7. Review parameters and input the VpcId as your default VPC and SubnetIds as one of the public subnet, choose Next.
  8. On the Configure stack options page, choose Next.
  9. Review the configuration. To acknowledge IAM resource creation, select I acknowledge that AWS CloudFormation might create IAM resources.
  10. Choose Create stack.
  11. Monitor the stack creation progress in the Events

The stack will create and deploy all required components to your IoT Greengrass core device.

To prepare IoT Greengrass core with a service role, follow these steps:

  1. Navigate to the IoT Greengrass console.
  2. Choose
  3. Under the section Greengrass service role, click Attach Role and select the role GreengrassServiceRole.

To install the IoT Greengrass core using the console, follow these steps:

  1. Navigate to the IoT Greengrass console.
  2. Choose Greengrass devices and choose Core devices.
  3. Choose Set up one core device.
  4. Choose Manual setup for one device.
  5. Set the following configurations:
    • Core device name: spokekit-[your-identifier].
    • Thing group name: existing group SpokeKits.
    • Greengrass Coore software runtime: Nucleus Classic.
    • Operating system: Linux.
    • Check Set up a device with installer download.
    • Choose Create thing.
  6. Follow the installer instructions generated by the console to set up the edge node.

To validate the IoT Greengrass core installation, follow these steps:

  1. Navigate to AWS IoT Greengrass console, then choose Core devices.
  2. Your device should show as Active.
  3. Status should be Healthy.

To validate the IoT Greengrass deployment, follow these steps:

  1. Navigate to AWS IoT Greengrass console, then choose Greengrass devices, Deployments.
  2. Click into the MQTTBridgeDeployment.
  3. Under Execution overview, wait until the deployment shows Succeeded

To verify component deployment, from the IoT Greengrass device, check the component status on the core:

sudo /greengrass/v2/bin/greengrass-cli component list

It should have the following components:

  • greengrass.clientdevices.mqtt.EMQX
  • greengrass.clientdevices.Auth
  • greengrass.clientdevices.mqtt.Bridge
  • greengrass.clientdevices.IPDetector
  • greengrass.DiskSpooler
  • dseid.offlineCOTGenerator
  • dseid.CotMessageProcessorComponent

At this point, you should have a fully functional IoT Greengrass core with all required components deployed and running. The system will now generate CoT messages locally and process them through the configured pipeline.

Test the solution

To verify CoT message generation at the edge, enter the following code to monitor the CoT generator logs and confirm message creation:

tail -f /greengrass/v2/logs/com.dseid.offlineCOTGenerator.log

You should see messages like the following:

2025-10-20T09:18:15.466Z [INFO] (Copier) com.dseid.offlineCOTGenerator: stdout. CoT XML: <event version="2.0" uid="AIRCRAFT-4851b0" time="2025-10-20T09:18:15.466407Z" start="2025-10-20T09:18:15.466407Z" stale="2025-10-20T09:19:45.466407Z" type="a-f-A-C-F" how="m-g"><detail><contact callsign="KLM896" type="AIRCRAFT" /><track speed="229.69924600000002" course="276.04" /></detail><point lat="38.901493" lon="-77.032480" hae="11582.400000000001" ce="9999999.0" le="9999999.0" /></event>. {scriptName=services.com.dseid.offlineCOTGenerator.lifecycle.Run, serviceName=com.dseid.offlineCOTGenerator, currentState=RUNNING}

2025-10-20T09:18:15.468Z [INFO] (Copier) com.dseid.offlineCOTGenerator: stdout. [10] Published 5/5 aircraft. {scriptName=services.com.dseid.offlineCOTGenerator.lifecycle.Run, serviceName=com.dseid.offlineCOTGenerator, currentState=RUNNING}

To verify edge processing, monitor the CoT processor logs:

tail -f /greengrass/v2/logs/com.dseid.CotMessageProcessorComponent.log

You’ll see message processing and expected TAK server connection attempts:

2025-09-01T16:33:05.413Z [INFO] (pool-3-thread-142) com.dseid.CotMessageProcessorComponent: Received CoT XML message, sending to TAK server
2025-09-01T16:33:05.413Z [INFO] (pool-3-thread-142) com.dseid.CotMessageProcessorComponent: Attempting to connect to TAK server: takserver.tak.local:8110

You’ll see connection errors to the TAK server. This is expected because no TAK server is deployed in this demo:

2025-10-20T09:19:10.626Z [ERROR] (pool-3-thread-23) com.dseid.CotMessageProcessorComponent: index.py:78,Error sending CoT message to takserver.tak.local:8110: [Errno -2] Name or service not known. {serviceInstance=0, serviceName=com.dseid.CotMessageProcessorComponent, currentState=RUNNING}

To verify cloud message delivery, follow these steps:

  1. Navigate to the AWS IoT Core console.
  2. Under Test and then MQTT test client.
  3. Choose Subscribe to topic.
  4. Enter topic: alldata/#.
  5. Choose Subscribe.

You should see messages like the following:

{
"Message": "<event version=\"2.0\" uid=\"AIRCRAFT-4bb2a1\" time=\"2025-09-02T06:27:31.419549Z\" start=\"2025-09-02T06:27:31.419549Z\" stale=\"2025-09-02T06:28:01.419549Z\" type=\"a-f-A-C-F\" how=\"m-g\"><detail><contact callsign=\"AC4bb2a1\" type=\"AIRCRAFT\" /><track speed=\"250.07122840000002\" course=\"75.22\" /></detail><point lat=\"38.919782\" lon=\"-77.113032\" hae=\"11277.6\" ce=\"9999999.0\" le=\"9999999.0\" /></event>"
}

To verify cloud processing, follow these steps:

  1. Navigate to the Amazon CloudWatch.
  2. Choose Log groups.
  3. Search for CotProcessor.
  4. Open the latest log stream.

You should see processed messages like the following:

{'Message': '<event version="2.0" uid="AIRCRAFT-76cdaa" time="2025-09-02T06:29:31.451835Z" start="2025-09-02T06:29:31.451835Z" stale="2025-09-02T06:30:01.451835Z" type="a-f-A-C-F" how="m-g"><detail><contact callsign="AC76cdaa" type="AIRCRAFT" /><track speed="270.5460996" course="108.4" /></detail><point lat="38.556932" lon="-77.108260" hae="11277.6" ce="9999999.0" le="9999999.0" /></event>'}

Cloud TAK server connection errors are expected because no server is deployed in this demo.

This testing sequence validates:

  • Local message generation
  • Edge message processing
  • Cloud message delivery
  • Cloud-side processing

All core functionality is operational, with expected TAK server connection failures both locally and in the cloud, because these servers are not part of the demo deployment.

Cleanup

To avoid ongoing charges and remove all resources created in this demonstration, use the following cleanup instructions. These actions can’t be undone, so make sure to properly back up your data prior to cleaning up.

To delete the stack using the console, follow these steps:

  1. Navigate to CloudFormation console.
  2. Select the stack greengrass-deployment.
  3. Choose
  4. Choose Delete stack to confirm.

To remove the IoT Greengrass core device, enter the following command on the edge device:

# Stop AWS Greengrass service
sudo systemctl stop greengrass.service
sudo systemctl disable greengrass.service

# Remove AWS Greengrass installation
sudo rm -rf /greengrass
sudo rm /etc/systemd/system/greengrass.service
sudo systemctl daemon-reload

To remove the IoT Greengrass core device using the AWS IoT console, follow these steps:

  1. Navigate to IoT Greengrass console and then choose Core devices.
  2. Select your core device.
  3. Choose Delete.
  4. Type delete to confirm.
  5. Choose Delete.

To delete the thing, follow these steps:

  1. Navigate to AWS IoT Core console.
  2. Under All devices, choose Manage and then Thing.
  3. Select the spokekit-* thing.
  4. Choose Delete.
  5. Type Delete thing to confirm.
  6. Choose Complete.

You might need to perform the following additional cleanup:

  • Check CloudWatch logs and delete any related log groups
  • Verify that no related IAM roles or policies remain
  • Check for any remaining AWS IoT certificates and delete if no longer needed

After completing these steps, all resources created during this demonstration should be removed, and you should no longer incur any related AWS charges.

Conclusion

In this post, we demonstrated how AWS IoT Greengrass can be used to build resilient edge applications capable of operating in challenging DDIL environments. Through our example of a tactical situational awareness system, we showcased how to maintain operational capability at the edge while ensuring data synchronization with cloud services when connectivity is available.

The solution we built demonstrates several key capabilities essential for modern military operations:

  • Autonomous edge operation during disconnected periods
  • Seamless data synchronization upon reconnection
  • Rapid deployment of application updates
  • Flexible message routing between local and cloud endpoints
  • Scalable architecture that can be extended for additional use cases

Although we focused on CoT message processing for situational awareness, the architecture patterns demonstrated here can be applied to a wide range of military use cases, from sensor fusion to autonomous system control. The combination of local processing power and cloud integration provides a flexible foundation for building increasingly sophisticated edge applications.

The ability to rapidly deploy and update these applications through IoT Greengrass gives organizations the agility they need to adapt to evolving threats and requirements. Whether it’s updating message formats, adding new processing capabilities, or integrating with additional systems, changes can be deployed quickly and securely across your entire fleet of edge devices.

As military operations continue to rely more heavily on data-driven decision-making, the ability to process information at the edge while maintaining synchronization with cloud services becomes increasingly critical. This solution provides a blueprint for building such systems, so that tactical units maintain their operational capabilities regardless of network conditions.

This architecture is particularly valuable for autonomous vehicle operations, where edge processing is critical for maintaining safe and effective operations in DDIL environments. The ability to process sensor data locally while maintaining fleet-wide coordination through cloud services when available enables sophisticated autonomous operations at scale. If you’re interested in learning more about building autonomous systems, read the AWS Public Sector Blog post Enabling the mission autonomy flywheel.

To get started with your own implementation, you can find the complete source code and deployment instructions in our GitHub repository. We encourage you to explore how this architecture can be adapted to meet your specific operational requirements.