Enrich IoT data with Lambda through Kinesis Data Firehose buffering
Design a solution to meet performance objectives.
Determine a strategy to improve performance.
Architect network connectivity strategies.
Answer
Correct answer: B — Use IoT Basic Ingest, write to Kinesis Data Firehose with 900 second buffering, and use Firehose to invoke Lambda for enrichment.
Accompany is building an application to collect and transmit sensor data from a factory. The application will use AWS IoT Core to send data from hundreds of devices to an Amazon S3 data lake. The company must enrich the data before loading the data into Amazon S3. The application will transmit the sensor data every 5 seconds. New sensor data must be available in Amazon S3 less than 30 minutes after the application collects the data. No other applications are processing the sensor data from AWS IoT Core. Which solution will meet these requirements MOST cost-effectively?
Community Votes
58% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Kinesis Data Firehose buffers records for up to fifteen minutes before delivering them to S3, and its transformation capability invokes Lambda for enrichment, so the buffering that reduces S3 request cost also fits inside the thirty minute window.
A factory application sends sensor data from hundreds of devices through AWS IoT Core to an S3 data lake, transmitting every five seconds. The data must be enriched before loading, must be in S3 within thirty minutes of collection, and no other application consumes it from IoT Core.
Invoking Lambda directly from the IoT rule for every message. With data arriving every five seconds from hundreds of devices, invoking Lambda per message is far more expensive than batching, and it produces many small S3 PutObject calls rather than consolidated deliveries through Firehose.
Community Discussion (19 comments)
mark_232323
👍 8
Selected: B
https://aws.amazon.com/blogs/iot/ingesting-enriched-iot-data-into-amazon-s3-using-amazon-kinesis-data-firehose/
053081f
👍 6
Selected: A
In this application, sensor data is transmitted at the following intervals: 1. Device to IoT Core (every 5 seconds) 2. IoT Core to S3 (every 30 minutes) The data load from IoT Core to S3 doesn't necessarily need to be real-time, and the most cost-effective solution is option A. Option A uses the simplest method to load data without using resources like Kinesis.
85b5b55
👍 1
Selected: A
the requirements is MOST cost-effective solutions. hence, I choosed A. (i.e. Less resources)
AzureDP900
👍 1
B is right, this meets the requirement of making new sensor data available in Amazon S3 less than 30 minutes after the application collects the data. The buffering interval of 900 seconds (15 minutes) is sufficient to meet this requirement, and the use of Kinesis Data Firehose ensures that the data is processed and delivered to Amazon S3 in a timely manner. This solution is also cost-effective because it: Uses AWS IoT Core Basic Ingest, which is free for up to 10 GB of incoming data per month. Uses Kinesis Data Firehose, which has a low cost compared to other services like Lambda or Timestream. Does not require the creation of multiple resources (e.g., Lambda functions, topics) as in some other solutions.
sashenka
👍 1
Selected: A
Option A is the most cost-effective solution because: Uses minimal services while meeting all requirements Leverages serverless architecture for automatic scaling Provides immediate processing without buffering delays Minimizes costs by eliminating unnecessary services * Direct integration between IoT Core and Lambda ensures low latency The Lambda function can process messages immediately as they arrive from IoT Core, enrich the data, and write to S3 well within the 30-minute requirement. This architecture is both simple and cost-effective, avoiding unnecessary services and their associated costs.
doobc
👍 1
B. buffering helps with cost of lambda
Danm86
👍 2
AWS IoT Core Basic is cheaper than AWS IoT core, also Kinesis Data Firehose Batching will reduce the number of write operations to S3 and Lambda invocations by buffering data. Hence even though there is an additional component of Kinesis Data Firehose, it is more cost effective than option A. According to me, the answer is Option B
Daniel76
👍 1
Selected: B
No other applications are processing the sensor data from AWS IoT Core: Use AWS IoT Core Basic Ingest to ingest the sensor data to reduce messaging cost: B or D https://docs.aws.amazon.com/iot/latest/developerguide/iot-basic-ingest.html Configure an AWS IoT rule action to write the data to Amazon KDF or KDS? "New sensor data must be available in Amazon S3 less than 30 minutes after the application collects the data." =>near real time, stream data to s3, no need storage or replay, we shd use autoscaling and fully managed KDF.
liuliangzhou
👍 1
Selected: A
A. The advantage of this method is its simplicity and high real-time performance, as Lambda functions can immediately respond to IoT events. The cost of Lambda functions is based on execution time and resource usage, which is very economical for small data processing tasks. B. The 900 second buffer interval of Kinesis Data Firehose does not meet real-time requirements (data needs to be processed within 30 minutes, while the set buffer here is 15 minutes). In addition, introducing Kinesis Data Firehose adds additional cost and complexity, especially when Lambda functions can directly process data.
jopaca1216
👍 1
Selected: B
Many devices sending data every 5 seconds, it's not necessary, due that you just need the data available in S3 within 30 minutes!
_Jassybanga_
👍 1
the data emitting time is 5 sec and lambda may take upto 15 mins to enrich the data , this detail is only captured in buffer section of KFS , hence going with B, If there is SQS queue in option A before lambda then i would have choosen that
dzidis
👍 2
Selected: B
As per this link it is B, firehose is used: https://aws.amazon.com/blogs/iot/ingesting-enriched-iot-data-into-amazon-s3-using-amazon-kinesis-data-firehose/
Incognito013
👍 2
Selected: A
We need simple and cost effective so choosing A
tsangckl
👍 3
Selected: B
I prefer B
Chakanetsa
👍 4
Selected: B
Best Answer: B. Use AWS IoT Core Basic Ingest to ingest the sensor data. Configure an AWS IoT rule action to write the data to Amazon Kinesis Data Firehose. Set the Kinesis Data Firehose buffering interval to 900 seconds. Use Kinesis Data Firehose to invoke an AWS Lambda function to enrich the data, Configure Kinesis Data Firehose to deliver the data to Amazon S3. Reasoning: Cost-effective: IoT Core Basic Ingest is the most cost-effective option for high-volume, low-value data. Low latency: Kinesis Data Firehose with a 900-second buffering interval provides a balance between cost and latency, meeting the requirement of data availability in S3 within 30 minutes. Scalability: Kinesis Data Firehose can handle high throughput, making it suitable for large volumes of sensor data. Simplicity: The solution involves a straightforward pipeline with minimal components.
vip2
👍 2
Selected: B
B is correct
Helpnosense
👍 4
Selected: A
Vote A because only required minimum services are involved. IoT core topic to hold income data, Lambda to enrich data and save to s3. IoT rule call Lambda and consume the incoming data.
kupo777
👍 2
A is incorrect. C is correct. AWS loT Core Basic Ingest → Cost optimization Amazon Kinesis Data Streams → Send every 5 seconds
kupo777
👍 3
A Simple and most cost-effective.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
An IoT rule writes the sensor data to Kinesis Data Firehose, where the buffering interval is set to 900 seconds, so records accumulate and are delivered to S3 in batched objects at most fifteen minutes after arrival, which is comfortably inside the thirty minute requirement. Firehose invokes the Lambda function for the data transformation step, so the enrichment happens on the way to S3 with no extra service in the path. Because data is buffered and delivered in batches, the S3 request and object counts are far lower than per-message writes, and no other application is reading from IoT Core, so the basic ingest path with Firehose is sufficient.Why the Other Options Are Wrong
A: Invoking Lambda from an IoT rule action runs once per message, and with a five second interval across hundreds of devices the invocation and S3 PutObject costs dominate, which contradicts the most cost-effective requirement. C: Timestream is a time series database, not a landing zone for S3, so a Lambda function would have to read the table and then write each record to S3 individually, which is both more expensive and more complex than the Firehose path. D: Kinesis Data Streams with a consumer Lambda writing each record with the PutObject API again performs per-record S3 writes with no buffering, so it is the most expensive of the batch-capable options and provides no batching benefit over the direct IoT rule.Community Comment Notes
The community voted 57 to 41 for B over A, and the deciding factor was the 900 second buffering interval against the thirty minute requirement, which the top-voted comment confirmed explicitly. The dissenting votes for A argued on simplicity and fewer resources, but they do not account for the per-message Lambda and S3 request cost at a five second ingest interval from hundreds of devices.Official Reference
Related Analysis
Practice All SAP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full SAP-C02 Practice Test →