Design High-Performing Architectures practice questions

Set reserved concurrency to a low fixed number.

Why wrong: Reserved concurrency limits the maximum number of simultaneous executions, but it does not pre-initialize environments or reduce the time needed to start them. In this scenario, it could even make bursts worse by capping throughput too aggressively.

Increase the Lambda timeout to 15 minutes.

Why wrong: Raising the Lambda timeout to 15 minutes only changes the maximum execution duration for each invocation; it does not affect how quickly execution environments are initialized or how fast the service scales out. Cold starts occur when a new environment is provisioned, and a longer timeout does nothing to pre-warm environments or reduce the time taken to load the runtime and function code. In fact, a longer timeout could adversely affect performance by allowing slow invocations to occupy resources longer, and it does not address the root cause of startup latency.

Add an SQS dead-letter queue to reduce startup latency.

Why wrong: An SQS dead-letter queue (DLQ) is a reliability mechanism that captures failed event records for later debugging or replay, but it has no role in Lambda initialization or scaling. When Lambda is invoked asynchronously with an SQS source, the DLQ simply holds messages that exceeded retry limits; it does not pre-warm execution environments and cannot reduce cold-start latency. Adding a DLQ adds complexity and improves robustness for failures, but it leaves the p95 latency problem entirely untouched.

Scale up only the writer instance and keep all queries on it.

Why wrong: Scaling up the writer instance by increasing its size (e.g., from r6g.large to r6g.2xlarge) provides only temporary and limited relief because all reads and writes still contend for the same CPU, memory, and I/O on a single node. Aurora storage is already separate from compute, but the writer instance alone must process every write and every read that is not routed elsewhere, so it remains the single point of contention. Aurora instance sizes have upper limits, so this approach cannot sustain growth and does not address the architectural pattern of separating read-heavy traffic from write-heavy traffic.

Replace the cluster with a single-AZ RDS instance to reduce replication overhead.

Why wrong: Replacing the Aurora cluster with a single-AZ RDS instance removes all read scaling capability because there are no read replicas, forcing every dashboard query and write onto one database instance. Single-AZ also sacrifices high availability, as a failure causes downtime with no failover target. The original bottleneck is read-heavy load, not replication overhead; Aurora Replicas use the same storage volume with minimal extra write cost, so eliminating them does not solve the problem and makes availability and performance worse.

Move the dashboard to DynamoDB without changing the query model.

Why wrong: DynamoDB is a NoSQL key-value and document database with a different data model, query semantics, and indexing mechanisms than Aurora PostgreSQL. Moving the dashboard to DynamoDB without rewriting the SQL queries, redesigning the schema, and adapting to eventual consistency or using PartiQL carefully would not work. Even if the dashboard were moved, this does not reduce the read load on the Aurora writer if the dashboard still needs the same transactional or relational queries; it also introduces a major application redesign with no direct benefit to the identified read bottleneck.

Resize the writer instance to a larger class so it can handle both writes and reads with fewer slowdowns.

Why wrong: Vertically scaling the writer instance to a larger class gives it more CPU and memory, which can temporarily reduce slowdowns caused by mixed workloads. However, this approach still funnels both writes and read-heavy reporting through the same instance, so resource contention remains. Larger instances are more expensive per hour, and you may reach an instance-size ceiling before read demand is satisfied. It does not provide the architectural separation that dedicated read replicas offer.

Enable cross-region replication for the entire cluster so reporting always runs in the secondary Region.

Why wrong: Cross-region replication creates a second Aurora cluster in a different Region, which is valuable for disaster recovery and low-latency reads in geographically distant locations. For a local production application, however, directing reporting traffic to the secondary Region would add significant network latency and may violate data residency/compliance requirements. Cross-region replication is asynchronous, so the disaster-recovery cluster can lag behind the primary, causing reporting queries to return stale data. It also adds operational complexity and cost far beyond what is needed to solve simple read-write contention in the primary Region.

Disable read replicas and use caching only in the application layer, keeping all queries connected to the writer endpoint.

