4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Identify opportunities for cost optimizations
Larchmont Freight's S3 and data transfer charges doubled last quarter, and Cost Explorer shows the increase only at the service level. The FinOps analyst needs to find which specific buckets and which usage types drove the increase, hour by hour over the last 90 days, and wants to query the data with SQL alongside the company's existing Amazon Athena workgroup. The analyst wants to minimize ongoing maintenance.
Which solution should the solutions architect recommend?
- ACreate a CUR 2.0 export in AWS Data Exports with hourly granularity, resource IDs included and Parquet format, deliver it to an S3 bucket, and query it from Athena by grouping on line_item_resource_id and line_item_usage_type.CUR 2.0 provides line items per resource and usage type at hourly granularity in a fixed schema, and Parquet output in S3 is designed for querying with Athena.
- BEnable hourly and resource-level data in Cost Explorer and filter by S3.Cost Explorer resource-level data covers only a recent window and limited services, and it does not offer SQL queries over 90 days of hourly line items.
- CDownload the monthly invoice PDFs and compare the S3 sections.Invoices summarize charges by service and Region, not by bucket or hour.
- DEnable S3 server access logging on every bucket and count requests with Athena.Access logs show requests but not the charges for storage, transfer and requests, and they must be enabled before the period being investigated.
Why: The Cost and Usage Report is the most granular billing data AWS provides, with one line per resource, usage type and time interval. CUR 2.0, delivered through AWS Data Exports, has a consistent schema with nested columns such as resource tags and supports hourly granularity with resource IDs and Parquet output. Pointing an Athena table at the export location lets analysts group by resource ID and usage type to see exactly what changed. A new export starts with the current billing period, but AWS Support can backfill earlier billing periods when the analyst opens a support case that names the export and the periods needed, so the 90-day window can be covered.
Identify opportunities for cost optimizations
Elmstead Group uses AWS Organizations with 45 accounts. Teams tag resources with a cost center key, but finance reports two problems: the tag does not appear as a grouping option in Cost Explorer, and resources use the keys CostCenter, costcenter and Cost-Center with values that do not match the official list of cost centers. Finance wants accurate cost center reporting from the next billing period onward.
Which two actions should the solutions architect take? Each correct answer presents part of the solution.
- AActivate CostCenter as a user-defined cost allocation tag in the Billing and Cost Management console of the management account.User-defined tags appear in Cost Explorer and the Cost and Usage Report only after they are activated as cost allocation tags in the management account.
- BAttach an Organizations tag policy that defines the CostCenter key with its exact capitalization and the allowed values, and enforce it for the resource types the teams create.Tag policies standardize key capitalization and allowed values across accounts and, when enforced, prevent noncompliant tagging operations on the specified resource types.
- CActivate the cost allocation tag separately in each member account's Billing console.In an organization, cost allocation tags are activated by the management account; member accounts cannot activate them for consolidated billing.
- DActivate the AWS-generated aws:createdBy tag and use it as the cost center.aws:createdBy records the identity that created a resource, not the cost center that should pay for it.
- EDeploy the AWS Config required-tags rule so that it activates the tag for cost allocation.The required-tags rule reports resources that lack specified tags but has no effect on cost allocation tag activation.
Why: Tag-based cost allocation depends on two things: the tag must be activated for billing, and the tag must be applied consistently. Activation happens in the management account and applies from the time of activation forward, which is why the tag did not appear in Cost Explorer. Tag keys are case sensitive, so CostCenter and costcenter are different keys to billing; an Organizations tag policy fixes the key format and allowed values and can block noncompliant changes. Detection rules and AWS-generated tags help with governance but do not fix either problem alone.
Identify opportunities for cost optimizations
Sorrel Health runs one shared Amazon EKS cluster in which 12 product teams deploy workloads to their own Kubernetes namespaces. In the company's CUR 2.0 export, the cluster appears only as the cost of the EC2 worker nodes, so finance charges every team an equal share. The CFO wants each team charged for the CPU and memory its pods actually reserve, using the existing CUR and Athena reporting, without changing the cluster's node layout.
What should the solutions architect recommend?
- ACreate a separate managed node group for each team and tag each node group with the team name.This changes the node layout and lowers bin-packing efficiency, which raises cost to solve a reporting problem.
- BTag the shared worker nodes with the name of every team that uses them.A resource can hold only one value per tag key, and node tags cannot divide the node's cost among the pods running on it.
- COpt in to split cost allocation data for Amazon EKS in the Billing and Cost Management preferences of the management account, include split cost allocation data in the CUR 2.0 export, and query the split cost columns grouped by namespace in Athena.Split cost allocation data divides the cost of each EC2 node among the pods on it based on reserved CPU and memory and adds those allocations to the CUR, where they can be grouped by Kubernetes namespace.
- DUse Cost Explorer to group the EC2 costs by the aws:createdBy tag.aws:createdBy identifies the principal that created a resource, such as the node group role, and cannot split shared node cost among namespaces.
Why: Shared clusters hide team-level cost inside node charges, and granular CUR analysis needs data at the container level. Split cost allocation data for Amazon EKS, and the equivalent feature for Amazon ECS, computes each pod's share of the underlying EC2 instance cost from its CPU and memory reservations and adds split line item columns to the Cost and Usage Report. The split line items carry AWS-generated tags such as aws:eks:namespace and aws:eks:cluster-name, so teams can be charged by namespace or cluster in Athena queries, and the same tags can be activated for Cost Explorer. The distractors either change architecture to fix reporting or rely on tags that cannot divide a shared resource.
Identify opportunities for cost optimizations
Nettlebed Design runs a single AWS account with all of its workloads in eu-west-2. Its monthly bill has been steady at about $250, and the owner wants a CloudWatch alarm that emails her when the estimated charges for the month exceed $300. She created an alarm in eu-west-2 but cannot find the EstimatedCharges metric.
What should the solutions architect tell her to do?
- AEnable detailed monitoring on her EC2 instances so that billing metrics appear in eu-west-2.Detailed monitoring changes EC2 metric frequency and has no effect on billing metrics.
- BTurn on receiving CloudWatch billing alerts in the Billing preferences, then create the alarm on the EstimatedCharges metric in the US East (N. Virginia) Region with an SNS email action.Billing metric data is stored only in us-east-1 and appears after billing alerts are enabled, regardless of where the workloads run.
- CCreate a metric filter on the CloudTrail log group to count billing events.CloudTrail records API activity, not charges, so a metric filter cannot estimate the bill.
- DInstall the CloudWatch agent so that it publishes estimated charges as a custom metric.The CloudWatch agent publishes system and application metrics from instances and has no access to account billing data.
Why: CloudWatch billing alarms are the simplest way to watch a predictable bill. Estimated charges are published as the EstimatedCharges metric in the AWS/Billing namespace, only in us-east-1, and only after billing alerts are enabled in the Billing and Cost Management preferences. A static threshold suits this account because usage is steady, unlike a variable workload that would need anomaly detection. The Region is the usual trap because the metric does not follow the workloads.