Troubleshooting practice questions

Network connectivity issues

Why it fails: Network connectivity issues are classified as system status check failures because they typically originate from AWS-side infrastructure, such as loss of power, network link outages, or routing problems. Instance status checks, on the other hand, monitor the health of the guest OS and applications, so a problem that is purely external to the instance would not trigger a failed instance status check. Therefore, while network issues may make the instance unreachable, they would be indicated by a system status check, not the instance status check the administrator is troubleshooting.

Detached EBS root volume

Why it fails: A detached EBS root volume would prevent the instance from booting or accessing the operating system entirely, but this scenario is detected by AWS as a system status check failure because the problem lies in the underlying storage attachment infrastructure. The instance status check cannot even begin to run if the root volume is not available, as the OS never loads enough to respond to health checks. Thus, a detached root volume is not a valid cause of an instance status check failure, which requires the OS to be running but unhealthy internally.

Insufficient memory for applications

Why it fails: Insufficient memory for applications can cause performance degradation, swapping, or application crashes, but the Linux or Windows kernel typically remains responsive enough to answer the health probes used by instance status checks. These checks depend on basic OS functionality, such as the network stack and process scheduler, which do not necessarily require sufficient memory for user applications. Therefore, while low memory is a serious problem, it would not directly cause an instance status check failure unless it leads to a kernel panic, which is not the typical outcome.

Use the 'Retain' deletion policy on the IAM role resource.

Why it fails: The DeletionPolicy attribute, including the 'Retain' value, only instructs CloudFormation to preserve a resource when its parent stack is deleted. It has no effect during stack creation and cannot prevent the service from failing when it tries to create an IAM role that already exists. Applying Retain here would be misleading and could leave orphaned roles after stack deletion, but it does nothing to resolve the current naming conflict.

Manually delete the existing IAM role and retry the stack creation.

Why it fails: Manually deleting the pre-existing IAM role might unblock stack creation, but it is not an automated or safe solution. The role may be in use by other applications, and deleting it manually could cause outages or require excessive IAM permissions. Furthermore, this approach sidesteps the root cause: the template explicitly declares a fixed, non-unique name. A proper fix should make the template self-sufficient by generating a unique name rather than requiring an operator to alter the environment.

Use a stack policy to prevent the creation of the IAM role.

Why it fails: Stack policies are JSON statements that control permitted updates and deletions on existing stack resources during a stack update operation. They are completely ignored during the initial creation of a stack, so they cannot prevent CloudFormation from attempting to create a resource with a conflicting name. Even if applied, a stack policy would not exempt CloudFormation from the IAM service's uniqueness constraint; it only governs modification actions, not creation.

Modify the Auto Scaling group to use On-Demand instances instead of Spot

Why it fails: Modifying the Auto Scaling group to use On-Demand instances would indeed eliminate the Spot launch failure, because On-Demand capacity is always available at a fixed price. However, this is a cost-inefficient workaround that discards the primary benefit of Spot pricing, potentially tripling or quadrupling compute costs. The underlying problem is not the instance type but the insufficient Spot bid price, so switching to On-Demand is an overreaction rather than a targeted solution.

Change the Auto Scaling group to a different AWS Region

Why it fails: Moving the Auto Scaling group to a different AWS Region could change the Spot price dynamics, since Spot prices vary by Region and Availability Zone capacity pools. However, this approach is disruptive and rarely a first step: it requires re-provisioning all associated resources, such as VPCs, subnets, load balancers, and data storage, and may introduce latency or compliance issues. The correct action is to adjust the Spot price cap in the existing launch template, which resolves the issue without re-architecting the environment.

Increase the desired capacity of the Auto Scaling group

Why it fails: Increasing the desired capacity of the Auto Scaling group will not resolve the Spot pricing problem, because the desired capacity only defines the target number of instances the group aims to maintain. If instances cannot be launched due to the Spot bid being below the market price, raising the desired capacity simply increases the number of failed launch attempts or keeps the group perpetually below capacity. This change could also strain other resources and does not alter the launch template's pricing parameters, leaving the original failure mode unchanged.

Amazon CloudWatch Logs

Why it fails: Amazon CloudWatch Logs is a centralized log storage and monitoring service that ingests, stores, and surfaces log data from sources such as applications, EC2 instances, or other AWS services. It does not independently capture network traffic; it only receives data that is explicitly sent to it, such as VPC Flow Logs. In this context, CloudWatch Logs could serve as a destination for VPC Flow Logs, but it is not the tool that monitors or captures the traffic itself.

