A logistics enterprise is designing a real-time container tracking and telemetry analytics platform. The system must ingest location updates from 500,000 global transport containers every 10 seconds (write-heavy NoSQL workload). Users require sub-second latency when querying the current status of any container. For auditing and long-term analytics, historical telemetry must be stored indefinitely with minimal storage and query costs. The disaster recovery requirements dictate a Recovery Time Objective (RTO) of less than 15 minutes and a Recovery Point Objective (RPO) of less than 1 minute for the active container database. In addition, an external auditing service in a separate AWS account must be able to periodically query the historical logs. Which two database and storage strategy options should the solutions architect choose to meet these requirements?
- Configure Amazon DynamoDB Global Tables for the active container tracking database to achieve multi-region replication and meet the RTO and RPO objectives.Cevap
- Enable a DynamoDB Stream on the active tracking table, use Amazon Kinesis Data Firehose to capture the stream and write the partitioned telemetry data to an Amazon S3 bucket, and use Amazon Athena to run ad-hoc queries on the historical data.Cevap
- CDeploy Amazon RDS for PostgreSQL with a Multi-AZ standby deployment, and configure the application to direct analytical read queries to the standby database instance to offload read traffic from the primary instance.
- DImplement a multi-region disaster recovery strategy by taking periodic snapshots of the database every 4 hours, copying the snapshots to a secondary region, and using AWS CloudFormation to automatically spin up a pilot light database environment during a failover.
- EStore the historical telemetry logs in an Amazon S3 bucket encrypted with the default AWS-managed KMS key (aws/s3), and modify the key policy to grant decrypt permissions to the external auditor's AWS account.