Soru

Zorluk: ZorDatabase and Storage Strategy

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?

  1. Configure Amazon DynamoDB Global Tables for the active container tracking database to achieve multi-region replication and meet the RTO and RPO objectives.Cevap
  2. 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
  3. C
    Deploy 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.
  4. D
    Implement 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.
  5. E
    Store 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.

Cevap

The correct strategy is to use Amazon DynamoDB Global Tables to meet the active tracking database's sub-second latency, multi-region availability, and RTO/RPO requirements. Additionally, a DynamoDB Stream should capture changes, and Kinesis Data Firehose should deliver them to Amazon S3, allowing Amazon Athena to cost-effectively run ad-hoc queries on the historical telemetry.
The correct options implement a highly available, low-latency tracking database using Amazon DynamoDB Global Tables, which meets the sub-minute RPO and sub-15-minute RTO through continuous cross-region replication. For historical analytics, streaming changes via DynamoDB Streams and Kinesis Data Firehose to Amazon S3 allows cost-effective storage. Ad-hoc analytics can then be performed using Amazon Athena without impacting the production transactional database. Furthermore, using customer-managed KMS keys allows for the modification of key policies to enable secure cross-account decryption for external auditing services.

Adım Adım Çözüm

1
Identify the requirements for the active tracking database, which demands high write throughput, sub-second query latency, and multi-region replication with RTO < 15 minutes and RPO < 1 minute.
Select Amazon DynamoDB Global Tables because it provides active-active replication with replica latency in seconds (meeting RPO < 1 min) and near-zero recovery time (meeting RTO < 15 min).
Standard relational database replication or backup/restore methods cannot guarantee both sub-second query latencies and a sub-minute multi-region RPO.
2
Evaluate the historical data retention and analytical query requirements.
Choose to stream data out of DynamoDB using DynamoDB Streams and Kinesis Data Firehose into an Amazon S3 data lake, then run queries using Amazon Athena.
This keeps storage costs low (S3) and ensures analytical query costs are pay-per-query (Athena) without degrading the performance of the active tracking database.
3
Evaluate the security and cross-account access requirements for encryption.
Identify that AWS-managed KMS keys cannot be modified or shared across accounts, requiring customer-managed KMS keys for the external auditor's cross-account access.
Using customer-managed KMS keys is required because policies of AWS-managed keys cannot be modified to grant external cross-account decryption permissions.

Anahtar Kavram

Designing high-performance, cost-effective global database and storage strategies using Amazon DynamoDB Global Tables, S3, Athena, and AWS KMS Customer Managed Keys.
Bu soruyu puanla