Cloudfront practice questions

Disable CloudFront access logging so fewer requests are recorded and billing decreases automatically.

Why it fails: Disabling CloudFront access logging does not lower the per-request or data-transfer charges that drive your bill; those charges are incurred when CloudFront receives requests and serves bytes to viewers, regardless of whether log files are written. Access log delivery to S3 has its own small storage and PUT costs, so turning it off only removes that separate cost and, more importantly, eliminates visibility into cache hit behavior. Since the core problem is a low cache hit ratio causing excessive origin fetches and data transfers, disabling logging does not address the root cause and may even make it harder to diagnose which objects are generating the most origin traffic. The correct approach is to make objects more cacheable by increasing TTLs and enabling compression, not to stop recording metadata about the requests.

Set the distribution’s origin to use S3 Transfer Acceleration to reduce the number of requests hitting S3.

Why it fails: Transfer Acceleration affects how data is delivered to S3 when accessed, but it doesn’t change whether CloudFront caches objects. If cache hit ratio is low due to TTL or cacheability headers, origin request volume remains high.

Force CloudFront to forward query strings to the origin for all static content so the latest versions are always fetched.

Why it fails: Forwarding query strings to the origin for all static content makes CloudFront treat each unique query string as a separate cache key entry, so even if the underlying file never changes, multiple query string permutations fragment the cache and often result in cache misses. This fragmentation lowers the cache hit ratio and drives more requests back to the S3 origin, which increases origin request costs and data transfer fees—exactly the opposite of the goal. Moreover, using query strings to 'fetch the latest version' is an anti-pattern; modern versioned static assets should embed a version or hash in the object path (e.g., /js/app.v1.js) or use a cache policy with TTLs that reflect immutability, not force revalidation via query parameters. To improve cost, you should configure CloudFront to ignore query strings for static content or use a cache policy that does not include them in the cache key, letting each versioned file be cached and reused efficiently.

A WAF rule that blocks requests without valid JWTs, without using signed URLs

Why it fails: WAF can inspect and block requests, but it is not the primary built-in CloudFront mechanism for time-limited, resource-scoped authorization. Implementing expiring per-user access with JWT validation via WAF is possible in some architectures, but it is not the most direct, native CloudFront feature described for this requirement.

Turning on S3 bucket public access block, without any CloudFront viewer authentication

Why it fails: Blocking public access ensures the objects can’t be fetched directly from S3, but it does not automatically ensure only authenticated users can fetch via CloudFront. If the CloudFront distribution allows access (and the origin access/OAC configuration permits it), requests can still reach CloudFront without user authentication and without a 1-hour expiry control.

Enabling CloudFront geo restriction to allow only one country

Why it fails: CloudFront geo restriction simply evaluates the requester's geographic IP location and either allows or blocks requests based on a country allowlist or blocklist. It cannot distinguish between authenticated and unauthenticated users, nor can it enforce a per-user or per-session expiration window, so it does not limit access to a specific 1-hour period. Geo restriction is designed for content licensing or regional legal constraints, not for temporary secure access to private images; even if the bucket is private, any user in an allowed country could still access the content indefinitely through the distribution unless another authorization mechanism is also configured. Therefore, geo restriction alone fails the requirement for expiring, user-specific authorization.

RDS read replicas

Why it fails: RDS read replicas are designed to scale relational database read throughput by asynchronously copying database transactions to secondary instances. They do not serve or cache static assets stored in Amazon S3, nor do they have any integration with S3 bucket contents. A read replica would still be deployed in a specific AWS Region and would require DNS routing and an application change to use, so it would not reduce latency for users downloading images globally.

A larger S3 bucket

Why it fails: Increasing the size of the S3 bucket has no effect on delivery latency because S3 performance is designed to scale automatically without needing larger buckets; latency is governed by geographic distance and network path between the user and the bucket's region. A bigger bucket does not create edge caches or replicate content to multiple locations, so a user in another hemisphere still traverses the same public internet path to the origin. S3 bucket size is simply a storage quota, not a delivery performance mechanism.

An EC2 Auto Scaling group in one Region

