Using the IAM instance profile is the AWS-recommended, secure, and efficient method. It provides short-term credentials automatically rotated by AWS, avoids hardcoding secrets, and leverages IAM policies for fine-grained access control. The other options introduce security risks (exposing secrets in user data/scripts), operational overhead (managing a bastion or EBS volumes), or are less dynamic.

A cross-region read replica meets the 15-minute RPO (as replication is near real-time) and allows for an RTO within minutes (promotion time). It is more cost-effective than Multi-AZ (which is for high availability within a region, not disaster recovery across regions) and more operationally efficient than managing snapshots or DMS for this specific RDS DR use case. Promoting a replica is a simple, managed operation.

Amazon CloudFront is a Content Delivery Network (CDN) designed for this exact scenario. It caches static content (like product images) at Edge Locations worldwide, serving subsequent requests from the edge with low latency. It is cost-effective for read-heavy, static content and requires no application change—you simply use the CloudFront URL instead of the S3 URL. S3 Transfer Acceleration optimizes uploads, not downloads. Global Accelerator is for improving performance of non-cacheable, dynamic applications. CRR would increase storage costs and complexity for managing multiple buckets.

To access resources in a VPC (like RDS), a Lambda function must be explicitly configured with VPC settings (subnets and security groups). The security group attached to the Lambda function must be allowed egress to the RDS port, and the RDS security group must allow ingress from the Lambda function’s security group. An IAM execution role is always required for Lambda, but it governs AWS service permissions, not network access. The other options compromise security (making RDS public) or are incorrect (Lambda doesn’t have a static IP, and VPC endpoints are for accessing AWS services, not RDS).

For an I/O-intensive batch job, the bottleneck is likely disk performance. i3 instances provide very high, low-latency I/O via local NVMe SSD instance storage, which is ideal for temporary processing of data sets. This is more performance-effective for this specific workload pattern than simply scaling up general-purpose compute (m5.4xlarge) or using expensive provisioned IOPS EBS. Migrating to Lambda might be possible but could require a significant architectural rewrite and may not be suitable for all batch processing logic.

Amazon SQS (Simple Queue Service) is a fully managed message queuing service designed for this exact scenario. It enables asynchronous, decoupled communication between tiers. The web tier can send messages to the queue, and the application tier instances can poll and process them at their own pace. SQS guarantees at-least-once delivery and retains messages if no consumer is available, fulfilling the requirement for temporary unavailability. SNS is a pub/sub service better for fan-out, not guaranteed delivery to a processing tier. A load balancer is for synchronous request/response. Amazon MQ is for legacy protocols, not needed here.

This is a canonical serverless data ingestion and analytics pipeline. IoT Core collects device data. Kinesis Data Firehose can buffer, transform (with Lambda), and batch load the streaming data directly into S3, the durable store for a data lake. Amazon Athena then provides serverless SQL querying capabilities on the data in S3. The other options either introduce unnecessary server management (EC2, Batch), are not optimized for a data lake/analytics use case (DynamoDB is a NoSQL key-value store), or are less suited for continuous streaming ingestion into a queryable lake (Redshift is a data warehouse, better for structured, loaded data).

For ElastiCache for Redis, enabling Multi-AZ with Automatic Failover is the primary high-availability feature. It maintains a synchronous standby replica in a different AZ. If the primary node fails or becomes unavailable due to AZ issues, ElastiCache automatically detects the failure and promotes the replica to primary, typically within a minute. This is a managed solution requiring no custom application logic. Simply adding more nodes to a cluster (without Multi-AZ) doesn’t guarantee failover across AZs. Managing two separate clusters adds significant application complexity.

S3 Glacier Flexible Retrieval is designed for archival data accessed 1-2 times per year, with retrieval times of minutes to hours, which is acceptable for annual audits. It offers significantly lower storage costs than S3 Standard-IA (which is for infrequent access needing millisecond retrieval). Intelligent-Tiering would not move objects to the Glacier storage classes, so it wouldn’t achieve the same level of savings for true archival. Manual movement is not scalable or automated. Glacier Flexible Retrieval provides the optimal balance of cost, durability, and retrieval performance for this use case.

Using the IAM instance profile is the AWS-recommended, secure, and efficient method. It provides short-term credentials automatically rotated by AWS, avoids hardcoding secrets, and leverages IAM policies for fine-grained access control. The other options introduce security risks (exposing secrets in user data/scripts), operational overhead (managing a bastion or EBS volumes), or are less dynamic.0