Why wrong: Application-layer caching only eliminates repeated identical queries, but reporting workloads often include unique aggregates, ad-hoc filters, or time-window scans that miss the cache and hit the database. With no read replicas, every such query—plus all production writes—must compete for the same writer instance's CPU, memory, and I/O. Disabling replicas removes the ability to scale reads horizontally, and cache invalidation becomes complex when writes constantly mutate the underlying data. This approach fails to offload steady read pressure from the writer.

Amazon API Gateway

Why wrong: Amazon API Gateway is a fully managed service for creating, publishing, and securing APIs, with features like authentication, throttling, and request/response transformation. It is restricted to HTTP(S) and WebSocket endpoints and does not act as a general-purpose load balancer for arbitrary TCP or UDP traffic. While it can route to microservices, it adds API management overhead and is not the appropriate service for balancing raw traffic to two application fronts without exposing a REST/WebSocket API contract.

Amazon CloudFront

Why wrong: Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations to improve latency and reduce origin load for HTTP(S) traffic. While it can route requests to different origins based on path patterns, its primary role is acceleration and content distribution, not backend load balancing; it lacks native TCP/UDP load balancing, target group health checks, and IP allowlisting for backend connections. It is therefore unsuitable for a workload split into two app fronts that require direct, scalable traffic distribution across compute resources.

Gateway Load Balancer

Why wrong: Gateway Load Balancer is designed specifically to deploy, scale, and manage third-party virtual appliances such as firewalls, intrusion detection/prevention systems, and deep packet inspection tools. It uses the GENEVE protocol to transparently forward traffic through an appliance chain, rather than acting as a traditional application load balancer. Consequently, it cannot perform HTTP routing or handle real-time UDP services directly, and any traffic sent to it must be destined for a network appliance, not for application endpoints.

Increase the function memory size and rely on faster initialization to reduce cold starts.

Why wrong: Allocating more memory to the Lambda function increases the proportional CPU allocation and can shorten the time needed for certain CPU-bound initialization tasks, such as loading libraries or connecting to databases. However, memory does not pre-provision any execution environments, so during a sharp traffic spike each new concurrent invocation still requires a full cold start—including container spin-up, runtime bootstrapping, and code download—which remains unpredictable. The option also lacks any mechanism to scale warm capacity with demand, so it does not address the specific latency spike pattern the team is trying to eliminate.

Set reserved concurrency equal to the expected peak requests per second for the function.

Why wrong: Setting reserved concurrency to match expected peak requests per second does not warm any execution environments; it merely defines an upper bound on the number of simultaneous invocations for the function and reserves that capacity against other functions in the account. In fact, if the reserved concurrency value is still lower than the actual burst of concurrent requests, lambda will throttle new invocations, causing request failures rather than preventing cold starts. Reserved concurrency is a governance and throttling control, not a way to maintain pre-initialized runtime instances, so it leaves the cold-start latency problem entirely unresolved.

Use an event source mapping with a higher batch size so Lambda triggers earlier and keeps the runtime warm.

Why wrong: Event source mappings apply to event sources such as SQS, Kinesis, or DynamoDB streams. For an ALB-triggered Lambda (synchronous request/response), batch size is not a mechanism to guarantee warm environments or to mitigate cold starts.

Place the instances across several Availability Zones for higher aggregate resilience.

Why wrong: Spreading instances across multiple Availability Zones (AZs) provides resilience by ensuring that the workload can continue even if one entire AZ becomes unavailable. However, traffic between AZs traverses longer physical distances and typically incurs higher and more variable latency than traffic within a single AZ, along with additional per-GB data transfer costs. For a distributed simulation that exchanges frequent, latency-sensitive messages, this cross-AZ overhead would degrade performance substantially, so the resilience benefit does not outweigh the network penalty here.

Use a spread placement group to pack the instances tightly together.

