CCNA Design Cost Questions

A Compute Savings Plan reduces cost for the predictable baseline while preserving flexibility across instance families and Regions. That fits a 24/7 web tier that is expected to run continuously. It is cheaper than On-Demand for the committed portion and avoids overcommitting to a specific instance family.

AWS Graviton-based instances after performance testing is the correct approach because Graviton processors (arm64 architecture) often deliver up to 20% better price-performance than comparable x86 instances for scale-out, stateless, and lighter-workload deployments like a marketing site running open-source software. The key is to first run performance testing to verify that your specific application stack—including any compiled binaries, libraries, or dependencies—is fully compatible and performs adequately on the arm64 architecture. If the workload is portable (e.g., running on Linux with open-source code), moving to Graviton instances reduces compute cost without sacrificing performance, making it a cost-effective modernization step.

Spot is the most cost-effective EC2 option when the workload can handle interruption. Because the jobs are stateless and can resume from checkpoints, losing an instance due to a Spot interruption does not lose progress. The design aligns directly with Spot’s best-effort interruption model, minimizing compute cost while still completing the batch work.

S3 and DynamoDB use gateway endpoints, which are the cost-effective private path for those services. Secrets Manager and CloudWatch Logs require interface endpoints for private access. Once these are in place, the NAT Gateway is no longer needed for this workload, eliminating the hourly and per-GB NAT charges while keeping traffic on the AWS network.

CloudFront cache misses increase when the cache key includes values that vary per request. If the tracking query string is part of the cache key, each unique ?utm value generates a separate cache entry even though the underlying object (JS/CSS/image) is identical, causing repeated origin fetches. Excluding query strings from the cache key collapses those variations into a single cached object, increasing the cache hit rate and reducing origin fetches and origin data transfer.

S3 lifecycle policies can automatically transition objects to lower-cost storage classes based on age. Transitioning after 30 days reduces ongoing storage costs because the logs are rarely accessed, while expiring after 1 year ensures you still meet the compliance retention window.

S3 Intelligent-Tiering automatically monitors and moves objects between four access tiers—frequent, infrequent, archive instant, and archive access—based on changing usage patterns, with zero retrieval fees and no latency impact. It allows the risk simulation workload to pay only for the storage class each file actually needs, while keeping every object immediately available for analysis.

Scheduled scaling allows the Auto Scaling group to adjust capacity based on known traffic patterns, such as scaling out before business hours and scaling in at night. This ensures sufficient capacity during peaks and reduces costs during low-traffic periods by terminating unused instances. It directly addresses the predictable nature of the workload.

S3 Intelligent-Tiering is designed for unknown or changing access patterns. It monitors access and automatically moves objects between tiers (for example, between frequent-access and infrequent-access tiers) based on actual usage, which avoids the need to manually decide transition schedules. This directly meets the requirement to reduce storage cost while eliminating ongoing manual tracking or periodic analysis.

Stopping an instance when it is not needed means you do not pay for compute hours while it is idle. Since the job runs for only about two hours each night, stopping the instance for the remaining 22 hours drastically reduces cost. Automated start and stop can be implemented with instance scheduler solutions or EventBridge and Lambda.

Compute Savings Plans provide discounted pricing for steady usage while allowing flexibility across instance families, OS, and sizes within the selected scope (for example, region). That matches the scenario: demand is steady enough for discounts, but the underlying instance type choices change frequently to meet performance needs.

On-demand capacity is suitable for unpredictable workloads and charges per request without capacity planning.

The hit ratio is low because CloudFront is varying the cache on request attributes that do not change versioned static files. Removing Authorization, cookies, and irrelevant query strings from the cache key allows CloudFront to reuse cached objects across users and sessions. Reducing the origin request policy avoids sending unnecessary viewer context to the origin. Because the filenames are already versioned, long TTLs can be used safely and will lower origin requests and S3 request costs.

Scheduled scaling lets you increase or decrease the desired capacity of an Auto Scaling group based on a date and time, which matches a workload with a known, repeating peak pattern. Scaling in overnight and on weekends terminates unneeded instances, so you pay only for the capacity actually required, while scaling out before business hours preserves availability during peak traffic.

S3 Cross-Region Replication (CRR) creates an asynchronous, automatic copy of every object in the us-west-2 source bucket to a destination bucket in us-east-1. By updating the application to read from the us-east-1 bucket, all GET requests stay within the same Region, eliminating inter-Region data transfer charges that currently accrue for each cross-Region read. Since CRR transfers each object once during replication (rather than on every read), this pattern becomes cost-effective when the application frequently reads the same large objects. You must still account for a short replication lag, so the app should tolerate eventual consistency for newly written objects.