AWS CloudTrail

Why it fails: AWS CloudTrail records API activity across your AWS account, providing an audit trail of management events (and optionally data events) like CreateBucket, RunInstances, or console sign-in operations. It monitors who made which API calls, from which IP address, and when, but it does not capture raw network packets or IP traffic flowing between resources. CloudTrail is a governance and compliance tool, not a network traffic monitoring solution.

AWS Config

Why it fails: AWS Config evaluates your AWS resource configurations against desired policies and records configuration changes as configuration items. It offers a history of resource settings, compliance status, and relationships between resources, but it has no visibility into the actual data packets traversing your VPC. AWS Config is designed to answer 'what is my resource's state?' rather than 'what network traffic is occurring?' Therefore, it is unsuitable for network traffic monitoring.

The FreeStorageSpace metric is not available for the selected DB instance class.

Why it fails: The FreeStorageSpace metric is a standard RDS CloudWatch metric that is emitted for every DB instance class, from db.t3.micro to db.r5.24xlarge, across all storage types (gp2, gp3, provisioned IOPS). A lack of disk space alarms cannot be caused by the instance class omitting this metric; if the metric were unavailable, the alarm would stay in INSUFFICIENT_DATA, not fail to trigger when storage actually filled.

The alarm was configured to use a static threshold but the metric is not emitted during storage operations.

Why it fails: CloudWatch alarms evaluate the latest available metric points against a threshold regardless of whether a static or anomaly-detection threshold is used. FreeStorageSpace is published continuously (typically every 60 seconds for RDS), including during storage operations, so the metric cannot be 'not emitted' during writes or other I/O. The alarm's threshold type and metric emission schedule are unrelated to the delayed trigger.

The alarm was monitoring the wrong metric, such as 'Storage' instead of 'FreeStorageSpace'.

Why it fails: Amazon RDS exposes a FreeStorageSpace metric measured in bytes, but it does not expose a standard metric simply named 'Storage'. If you mistakenly monitored a custom or non-existent metric, the alarm would never receive data points and would remain in INSUFFICIENT_DATA instead of entering ALARM. Since the described issue is an alarm that failed to trigger on an existing storage problem, the correct fix is to use FreeStorageSpace with a suitable threshold, not to point at a nonexistent 'Storage' metric.

Export query results directly to an S3 bucket.

Why it fails: CloudWatch Logs Insights does not provide a native one-click export of query results to S3. The service's export-to-S3 functionality (via the console or aws logs export-task API) is designed to export entire log groups in a compressed GZIP format, not the filtered/aggregated output of an Insights query. To persist query results to S3, you must orchestrate it yourself by calling StartQuery and GetQueryResults via the SDK and then writing the returned data to an S3 bucket using your own code or a Lambda function.

Schedule queries to run at a specific time.

Why it fails: CloudWatch Logs Insights is an interactive, on-demand query engine and does not support native scheduling or cron-based recurring execution. There is no console button or API to schedule a Insights query; any recurring analysis must be built externally, for example, by using Amazon EventBridge rules to trigger an AWS Lambda function that programmatically runs the query via the StartQuery API and processes the results. This distinction is why 'Schedule queries to run at a specific time' is not a valid feature of the service itself.

Reboot the instance.

Why it fails: Rebooting the instance performs a soft reset of the guest operating system but does not migrate the workload to a different physical host. If the underlying host has degraded hardware or lost network connectivity, the system status check will continue to fail after a reboot because the instance remains on the same problematic host. Reboot is appropriate for addressing OS-level hangs or software hangs, not for resolving AWS-detected infrastructure faults.

Restore the instance from the latest AMI.

Why it fails: Restoring from the latest AMI is a disaster-recovery action that replaces the entire instance with a fresh one built from a saved image, which is excessive and destructive for a running-instance hardware failure. It would lose all data on instance store volumes and any changes made after the snapshot, and it does not directly address the underlying host fault that is already in progress. This action should be reserved for scenarios like corruption or accidental deletion, not for troubleshooting a single degraded host.

The alarm is in the 'OK' state and not 'INSUFFICIENT_DATA'.

Why it fails: If the alarm were in the INSUFFICIENT_DATA state, it would indicate that CloudWatch lacked enough metric samples to evaluate the threshold—often due to missing data or down instances. However, an OK state means CloudWatch is receiving valid CPUUtilization data and evaluating it successfully. The real reason the alarm isn't firing is that the metric must remain above 80% for two consecutive 5-minute evaluation periods, and short spikes don't satisfy that sustained-breach condition.