Why wrong: A spread placement group deliberately places each instance on a separate underlying rack, each with its own power and network sources, to maximize fault isolation and reduce the risk of correlated failures. While this is excellent for high availability and critical applications, it does not pack instances tightly together; in fact, it disperses them across distinct hardware, which increases physical distance and network hops. The inherent trade-off is higher inter-instance latency, which directly contradicts the low-latency requirement of a tightly coupled distributed simulation.

Put the workload behind CloudFront so internal node communication is faster.

Why wrong: CloudFront is a content delivery network (CDN) that accelerates delivery of public web content by caching it at edge locations close to end users. It does not sit on the private network path between EC2 instances, nor does it intercept or optimize east-west traffic inside a VPC. For a distributed simulation that uses internal IPs and potentially non-HTTP protocols, CloudFront would be completely out-of-band and would introduce an unnecessary public hop if used at all, making it a poor choice for reducing intra-cluster latency.

Increase the function memory size to the maximum and rely on the larger memory to eliminate cold starts.

Why wrong: Allocating more memory to a Lambda function increases the CPU and network throughput, which can shorten execution time but does not address the initialization phase of a cold start. New execution environments are still created from scratch, including loading the code and initializing the runtime, which the memory setting does not preempt. Additionally, maxing out memory increases your cost significantly, making this a costly and ineffective strategy for latency guarantees.

Configure an ALB with target group health checks to keep Lambda warm by sending periodic requests.

Why wrong: Sending heartbeat requests through an ALB health check can keep one Lambda instance warm, but Lambda functions typically scale out to many concurrent instances, and health checks target only a single instance at a time. When a burst of traffic arrives, the other instances will still face cold starts, so consistency is not achieved. Furthermore, Lambda freezes and times out instances after several minutes of inactivity regardless of health checks, so this workaround is neither reliable nor scalable.

Turn on AWS CloudTrail data events to monitor cold start frequency and tune the runtime accordingly.

Why wrong: CloudTrail data events record API calls and management actions, not internal Lambda performance metrics such as cold start duration. Monitoring cold starts with CloudTrail provides visibility after the fact, but it does nothing to eliminate the latency itself. Tuning the runtime based on historical logs is a reactive process and cannot guarantee consistent low latency for every incoming request.

Provision AWS WAF rules to reduce DynamoDB read latency caused by bots

Why wrong: AWS WAF is a web application firewall that inspects HTTP/S traffic at your CloudFront, Application Load Balancer, or API Gateway layer, filtering out malicious requests like SQL injection or DDoS bots. It has no integration with DynamoDB's data plane and cannot intercept or cache DynamoDB read requests made directly via the AWS SDK or API. Even if you block all bot traffic, the legitimate application reads would still traverse the same DynamoDB path and experience the same hot-key latency; the issue is caching, not threat protection.

Enable multi-region writes in DynamoDB Global Tables to speed up reads locally

Why wrong: Global Tables primarily provides replication across regions for availability and regional access. It does not target latency for hot keys within a single region, and it changes replication/write behavior rather than accelerating DynamoDB point reads.

Add more read capacity units to DynamoDB and avoid caching entirely

Why wrong: Adding more read capacity units (RCUs) increases the number of provisioned reads per second, which reduces throttling and improves throughput under high load, but it does not lower the inherent latency of a single DynamoDB point read. The application's problem is latency for frequently accessed hot keys, not a lack of capacity, so paying for more RCUs would not speed up the response time for those repeated reads. DAX specifically addresses this by serving the hottest items from memory, avoiding the network and disk I/O path to DynamoDB for cached keys.

Lower the TTL to a few seconds so cached objects expire sooner and origin fetches decrease.

Why wrong: Lowering the TTL to a few seconds does not solve the underlying cache fragmentation problem caused by per-user changing headers; it only makes each cache entry expire far more quickly. Once expired, CloudFront must revalidate or re-fetch the object from the origin, even if the same cache key is requested again moments later. With a TTL of a few seconds, the object will frequently be stale, effectively converting steady user traffic into a near-constant stream of origin requests and making the cache hit rate worse, not better.

Disable caching for the affected paths so CloudFront always forwards all headers to the origin.

