What should a solutions architect recommend to meet these requirements?
Store the transactions data into Amazon DynamoDB. Set up a rule in DynamoDB to remove sensitive data from every transaction upon write. Use DynamoDB Streams to share the transactions data with other applications.
Stream the transactions data into Amazon Kinesis Data Firehose to store data in Amazon DynamoDB and Amazon S3. Use AWS Lambda integration with Kinesis Data Firehose to remove sensitive data. Other applications can consume the data stored in Amazon S3.
Stream the transactions data into Amazon Kinesis Data Streams. Use AWS Lambda integration to remove sensitive data from every transaction and then store the transactions data in AmazonDynamoDB. Other applications can consume the transactions data off the Kinesis data stream.
Store the batched transactions data in Amazon S3 as files. Use AWS Lambda to process every file and remove sensitive data before updating the files in Amazon S3. The Lambda function then stores the data in Amazon DynamoDB. Other applications can consume transaction files stored in Amazon S3.
Explanations:
While DynamoDB can store transaction data and DynamoDB Streams can share data with other applications, it does not natively support real-time processing to remove sensitive data on write. This approach may also introduce challenges in handling peak load efficiently.
Kinesis Data Firehose is primarily for batch loading data to destinations like S3 or DynamoDB. While it can integrate with Lambda for processing data, the latency in Firehose is higher compared to Kinesis Data Streams, making it less suitable for near-real-time processing requirements.
Kinesis Data Streams is designed for real-time data processing, allowing for immediate handling of streaming transaction data. Using AWS Lambda to remove sensitive data before storing it in DynamoDB meets the scalability and near-real-time requirements, and applications can consume from the stream effectively.
This option suggests processing batched transaction files in S3, which would not meet the near-real-time requirement as it involves latency due to file processing and updating. It is less efficient for handling high-frequency transactions compared to streaming solutions.
I systematize that the answer is:
Stream the transactions data into Amazon Kinesis Data Streams. Use AWS Lambda integration to remove sensitive data from every transaction and then store the transactions data in AmazonDynamoDB. Other applications can consume the transactions data off the Kinesis data stream.