The CPUUtilization metric is not enabled by default for EC2 instances.

Why it fails: EC2 CPUUtilization is always available and published to CloudWatch at no additional charge for all instances, regardless of the operating system or instance type. With basic monitoring, the metric is reported every 5 minutes; with detailed monitoring, it is reported every 1 minute. Therefore, the metric is certainly enabled and present, so the absence of this alarm cannot be attributed to a missing metric. The failure to trigger must be caused by the alarm's evaluation logic requiring sustained high utilization over multiple periods.

The alarm period is set to 5 minutes, but the metric is reported every 1 minute.

Why it fails: The alarm period defines the time window over which each data point is aggregated, and a period of 5 minutes is perfectly compatible with metric data arriving every 1 minute—CloudWatch simply aggregates the 1-minute samples into a 5-minute average. The mismatch between period and metric reporting frequency is not the cause of the failure. Rather, the problem is that the alarm requires two consecutive periods of breach, so even though fresh data is arriving every minute, the sustained 10-minute threshold is not met.

The VPC peering connection is not properly configured for TCP traffic

Why it fails: A VPC peering connection operates at the network layer and does not inspect or filter traffic by protocol; it simply provides connectivity between the two VPCs. If the peering connection were improperly configured, all IP traffic—including ICMP and TCP—would be affected, not just TCP on port 443. The fact that ICMP succeeds indicates the peering link itself is functional, and any TCP-only failure must be caused by a layer above the peering connection, such as routing, security groups, or NACLs.

The route tables in the VPCs do not contain a route for the other VPC's CIDR

Why it fails: Route tables in a VPC are protocol-agnostic—they direct packets based on destination CIDR, not on whether the payload is ICMP, TCP, or UDP. If the route tables in either VPC lacked the route for the other VPC's CIDR, the ICMP echo request or reply would also be dropped, since routing is required for all packet types. Because ICMP traffic is reaching the instance successfully, the route tables must contain the necessary peering routes for both directions. Therefore, missing routes cannot be the cause of a TCP-only connectivity problem.

The security group on the EC2 instance is blocking inbound TCP traffic on port 443

Why it fails: The question explicitly states that the security groups are configured to allow all inbound and outbound traffic, so a security group rule cannot be blocking inbound TCP on port 443. Even if the security group were more restrictive, security groups are stateful—return traffic for an allowed outbound connection is automatically permitted without an explicit inbound rule. Since the issue is specifically with return traffic on ephemeral ports, a stateful security group would not drop those packets, whereas a stateless NACL would. This option contradicts the given facts and the observed symptom.

The security group inbound rule for HTTPS is misconfigured.

Why it fails: The security group already has an inbound rule permitting HTTPS (port 443) from the required sources, so a misconfigured inbound rule cannot explain the failure. If the rule were missing or too restrictive, the TCP handshake would time out before reaching the instance, affecting all traffic, including SSH. The scenario indicates SSH works, and a security group is stateless only if it is a network ACL; a security group issue would not selectively block port 443 while leaving port 22 open unless the rules explicitly allow that. Given the rules are correctly configured, the root cause must be at the guest OS or application layer.

The instance has an incorrect route table entry.

Why it fails: A route table entry applies to all traffic leaving the subnet, not to specific destination ports. Since SSH connectivity to the instance succeeds, the instance must have a valid route back to the client's network, and any route table misconfiguration would disrupt all IP connectivity, not just HTTPS. The fact that port 443 fails while port 22 succeeds points to a service-level issue on the instance rather than a network-layer routing problem. Therefore, an incorrect route table entry is not a plausible cause for this port-specific failure.

The instance has insufficient CPU credits.

Why it fails: Insufficient CPU credits would cause the instance to be throttled to the baseline CPU performance, but the scenario explicitly states CPU utilization is 5%, which indicates the instance is not resource-constrained. If credit exhaustion were the issue, you would typically observe high CPU utilization near the baseline, overall poor performance, or a CloudWatch alarm for CPU credit balance, not a complete failure of a single port. Moreover, CPU throttling affects all processes on the instance, so SSH sessions would also be sluggish or fail. Therefore, the lack of HTTPS connectivity is unrelated to CPU credit availability.

The IAM role is not assigned to the Lambda function's execution role.