Why wrong: Disabling caching for the affected paths removes the CDN's ability to serve any request from an edge location. Every user request is forced all the way to the origin, so the cache hit rate drops to zero for those paths and the origin must handle 100% of the traffic it was trying to offload. This not only eliminates the performance and cost benefits of CloudFront but also increases origin load and latency, directly contradicting the goal of reducing origin fetches.

Force all requests to use query-string based caching and include all headers in the cache policy for correctness.

Why wrong: Including high-cardinality, per-user changing headers in the cache key preserves the cache fragmentation problem and keeps the hit rate low. Query-string caching does not address header-driven variability unless the cache key is explicitly designed to exclude the varying elements.

Create a placement group with the 'spread' strategy to separate instances across underlying hardware for fault tolerance.

Why wrong: Spread placement groups instead place each instance on its own distinct rack, each with independent power and networking hardware, to maximize fault isolation and availability. While this eliminates correlated hardware failures, it also ensures physically separated instances with longer network paths and higher inter-instance latency. For a synchronization-heavy workload, this placement inherently increases communication overhead and variability, directly counteracting the low-latency requirement.

Use the default placement strategy and rely on Auto Scaling to keep instances from drifting to different locations.

Why wrong: The default strategy does not guarantee physical co-location for low-latency networking. Auto Scaling changes the set of running instances over time and can introduce placement variation, so it cannot reliably eliminate network latency spikes caused by instance placement.

Avoid placement groups and instead use Amazon S3 for inter-node messaging to minimize direct network traffic between instances.

Why wrong: Amazon S3 is an object storage service, not a low-latency messaging bus; every inter-node communication would require an HTTP/S3 API call, adding connection setup, signing, and request processing overhead measured in tens to hundreds of milliseconds. This is orders of magnitude slower than direct instance-to-instance traffic over a VPC or a cluster placement group's network. Furthermore, S3's consistency model and per-object operations introduce additional complexity without solving the physical placement problem that causes network latency.

Application Load Balancer (ALB) using HTTP/HTTPS listeners with host-based routing

Why wrong: Application Load Balancer (ALB) operates at Layer 7 and parses the HTTP/HTTPS request stream, which means host-based routing depends on the HTTP Host header to select a target. Arbitrary TCP traffic such as a custom binary protocol or a database replication stream does not contain HTTP headers, so ALB cannot inspect or route it meaningfully. Even though ALB supports health checks, its listeners themselves only understand HTTP/HTTPS and gRPC, so it is fundamentally incapable of load-balancing raw non-HTTP TCP streams.

Classic Load Balancer (CLB) configured for TCP health checks only

Why wrong: Classic Load Balancer (CLB) is a legacy Layer 4 load balancer that can accept TCP connections, so merely configuring TCP health checks does not fix its underlying limitations. CLB lacks modern features such as target groups that can register EC2 instances and IP addresses across VPCs, static elastic IP assignments, and the consistent source IP preservation and high-throughput connection handling that NLB provides. Because AWS no longer recommends CLB for new architectures and it is in maintenance mode, using it for high-performance TCP traffic distribution to multiple services is an outdated choice compared with NLB.

API Gateway with a VPC Link to forward raw TCP traffic

Why wrong: API Gateway is a service designed for building HTTP, REST, and WebSocket APIs, not for transparently forwarding raw network-layer TCP segments. A VPC Link integrates API Gateway with private resources in a VPC, but that integration is still an HTTP proxy path: API Gateway forwards HTTP requests to an NLB or other HTTP-compatible endpoint and cannot maintain a raw bidirectional TCP connection for arbitrary protocols. Because API Gateway's model is request/response over HTTP, it cannot replace a Layer 4 load balancer for long-lived non-HTTP workloads like custom socket protocols or database connections.

Set Cache-Control: no-cache so CloudFront always revalidates with the origin