Expiring noncurrent versions after a retention period removes old versions that are no longer needed, directly reducing storage charges while keeping current objects and recent versions protected. This is the standard S3 lifecycle action for controlling version accumulation cost.

Fargate Spot offers up to 70% lower cost for interruptible tasks, and mixing it with a small on-demand baseline preserves availability when Spot capacity is reclaimed. Because the API runs behind an ALB with multiple tasks, a reclaimed Spot task is replaced and traffic continues, making this a valid cost reduction.

Spot Instances offer the largest discounts (up to 90% off On-Demand) and are ideal for fault-tolerant, flexible workloads like batch processing that can be interrupted and resumed. Since the job checkpoints its progress, it can handle interruptions gracefully. Using Spot Instances directly addresses the cost minimization goal while accommodating the job's interruptible nature.

Using On-Demand for the master node keeps the cluster's control plane stable, while Spot Instances on task nodes can reduce compute cost because the stateless batch jobs can be re-run if a Spot node is reclaimed. This matches the SAA-C03 cost-optimization goal for transient, fault-tolerant analytics workloads.

Reserved Instances with All Upfront payment provide the highest discount (up to 72% off On-Demand) for a 1- or 3-year commitment. By paying the entire amount upfront, the company maximizes savings. This option is ideal for steady-state workloads where the instance type and region are known, and the company is willing to commit for 3 years.

S3 Glacier Instant Retrieval is designed for long-lived, rarely accessed data that still needs millisecond retrieval. It costs significantly less than S3 Standard-IA for storage while meeting the auditors' requirement to fetch any image within minutes. This aligns storage cost with the access pattern over the seven-year retention period.

A Compute Savings Plan is the most cost-effective option because it provides a significant discount (up to 66% versus On-Demand) in exchange for a one- or three-year hourly spend commitment, while allowing flexibility across instance families, sizes, availability zones, regions, and even compute services like Lambda and Fargate. For a production portal that runs continuously, the predictable, always-on usage justifies the commitment, and the plan automatically applies to any EC2 instance usage without needing specific instance configurations.

Right sizing reduces cost by matching instance capacity to actual demand. If average CPU is consistently low (around 10%) and performance is stable, it strongly indicates overprovisioning. Moving to a smaller instance (or a smaller capability within the same family) typically lowers hourly cost while maintaining sufficient capacity for the workload.

Compute Savings Plans apply to AWS Fargate usage as well as EC2 and Lambda, so they reduce the effective rate for Fargate vCPU and memory while preserving the existing task definitions. For a continuous 3-year commitment, this is the direct way to lower Fargate compute cost without changing the architecture.

A gateway VPC endpoint for Amazon S3 inserts a prefix-list route into the VPC route table, directing traffic destined for S3 to the AWS network without leaving through a NAT gateway or internet gateway. Gateway endpoints are free—there is no hourly fee and no per-GB data processing charge—so the NAT gateway's per-GB processing fee on these downloads is completely eliminated. This is the only option that directly removes the data processing cost while preserving private connectivity.

Amazon SQS is a fully managed queue that satisfies durable, at-least-once messaging without requiring broker administration. It removes the EC2 broker fleet, patching, backups, and failover testing, and it reduces outage risk from broker maintenance. Because the workload does not need AMQP-specific features such as exchanges or routing keys, SQS is the most cost-effective and operationally simple replacement.

Spot Instances offer the largest discounts, up to 90% off On-Demand prices, and are ideal for workloads that can tolerate interruption. The company accepts a brief interruption and can restart the instance automatically, which aligns with Spot behavior. For a low-traffic website with steady usage, Spot can significantly reduce cost. Using a Spot Fleet or Auto Scaling group with a diversified allocation strategy improves availability.

CloudFront cache hit ratio improves when objects are cacheable for longer and requests can be served from edge caches. Proper TTLs for versioned assets prevent unnecessary revalidation. Compression reduces payload size for eligible content types, lowering transfer costs.

Versioned assets are ideal for long cache lifetimes because their URLs change when the content changes. Strong Cache-Control headers let CloudFront serve more requests from edge locations instead of repeatedly fetching the same files from S3.

Because the workload is steady, stateless, and committed to a single instance family in a single Region for three years, an EC2 Instance Savings Plan gives the deepest discount of any commitment-based option. Paying All Upfront maximizes the discount further, and the plan still allows changing instance size within the same family, so operational flexibility is preserved.

