Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 80 discussion

C and E are the correct answers. Option C: Leveraging Amazon Kinesis Data Streams and AWS Lambda to ingest and process the raw data would help to resolve the issues with the API servers being consistently overloaded. By using Kinesis, the data can be ingested and processed in real-time, allowing the API servers to handle the increased load. Using Lambda to process the data can also help to improve the overall performance and scalability of the platform. Option E: Re-architecting the database tier to use Amazon DynamoDB instead of an RDS MySQL DB instance would help to resolve the issues with high write latency. DynamoDB is a NoSQL database that is designed for high performance and scalability, making it a good fit for this use case. Additionally, DynamoDB supports auto-scaling, which can help to ensure that the database can handle the expected growth in the number of sensors.

C + E provide the most scalable, cost-efficient, and future-proof architecture for the company's IoT platform.

B. Rediseñar a Amazon Aurora + réplicas de lectura ➔ ✅ Sí. Aurora es mucho más escalable y eficiente que MySQL RDS normal. Puedes crear réplicas de lectura automáticas para distribuir carga sin mucho esfuerzo manual. Permite crecimiento masivo de forma rentable porque Aurora gestiona réplicas y escalado de manera serverless si quieres (Aurora Serverless v2). C. Kinesis Data Streams + Lambda para ingesta ➔ ✅ Sí. Si los sensores envían muchísimos datos en tiempo real, meterlos directo en EC2+RDS satura todo. Kinesis puede recibir millones de eventos por segundo de forma masiva, almacenar temporalmente y procesarlos por lotes (batching) con Lambda, desacoplando la presión sobre tus APIs y la base de datos. Escala automáticamente y es muy rentable.

A. will not fix the problem B. read replicas will not fix the high write latency D. is for debugging, not a solution This make it C and E

Write performance will be improved by switch RDS to Aurora. RDS to Aurora is smooth transition without too much on the application side. Answer E will application side not just backend DB.

B. Re-architect the database tier to use Amazon Aurora and add read replicas Aurora automatically scales storage up to 128 TB without manual resizing. Faster writes and lower read latency than standard RDS MySQL. C. Use Amazon Kinesis Data Streams and AWS Lambda for ingestion and processing Decouples IoT data ingestion from database writes Kinesis Data Streams ingests large volumes of sensor data without overloading API servers. Scales automatically with the number of sensors. Not E becvause DynamoDB is NOSql and doesn't support MySQL.

B. Re-architect the database tier to use Amazon Aurora instead of an RDS MySQL DB instance and add read replicas. Amazon Aurora is a managed database service compatible with MySQL, designed for high performance and scalability. Aurora provides better write performance and supports read replicas to handle increased read traffic as the platform grows. This will address the high write latency issue and enable horizontal scaling. C. Leverage Amazon Kinesis Data Streams and AWS Lambda to ingest and process the raw data. Using Amazon Kinesis Data Streams for data ingestion offloads traffic from the API servers, reducing their load and improving scalability. AWS Lambda can process the raw data in real time and pass it to the database or other systems, providing a cost-effective and scalable solution for data processing.

By combining C (Kinesis + Lambda) with E (DynamoDB), you're preparing the platform to handle exponential growth in sensor data while ensuring high availability, scalability, and low latency for both data processing and storage. This solution directly addresses the need for a robust, future-proof architecture capable of supporting massive data volumes without bottlenecks, making it well-suited for the IoT platform's growth.

E would require a shift from relational to a no-sql table - what if there are multiple tables?

C is straightforward. I go for E rather than B, because db shows heavy write latency, not limit. Replacing with Aurora will speed up thing up until a limit. Goal is to deal with it once and for all

By combining options B and C, the company can address the current performance and scalability issues while enabling future growth as more sensors are deployed. Amazon Aurora provides a scalable and high-performance relational database, while Kinesis Data Streams and Lambda offer a serverless and cost-effective solution for ingesting and processing the raw data streams. Option A may provide temporary relief by increasing IOPS, but it doesn't address the scalability and performance limitations of RDS MySQL. Option D can help identify application issues but doesn't solve the underlying database problems. Option E is not ideal as DynamoDB is a NoSQL database, and the existing application is likely designed for a relational database like MySQL or Aurora, requiring significant changes to the application code and data modeling.

C. Leverage Amazon Kinesis Data Streams and AWS Lambda to ingest and process the raw data. E. Re-architect the database tier to use Amazon DynamoDB instead of an RDS MySQL DB instance.

What discards B is "Add read replicas", the problem is writing the new data in the DB, adding Read replicas will increase the cost and this is not what question requests "maintain cost"

Write performance will be improved by switch RDS to Aurora. RDS to Aurora is smooth transition without too much on the application side. Answer E will application side not just backend DB.

Option CE and BC. The only reason I choose E over B because said SO. Per AWS, DynamoDB is suitable for IoT ( Sensor data and log ingestion) https://docs.aws.amazon.com/whitepapers/latest/best-practices-for-migrating-from-rdbms-to-dynamodb/suitable-workloads.html

CE, kinesis + lambda & Dynamodb

Switching from RDS mysql to aurora will improve performance, by up to 10 times, which could solve the write issue. Switching from relationship database to nosql is not practical, need re-engineering whole application. plus, the performance improvement of nosql are around data read, not data write ( creating/updating indexes is a huge effort)