Why it fails: An EC2 Auto Scaling group in one Region adds compute capacity within that single region, but it does not cache static S3 content or place content closer to a global user base. Without a CDN or edge layer, users must still cross the internet to that region, and scaling EC2 instances only helps if the bottleneck is application compute, not geographic distance to static objects. Additionally, introducing EC2 to serve S3 content would require custom software and significant operational overhead for no global latency benefit.

Migrate the session table to Amazon DynamoDB with on-demand capacity and update the application to use DynamoDB for session storage.

Why it fails: DynamoDB can store session state and scale well, but it introduces higher latency than an in-memory cache for session reads and writes. It also adds cost and complexity for a workload that benefits more from a caching layer. While viable, it is not the optimal choice for reducing database bottleneck and improving performance for frequently accessed session data.

Increase the size of the relational database instance and add read replicas, then direct session reads to the replicas and writes to the primary.

Why it fails: Scaling the database and adding read replicas can help with read-heavy workloads, but session writes still go to the primary, and replication lag may cause stale session reads. This does not eliminate the database as a bottleneck and adds cost. It also does not externalize session state as effectively as an in-memory cache.

Enable sticky sessions on the Application Load Balancer and store session state in the local memory of each EC2 instance.

Why it fails: Sticky sessions tie users to specific instances, which can cause uneven load distribution and session loss if an instance fails. Storing sessions locally also makes the application stateful, contradicting the requirement. This approach does not reduce database load in a scalable way and harms availability and elasticity.

Amazon S3 Transfer Acceleration

Why it fails: S3 Transfer Acceleration uses AWS edge locations to accelerate TCP/HTTP transfers to and from Amazon S3 over the public internet. It has no effect on DynamoDB API calls, which go through a completely different control/data plane endpoint, and it cannot cache or prefetch item-level data. As a result, it would not reduce repeated-read latency for this application.

Amazon EFS

Why it fails: Amazon EFS provides scalable, elastic POSIX-compliant file storage via NFS for use with EC2 instances and on-premises servers. It does not natively integrate with DynamoDB as a read cache; using it would require the application to implement custom replication logic and would introduce file-system latency far above DynamoDB's own response times. For repeated single-item reads, EFS cannot satisfy the API pattern or provide item-level caching.

AWS CloudTrail for data plane reads

Why it fails: AWS CloudTrail, when configured with data events, records DynamoDB reads for audit, security, and compliance purposes, but it does not retain the response payloads and logs are delivered asynchronously. Querying CloudTrail for read history would be many orders of magnitude slower than DynamoDB itself and cannot serve current data. It is fundamentally a governance tool, not a low-latency cache for application reads.

WAF rules only evaluate requests after they reach the origin, so the absence of matches means the origin is blocking traffic first.

Why it fails: WAF rules are evaluated by CloudFront at the edge location, before any request is forwarded to the S3 origin. If a rule matches, the request is blocked and the origin never sees it; if no rule matches, the request is forwarded normally. Therefore an absence of WAF matches cannot be explained by the origin blocking traffic first—if the web ACL were properly associated, the edge would have logged an evaluation. The real cause is usually a missing association, wrong AWS region/scope, or rules that do not have the intended conditions.

For CloudFront, you must use a regional WAF endpoint and cannot use a global web ACL.

Why it fails: CloudFront does not use a regional WAF endpoint; it requires a web ACL with the CloudFront scope, which is created and managed in us-east-1 (N. Virginia). Regional web ACLs are for Application Load Balancers, API Gateway, and other regional resources. Attempting to use a regional endpoint would make the web ACL unusable for the distribution, so the correct fix is to create a global-scope ACL in us-east-1 and associate it with CloudFront.

WAF web ACL rules never apply to signed URLs or signed cookies, so the web ACL is bypassed by design.

Why it fails: Signed URLs and signed cookies do not exempt a request from WAF inspection. CloudFront still forwards the request metadata to the WAF at the edge, and every rule in the associated web ACL is evaluated against the request before it is allowed through. The signature only authenticates access to the S3 origin; it does not disable or bypass the web ACL, so an absence of matches indicates a scope/association issue rather than a signed-request bypass.

Use AWS WAF CloudFront (global) scope and associate the web ACL with the ALB