Spot Instances offer up to 90% discounts compared to On-Demand and are ideal for fault-tolerant, interruptible workloads like this simulation. Checkpointing to EBS allows the job to resume after a Spot interruption. A persistent Spot request maintains the desired capacity, helping the job finish within the nightly window while minimizing compute cost.

Setting appropriate Cache-Control headers on the origin instructs CloudFront's edge locations to serve static images for a longer period without requesting them from S3. A longer TTL, such as a max-age of one year for immutable assets, increases the cache hit ratio and dramatically reduces the number of origin fetches. This directly lowers S3 request costs and reduces latency for end users.

Spot provides significantly lower pricing than On-Demand for interruptible workloads. Because the workload can restart from checkpoints, termination interruptions are acceptable and the application can recover efficiently, meeting both correctness and throughput requirements at a lower cost.

An S3 Lifecycle policy can automate age-based transitions from S3 Standard to S3 Standard-IA and then to Glacier classes, aligning storage costs with the 30-day query pattern. Because log files are queried most heavily when new and rarely when old, transitioning older objects to lower-cost storage maintains S3 API access while reducing spend. Lifecycle rules are the recommended mechanism for this optimization, with no manual intervention or infrastructure changes.

ECS Service Auto Scaling automatically adjusts the desired count of tasks in a service based on metrics such as CPU utilization or request count. By scaling out during peak hours and scaling in during low-traffic periods, the company pays only for the resources needed, optimizing costs. This directly addresses the variable traffic pattern without manual intervention and maintains performance.

S3 Intelligent-Tiering monitors access patterns and automatically moves objects between frequent and infrequent access tiers, with no retrieval fees or delays. This satisfies the stem's unpredictable-access and no-custom-scripts constraints, unlike lifecycle policies that require manual rule design.

The metrics indicate headroom that is not being used (low CPU, stable latency, and low gp3 utilization). The most direct cost optimization is to reduce overprovisioned spend by right-sizing the instance type and tuning gp3 IOPS/throughput to match actual demand. Because performance and latency are already stable, these changes are the most likely to reduce cost without degrading performance.

EC2 Spot Instances offer spare compute capacity at discounts of up to 90% compared to On-Demand. Although AWS can reclaim capacity with a two-minute interruption notice, the thumbnail batch can be made resilient by checkpointing progress to Amazon S3 or Amazon EFS and resuming from the last completed step. Because image processing is idempotent and time-flexible, this provides the lowest cost without losing completed work.

A Compute Savings Plan covers the predictable baseline at a discounted rate across EC2, Fargate, and Lambda, which suits a continuously running stateless container platform. Bursts above the committed hourly spend are simply billed at On-Demand rates, so the architecture absorbs short spikes without overcommitting. This balances savings with the flexibility the platform needs.

Compute Savings Plans provide a discount for a consistent amount of EC2 (and related covered usage) in a region while allowing flexibility to change instance families and sizes within the covered scope. Because the team’s requirements may evolve and they primarily need to manage average utilization (40% baseline), Compute Savings Plans match both the cost-reduction goal and the flexibility requirement better than instance-specific commitments.

NAT gateways are zonal resources, and AWS best practice is to deploy one per Availability Zone for high availability; multiple NAT gateways in the same AZ offer no added resilience because an AZ failure takes them all down. Before optimizing cost, verify whether each private subnet in each AZ actually needs outbound NAT capacity. If batch workloads run primarily in one AZ or can tolerate reduced availability, a single NAT gateway may be sufficient, but cross-AZ traffic from other AZs will incur inter-AZ data transfer charges in addition to the NAT gateway hourly and per-GB processing costs.

On-Demand Instances provide the flexibility to scale up and down without long-term commitment, matching the unpredictable spikes. An Auto Scaling group automatically adjusts capacity to maintain performance. While Spot Instances could be cheaper, they risk interruption, which is unacceptable for a latency-sensitive bidding platform. Savings Plans or Reserved Instances would not provide the needed elasticity for unpredictable surges and could lead to overprovisioning or insufficient capacity.

Standard Reserved Instances offer the highest discount among Reserved Instance types, especially with a 3-year All Upfront commitment. Because the workload is steady, uses a consistent instance family and size, and runs across multiple AZs, Standard RIs are a perfect fit. They provide a capacity reservation and significant cost savings compared to On-Demand, and the All Upfront payment maximizes the discount.

Spot Instances offer significant discounts (up to 90% off On-Demand) and are ideal for fault-tolerant, flexible workloads like batch processing that can checkpoint and resume. The job can handle interruptions, so the risk of Spot termination is acceptable. This pricing model minimizes compute costs while meeting the job's requirements.

