Task 3.5: Identify opportunities for cost optimizations.

• AAWS Budgets reports sent to the team every week

  Incorrect

  Budgets reports show performance against budgets. They do not collect or rank savings recommendations.

• BAWS Cost Anomaly Detection monitors for each account

  Incorrect

  Cost Anomaly Detection finds unusual spend. It does not recommend rightsizing, idle deletion or commitments.

• CCost Optimization Hub, enabled for the organization

  Correct

  Cost Optimization Hub consolidates and prioritizes recommendations for rightsizing, idle resources, Savings Plans and Reserved Instances across accounts and Regions, and it deduplicates savings.

• DThe Cost Explorer cost and usage graphs grouped by linked account

  Incorrect

  Cost Explorer shows where money went. Grouping by account does not combine or rank savings opportunities.

"One ranked list of savings, deduplicated, across accounts" is what Cost Optimization Hub is for.

• ATurn on resource-level data in Cost Explorer and export the grouped cost and usage view every month

  Incorrect

  Resource-level data in Cost Explorer covers only the past 14 days at daily granularity, so it cannot show a full year per resource.

• BExport CUR 2.0 with resource IDs through AWS Data Exports to Amazon S3 and query it with Amazon Athena

  Correct

  Data Exports creates recurring exports of CUR 2.0 in Amazon S3, a standard export can include the ID of each resource, and the exports can be analyzed with tools such as Amazon Athena.

• CDownload the monthly invoice PDFs from the Billing console and load them into a shared spreadsheet

  Incorrect

  Invoices summarize charges. They do not list each resource or its tags.

• DCreate an AWS Budgets cost budget for each tag value and compare the budgets with each other every month

  Incorrect

  Budgets track spend against thresholds. They do not give per-resource costs that can be queried with SQL.

Per-resource, per-tag cost data over long periods comes from the Cost and Usage Report, delivered by Data Exports and queried with Athena.

• ARun the agents on Spot Instances of several types in an Auto Scaling group that scales on queue depth

  Correct

  Spot Instances suit stateless, interruptible work, diversifying instance types with the price-capacity-optimized strategy reduces interruptions, and scaling on the queue removes idle agents at night.

• BBuy a three-year Compute Savings Plan that covers all 40 build instances around the clock, every day of the week

  Incorrect

  A commitment discounts the hours, but the company would keep paying for 40 instances that are mostly idle at night and on weekends.

• CBuy Standard Reserved Instances for the 40 instances of the current type for a three-year term

  Incorrect

  Reserved Instances lower the hourly price but lock in the full fleet around the clock, including the idle hours.

• DMove the agents to Dedicated Hosts so that the company controls instance placement and host utilization

  Incorrect

  Dedicated Hosts address needs such as bringing existing per-socket or per-core licenses. They do nothing about the idle hours of the fleet.

Interruptible, queue-driven work that is idle half the time is Spot plus scaling to demand, not a commitment.

• AShare the production cluster with the 10 test accounts through AWS RAM and have each account create its own Aurora clone of the cluster

  Correct

  A clone starts by sharing data pages with its source through copy-on-write, so new storage is allocated only for changed data, and cloning is faster and more space-efficient than restoring a snapshot. A cluster shared through AWS RAM can be cloned by each authorized account, one cross-account clone per account and up to 15 per cluster, and each clone gets its own DB instances.

• BKeep restoring the latest snapshot every week, but on smaller instance classes and with the copies kept for only five days

  Incorrect

  A restore creates a new DB cluster by physically copying the data, which is slower and uses more space than cloning, so each environment still stores a full copy while it exists. Smaller instances cut compute, not storage.

• CAdd Aurora Replicas to the production cluster and point each test environment at the instance endpoint of its own replica

  Incorrect

  Replicas share the cluster volume, so they add no storage copies, but they are read-only instances inside the production cluster and account, while the testers need writable copies in their own accounts.

• DExport the latest snapshot to Amazon S3 in Parquet each week and let the test environments query the export with Amazon Athena

  Incorrect

  Snapshot export writes compressed Parquet files that tools such as Athena can analyze, but tests that write to a PostgreSQL database cannot run against exported files.

The constraints are writable copies of recent data in each test account, ready in minutes, off the production instances, and far less storage. Snapshot restores are slow full copies, replicas are read-only and stay in the production cluster, and exported Parquet files are not a database. Sharing the cluster through AWS RAM lets each of the 10 accounts create one cross-account clone, well within the 15 allowed per cluster, and each clone stores only the pages its environment changes.

• ASet a 30-day retention period on every existing log group so that CloudWatch Logs deletes older events automatically

  Correct

  By default, log data is stored indefinitely. With a retention setting, data older than the setting is deleted automatically, typically within 72 hours, and the last 30 days stay in the log group for queries.

• BExport each log group to Amazon S3 every day and let S3 lifecycle rules archive the exported files after 30 days

  Incorrect

  Exported files can be archived or deleted by lifecycle rules, but exporting does not remove anything from the log groups, and AWS recommends against regular exports as a way to archive logs.