Why it fails: AWS WAF web ACLs are available in two scopes: CloudFront (global) and Regional. A CloudFront-scoped web ACL can only be associated with a CloudFront distribution, not with a regional endpoint such as an ALB. Attempting to attach a global web ACL to an ALB is unsupported and will not apply WAF protection to the load balancer. To protect an ALB, you must create a Regional web ACL in the same Region and associate it directly with the ALB resource.

Use AWS Shield Advanced and rely on it to inspect payloads for SQL injection and XSS

Why it fails: AWS Shield Advanced is a managed distributed denial-of-service (DDoS) protection service that provides always-on network and transport-layer mitigation and access to the DDoS Response Team. It does not parse HTTP headers, query strings, or request bodies, so it cannot identify SQL injection or XSS signatures. Those application-layer threats require rule-based inspection in AWS WAF, which evaluates HTTP content; Shield Advanced alone is not a substitute.

Use security groups only, because they can detect SQL injection patterns in HTTP requests

Why it fails: Security groups act as a virtual firewall that filters traffic based on IP addresses, ports, and protocols at the network and transport layers. They have no visibility into HTTP application-layer data, such as URI paths, query string contents, or request bodies, which are the only places SQL injection and XSS payloads appear. As a result, security groups cannot detect or block those attacks; this requires a WAF rule that inspects the actual HTTP request content.

Amazon S3 Select

Why it fails: Amazon S3 Select is a service for running SQL-like queries directly on objects stored in S3, returning only a filtered subset of the data to reduce data transfer and processing cost. It does not provide any in-memory caching or low-latency read acceleration for DynamoDB items, and it cannot act as a front-end layer to intercept database access. Instead, it optimizes access to objects within S3 itself, which is fundamentally different from serving a high volume of repeated DynamoDB reads.

Amazon SQS FIFO queue

Why it fails: Amazon SQS FIFO queues provide ordered, exactly-once message delivery for decoupled application components, ensuring strict ordering and preventing duplicate processing. They are a messaging system, not a low-latency cache or a data store, so they have no mechanism to serve or cache DynamoDB item reads. A FIFO queue would add significant latency and complexity if used for database read acceleration, and it cannot reduce the number of DynamoDB read operations.

AWS Lambda provisioned concurrency

Why it fails: AWS Lambda provisioned concurrency keeps a specified number of function execution environments pre-initialized, eliminating cold starts and thereby reducing invocation latency. While this improves the performance of the calling code, it does not affect the latency of DynamoDB calls between Lambda and DynamoDB, nor does it cache any data fetched from DynamoDB. Each individual Lambda invocation still performs its own Read operation against DynamoDB, so provisioned concurrency does nothing to accelerate repeated identical reads.

Amazon S3 bucket versioning

Why it fails: S3 bucket versioning protects object data inside an Amazon S3 bucket by retaining multiple versions of each object, allowing rollback after accidental deletion or overwrite. However, an EBS volume is a raw block device mapped to an EC2 instance, not an object in S3, so versioning does not capture the volume's file system, boot sector, or unallocated blocks. Even if you copy files from the volume to S3, versioning would only manage those individual object versions, not the volume itself. It cannot generate a point-in-time snapshot or restore the EBS volume as a usable device.

AWS Security Hub

Why it fails: AWS Security Hub is a security posture management service that aggregates findings from services like GuardDuty, Inspector, and Macie, and runs compliance checks against standards such as CIS AWS Foundations and PCI DSS. It gives you dashboards and alerts about misconfigurations and threats, but it has no mechanism to initiate backups, create snapshots, or restore EBS volumes. The service never reads or writes to the block-level data on your EBS volumes, so it cannot recover lost or corrupted data. While security findings might indicate a problem, Security Hub itself is not a backup or disaster recovery tool.

Amazon CloudFront invalidations

Why it fails: Amazon CloudFront is a content delivery network that caches web content at edge locations, and invalidations simply remove cached objects to force the origin to serve updated versions. It operates at the HTTP layer and has no visibility into or control over Amazon EBS block storage attached to an EC2 instance. An invalidation can never recreate a lost EBS volume or restore its point-in-time data because CloudFront has no interaction with EBS volumes, snapshots, or regional storage APIs. Therefore, it is wholly irrelevant for protecting or recovering EBS data.

