Task 2.6: Determine a cost optimization strategy to meet solution goals and objectives

• AReplace the NAT gateways with NAT instances on large EC2 instance types

  Incorrect

  NAT instances remove the NAT gateway charges but add instance costs and management, and the traffic would still pass through a NAT device.

• BAdd gateway VPC endpoints for Amazon S3 and DynamoDB to the route tables of the private subnets

  Correct

  Gateway endpoints for S3 and DynamoDB carry the traffic privately from the VPC and have no additional charge, so the NAT gateway data processing charges for this traffic disappear.

• CAdd interface VPC endpoints for Amazon S3 and DynamoDB in each Availability Zone

  Incorrect

  Interface endpoints are billed per hour and per GB processed, so they cost more than gateway endpoints for the same traffic.

• DMove the instances to public subnets with public IP addresses and reach the services through an internet gateway

  Incorrect

  This removes the NAT charges but exposes the instances, and the requirement that data does not use the internet path would no longer be met.

For S3 and DynamoDB in the same Region, gateway endpoints are both the private path and the cheapest one.

• AEC2 Instance Savings Plans for the instance family that the platform uses at launch

  Incorrect

  EC2 Instance Savings Plans apply to one instance family in one Region, and they do not cover Fargate or Lambda.

• BStandard Reserved Instances for the instance types in the launch design

  Incorrect

  Standard Reserved Instances are tied to instance attributes and do not apply to Fargate or Lambda usage.

• CCompute Savings Plans sized to the steady baseline of hourly compute spend

  Correct

  Compute Savings Plans apply to EC2 usage regardless of instance family, size, operating system, tenancy or Region, and also to Fargate and Lambda usage.

• DSpot Instances for the baseline, with On-Demand Instances as a fallback

  Incorrect

  Spot Instances can be interrupted, so they do not suit a baseline that must run around the clock, and they are not a commitment-based discount.

The more the platform will change, the more flexible the commitment must be: Compute Savings Plans follow usage across families, Regions and compute services.

• ACreate a cost budget per account with an 80% forecast alert and a budget action that applies a restrictive IAM policy at 100%

  Correct

  AWS Budgets can alert on forecast and actual spend, and budget actions can apply an IAM policy or SCP automatically, or after approval, when a threshold is reached.

• BTurn on AWS Cost Anomaly Detection for each sandbox account and send its anomaly alerts to the development team

  Incorrect

  Cost Anomaly Detection alerts on unusual spend patterns. It does not track a fixed limit or apply any policy.

• CCreate a CloudWatch billing alarm for each account that sends an Amazon SNS notification when charges reach 2,000 USD

  Incorrect

  A billing alarm notifies, but removing permissions would need custom code subscribed to the notification, and there is no forecast alert.

• DReview the AWS Trusted Advisor cost optimization checks for each sandbox account at the end of every month

  Incorrect

  Trusted Advisor recommends savings. It does not enforce a limit, and a monthly review comes too late.

Budgets cover both halves: forecast alerts for awareness and budget actions for control.

• AStore the documents on EBS volumes attached to a file server

  Incorrect

  Block storage costs more and is not suited to archives.

• BUse S3 Standard-IA for all ten years to keep retrieval fast

  Incorrect

  Standard-IA costs more than archive classes for data that is almost never read.

• CKeep all documents in S3 Standard

  Incorrect

  S3 Standard is priced for frequently accessed data.

• DAdd a lifecycle rule to S3 Glacier Deep Archive after 90 days

  Correct

  Lifecycle rules can transition objects that do not need real-time access to S3 Glacier Deep Archive.

Long-term archives that are rarely read move to Deep Archive by lifecycle.

• AMove the database to an RDS Single-AZ DB instance

  Incorrect

  This gives up Aurora's availability to change cost, and is not the direct fix.

• BAdd more Aurora Replicas to spread the I/O

  Incorrect

  More replicas add instance cost; I/O is still charged per request.

• CSwitch the cluster to Aurora I/O-Optimized storage

  Correct

  I/O-Optimized has no charges for read and write I/O and is the best choice when I/O spending is 25% or more of the Aurora bill.

• DTurn on Aurora Backtrack

  Incorrect

  Backtrack is an Aurora MySQL feature that rewinds data; it does not change I/O pricing.

When I/O dominates Aurora cost, use I/O-Optimized storage.

• AProvisioned capacity mode with auto scaling, its minimum at the baseline and its maximum above the forecast peak

  Correct

  Provisioned tables are charged for the hourly capacity provisioned, not for the requests consumed, which gives cost predictability for steady workloads with forecastable growth. Auto scaling uses target tracking to move capacity between the minimum and maximum as traffic changes.

• BOn-demand capacity mode with a maximum throughput setting at the forecast peak to cap the table's request rate

  Incorrect

  On-demand needs no capacity planning, and a maximum throughput setting caps how fast the table can be used. But on-demand charges for the requests served, which is the billing model finance does not want.

• CProvisioned capacity mode set to the forecast peak all day, raised each month to match the growth forecast

  Incorrect

  Fixed provisioning at the peak avoids throttling and is predictable, but it pays for peak capacity around the clock and needs a manual change every month, which the team will not do.

• DProvisioned capacity mode fixed at the baseline, with a DynamoDB Accelerator (DAX) cluster in front of the table for the peak

  Incorrect

  DAX is a write-through cache for eventually consistent reads and is not ideal for write-intensive applications. Every write still goes to the table first, so the peak's order writes would be throttled at baseline capacity.

The constraints are billing that follows an approved capacity plan, no throttling, no manual changes and no all-day peak capacity. On-demand bills per request even with a throughput cap, fixed peak provisioning wastes capacity and needs monthly edits, and a read cache does not absorb a peak made of writes. Provisioned capacity with auto scaling between the baseline and the peak meets every constraint.

• AMove the volumes to io2 Block Express for consistent performance

  Incorrect

  io2 is the highest-performance type for critical, IOPS-intensive workloads, more than this workload needs.

• BUse instance store for all volumes

  Incorrect

  Instance store data is temporary and not suited to persistent volumes.

• CUse gp3 volumes with IOPS set independently of size

  Correct

  gp3 lets you provision performance independently of volume size, at a 20 percent lower price per GiB than gp2.

• DMove the volumes to st1 HDD volumes

  Incorrect

  Throughput-optimized HDD does not suit transactional workloads that need IOPS.

gp3 removes the need to oversize volumes for IOPS and costs less per GiB.

• AOn-Demand Instances for every node in the cluster

  Incorrect

  All On-Demand pays full price for work that tolerates interruptions.

• BSpot Instances for the primary node

  Incorrect

  Losing the primary node would end the cluster.

• COn-Demand primary and core nodes, Spot task nodes

  Correct

  Task nodes do not store data, so they can use Spot Instances at a reduced cost while core nodes keep HDFS data.

• DSpot Instances for all core nodes to save the most

  Incorrect

  Core nodes store HDFS data, which could be lost if Spot capacity is reclaimed.

On EMR, run task nodes on Spot and keep data-holding nodes On-Demand.