S3 Standard-IA and One Zone-IA both provide immediate millisecond retrieval, satisfying the instant-access constraint, while their lower storage price suits infrequent access. Standard-IA replicates across three Availability Zones; One Zone-IA stores data in a single AZ, so choose it only when reduced resilience is acceptable.

The prompt requires (1) cost reduction for data that becomes infrequently accessed and (2) quick retrieval when accessed again, and (3) a minimum retention of at least 18 months. Glacier Instant Retrieval is intended for data that is accessed occasionally and needs fast retrieval. Transitioning after 30 days moves the long-term, rarely accessed portion of the data to a cheaper class, while expiring at 18 months satisfies the explicit retention requirement (the objects remain for at least 18 months).

Spot Instances offer spare AWS compute capacity at discounts of up to 90% compared to On-Demand, and they can be reclaimed by AWS with a two-minute warning when capacity is needed elsewhere. Because the dev sandbox runs only at night and can be interrupted without negative impact, it is an ideal fit for Spot. The main risk is interruption, but that is acceptable for this use case.

AWS Graviton-based instances, such as m6g, c6g, and r6g, are built on the Arm architecture and typically offer up to 20% better price-performance than comparable x86 instances. The catch is that your application and its dependencies must be compiled or runnable on Arm, so performance testing is essential to confirm compatibility and measure actual throughput, latency, and cost-per-request before migrating the test environment.

Scheduled scaling lets you set the desired capacity based on a known schedule, so the Auto Scaling group can scale down when traffic is predictably low and scale up before the peak. This directly matches capacity to demand and avoids paying for idle instances during off-peak hours, making it the most cost-effective option for a predictable pattern.

Aurora Serverless v2 scales capacity in fine-grained increments and can scale down to a low minimum during idle periods while remaining available to accept connections. Because the database is almost unused outside business hours but must stay online, this pay-for-what-you-use capacity model reduces cost more effectively than a fixed-size RDS instance that bills the same rate around the clock.

Spot Instances bill at up to a 90% discount versus On-Demand, and the checkpoint-based restart design means a two-minute interruption notice causes no lost work. Since the stem accepts interruptions provided the job resumes automatically, Spot delivers the lowest compute cost without violating any stated constraint.

Spot Instances cost substantially less than On-Demand, and the five-minute checkpointing means an interruption loses at most five minutes of work. Restarting from the last checkpoint keeps the 2–4 hour job within the 07:00 deadline, unlike uncheckpointed interruption.

Compute Savings Plans provide discounted pricing in exchange for committing to a consistent hourly spend (scoped to a Region). They apply to EC2 usage and are flexible enough that you can change EC2 instance families over time while still receiving the Savings Plans discount within the commitment scope.

CloudFront caches objects at edge locations close to users, which lowers download latency and reduces the volume of data transferred from the S3 origin. Because the content changes only a few times per month, a long cache time-to-live means the vast majority of requests are served from the edge at the lower CloudFront data transfer rate, cutting both latency and cost.

On-demand capacity mode charges only for the read and write requests the table actually serves, so idle provisioned capacity no longer incurs cost. Because the pipeline's traffic is unpredictable and bursty, on-demand absorbs spikes without pre-provisioning, directly aligning spend with usage and eliminating charges for capacity that sits unused during quiet periods.

This directly addresses the two visible recurring cost drivers. Applying a 90-day retention policy stops indefinite log storage growth while still meeting the audit requirement. Basic monitoring is sufficient when 1-minute metrics are not required all the time, and detailed monitoring can be enabled selectively during incidents instead of paying for it across all 200 instances continuously.

Application Auto Scaling with target tracking adjusts the desired task count to match demand, so the service scales out during business-hour peaks and scales in overnight when traffic nears zero. Setting a low minimum keeps a task ready to absorb the first requests, preserving responsiveness. Because Fargate bills per task-second, scaling in directly reduces spend, making this the best cost-and-performance balance.

A Compute Savings Plan applies to EC2, Fargate, and Lambda across families, sizes, tenancies, and Regions, so the company can change instance families or Regions without losing the discount. Committing only to the steady-state baseline covers the always-on capacity and leaves burst capacity billed at On-Demand rates.

An S3 lifecycle policy is the correct solution because it lets you automate storage class transitions based on object age: for example, keep logs in S3 Standard for the first 30 days for active queries, then transition them to S3 Standard-IA or S3 Glacier Instant Retrieval for cheaper long-term storage. Lifecycle rules can chain multiple transitions, so you can progressively move objects to even colder classes (e.g., Glacier Flexible Retrieval) after 90 or 180 days. This matches storage cost to actual access patterns while maintaining the ability to retrieve logs when needed, without manual operations or expensive ingestion-time decisions.