Write to DynamoDB only, and never update or invalidate the Redis cache.

Why it fails: Writing only to DynamoDB while never invalidating or updating the Redis cache means every read served from Redis returns the previously cached, now-stale value. Even if a TTL is set, the stale data can live for the full TTL duration, which directly violates the requirement that updates become quickly visible. This approach sacrifices correctness for simplicity because the cache is never told that the source of truth changed, so it cannot reflect the new data until expiration. You must either invalidate the key on writes so the next read reloads from DynamoDB, or proactively update the cached value.

Cache only for reads, and do not fetch from DynamoDB when a key is missing.

Why it fails: If you do not fetch from DynamoDB on cache misses, you can return empty or incorrect responses. Cache-aside requires falling back to the source of truth. This option would break the functionality under cache misses.

Rely on eventual consistency of Redis replication to propagate updates to all nodes.

Why it fails: Relying on Redis replication to propagate updates to all nodes is fundamentally orthogonal to application-level cache correctness. Replication only copies Redis write commands from the primary to replicas; it does not know anything about changes made to DynamoDB, nor does it trigger any invalidation of keys that correspond to changed records. If the application never writes to Redis after a DynamoDB update, all nodes—primary and replicas—will continue serving the same stale cached entries. Moreover, replication lag can cause different nodes to return different values, making consistency worse, so this approach provides no benefit for reflecting source-of-truth changes.

AWS Backup Vault Lock

Why it fails: AWS Backup Vault Lock is incorrect because it enforces a write-once-read-many (WORM) policy on backup vaults to protect backup files from deletion or alteration. It has no effect on how CloudFront or S3 serves website content, and it cannot serve cached versions of the site during an outage. Its purpose is data protection compliance, not content delivery resilience.

IAM Access Analyzer

Why it fails: IAM Access Analyzer is incorrect because it is a security tool that scans resource policies to detect external access, helping identify unintended sharing of S3 buckets. It does not cache content, proxy requests, or interact with CloudFront edge nodes. Therefore, it cannot mitigate an S3 origin outage, as its function is purely analytical and does not participate in the content delivery path.

S3 Select

Why it fails: S3 Select is incorrect because it enables efficient SQL-based querying of data stored in S3 objects, returning only filtered subsets of data to reduce network usage. It is designed for data processing scenarios, not for serving static websites, and it does not maintain a cache of responses. In an outage where S3 is unreachable, S3 Select would also be unavailable, so it offers no origin outage tolerance.

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

Why it fails: 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 it fails: 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 it fails: 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.

Enable S3 static website hosting and disable CloudFront, because website hosting blocks direct object URL access.

Why it fails: S3 static website hosting exposes objects through the website endpoint (e.g., bucket.s3-website-region.amazonaws.com) but does not prevent access via the original REST endpoint; any bucket policy that permits public read keeps direct object URLs working. Website hosting also has no mechanism to restrict requests to a particular origin or distribution, and it lacks native HTTPS support on the custom website endpoint. Removing CloudFront would therefore not secure the content and would forfeit edge caching, TLS termination, and the ability to use features like WAF.

Add a WAF rule that rate-limits requests to the S3 bucket domain to make direct access impractical.

Why it fails: AWS WAF is a service you attach to resources like CloudFront or Application Load Balancers, not directly to an S3 bucket, so a WAF rule cannot be applied to the bucket's own domain. Even if you added a rate-limit rule at CloudFront, it only throttles traffic coming through that distribution; browsers or scripts hitting the S3 endpoint directly would bypass the rule entirely. Rate limiting is also a mitigation, not an access control guarantee, and would not stop a low-volume attacker from reading every object.

Turn on S3 object versioning so that attackers cannot read previous objects.

Why it fails: Object versioning stores multiple versions of each object to guard against accidental deletion or overwrites, but it has no effect on the bucket policy or the public-read permissions that make objects available via direct URLs. If an object is publicly readable, anyone can still download the current version, and in some cases versioned objects are accessible by including a version ID header. Enabling versioning actually increases the attack surface by retaining older versions that attackers could potentially read if permissions remain permissive.

S3 Cross-Region Replication

