FinOps on AWS — Tagging, Budgets & Cost Allocation Reports
Recap: From Right-Sizing to Chargeback
Day 54 gave us three instruments for looking at spend: Compute Optimizer right-sizing recommendations, Cost Explorer forecasts and RI purchase recommendations, and Trusted Advisor cost/security/performance/fault-tolerance checks. All three answer the question "are we spending the right amount on the right shapes of infrastructure?" — and all three answer it at the level of the whole account, or at best a service and a region. None of them can tell you which team owns the bill.
That is the same lifecycle stage with a different concern. Right-sizing is a technical optimization: you look at utilization, you change an instance family, you save money. Chargeback is an organizational one: you look at a bill, you attribute it to a cost center, and someone outside engineering has to trust the number. The tooling overlaps — Cost Explorer is the front end for both — but the prerequisite is entirely different. Right-sizing needs metrics. Chargeback needs tags, and tags are a governance problem long before they are a reporting problem. Today is about building the attribution layer that makes yesterday's recommendations defensible to Finance.
Foundations You'll Need Today
Today's material is about money, and money is the one part of AWS that behaves differently from everything else you have learned so far. Before we get into budgets and reports, there are four ideas the rest of this day assumes you already hold in your head. None of them are complicated, but all four are load-bearing.
Tags: Labels You Stick on Resources
A tag is just a label — a key and a value, like Environment=prod or CostCenter=4471 — that you attach to an AWS resource such as an EC2 instance, an S3 bucket, or a database. The problem tags solve is that AWS resources have no inherent sense of ownership. An instance knows what shape it is and what region it lives in, but it has no idea which team created it or what project it belongs to. Tags are how humans write that meaning onto the resource. The important wrinkle is that tags are not a global AWS feature: each service stores its own tags, so an instance's tags live in EC2 and a bucket's tags live in S3, and a resource type that does not support tagging simply cannot be labeled at all. Tags are also case-sensitive, which is why CostCenter and costcenter are two different keys and not the same one.
Accounts and Organizations: Why There Is More Than One
An AWS account is the fundamental container in AWS. It holds your resources, it holds your users and permissions, and — critically for today — it is the unit that AWS bills. Every charge on your bill is attached to exactly one account. Most organizations outgrow a single account quickly, because one account means one shared set of limits, one shared blast radius if something goes wrong, and one undifferentiated bill. So they create many accounts and group them using a service called AWS Organizations, which arranges accounts into a tree of organizational units (OUs) — for example, a "Workloads" OU containing a "Payments" account and a "Search" account. One account in that tree is designated the management account (sometimes called the payer account), and it is the one that receives the consolidated bill for everyone. The other accounts are member accounts. This structure matters today because the management account is where cost reporting is configured, while the resources that generate the costs live in the member accounts.
Service Control Policies: Guardrails, Not Permissions
A service control policy (SCP) is a rule you attach to an OU or an account in AWS Organizations that limits what anyone inside that scope is allowed to do. The mental model that trips people up is thinking of an SCP as a permission. It is the opposite: an SCP never grants access, it only takes it away. If an IAM user in a member account has a policy allowing them to launch an EC2 instance, and an SCP attached to their OU denies launching instances without a particular tag, the launch fails — the SCP wins, because the effective permission is the intersection of what IAM allows and what the SCP permits. This is why SCPs are the tool of choice when you need to make something mandatory rather than merely recommended. A Config rule can tell you after the fact that a resource was created without a tag; an SCP can prevent the resource from being created at all.
Billing Line Items: What the Bill Actually Contains
When people say "the AWS bill," they usually picture a total at the bottom of a page. What AWS actually produces is a long list of line items, where each line describes one slice of usage: this account, this service, this region, this usage type, this quantity, this cost. A single EC2 instance running for a month generates many lines, because compute hours, EBS storage, and data transfer are all billed separately. This granularity is the reason cost reporting is possible at all — you can slice the list by account, by service, by region, and, once you have done the work today's material describes, by tag. It is also the reason the Cost and Usage Report exists: it is the raw list, delivered as files, for anyone who needs to process it rather than look at it.
With that grounding — labels, accounts, guardrails, and line items — here is why cost attribution is a governance problem before it is a reporting problem, and what the exam expects you to do about it.
1. Why FinOps Is on the Exam
SAP-C02 has a dedicated cost-optimization domain, and within it the questions split cleanly into two families. The first family is about choosing cheaper infrastructure: Savings Plans versus Reserved Instances versus Spot, Graviton versus x86, S3 storage class selection, right-sizing. Day 53 and Day 54 covered that family. The second family is about knowing where the money went and being able to prove it — and that family is where tagging, budgets, and the Cost and Usage Report live. The exam tests the second family less often but more sharply, because the answers are less about product knowledge and more about sequencing. A question that asks "what should be done first" has exactly one defensible answer, and it is almost never the reporting tool.
The architectural problem underneath is that AWS billing is account-scoped by default. Every line item in your bill is attached to an account, a service, a region, and a usage type. That is enough to answer "how much did we spend on EC2 in us-east-1" and nothing else. It cannot answer "how much did the payments team spend," because the payments team is not an account — it is a set of resources spread across accounts, and the only thing tying those resources together is metadata that someone had to apply deliberately. Cost allocation is therefore not a reporting feature you turn on; it is a data-quality program that produces a report as a side effect. The exam rewards candidates who understand that ordering.
There is a second reason this shows up: the multi-account governance material from Week 1 is the enforcement mechanism. SCPs, AWS Config rules, and Control Tower guardrails are the tools that make tagging mandatory rather than aspirational, and the exam likes questions that connect a governance control to a downstream business outcome. When a scenario describes an organization that "cannot produce per-team cost reports," the correct answer is usually to fix the tag enforcement at the Organizations layer, not to buy a third-party FinOps platform. The platform can only report on the tags that exist.
Finally, cost questions on SAP-C02 are frequently disguised as architecture questions. A scenario about consolidating accounts, choosing between a shared VPC and per-team VPCs, or deciding whether to run a workload in one region or three all have cost-attribution consequences. Being able to say "this design makes chargeback harder because the resources cannot be tagged independently" is a senior-architect move, and it is the kind of reasoning the exam is trying to surface.
2. How Cost Attribution Actually Works
The mechanism has four moving parts, and understanding the order they fire in explains most of the confusing behavior people hit in practice. The first part is the tag itself: a key-value pair attached to a resource, stored by the service that owns the resource. Tags are not global. An EC2 instance's tags live in EC2, an S3 bucket's tags live in S3, and a resource that does not support tagging simply cannot participate in cost allocation no matter how much you want it to. The second part is the billing pipeline, which records usage against resources and, at the end of each billing period, emits line items. The third part is the cost allocation tag activation step, which is a deliberate, per-key opt-in in the Billing console. The fourth part is the report — Cost Explorer, a budget, or the CUR — which reads the activated tags and groups by them.
The activation step is where most people lose an afternoon. Attaching a tag to a resource does nothing for cost reporting until you go into the Billing console and activate that tag key for cost allocation. Activation is per key, not per value, and it is not retroactive in the way people expect: once a key is activated, AWS begins including it in your cost allocation data going forward, and historical data for that key is generally not backfilled. This means the sequence matters enormously. If you tag resources in January and activate the key in March, your January and February costs will show up as untagged. The practical implication is that tag activation should happen before or alongside the tagging rollout, not after it.
There is also a distinction between AWS-generated tags and user-defined tags that the exam likes to probe. AWS-generated tags are applied by AWS itself — things like aws:createdBy — and they are available for cost allocation without you doing anything. User-defined tags are the ones you apply, and they are the ones that require activation. Both appear in the CUR, but only user-defined tags are under your control, which is why the enforcement conversation is always about user-defined tags.
Once tags are activated, the three reporting surfaces diverge in granularity and latency. Cost Explorer is the interactive front end: it aggregates, filters, and groups by activated tags, and it is where most day-to-day analysis happens. AWS Budgets is a threshold engine that watches a filtered slice of that same data and fires when actual or forecasted spend crosses a line. The Cost and Usage Report is the raw feed: the most granular billing data AWS publishes, delivered to S3 as files, with line items at the resource and usage-type level. The relationship is a funnel — CUR is the source of truth, Cost Explorer is a query layer over it, and Budgets is an alerting layer over a filtered view of it. When a scenario asks for "the most granular billing data for custom tooling," it is asking for CUR, and the word "custom" is the tell.
3. The Core Decision Boundary: Which Reporting Surface
Almost every cost-visibility scenario reduces to one fork: does the requirement describe a human looking at a chart, a machine firing an alert, or a system consuming raw data? Those three map to Cost Explorer, AWS Budgets, and the Cost and Usage Report respectively, and the exam is usually testing whether you can hear which one the scenario is describing. The trap is that all three can technically answer a lot of the same questions — you can build a budget on almost anything Cost Explorer can show — so the differentiator is not capability but fitness for the stated consumer.
The second-order fork, which appears in harder questions, is whether the requirement is about attribution or about control. Attribution is "tell me how much each team spent." Control is "stop the payments team from spending more than $40,000 this month." Attribution is a reporting problem solved with tags and CUR. Control is a governance problem solved with Budgets actions, which can apply an IAM policy or stop instances when a threshold is breached. Candidates who conflate the two tend to pick Budgets for pure reporting questions, which is defensible but not the best answer when the scenario explicitly asks for granular data export.
| Requirement | Best fit | Why |
|---|---|---|
| Interactive exploration of spend by team | Cost Explorer | Aggregates and groups by activated tags with no pipeline to build |
| Alert when forecasted spend exceeds a threshold | AWS Budgets | Purpose-built threshold engine with forecasted and actual comparisons |
| Automated action when a threshold is breached | AWS Budgets actions | Can apply IAM policies or stop instances on breach |
| Raw line-item data for a BI tool or data lake | Cost and Usage Report | Most granular billing data, delivered to S3 on a schedule |
| Per-resource cost attribution | CUR with resource IDs enabled | Resource-level line items are a CUR option, not a Cost Explorer one |
| Showback to a team that has no AWS access | Cost Explorer saved reports or CUR-fed dashboard | Depends on whether the consumer needs live data or a scheduled extract |
The resource-level detail row is worth internalizing. Cost Explorer groups by service, account, region, and tag, but it does not give you a line item per EC2 instance. If a scenario needs to know that a specific instance cost $412 last month, that is a CUR question, and you have to have enabled resource IDs when you configured the report. This is a common exam gotcha because the requirement sounds like something Cost Explorer should handle.
4. Configuration Modes and Their Tradeoffs
Each of the three surfaces has configuration choices that trade effort against capability, and the exam tends to test the ones where the default is wrong for the stated requirement. For Cost Explorer the main choice is granularity and lookback: the console defaults to monthly granularity, and daily or hourly granularity is available but changes how much history you can see and how the data is aggregated. There is also a per-account enablement step — Cost Explorer has to be turned on before it will show anything, and it takes roughly a day before data appears. A scenario that says "we enabled Cost Explorer this morning and see nothing" is describing expected behavior, not a bug.
For AWS Budgets the meaningful choices are the budget type, the period, and whether the threshold is measured against actual or forecasted spend. Actual-spend budgets fire after the money is gone, which is fine for accounting but useless for prevention. Forecasted-spend budgets fire when AWS projects you will exceed the threshold within the period, which is what you want for a control. The period choice matters too: a monthly budget with a 100% threshold behaves very differently from a daily budget with the same threshold, because the daily one catches a runaway job on day two instead of day twenty-eight. Budgets also support a fixed target versus a planned-usage model, where you specify expected usage and let the budget alert on the delta.
The Cost and Usage Report has the richest set of knobs and the most consequences for getting them wrong. You choose the time granularity (hourly, daily, or monthly), whether to include resource IDs, whether to integrate with Athena, and which S3 bucket receives the files. Hourly granularity with resource IDs produces a very large dataset — this is the configuration that makes CUR useful for chargeback and also the one that makes people underestimate their S3 storage bill. The report is delivered as CSV or Parquet; Parquet with Athena integration is the standard pattern for anything beyond a one-off analysis, because it is columnar and dramatically cheaper to query.
There is one more configuration decision that sits above all three: whether the tags themselves are enforced. A tag policy that is merely documented will decay. Enforcement options run from soft (Config rules that flag non-compliant resources) to hard (SCPs that deny resource creation without required tags). The tradeoff is real — hard enforcement breaks automation that does not yet apply tags, and it will generate support tickets in the first weeks — but soft enforcement produces exactly the inconsistent tagging that makes the whole reporting stack useless. Most mature organizations land on hard enforcement for a small set of mandatory keys and soft enforcement for everything else.
5. Sizing, Limits and Quotas
The numbers that matter here are mostly about tag mechanics and report delivery, and they are the kind of thing the exam expects you to recognize rather than recite. Tags are limited per resource, and the limit varies by service — most services allow 50 user-defined tags per resource, though some allow fewer. Tag keys are case-sensitive, which is a quiet source of duplicate-looking data: CostCenter and costcenter are two different keys, and activating one will not capture resources tagged with the other. Tag values are also case-sensitive, so Prod and prod will appear as separate groups in your reports.
Cost allocation tag activation has its own limits. There is a maximum number of cost allocation tags that can be active at once, and the practical guidance is to activate only the keys you actually report on, because every active key adds columns to the CUR and complexity to every downstream query. Activation is also per payer account in an Organizations setup, which means the management account controls what the whole organization can report on.
| Item | Value / behavior | Practical consequence |
|---|---|---|
| User-defined tags per resource | Typically 50, service-dependent | Enough for cost keys; not a constraint in practice |
| Tag key case sensitivity | Case-sensitive | CostCenter and costcenter are distinct keys |
| Cost allocation tag activation | Per key, opt-in, in the Billing console | Tagging without activation produces no cost data |
| Historical backfill on activation | Not retroactive in the way most people expect | Activate keys before or with the tagging rollout |
| Cost Explorer data latency | Roughly a day after enablement | Empty console on day one is expected |
| CUR granularity options | Hourly, daily, or monthly | Hourly plus resource IDs is the chargeback-grade config |
| CUR delivery format | CSV or Parquet, to S3 | Parquet plus Athena is the standard analysis pattern |
| Budget period options | Daily, monthly, quarterly, annually | Daily budgets catch runaway spend far earlier |
The CUR storage cost is the number people forget. A large organization running hourly granularity with resource IDs enabled can produce a substantial volume of data every month, and because the report lands in S3, it accrues storage charges indefinitely unless you set a lifecycle policy on the bucket. The exam does not usually ask for the exact figure, but it does like scenarios where the cost-visibility solution itself has a cost that needs managing — and the correct answer is a lifecycle rule on the CUR bucket, not disabling the report.
6. Failure Modes and What They Look Like in Production
The most common failure is silent and looks like success: the reports run, the charts render, and a large fraction of spend lands in an "untagged" or "no tag key" bucket. This happens for three reasons, and distinguishing them is the first diagnostic move. Resources created before the tagging rollout were never tagged. Resources created after the rollout were tagged with a key that was never activated for cost allocation. Or resources were tagged with a case variant of the expected key. The symptom is identical in all three cases — a big untagged slice — so the diagnostic is to open the CUR and look at the actual tag keys present on the untagged line items, not to assume the rollout failed.
The second failure mode is tag drift, where the tag exists but the value is wrong or inconsistent. A team tags half its resources Environment=prod and half Environment=production, and now every report has two production rows that nobody reconciles. This is worse than missing tags in some ways, because missing tags are visibly missing while wrong values look plausible. The diagnostic here is a Config rule or a periodic query against the CUR that enumerates distinct values per key and flags anything outside an approved list.
The third failure mode is budget alert fatigue. An organization creates a budget per team with a threshold set at the team's expected spend, and within a month every team is over because the thresholds were set from a single month's baseline that happened to be low. The alerts fire constantly, people start filtering them, and the control is effectively gone. The fix is not to raise thresholds blindly but to set them from a trailing average with headroom, and to separate the "you are trending over" alert from the "you have breached" alert so the two have different urgency.
The fourth is the one that catches architects specifically: a workload design that makes attribution impossible. If a shared ECS cluster runs containers for four teams, and the cluster is tagged once, then the cluster's cost is attributable to nobody in particular. The same is true of a shared NAT Gateway, a shared Transit Gateway, or a shared RDS instance with multiple schemas. These are legitimate architectural choices, but they push cost attribution into a manual allocation model — you split the shared cost by some agreed ratio — and the exam will sometimes present this as the reason a design fails a cost requirement. The fix is either to tag at a finer granularity where the service supports it, or to accept a documented allocation model and be explicit that it is an estimate.
7. The Operational Angle: Making Cost a First-Class Signal
Cost is an operational signal in the same way latency and error rate are, and it deserves the same treatment: a metric, a threshold, an alert, and a runbook. The metric is the budget's actual or forecasted spend. The threshold is the budget amount. The alert is the budget notification, delivered to an SNS topic so it can reach the same on-call channel as everything else. The runbook is the part most organizations skip, and it is the part that determines whether the alert is actionable. A budget alert that says "you are over budget" with no next step is noise. A budget alert that links to a runbook saying "check for orphaned NAT Gateways, unattached EBS volumes, and runaway Lambda invocations in this account" is a control.
The SLO framing is useful here too. If Finance has agreed that each team's monthly spend will stay within 10% of forecast, that is an objective, and the budget is the measurement. The error budget concept translates directly: a team that is consistently 3% under forecast has headroom to experiment, and a team that is consistently at the edge should be reviewing its architecture before it breaches. Framing cost this way moves it out of the annual-negotiation category and into the continuous-improvement category, which is where it actually gets managed.
On the monitoring side, the practical setup is a small number of budgets per account rather than one giant budget for the organization. A per-account budget catches the account that has gone rogue. A per-service budget catches the service that has changed shape. A per-team budget, built on a cost allocation tag filter, is the one Finance actually cares about. These three views answer different questions and all three are cheap to create. The mistake is building only the third one, because a team-level budget will not tell you which account to look in when it fires.
Finally, there is a hygiene routine worth putting on a schedule: a monthly review of untagged spend, a quarterly review of active cost allocation tags to retire keys nobody queries, and an annual review of the CUR bucket's lifecycle policy. None of these are glamorous, and all of them are the difference between a cost program that works and one that produced a nice dashboard in year one and drifted into irrelevance by year two.
8. Edge Cases and Exam Gotchas
The single most-tested gotcha is the activation step. A scenario will describe an organization that has tagged every resource correctly and still cannot see per-team costs. The answer is that the tag keys were never activated for cost allocation in the Billing console. This is worth memorizing as a pattern because it appears in several forms: sometimes the scenario says the tags exist, sometimes it says the tags were applied by automation, and sometimes it says the tags are visible in the resource console — all of which are true and all of which are irrelevant until activation happens.
The second gotcha is the difference between a tag being present and a tag being useful. A resource tagged Name=web-server-01 has a tag, but Name is not a cost allocation key and will not help you attribute spend. The exam sometimes presents a scenario where tagging is "complete" but the tags are operational rather than financial, and the correct answer is to introduce cost-specific keys rather than to activate the existing ones.
The third is the shared-resource problem described earlier. When a scenario asks how to attribute the cost of a shared service, the honest answer is that you cannot do it precisely with tags alone, and the exam usually wants you to recognize that rather than propose a tag that does not exist. Options include splitting the shared cost by an agreed allocation, or restructuring so the shared resource becomes per-team — but the latter is often architecturally worse, and the exam will sometimes test whether you resist that trade.
The fourth is the CUR resource-ID option. If a scenario needs per-resource cost data and the CUR was configured without resource IDs, the fix is to reconfigure the report, and the historical data will not have the detail. This is a "you had to plan ahead" gotcha, similar in shape to the activation one.
The fifth is the Organizations angle: cost allocation tags are activated in the management account and apply across the organization, but the tags themselves are applied in member accounts. A scenario where member accounts tag resources but the management account never activates the keys is the same failure as the first gotcha, viewed from a different direction. And a scenario where the management account activates keys that member accounts never apply produces empty columns — the mirror image.
9. This vs. the Services It Gets Confused With
The confusion set here is small but sharp, because the three reporting surfaces overlap in capability and the adjacent cost tools overlap in purpose. The cleanest way to hold it is by consumer: Cost Explorer is for a human exploring, Budgets is for a threshold firing, CUR is for a system consuming. Everything else is a variation on those three.
| Service | Primary job | Pick it when… |
|---|---|---|
| Cost Explorer | Interactive analysis and forecasting | A person needs to explore spend by tag, service, or account |
| AWS Budgets | Threshold alerting and automated action | You need to be told, or act, when spend crosses a line |
| Cost and Usage Report | Raw granular billing data | A BI tool, data lake, or custom system needs line-item detail |
| Compute Optimizer | Right-sizing recommendations | The question is "is this instance the right shape," not "who owns it" |
| Trusted Advisor | Best-practice checks across pillars | You want a broad sweep including idle-resource detection |
| Cost Allocation Tags | The attribution substrate | Always — nothing above works without it |
The distinction between Cost Explorer and CUR is the one most often missed. Cost Explorer is not a thin wrapper over CUR in the sense that you can get the same data from either; Cost Explorer aggregates and does not expose resource-level line items, while CUR does. If the requirement mentions a specific resource, a specific hour, or a downstream system, it is CUR. If it mentions a chart, a trend, or a forecast, it is Cost Explorer.
The distinction between Budgets and everything else is that Budgets is the only one that can act. Cost Explorer and CUR are read-only. If a scenario says "and then automatically restrict the team's ability to launch new instances," that is a Budgets action, and no amount of Cost Explorer configuration will produce it. Recognizing the word "automatically" as the signal for Budgets actions is a reliable exam heuristic.
Hands-On Lab: A Mandatory Tagging Policy and Per-Cost-Center Budgets (60 min)
This lab builds the attribution layer end to end: a tag taxonomy, hard enforcement at the Organizations layer, activation of the cost allocation keys, and a budget per cost center with a forecasted-spend alert. Work in a sandbox organization with at least two member accounts. If you do not have an organization, you can do steps 3 through 6 in a single account and note where the Organizations steps would sit.
1. Define the taxonomy before touching anything. Write down the mandatory keys and their allowed values. A workable minimum is CostCenter (values matching your finance system's cost center codes), Environment (prod, staging, dev), and Owner (an email or team alias). Keep the value sets small and lowercase, and write them down somewhere a human can find them — the most common cause of tag drift is that nobody knows what the approved values are. Resist adding more keys at this stage; every key you add is a column in the CUR and a thing that can be wrong.
2. Decide the enforcement level per key. For CostCenter and Environment, choose hard enforcement: an SCP that denies resource creation when the required tags are absent. For Owner, start with a Config rule that flags non-compliance rather than blocking, because ownership is often assigned after creation. Write down which keys are hard and which are soft, and why.
3. Build the SCP. In the management account, create a service control policy that denies the relevant create actions when aws:RequestTag/CostCenter or aws:RequestTag/Environment is missing. Attach it to the OU containing your workload accounts, not to the root, so you can exempt the management account and any sandbox OUs. Test it by attempting to launch an EC2 instance with no tags and confirming the denial, then with both tags and confirming success. Note the exact error message — you will see it again from teams.
4. Activate the cost allocation keys. In the Billing console of the management account, activate CostCenter and Environment for cost allocation. Confirm they appear in the list of active cost allocation tags. This is the step that makes everything downstream possible, and it is the step most people forget. If you are working in a single account, activate them there.
5. Tag a representative set of resources. Launch a handful of resources across two accounts with the mandatory tags applied, using values from your approved list. Include at least one resource you deliberately leave untagged in an account where the SCP does not apply, so you can see what untagged spend looks like in the reports.
6. Build a budget per cost center. Create an AWS Budget of type Cost budget, scoped with a tag filter on CostCenter equal to one of your values. Set the period to monthly and the amount to a realistic figure. Add two notifications: one at 80% of forecasted spend, and one at 100% of actual spend. Send both to an SNS topic rather than to individual email addresses, so the alert can be routed to the same channel as your other operational alerts.
7. Verify the pipeline. Wait for the next billing data refresh — this can take up to a day — then open Cost Explorer, group by CostCenter, and confirm your tagged resources appear under the right value and that the deliberately untagged resource appears under "no tag key." This untagged bucket is the number you will be managing for the rest of the program's life, so look at it deliberately.
8. Configure the CUR. Create a Cost and Usage Report with hourly granularity, resource IDs enabled, and Parquet format, delivered to a dedicated S3 bucket. Add a lifecycle policy to that bucket that transitions objects to a cheaper storage class after 90 days and expires them after a year. If you have Athena available, set up the integration and run one query that sums cost by CostCenter for the previous day.
9. Write the runbook. One page: what a budget alert means, the three things to check first (untagged spend, orphaned resources, a recent deployment that changed instance shapes), and who to contact if the spend is legitimate. This is the artifact that turns the lab into an operational control.
Scenario Question Drills (20 min)
Q1. Finance wants to see AWS spend broken out per business unit, but resources are inconsistently tagged today. What should be enforced first?
Q2. An organization has tagged every EC2 instance with a CostCenter key, but Cost Explorer still shows all spend as untagged. What is the most likely cause?
Q3. A BI team needs line-item billing data at the individual resource level, refreshed daily, to feed a custom chargeback dashboard. Which service should you configure?
Q4. A team's monthly spend is unpredictable and Finance wants to be warned before the month ends if the team is on track to exceed its allocation. Which budget configuration fits?
Q5. A company wants a control that automatically restricts a team's ability to launch new EC2 instances when its monthly spend exceeds a threshold. What should be configured?
Q6. Reports show two separate production rows, one for Environment=prod and one for Environment=Production. What is the root cause?
Q7. A shared ECS cluster runs containers for four different teams, and Finance wants each team's cost attributed precisely. What is the most accurate statement about this requirement?
Q8. An organization's CUR bucket has grown to a significant monthly storage cost. What is the appropriate fix?
Q9. A company wants to enforce that no EC2 instance can be launched without a CostCenter tag, across all workload accounts. Which mechanism is appropriate?
Q10. Cost Explorer was enabled this morning and shows no data. What is the expected explanation?
Q11. A team has tagged resources with Name, Team, and AppVersion, and Finance cannot produce per-team reports. What is the most likely issue?
Q12. An organization wants a single view of spend that catches an individual account going rogue, a service changing shape, and a team overspending. What is the recommended budget structure?
Q13. A company needs per-resource cost data for the last six months, but the CUR was configured without resource IDs. What is true?
Q14. In an AWS Organizations setup, where are cost allocation tags activated, and where are the tags themselves applied?
Q15. A budget alert fires every week and the on-call team has started ignoring it. What is the most effective remediation?
Peek into Tomorrow: DMS and the Cost of Moving Data
Everything in this day assumed the data is already where it needs to be and the only question is who pays for it. Tomorrow that assumption breaks, because the highest-yield topic in the migration domain is about moving data between engines while the source keeps serving traffic — and the mechanism that makes that possible is Change Data Capture. The open question is what "minimal downtime" actually costs you in configuration complexity. A full load is simple and cheap to reason about, but it implies a maintenance window proportional to the dataset. Full load plus CDC removes the window, and in exchange you now own a replication instance that has to be sized correctly, a change stream that has to keep up, and a class of failures that only appear under sustained write load.
There is a second question hiding underneath, and it is the one that separates a working migration from a stalled one: what happens to the objects that do not convert cleanly? When the source and target engines differ, schema conversion produces a completeness percentage, and the remainder is manual work that no amount of replication capacity will fix. Tomorrow's material is where the DMS full load versus CDC decision, replication instance sizing, LOB handling, and the schema-conversion-plus-replication pattern come together — and where the cost model shifts from "who owns this line item" to "what does this migration window actually cost the business."
Sources
- AWS Billing — Using cost allocation tags
- AWS Billing — Managing costs with AWS Budgets
- AWS Cost and Usage Report — What is the AWS Cost and Usage Report?
- AWS Billing — What is AWS Cost Explorer?
- AWS Tag Editor — Tag policies in AWS Organizations
- AWS Organizations — Service control policies
- AWS Billing — Querying the CUR with Amazon Athena
- AWS Well-Architected — Cost Optimization Pillar