Why it fails: This answer is incorrect because the execution role is already attached to the Lambda function; otherwise the function would have no permissions to call any AWS services or even start execution. The administrator is troubleshooting an existing function whose role is properly assigned, as confirmed by checking the function configuration. The problem lies not in role assignment but in the scope of the permissions within that role, specifically the resource ARN used for the log group.

The Lambda function is in a VPC without a VPC endpoint for CloudWatch Logs.

Why it fails: This answer is incorrect because a Lambda function in a VPC can still publish logs to CloudWatch Logs using a NAT gateway or a VPC interface endpoint is not required. Without a VPC endpoint, the function can reach the public CloudWatch Logs service through a route to an internet gateway via the NAT device. Since the question does not mention a NAT gateway being absent and the log group name mismatch is a more specific cause, this option is not the correct explanation.

The policy does not include the logs:PutLogEvents permission.

Why it fails: This answer is incorrect because the IAM policy already grants the logs:PutLogEvents action, so the permission is present. The issue is that the Resource ARN in that policy statement is scoped to a log group name that does not match the one Lambda actually creates. If the action were missing, the error would be an explicit access denied for the logs:PutLogEvents action, rather than a log group name mismatch.

Use CloudWatch metrics for RDS and create a dashboard for CPU utilization.

Why it fails: CloudWatch metrics for RDS provide aggregated, instance-level CPU utilization but offer no visibility into which specific SQL statements are consuming those CPU resources. A dashboard can display the overall trend or alert on thresholds, but it cannot attribute high CPU to a particular query, so it fails to isolate the root cause needed for this troubleshooting scenario.

Enable Enhanced Monitoring for the RDS instance and view the CPU metrics.

Why it fails: Enhanced Monitoring provides OS-level metrics such as vCPU, memory, and process-level CPU usage for the RDS instance's host, but it does not map that CPU consumption to individual database queries or sessions. It may show that the instance is CPU-heavy or that a particular process like MySQL is using CPU, but it cannot reveal which SQL statement is responsible, leaving the diagnostic incomplete.

Enable CloudWatch Logs for the RDS instance and filter for slow query logs.

Why it fails: Slow query logs only capture queries whose execution time exceeds the long_query_time threshold, which measures duration—not CPU consumption. A CPU-intensive query can execute quickly and never appear in slow query logs, while a slow query might be caused by lock waits or I/O rather than CPU, so filtering these logs could either miss the problematic query or produce misleading results.

Enable detailed CloudWatch Logs and search for 'timeout' strings.

Why it fails: Enabling detailed CloudWatch Logs and searching for 'timeout' strings would only confirm that a timeout occurred, not which code path caused it. Lambda's native logging captures stdout/stderr and platform-generated START/END/REPORT messages, but these provide aggregate duration (e.g., 'Duration: 1500.23 ms') rather than per-line timings. A timeout search might reveal the final error, but it cannot break down execution time across individual API calls or computational steps inside the function. This approach lacks the subsegment-level detail that X-Ray's trace data provides.

Set a CloudWatch Metric Filter for 'Duration' and create an alarm.

Why it fails: Setting a CloudWatch Metric Filter for 'Duration' and creating an alarm gives you only aggregate performance statistics, such as average or percentile durations across all invocations. A metric filter would parse the 'Duration' value from Lambda's REPORT log lines, but that represents total function time, not the time spent on individual code statements or SDK calls. The alarm can notify you that a problem exists (e.g., p95 duration exceeded), but it cannot localize the slowness to a specific line or external service. For that, you need per-request trace data like X-Ray's segments, which break down execution into measurable subcomponents.

Enable AWS CloudTrail data events for the Lambda function.

Why it fails: AWS CloudTrail data events for Lambda record management and invoke API actions made against the Lambda service, such as 'Invoke' or 'UpdateFunctionCode', but they do not inspect the internal execution of your function. Even if you enable data events for the specific function, you will see that an invocation occurred and from which principal, but you will not get any timing breakdown of the code that ran inside the container. CloudTrail's logs are designed for auditing API activity and security analysis, not for profiling application performance. X-Ray, by contrast, runs inside the execution environment and can capture the duration of every code block and downstream interaction.

The CloudWatch agent is not running on the instance.

Why it fails: If the `amazon-cloudwatch-agent` service were actually stopped or crashed, it would make no API calls at all, and you would not observe a policy-related failure; instead, the agent log would be silent and the `/var/log/aws/amazon-cloudwatch-agent` directory might not even exist. The administrator has already confirmed the agent is installed, and the symptom is that it fails to deliver logs, not that the process is down. Checking with `systemctl status amazon-cloudwatch-agent` would show the service active, and a stopped service cannot produce the IAM resource-mismatch error that the question implies, so this is not the correct explanation.

