This Guidance demonstrates how to build an application that helps farmers improve productivity by capturing data from their agricultural operations. With AWS services, Internet of Things (IoT) devices, such as soil sensors and weather stations, are installed to measure temperature, rainfall, soil moisture, and crop conditions for data-driven decision-making in farming.
AWS IoT rule forwards data to Amazon Managed Streaming for Apache Kafka (Amazon MSK) based on rule conditions that are setup.
JSON data from the sensors is stored in Amazon DocumentDB (with MongoDB compatibility) leveraging Amazon MSK serverless and containerized Kafka connector that is setup on AWS Fargate.
Smart farms containerized microservices process the sensor and third-party data received, and generate recommendations to farmers. Smart farm's microservices can run on either Amazon Elastic Container Service (Amazon ECS), Fargate, or Amazon Elastic Kubernetes Service (Amazon EKS).
Amazon EventBridge triggers AWS Lambda function periodically to collect data such as weather updates and soil tests results from third-parties.
Agriculture officers, insurance companies, or farmers can access smart farm application for additional information using Amazon API Gateway (this is an optional user action).
Smart Farm’s organization admins can generate reports or perform on-demand analysis on the data stored in Amazon DocumentDB using Amazon Athena, Amazon QuickSight, or any other reporting (this is an optional user action).
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.
To improve operational efficiency, use Amazon CloudWatch for monitoring, and enable logging to CloudWatch for each AWS Service. You can configure logging for all of AWS IoT Core or only specific groups. For API Gateway, you can enable API logging to CloudWatch. To identify queries that may need tuning, you can use Amazon DocumentDB Performance insights or use Amazon DocumentDB profiler to define a slow query and log its execution details to CloudWatch logs.
AWS IoT Core provides fine-grained access controls for managing topic permissions. Every device or sensor needs a credential to interact with AWS IoT, and all traffic to and from AWS IoT is encrypted via Transport Layer Security (TLS). Use Identity and Access Management (IAM) roles to provide only the needed permissions to Lambda to access Amazon MSK and API Gateway. Amazon DocumentDB allows for encryption at rest, as well as TLS for data in transit. To further protect resources in production, use Amazon Cognito to protect the API Gateway for public user authentication and authorization.
Serverless technologies implemented in this Guidance are highly available and scalable depending on traffic. Amazon DocumentDB is a fully managed document database service that is deployed as a highly available 3 node cluster spanning across three Availability Zones and allows you to scale vertically and horizontally. Backup in Amazon DocumentDB is enabled by default and cannot be disabled, and the database can be restored to any second during the retention period, up to the last five minutes.
This Guidance comprises managed services, integrated monitoring, alerting, reporting, and event-driven workloads. The services selected for this Guidance have high availability, resiliency, efficiency, and remove undifferentiated heavy lifting. Amazon DocumentDB allows for flexibility within document storage due to the expected changes in IoT hardware, sensors, and schemas that are common within agricultural implementations of IoT.
To avoid over provisioning of resources, this Guidance incorporates serverless technologies for on-demand data ingestion, processing storage, and to optimize costs through pay-as-you-go pricing. With Amazon DocumentDB, you only pay for the capacity you use for storage and backup; it offers per second billing for compute with no extra cost for encryption and monitoring. As Amazon DocumentDB supports flexible data model (also called 'schemaless'), it reduces engineering effort required to support new IoT devices. New IoT device models often bring varying sensor values and can require changes to schemas.
The serverless services used in this Guidance ensure that just the right amount of resources are utilized to handle the workload. And the use of managed services (such as Amazon DocumentDB) are aimed at reducing carbon footprint using AWS Graviton Processors compared to the footprint of continually operating on-premises servers. The scaling features of Amazon DocumentDB allows for scaling vertically and horizontally to reduce unnecessary resources.
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
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.
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.