Why wrong: The no-cache directive is frequently misunderstood: it does not tell CloudFront to stop caching, but to store the response and revalidate it with the origin before every use. This means every single request for a versioned asset yields a conditional request to the origin to verify whether the cached copy is still fresh. Because the origin may return a 304 or even a 200 with the full body, the cache hit ratio drops dramatically and origin load rises, defeating the entire purpose of CloudFront for static files. In contrast to immutable, which explicitly tells clients and caches to serve the cached copy without revalidation, no-cache forces the opposite behavior and should be avoided for versioned assets.

Set Cache-Control: max-age=0 and rely on CloudFront to cache by default

Why wrong: Setting max-age=0 marks the object stale immediately, so CloudFront must revalidate against the origin on every request before serving a cached copy. Even though CloudFront retains the object in its cache, each miss triggers a conditional GET (If-None-Match or If-Modified-Since), and the origin typically returns a 304 Not Modified rather than the full payload. This eliminates the benefits of a long-lived edge cache, increases origin requests and latency, and directly contradicts the goal of maximizing cache hit rate for unchanged versioned assets. Relying on 'default caching' does not help because the cache-control directive explicitly disables freshness.

Disable CloudFront caching and forward all headers and query strings to the origin

Why wrong: Disabling CloudFront caching and forwarding all headers and query strings to the origin strips the CDN of its core value: serving identical content from edge locations. Forwarding every header and query parameter expands the cache key, so the same versioned asset requested with different cookies, User-Agent values, or tracking parameters becomes hundreds of separate cache entries, causing fragmentation and overwhelming the origin with cache misses. This configuration forces every request to traverse the full network path to the origin, increasing latency, origin bandwidth, and cost. It also prevents any reuse of cached versions, making the static asset delivery slower and more expensive than without a CDN.

Use a spread placement group to distribute instances across distinct hardware to reduce jitter.

Why wrong: A spread placement group places each instance on a distinct physical rack to maximize fault isolation, which deliberately separates instances from one another. This topological separation increases the network distance and the number of network hops between nodes, causing higher latency and jitter compared to a cluster placement group. Additionally, a single spread placement group is limited to a maximum of seven instances per Availability Zone, which is often insufficient for large distributed training clusters.

Use a partition placement group and place each node into its own partition for uniform latency.

Why wrong: Partition placement groups provide isolation between partitions for very large deployments, limiting blast radius. They are not the best choice for maximizing low-jitter network performance among every node that must communicate constantly within a single AZ.

Do not use a placement group; rely on the default EC2 scheduling to balance latency and availability.

Why wrong: Enabling default EC2 scheduling without a placement group does not guarantee that instances will be co-located on the same physical rack or even the same network segment. The hypervisor scheduler can place instances on different underlying hosts, each with independent network paths, resulting in variable inter-instance latency and jitter. For a latency-sensitive distributed training workload that requires tight synchronization and frequent small-message passing, this unpredictability directly degrades performance and makes it impossible to rely on consistent low-latency communication.

Use an Application Load Balancer (ALB) with UDP listeners and configure TLS passthrough.

Why wrong: ALB is intended for HTTP/HTTPS Layer 7 traffic and does not provide UDP load balancing suitable for low-latency game traffic. Even with TLS passthrough concepts, the missing UDP support makes ALB incompatible with the requirement.

Use Amazon API Gateway with a WebSocket API and keepalive pings to provide UDP-like low-latency delivery.

Why wrong: Amazon API Gateway WebSocket APIs use a persistent TCP-based WebSocket connection, which does not provide the connectionless datagram behavior of UDP. Keepalive pings simply maintain the TCP connection; they do not emulate UDP's low-overhead, best-effort delivery or reduce the overhead of TCP's reliability and flow control. As a fully managed API service, API Gateway is designed for HTTP/WebSocket application messaging, not for raw UDP game traffic load balancing and packet forwarding.

Use a Classic Load Balancer and multiplex UDP over TCP to meet the UDP and low-latency requirements.