Correct. Compute Savings Plans discount steady usage across EC2 and other compute services without forcing a specific instance family. The API has predictable 24/7 demand, so a commitment fits the usage pattern and lowers cost safely.

Compute Savings Plans apply to Fargate vCPU and memory usage as well as to Lambda and EC2, so they discount the steady portion of this service without requiring any server management. Committing to the overnight baseline captures the discount on usage that is certain to occur, while the variable daytime scale-out remains on On-Demand rates.

AWS Compute Optimizer analyses CloudWatch metrics from EC2 instances to generate rightsizing recommendations, flagging over-provisioned CPU, memory and network capacity. It directly satisfies the stem's requirement to identify oversized instances, unlike Trusted Advisor's narrower checks or Cost Explorer's spend-only view.

Unattached EBS volumes in an 'available' state continue to incur per-GB-month charges because AWS bills for allocated block storage capacity regardless of whether a volume is attached to an instance. After verifying that each orphaned volume contains no critical data or that its data is already safely backed up, deleting the volume is the direct, effective way to eliminate that recurring cost and is the primary cost optimization in this scenario.

This follows the access pattern and the retrieval-time requirement. S3 Standard fits the heavy-read period in the first 30 days. Standard-IA is a lower-cost choice for the next 90 days when access is only occasional, and Glacier Flexible Retrieval is appropriate after day 120 because the logs are rarely read and can tolerate retrieval in hours. Expiration at day 400 satisfies the retention requirement exactly.

S3 Glacier Flexible Retrieval is an archive class that supports retrieval in minutes to hours, and its Standard retrieval option completes within 3 to 5 hours, comfortably inside the 12-hour requirement. It has lower storage cost than S3 Standard and Glacier Instant Retrieval, so transitioning objects after the 60-day active period minimizes cost while meeting the retrieval and retention requirements.

AWS Compute Optimizer uses machine learning to analyze historical CloudWatch telemetry, including CPU, memory, I/O, and network utilization, and generates right-sizing recommendations for EC2 instances, Auto Scaling groups, and EBS volumes. It identifies underutilized or overprovisioned instances, providing confidence scores and potential cost savings, which directly addresses the oversized compute problem. For existing resources, it offers optimized findings and can suggest smaller instance types based on observed load.

Spot Instances exploit spare EC2 capacity at discounts up to 90%, and the job's interruptible, restartable nature satisfies their two-minute interruption notice without data loss. The architecture review board's managed AWS-native constraint is met because Spot is an AWS-native purchasing model, not a third-party broker.

Compute Savings Plans provide a discounted hourly rate in exchange for a commitment. They are the most flexible Savings Plans option and can apply across EC2 usage regardless of instance family or size changes, so the team can continue tuning instance types while still receiving discounted pricing for the committed usage.

Compute Savings Plans apply the largest discount to a committed hourly spend and automatically cover any EC2 instance family, size, tenancy, Region, and even Lambda and Fargate usage. This satisfies the steady three-year commitment while preserving the flexibility to change instance families, which is exactly what the team requires here.

S3 Glacier Deep Archive is the lowest-cost storage class, designed for data that is rarely accessed and can tolerate retrieval times of 12 hours or more. It meets the 48-hour retrieval requirement and is ideal for compliance archives. With 500 TB stored and only annual access, this class provides the greatest cost savings compared to other options.

S3 Glacier Deep Archive is the lowest-cost storage class for long-term retention, ideal for compliance data accessed rarely. Transitioning after 30 days aligns with the access pattern. Lifecycle policies automate the transition, eliminating manual intervention. This approach minimizes storage costs for the 10-year retention period, as Deep Archive costs significantly less than S3 Standard or other infrequent access tiers.

A Compute Savings Plan applies to EC2 usage regardless of instance family, size, tenancy, or Region, and a 3-year term with partial upfront payment yields a significant discount over On-Demand. Because the workload is predictable and will run for at least three more years, this commitment matches the usage and reduces compute cost without architectural changes.

This option correctly leverages S3 Lifecycle rules to transition older, less frequently accessed backups to S3 Glacier Flexible Retrieval. This storage class provides significant cost savings compared to S3 Standard or S3-IA, while still supporting retrieval times measured in hours, which comfortably meets a 24-hour Recovery Time Objective (RTO). Maintaining retention until day 90 also satisfies the long-term data retention requirement efficiently.

S3 lifecycle policies can automatically transition objects based on age to storage classes priced for infrequent access (for example, Standard-IA or Glacier-based classes). This preserves the data for later troubleshooting while lowering storage cost as objects become older.