An IoT platform ingests sensor data via Node.js API servers on EC2 behind an Application Load Balancer and stores it in an RDS MySQL instance on a single 4 TB General Purpose SSD. Sensor count is growing; API servers are overloaded and RDS shows high write latency. Which two actions together provide a permanent, scalable, and cost-efficient resolution as more sensors are added?

The current architecture faces scalability issues with both the API servers and the RDS MySQL database. Using Amazon Kinesis Data Streams to ingest raw sensor data and process it with AWS Lambda addresses the API server overload. Kinesis Data Streams is designed for high-throughput, real-time data ingestion, offloading this burden from the API servers. Lambda provides a serverless, scalable compute solution for processing the data. Re-architecting the database tier to use Amazon DynamoDB instead of RDS MySQL resolves the high write latency and scalability concerns of the database. DynamoDB is a fully managed NoSQL database service that offers single-digit millisecond performance at any scale, making it ideal for high-volume IoT sensor data with varying access patterns. Increasing the MySQL volume size might temporarily improve IOPS but doesn't address the fundamental scalability limitations of a single relational database instance for high-volume writes. Re-architecting to Amazon Aurora with read replicas helps with read scaling but doesn't fully resolve the write scaling challenges for very high-throughput IoT data. AWS X-Ray is for troubleshooting, not a scaling solution, and adding more API servers without addressing the database bottleneck will only shift the problem.