The IAM role does not have permission to describe log groups.

Why it fails: The `logs:DescribeLogGroups` action is a read-only listing operation used primarily by the AWS Management Console and CLI for browsing log groups; it is not part of the log-ingestion data path. To send logs, the CloudWatch agent needs only `logs:CreateLogGroup` (if the group does not exist), `logs:CreateLogStream`, and `logs:PutLogEvents` — and in this scenario those permissions are already granted on the `MyAppLogs` ARN. A role without `DescribeLogGroups` can still append events to a known log group and stream; missing this permission would not stop the agent from writing logs, so it cannot be the cause of the delivery failure.

The instance does not have outbound internet access to reach CloudWatch Logs.

Why it fails: While the CloudWatch agent normally needs outbound connectivity to reach `logs.<region>.amazonaws.com` on HTTPS, this scenario's failure mode is an IAM authorization issue, not a network issue. A lack of internet access would produce connection timeouts, DNS resolution failures, or `RequestError` messages in the agent's log, not an `AccessDeniedException` caused by a resource name mismatch. Moreover, if the instance is in a private subnet, it could still send logs through a VPC endpoint without any internet gateway, so the absence of outbound internet is not inherently fatal and is not the most likely explanation here.

Enable cross-zone load balancing.

Why it fails: Cross-zone load balancing affects how traffic is distributed across healthy targets in multiple Availability Zones, not whether those targets are considered healthy. Even with cross-zone load balancing enabled, the ALB will still return a 503 if every target in the target group fails its health check. This option addresses load distribution and capacity utilization but has no influence on the health state registration or the health check evaluation process that determines target eligibility.

Increase the idle timeout on the load balancer.

Why it fails: The idle timeout on an Application Load Balancer controls how long the load balancer keeps a connection open when no data is transmitted, which is relevant for long-lived HTTP connections that may need a larger timeout for activities such as file uploads or streaming. A 503 error is generated during the request routing phase when no healthy targets are available to handle the request, not because of a connection being dropped due to inactivity. Increasing the idle timeout would not change the underlying health status of the EC2 instances and therefore cannot resolve the Service Unavailable response.

Add more subnets to the load balancer.

Why it fails: Adding more subnets to the load balancer improves its availability by allowing it to scale across additional Availability Zones, but this does not repair the health check status of the existing registered targets. If the current targets are unhealthy, the ALB still has zero eligible targets in its target group, so any request from any subnet will result in a 503. The root cause is target-level health, not the load balancer's network footprint; thus, expanding subnets is a distraction from the actual issue.

Increase the instance memory by changing to r5.large.

Why it fails: r5.large is a memory-optimized instance that provides 16 GiB of RAM, significantly more than the current instance, but it does not alleviate CPU saturation. The symptom is high CPU utilization or a low CPU credit balance, not memory pressure, so adding RAM leaves the actual bottleneck untouched. Moreover, r5.large has the same vCPU count as many current generation instances, so it would not meaningfully increase compute throughput for a CPU-bound workload.

Enable EBS-optimized on the instance and use provisioned IOPS SSD volumes.

Why it fails: Enabling EBS optimization and switching to provisioned IOPS (io1/io2) volumes boosts storage throughput and reduces EBS wait times, but this has no effect on how many CPU cycles the application receives. A CPU-bound process will remain starved for compute even with extremely fast storage. EBS optimization adds dedicated network connectivity to EBS, and PIOPS guarantees I/O performance, but neither increases vCPU capacity or resolves a negative CPU credit balance.

Increase the size of the EBS volume to improve disk throughput.

Why it fails: Increasing the EBS volume size raises the baseline I/O limits for gp2 volumes, but disk I/O has not been identified as the limiting factor in this scenario. The application's slowness is driven by CPU exhaustion or throttling, so adding storage throughput will not reduce CPU utilization or allow more instructions per second. In fact, resizing the volume would incur additional costs and administrative overhead while providing zero benefit to a CPU-bound workload.

Increase the number of EC2 instances to reduce the load on the database.

Why it fails: Scaling out EC2 instances only adds application capacity and increases the pool of concurrent connections to the database. If slow queries are consuming CPU, I/O, or lock resources, more instances will amplify contention and potentially degrade performance further. The underlying issue is likely an inefficient SQL statement or missing index, which must be identified before any capacity changes are considered.

Add an ElastiCache Redis cluster to cache database queries.