Why wrong: The Classic Load Balancer operates at Layer 4, but its listeners are limited to TCP and SSL/TLS; it has no UDP listener capability. Multiplexing UDP datagrams over a TCP byte stream fundamentally changes transport semantics—TCP's reliable delivery, in-order guarantees, and retransmission logic introduce head-of-line blocking and added latency, which is counterproductive for real-time gameplay. Furthermore, CLB is a legacy load balancer without the low-latency, connection-oriented UDP forwarding that game streaming requires.

Increase instance storage throughput limits and disable synchronous replication to speed up all queries

Why wrong: Storage throughput tuning may help some I/O-bound scenarios, but it does not separate dashboard read workload from OLTP write contention. Disabling synchronous replication is not a safe or targeted approach for improving dashboard performance and can change durability/consistency characteristics.

Replace RDS with Amazon S3 because dashboards require SQL result caching

Why wrong: Amazon S3 is a highly durable object storage service, not a PostgreSQL-compatible relational database, so it cannot execute the SQL/select queries a dashboard needs. Even if S3 stored export snapshots or result sets, any caching or aggregation would still require a compute/query engine such as Athena or Redshift, not S3 itself. Replacing RDS with S3 would eliminate the database access layer entirely and therefore would not alleviate, but rather completely break, the dashboard's current read workload.

Move the primary database to a different AWS Region to reduce network latency

Why wrong: Changing regions may affect client network latency, but it does not offload read workload from the primary. The core performance issue described is contention between dashboard reads and primary writes, which read replicas are designed to address.

Increase the Lambda memory size only, without changing how Lambda is invoked

Why wrong: Higher memory increases available CPU and can reduce execution time, which may help average latency. However, it does not guarantee that execution environments are already initialized after a deployment, so cold starts can still occur.

Enable dead-letter queues (DLQ) to retry failed cold starts

Why wrong: Dead-letter queues in Lambda are designed for asynchronous invocation flows: when an event source retries an invocation and it still fails, the event is sent to an SQS queue or SNS topic for later analysis. API Gateway invokes Lambda synchronously, so response errors are returned to the caller immediately and failed events are not routed to a DLQ at all. A cold start is not an invocation failure—it is a successful invocation that merely takes extra time to initialize a new execution environment, so retrying through a DLQ neither prevents the delay nor pre-warms anything.

Attach a CloudFront distribution to cache API Gateway responses for 5 minutes

Why wrong: Caching API responses can reduce origin/API Gateway traffic for repeat reads, but it does not change Lambda’s initialization behavior for requests that do reach Lambda. Cold starts would still occur for any cache misses or uncached requests.

Forward all cookies and query strings so each request is treated as unique.

Why wrong: Forwarding all cookies and query strings in a cache policy makes CloudFront include them in the cache key, so any variation—even a session cookie or tracking parameter—creates its own distinct cached object. Most such variations are irrelevant to the asset's content, so this sharply reduces the cache hit ratio and forces CloudFront to fetch duplicates from the S3 origin, increasing cost and latency.

Switch the bucket to S3 Intelligent-Tiering to reduce CloudFront origin requests.

Why wrong: S3 Intelligent-Tiering is a storage class that automatically moves objects between access tiers to reduce storage cost; it has no effect on CloudFront cache behavior or how often the origin is fetched. CloudFront still needs to pull the object from S3 via the same GET request path whenever a cache miss occurs, and Intelligent-Tiering does not change request routing, latency, or cache hit ratio.

Add more NAT Gateways to improve the speed of CloudFront origin fetches.

Why wrong: CloudFront is an AWS-managed edge service that pulls from your S3 origin over AWS's private network; it never traverses VPC resources like NAT gateways, which are used for outbound internet access from private subnets in a VPC. Adding NAT gateways therefore cannot speed origin fetches or alter CloudFront caching behavior—it only increases cost and has no bearing on the cache hit ratio problem.

Use sc1 because it is optimized for infrequent access and large objects.

Why wrong: SC1 (Cold HDD) is a cold-storage volume type optimized for infrequent, large sequential reads, with maximum IOPS of about 250 per volume and no burst capability. The exhibit shows a transactional database workload requiring roughly 10,000 random IOPS and low latency, far exceeding SC1's performance envelope. Using SC1 would cause severe queue buildup and unacceptable performance, so it cannot address the demonstrated bottleneck.