Why it fails: S3 Cross-Region Replication (CRR) is an asynchronous background process that copies objects from a source bucket to a destination bucket in another region for compliance, backup, or disaster recovery. It does not intercept or route live application traffic, and clients do not automatically gain lower latency unless you add complex routing logic to point them at the replicated bucket. It also cannot optimize dynamic TCP/UDP flows from a telemetry pipeline, so it is fundamentally a storage-level durability feature, not a performance accelerator.

CloudFront only with long TTLs

Why it fails: CloudFront with long TTLs is designed for cacheable HTTP content, but telemetry pipeline traffic is often dynamic, unique, or time-sensitive, so long TTLs would serve stale or incorrect measurements to consumers. Although CloudFront can terminate TLS and provide some connection reuse, its primary performance win comes from caching responses at edge locations—which fails for requests that must reach the origin. For uncacheable, dynamic traffic, Global Accelerator is superior because it optimizes the network path without assuming content can be cached.

AWS Backup cross-Region copy

Why it fails: AWS Backup cross-Region copy creates point-in-time backup copies in a different region for disaster recovery and regulatory retention. These copies are dormant snapshots of data, not live endpoints, and restoring them requires explicit operator action and takes minutes to hours. They have no effect on in-flight telemetry ingestion or user latency; using them for performance would be like reading from an offline tape instead of a routing service.

Disable CloudFront caching so every request goes back to S3 for the latest image

Why it fails: Setting TTLs to zero or otherwise disabling CloudFront caching forces every request to be treated as a cache miss and triggers a fetch to the S3 origin that hosts the static images. This re-introduces full origin load, multiplies S3 GET request costs, and removes the edge-side response that CloudFront could have reused, which also increases user-perceived latency especially for remote clients. It directly contradicts the goal of using a CDN, because the image objects are immutable static files that should be cached for high hit ratios.

Route users directly to the S3 website endpoint to bypass CloudFront

Why it fails: Bypassing CloudFront by sending users directly to the S3 website endpoint eliminates edge caching. All image requests then traverse to the bucket's origin region, causing higher latency for global users, and S3's standard request/transfer pricing applies for every object served. Unlike CloudFront, the S3 website endpoint is typically HTTP-only (unless you use the REST endpoint with custom SSL), and it lacks the ability to enforce cache-control headers at the CDN level, so it would not reduce the volume of data pulled from the origin.

Turn on a NAT Gateway for the CloudFront origin to reduce bandwidth charges

Why it fails: A NAT Gateway is unrelated to CloudFront or S3 origin access; it provides outbound internet connectivity for resources in private subnets of a VPC. CloudFront reaches S3 through AWS's internal network, and NAT Gateway does not sit in that data path, so it cannot influence cache hit ratio or origin fetch frequency. Moreover, NAT Gateway charges an hourly fee plus per-GB processing cost, so adding one would simply increase the bill without any benefit to image delivery.

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

Why it fails: 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 it fails: 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 it fails: 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.

Enable termination protection on the EC2 instances and configure an Elastic IP address per instance so that clients can reconnect to the same address after a zone failure.

Why it fails: Termination protection only blocks accidental instance termination; it does nothing when an Availability Zone itself is impaired. Elastic IP addresses are Regional and can be remapped, but clients are connecting to the load balancer endpoint, not to instance addresses, so this design neither preserves the endpoint nor provides running capacity in a second zone.

Replace the Network Load Balancer with an Application Load Balancer deployed in one Availability Zone and attach an Auto Scaling group with a desired capacity of two instances.

Why it fails: An Application Load Balancer is also a Regional resource, but keeping the Auto Scaling group in a single Availability Zone means the workload still has no capacity in a second zone, so a zone failure still takes down every instance. This option changes the load balancer type and its DNS name, which also violates the requirement that clients keep using the existing API endpoint.

Create a second Network Load Balancer in a different Availability Zone and use Amazon Route 53 weighted routing to send half the client traffic to each load balancer.

Why it fails: A second Network Load Balancer in another zone does not protect the instances, which remain in one zone, and weighted routing does not automatically withdraw a failed endpoint from DNS. Weighted records keep resolving to the failed load balancer until health checks and TTL expire, and clients would also need to tolerate two different endpoint names, which the scenario forbids.