Why it fails: An ElastiCache Redis cluster can reduce repeated identical read queries, but it does nothing for slow-running queries that miss the cache, for write-heavy workloads, or for queries triggered by unique user parameters. Cache misses still traverse the full query path, and if the slowness stems from resource saturation or suboptimal execution plans, caching masks the symptom without resolving the root cause. Diagnostic analysis of the actual queries is required first.

Create a Read Replica and offload read traffic to it.

Why it fails: A Read Replica offloads read-only traffic to a separate endpoint, but asynchronous replication means writes still hit the primary and replicas can lag. If the slow web app is caused by long-running transactions, lock contention, or expensive queries that generate high CPU on the primary, a replica merely distributes the same inefficient workload. It does not improve the performance of the specific queries that are saturating the database.

Add SQS permissions to the Lambda execution role.

Why it fails: Adding SQS permissions to the Lambda execution role grants the function identity access to poll, receive, and delete messages from the queue, but it does not affect Lambda's ability to launch execution environments. When reserved concurrency is set to 0, the Lambda service throttles every invocation before your code runs, so even a perfectly permissioned role will never see a message delivered. IAM permissions are a prerequisite for SQS integration, but they cannot overcome an explicit concurrency cap of zero.

Configure a dead-letter queue for the Lambda function.

Why it fails: A dead-letter queue (DLQ) is a destination for events that have failed after all retries or exhausted the maximum-age limit; it is a safety net, not a processing enabler. If the function has zero reserved concurrency, events are throttled and may be discarded or retained depending on source type, but configuring a DLQ only redirects failures and still does not allow a single invocation to succeed. The root cause remains the concurrency configuration, not error-handling policy.

Increase the batch size in the event source mapping.

Why it fails: Batch size controls how many records from the SQS queue are included in a single Lambda invocation, and increasing it can improve throughput by reducing per-message overhead. However, if the function has zero reserved concurrency, every invocation—regardless of batch size—is throttled before execution, so no messages are processed at all. Changing batch size is a performance-tuning lever after the invocation path is unblocked, not a solution to a complete lack of execution capacity.

Place the S3 bucket in a different AWS region to reduce latency.

Why it fails: Moving the S3 bucket to a different region does not resolve a Lambda timeout because the timeout is enforced on the function's total execution duration, not on network round-trip time. Even if latency to Amazon S3 is reduced, the function code may still take longer than the configured timeout to process the file. Additionally, changing regions could actually increase latency if the Lambda function remains in its original region, and it may introduce compliance or data sovereignty issues.

Enable provisioned concurrency for the Lambda function.

Why it fails: Provisioned concurrency pre-warms Lambda execution environments to reduce cold start latency, but it has no effect on the function's maximum execution time. The timeout is a hard limit on how long an invocation can run, and once that limit is reached, the execution is terminated regardless of how many concurrent environments are available. Therefore, this option incorrectly conflates performance latency with the fundamental execution duration constraint.

Configure EC2 Auto Scaling to launch more instances for the Lambda function.

Why it fails: EC2 Auto Scaling manages the horizontal scaling of Amazon EC2 instances based on policies, but Lambda functions do not run on EC2 instances that you manage or control. AWS Lambda is a serverless compute service where scaling is automatic and handled entirely by the service based on request rate. Launching additional EC2 instances would not affect Lambda's execution environment, so this option is not a valid remedy for a Lambda timeout.

The instance type is too small for the workload.

Why it fails: The RDS instance class determines vCPU and memory, but for gp2 storage, the baseline IOPS and burst capability are governed by the volume's size in GiB, not the instance type. Resizing the instance vertically would not raise the gp2 volume's baseline IOPS, so the I/O credit exhaustion — and resultant throttling — would persist unchanged.

The database is experiencing write contention.

Why it fails: Write contention occurs when multiple sessions compete for row or table locks, typically surfacing as elevated WriteIOPS, high lock wait time, or increased queue depth. Because the reported WriteIOPS is low, the database's write path is not saturated; the bottleneck is instead a read-heavy pattern that is depleting the gp2 burst balance, making write contention an implausible diagnosis.

The network bandwidth is insufficient.

Why it fails: Network bandwidth is the throughput of the connection between the application and the RDS endpoint, and it does not affect how EBS volumes deliver disk I/O. The throttling symptom is caused by the EBS volume's credit exhaustion, which is a storage-level constraint independent of network throughput; even with unlimited network bandwidth, the volume would still throttle to its baseline IOPS.