• CAdd data protection policies to the log groups so that sensitive values are masked before the events are stored

  Incorrect

  Data protection policies help protect sensitive log data by masking it. They do not shorten how long events are kept.

• DLower the applications' log level to WARN so that much less log data is written to the log groups from now on

  Incorrect

  Writing less would slow the growth, but it changes today's logging, which must stay as it is, and every old event would still be stored indefinitely.

The constraints are deleting old events, keeping 30 days in CloudWatch, no change to application logging and no recurring jobs. Exports add copies without removing data, masking only protects content, and a lower log level changes the applications. A 30-day retention setting on each log group lets CloudWatch Logs delete older events on its own.

• AChange the bucket's default encryption to SSE-S3 so that new objects no longer need any requests to AWS KMS

  Incorrect

  SSE-S3 adds no encryption fees, so it would remove the KMS charges, but the objects would no longer be protected by the company's customer managed key, which compliance requires.

• BSwitch the bucket's default encryption to DSSE-KMS with the same customer managed key for stronger protection

  Incorrect

  DSSE-KMS applies two layers of encryption for standards that require multilayer encryption. It brings more KMS API calls and a higher cost than SSE-KMS, and S3 Bucket Keys are not supported with it.

• CRequest a higher AWS KMS request quota for the account so that the ingestion jobs are not throttled at peak

  Incorrect

  KMS request quotas are adjustable through Service Quotas, which helps when calls are throttled. A higher quota does not lower the number of requests or their cost.

• DTurn on S3 Bucket Keys for SSE-KMS in the bucket's default encryption with the same customer managed key

  Correct

  A bucket-level key reduces SSE-KMS request costs by up to 99 percent by cutting the request traffic from S3 to AWS KMS, while objects stay encrypted under the same KMS key. It needs no change to client applications and applies to new objects.

The constraints are the same customer managed key, a large cut in KMS request cost, and no code changes. SSE-S3 drops the required key, DSSE-KMS costs more and cannot use Bucket Keys, and a quota increase only allows more requests. S3 Bucket Keys keep SSE-KMS with the same key while sharply reducing calls to AWS KMS for the new objects that dominate this workload.

• AKeep the fixed group and buy an EC2 Instance Savings Plan that covers the hourly cost of all 40 instances

  Incorrect

  A Savings Plan lowers the rate in exchange for a one- or three-year commitment, which the company wants to avoid, and the idle instances keep running and are still paid for.

• BSpread tasks across zones and then binpack on memory, with a capacity provider that uses managed scaling for the group

  Correct

  Binpack places tasks to leave the least unused CPU or memory, which minimizes the number of instances in use, while the zone spread keeps each service across Availability Zones. Managed scaling then adds and removes instances to match what the tasks reserve.

• CAdd a distinctInstance placement constraint so that every task gets an instance of its own and GPUs are not shared

  Incorrect

  distinctInstance places each task on a different container instance, which needs at least as many instances as tasks and leaves the other GPUs on each instance idle.

• DMove the services to AWS Fargate so that capacity follows the tasks and no instances are left idle

  Incorrect

  Fargate removes instance management, but the gpu task definition parameter is not valid for Fargate tasks, so GPU tasks cannot run there.

The waste comes from two choices: spreading tasks over every instance and a fixed group size. Packing tasks with binpack after a zone spread uses as few instances as possible, and ECS cluster auto scaling with managed scaling at the default 100% target capacity removes the instances that no longer hold tasks and adds them back when demand rises. A Savings Plan only discounts the waste, and Fargate cannot run GPU tasks.

• ASwitch the table to on-demand capacity mode so that the nightly job no longer needs provisioned capacity set aside for it

  Incorrect

  On-demand mode removes capacity planning for the nightly burst, but the job would still run, and every read and delete it makes would still be billed as a request.

• BAdd a global secondary index on the creation date so that the job queries only old items instead of scanning the table

  Incorrect

  A query on an index avoids reading the whole table, but the job still runs and issues every delete, and the index adds its own storage and write costs.

• CTurn on TTL with an expiration timestamp on each item, and filter out expired items in the application's queries

  Correct

  DynamoDB deletes expired items automatically, without consuming write throughput, typically within a few days of expiration. Because expired items can be read until then, AWS advises filter expressions to remove them from query and scan results.

• DProcess the table's stream with a Lambda function that deletes each session item once it is older than 24 hours

  Incorrect

  DynamoDB Streams captures item-level changes for processing, so the function could find old items without a scan, but its deletes still consume write capacity like any other delete.

The constraints are no paid deletes, no scan, no clean-up job, and no expired session accepted. On-demand mode, an index and a stream-driven function all keep a component that issues paid deletes. TTL deletes expired items without using write throughput, and filtering on the expiration attribute covers the days before an expired item is removed.