Leave the bucket public but require CloudFront signed cookies for all users.

Why it fails: Making the bucket public allows any internet user with an S3 endpoint URL to retrieve objects directly, completely bypassing CloudFront. Signed cookies only restrict who can access content through the CloudFront distribution; they have no bearing on S3's own URL. Therefore, the requirement to prevent direct access is violated because the origin remains exposed. The bucket policy must deny direct access, not rely on viewer-side authentication.

Use an S3 access point and give it a public policy so CloudFront can reach the objects.

Why it fails: An S3 access point is a managed entry point for S3, but assigning it a public policy simply grants anonymous read access to the access point's own Amazon Resource Name (ARN). CloudFront can be configured to use a private access point with origin access control, but a public policy would let anyone directly request objects via that access point ARN. This fails the stated requirement because you need to restrict access exclusively to the CloudFront distribution, not make objects publicly reachable.

Use S3 object ACLs to grant read access only to users behind CloudFront.

Why it fails: S3 object ACLs are a legacy access-control mechanism that grants permissions to AWS accounts or predefined groups like Everyone, but they cannot reference a CloudFront distribution or require that the request came through CloudFront. Even if you set per-object ACLs, direct S3 requests would still be evaluated based on the ACL, and there is no way to enforce CloudFront as the sole source without OAC and a bucket policy. Moreover, ACLs do not support fine-grained source-ARN conditions used to secure an origin, and relying on them is impractical for many objects.

S3 Cross-Region Replication

Why it fails: S3 Cross-Region Replication is wrong because it asynchronously copies objects from one S3 bucket to a bucket in another Region for data durability, disaster recovery, or compliance. It does not alter user traffic flow or optimize the network path; users still traverse the public internet to reach the ALB in its single Region. Replication is a storage feature, not an application-layer traffic accelerator, so it has no impact on live user latency.

AWS Backup cross-Region copy

Why it fails: AWS Backup cross-Region copy is wrong because it copies recovery points (such as EBS snapshots, RDS snapshots, and DynamoDB backups) to a different Region for backup integrity and disaster recovery. This copying is performed offline and does not affect the runtime request path or user network routing. It cannot accelerate dynamic application traffic, and it has no mechanism to bring content closer to users or reduce latency to the ALB.

CloudFront only with long TTLs

Why it fails: CloudFront with only long TTLs is wrong because CloudFront is optimized for cacheable HTTP content; locking in long TTLs would cause the analytics dashboard to serve stale metrics whenever the origin data changes. For dynamic content, CloudFront would need TTL=0 to fetch fresh data, and even then it only supports HTTP(S), not the full TCP/UDP optimization provided by Global Accelerator. Long TTLs specifically undermine the real-time requirement of an analytics dashboard and fail to accelerate the underlying network path.

IAM Access Analyzer

Why it fails: IAM Access Analyzer is a permissions-analysis tool that inspects IAM policies and resource-based policies (like S3 bucket policies) to detect unintended external access, and it can generate least-privilege policies from CloudTrail logs. However, it exists entirely outside the data path for content delivery: it does not cache objects, intercept requests, or serve static content. When the S3 origin is unavailable, Access Analyzer's only function is to audit permissions, so it cannot provide any resilience or availability for the website.

AWS Backup Vault Lock

Why it fails: AWS Backup Vault Lock provides a write-once-read-many (WORM) protection on backup vaults, making backup copies immutable to prevent accidental or malicious deletion, even by root users. While this is a valuable compliance and ransomware-protection feature, it only applies to backup data managed by AWS Backup, not to the S3 bucket hosting your static website. It does not participate in content delivery, caching, or request routing, so it cannot help CloudFront serve content when the origin is temporarily unavailable.

S3 Select

Why it fails: S3 Select is a query feature that uses SQL to retrieve only a subset of rows or columns from an object in S3, reducing data transferred for analytics workloads. It requires direct, real-time access to the S3 object; it does not cache any data at the edge, nor does it maintain an independent copy of the object. Therefore, if the S3 bucket is down, S3 Select cannot retrieve anything, and it provides no benefit to a static website that normally serves full objects via CloudFront.