Use st1 because it provides high throughput for streaming data.

Why wrong: ST1 (Throughput Optimized HDD) is built for high-throughput sequential workloads, such as data warehouses and log processing, with max IOPS around 500 and burst capabilities only for sequential access. The exhibit shows a database requiring about 10,000 random IOPS and suffering queue buildup, which is the opposite of ST1's design point. Random I/O on ST1 would yield poor latency and minimal throughput, so it cannot serve this transactional workload.

Use standard magnetic storage because it is compatible with all EC2 instances.

Why wrong: Standard magnetic storage is a legacy, deprecated volume type with extremely variable latency and throughput, typically a few hundred IOPS at best. While it was historically compatible with many EC2 instances, compatibility does not solve the performance problem shown: the database needs low-latency, high-random-IOPS performance, and magnetic volumes would amplify queue buildup. This option fails on performance and also lacks the reliability and consistency expected for modern database workloads.

Increase the function timeout so throttling is less likely.

Why wrong: Timeout affects how long a request can run, not how many requests can run concurrently. Throttling is typically related to concurrency limits rather than time limits. Increasing timeout does not reserve capacity for another function.

Enable Provisioned Concurrency for every Lambda in the account.

Why wrong: Provisioned Concurrency is useful for reducing cold starts, but it is not primarily a mechanism to guarantee capacity against account-wide spikes. Applying it to every function increases cost. Reserved concurrency is the direct control for prioritizing concurrency capacity.

Reduce the number of IAM policies attached to the Lambda roles.

Why wrong: Reducing the number of IAM policies attached to Lambda roles does not affect Lambda concurrency throttling in any way. IAM policies govern which AWS actions and resources the function can access, but they have no bearing on the execution capacity available to the Lambda service. Throttling (HTTP 429) occurs when a function exceeds its allocated concurrency — either the account-level limit or per-function Reserved Concurrency — not when permissions are overly broad. Simplifying IAM roles improves security and manageability, but it cannot increase the pool of concurrent executions available to the important function.

Choose a compute-optimized instance family such as C6i to increase CPU performance.

Why wrong: C6i instances, based on Ice Lake with high turbo frequencies, are engineered for compute-bound workloads that need fast vCPUs and high sustained CPU performance. But the exhibit shows CPU utilization is consistently low while memory usage sits near the ceiling, meaning the bottleneck is the size of the working set, not the processing speed. Adding compute capacity will not reduce memory consumption or paging activity; the application's heap, cache, or data structures are simply exceeding the instance's RAM. A memory-optimized family like R6i provides more memory per vCPU and is the correct choice when such a clear memory saturation pattern is visible.

Choose a storage-optimized instance family such as I4i to improve block storage throughput.

Why wrong: I4i instances are built around high-performance NVMe instance storage, delivering extremely high disk throughput and low latency for I/O-bound workloads such as transactional databases. However, the exhibit indicates memory near saturation while CPU remains low, with no evidence of storage bottlenecks such as high EBS wait time, disk queue depth, or throughput limits. Even if the application is swapping to instance store, faster disks only mask the symptom; DRAM is still orders of magnitude faster than any NVMe, so providing more RAM via an R6i instance is the correct remedy. Selecting I4i would compound cost without relieving the actual memory contention.

Choose a burstable instance family such as T3 to reduce cost and improve performance.

Why wrong: T3 instances are burstable, relying on CPU credits to provide a baseline level of compute and burst above it only as credits allow. This design is appropriate for transient, low-average CPU workloads, but it does nothing to address the exhibit's sustained memory saturation. Memory pressure is not cured by CPU credits; T3 instances offer the same standard vCPU-to-RAM ratios as other families in many cases, and if the OS begins swapping to disk, application latency will remain high regardless of CPU headroom. Choosing T3 would actually risk throttled performance during sustained use, making it a poor fit for this memory-bound application.