AWS costs: Config pricing deep-dive - tuning the recorder

Logeshwaran.C

AWS Config charges you for three separate meters running at once — configuration items recorded, rule evaluations run, and conformance pack evaluations layered on top — and the recorder is the lever that controls the biggest of the three. Here's the counterintuitive part: continuous recording, priced at $0.003 per configuration item, often costs more in total than daily recording at $0.012 per item, because continuous mode bills every single change while daily mode bills at most one item per resource per day.

⚡ Quick Answer

Cheapest first move → Switch the configuration recorder from Continuous to Daily recording for any resource type that changes often but doesn't need real-time alerts.

Biggest single cut → Exclude high-churn, low-value resource types (Auto Scaling launch configs, ephemeral EC2 Spot instances, Lambda versions) from the recorder entirely.

Hidden trap → A service-linked recorder (Security Hub, CloudWatch Observability Admin) set to continuous recording can silently override your customer managed recorder's "Daily" setting for any resource type both of them track.

Full breakdown, worked numbers, and every lever below — start with the five levers that actually cut the bill.

AWS's own pricing example proves the point above: 1,000 continuous configuration items cost $3.00, while the identical 24 hours of activity under daily recording costs $1.20. Get the recording frequency wrong on a noisy resource type and you're paying a real premium for change history most reviews never open.

Jake had never opened the AWS Config line item on his invoice before. He runs a small mobile phone repair shop, and about eighteen months ago he started renting out a rack of refurbished laptops to local students on a monthly plan — which meant an AWS account, a handful of EC2 instances, some S3 buckets for backups, and, because his cousin told him it was "just good practice," AWS Config turned on with the default settings and never touched again.

Then a bill came in nearly four times his usual number, and he didn't know why. That's the shop-floor version of a very common problem: AWS Config is one of the only AWS services where the meter runs based on how much your infrastructure changes, not how much of it you have sitting still. A quiet account can cost almost nothing. A noisy one — Auto Scaling groups cycling instances, Lambda publishing new versions, CI/CD pipelines updating security groups — can generate tens of thousands of billable configuration items a month without a single new resource being provisioned.

What AWS Config Actually Charges You For

AWS Config's own pricing page states the model plainly: you're charged based on the number of configuration items recorded, the number of active AWS Config rule evaluations, and the number of conformance pack evaluations in your account. There's no minimum, no upfront commitment, and — importantly — no free tier for the service itself. You pay for exactly what the recorder captures.

A configuration item (CI) is a record of the configuration state of one resource at one point in time. Every time AWS Config's recorder detects that a resource it's watching was created, changed, or deleted, it writes a CI. A rule evaluation is a single compliance check of one resource against one AWS Config rule. A conformance pack evaluation is the same idea, but for a rule bundled inside a conformance pack — the grouped rule sets used for frameworks like PCI-DSS or CIS benchmarks.

Billing component What triggers it Rate
Continuous configuration item A resource in scope changes, and the recorder is set to continuous $0.003 per item
Daily (periodic) configuration item The recorder is set to daily and the resource's state differs from the prior 24-hour snapshot $0.012 per item
Config rule evaluation A rule checks a resource's compliance state $0.001 (first 100,000) / $0.0008 (next 400,000) / $0.0005 (above 500,000) per evaluation, per Region
Conformance pack evaluation A rule inside a conformance pack checks a resource Same tiered rate as rule evaluations
S3, SNS, Lambda Storing snapshots/history in S3, delivering change notifications via SNS, running custom rules on Lambda Standard rates for each of those services

‍♂️ Jake's Reality Check

"So the CIs themselves cost pennies each. Why did my bill jump so much?"

Because pennies multiply fast when a resource changes hundreds of times a month. A single Auto Scaling group cycling instances every few hours, or a CI/CD pipeline that touches a security group on every deploy, can generate thousands of CIs on its own — and if you've also got twenty Config rules evaluating every one of those resources, the rule-evaluation meter is running right alongside it.

Continuous vs. Daily Recording — the Trap in the Per-Item Price

AWS Config supports two recording frequencies for the customer managed recorder: Continuous recording, which writes a new CI the instant a change happens, and Daily recording, which writes at most one CI per resource per day, and only if that resource's state differs from the previous day's snapshot. This is what the pricing page calls "periodic recording" — same setting, two names, one behavior.

Look at the per-item price on its own and daily recording looks expensive: $0.012 versus $0.003, a 4x markup per item. That reading is backwards, and AWS's own published example shows why. Take 100 EC2 instances, each generating 10 configuration changes in a 24-hour window — 1,000 total change events.

Recording frequency CIs generated Cost for the 24-hour period
Continuous 1,000 (every change is recorded) 1,000 × $0.003 = $3.00
Daily 100 (one per resource, regardless of how many times it changed) 100 × $0.012 = $1.20

Same infrastructure, same 24 hours — daily recording came out 60% cheaper, because it collapses ten change events per resource into one billable item. The higher unit price only matters once per resource, per day, no matter how many times that resource actually changed. Continuous recording bills every single one of those ten events separately. The break-even point sits somewhere around four changes per resource per day; below that, continuous is usually cheaper per resource, and above it, daily usually wins.

✅ Why daily recording is the sane default for most accounts

Unless you're running AWS Firewall Manager — which depends on continuous recording to monitor your resources — or you need to catch a misconfiguration within minutes for a security-sensitive resource type, daily recording gives you the same compliance history at a lower cost on any resource type that changes frequently. Reserve continuous recording for the resource types where minute-by-minute drift actually matters to you: IAM policies, security groups, S3 bucket policies. Leave the high-churn, low-stakes resource types on daily.

Ethan put it to Jake this way: "Continuous recording is a security camera that never stops filming. Daily recording is a camera that only saves the last frame of the day. For your S3 bucket policies, you want the camera running. For your Auto Scaling launch templates that regenerate every deploy, you don't need the footage — you need to know what it looked like this morning."

Estimating How Many Configuration Items You're Actually Generating

The single most useful thing you can do before flipping AWS Config on — or before deciding whether to switch an existing recorder's frequency — is find out how many change events your account already produces. AWS Config's own documentation flags this explicitly: the first month you record with Config, you should expect elevated activity, because the recorder runs a full evaluation pass on every resource you've selected during initial bootstrapping. That first-month spike is not a bug and not a billing error; it's the baseline snapshot.

To estimate volume before you commit, AWS's Cloud Operations team recommends querying AWS CloudTrail — specifically CloudTrail Lake — for the management events that would trigger a configuration item if Config were recording. You're counting API calls that mutate a resource (create, update, delete) across the resource types you're considering. It won't be a perfect one-to-one match — some resource types, like AWS::Config::ResourceCompliance, aren't captured by a simple CloudTrail query — but it gives you a real number to size your budget against instead of guessing.

  1. Open the CloudTrail console and go to Lake in the left navigation.
  2. Open the Editor and point a query at your CloudTrail Lake event data store, filtering for management events from the AWS service sources you care about (EC2, S3, IAM, and so on).
  3. Count events grouped by account and Region — that count is a reasonable upper bound for the configuration items those resource types would generate under continuous recording.
  4. Compare that number against the $0.003 (continuous) and $0.012 (daily, but far fewer items) rates to see which frequency actually lands cheaper for your change volume.

One caveat worth saying plainly: running that CloudTrail Lake query itself costs money — it's billed under CloudTrail's own pricing, separate from Config. It's still cheaper than turning Config on blind and finding out the hard way. And it's especially worth running if any part of your workload is ephemeral — AWS Config's documentation specifically calls out EC2 Spot Instances, Amazon EMR jobs, and AWS Auto Scaling as workloads that will generate elevated CI counts purely from their normal create-and-terminate cycle, independent of anything going wrong.

Recording Strategy: All Supported, Specific, or Exclusion

Recording frequency (continuous vs. daily) controls how often a resource generates a billable item. Recording strategy is a separate dial — it controls which resource types get recorded at all. By default, a customer managed configuration recorder records all supported resource types in its Region, excluding the global IAM types (AWS::IAM::Group, AWS::IAM::Policy, AWS::IAM::Role, AWS::IAM::User), which you have to opt into separately.

In the console, you'll see this framed as "Record all resource types with customizable overrides" or "Record specific resource types." In the API and CLI, the same choices map to three recording strategy values: ALL_SUPPORTED_RESOURCE_TYPES, INCLUSION_BY_RESOURCE_TYPES, and EXCLUSION_BY_RESOURCE_TYPES.

Strategy What it records Best when
Record all resource types (ALL_SUPPORTED_RESOURCE_TYPES) Every supported type, including new ones AWS adds later, minus pre-Feb-2022 global IAM types unless added You want blanket compliance coverage and cost is secondary
Record specific resource types (INCLUSION_BY_RESOURCE_TYPES) Only the types you list Your compliance scope is a known, short list (e.g. only EC2, S3, IAM)
Record all with exclusions (EXCLUSION_BY_RESOURCE_TYPES) Everything except the types you name You want broad coverage but need to cut a few known high-churn, low-value resource types

For most cost-sensitive accounts, the exclusion strategy is the sweet spot: you keep new resource types automatically covered as AWS adds them, while carving out the specific types you already know are noisy. AWS Config's own guidance names the usual suspects for exclusion directly — ephemeral workloads like EC2 Spot Instances, Amazon EMR jobs, and resources spun up and torn down by Auto Scaling. If a resource type isn't recorded at all, Config still captures its creation and deletion for free — no configuration detail, no relationship tracking, just a notification and a null-valued entry on the resource's details page. You lose the history, but you don't pay for it.

The Five Levers That Actually Cut the Bill

Cheapest and least disruptive first. Work down this list before you touch anything structural.

  1. Switch high-churn resource types to daily recording. Leave sensitive types (IAM, security groups, S3 policies) on continuous; move Auto Scaling, Lambda versions, and other frequently-regenerated types to daily. This alone was the difference in the $3.00-vs-$1.20 example above.
  2. Exclude ephemeral resource types entirely. Spot Instances, EMR job resources, and Auto Scaling lifecycle artifacts generate configuration items on every create and terminate cycle. If you don't need their compliance history, exclude them from the recorder using EXCLUSION_BY_RESOURCE_TYPES — or, for genuinely disposable test workloads, run them in a separate account with Config turned off.
  3. Trim your rule set to what you actually act on. Every active Config rule evaluates every in-scope resource it applies to, and each evaluation is billed on the same tiered scale as CIs. A rule nobody reads the findings for is still running the meter.
  4. Deploy global-resource rules to one Region only, not every Region. If a rule checks a global IAM resource type, running it in five Regions produces five times the evaluations for the same underlying resource.
  5. Watch for service-linked recorder overlap. A service-linked recorder set to continuous recording and a "PAID" scope will silently force continuous billing on any resource type it shares with your customer managed recorder — even if your recorder's console page still reads "Daily recording." More on this below.

Rule Evaluations and Conformance Packs — the Second Meter

Configuration items are only the first meter. The second is rule evaluations, and it's tiered — a volume discount that kicks in automatically as you cross thresholds. The first 100,000 evaluations in a Region cost $0.001 each; the next 400,000 (100,001–500,000) drop to $0.0008; anything above 500,000 costs $0.0005. Conformance pack evaluations — rules bundled together to check a framework like PCI-DSS or CIS benchmarks — bill on the exact same tiered structure.

Here's a nuance most teams miss: AWS Config rules can run in two modes, detective (checking existing resources after the fact) and proactive (checking a resource definition before it's created, typically inside CloudFormation). If a rule has only proactive mode enabled, its evaluations are billed at the normal tiered rate. But if a rule has both detective and proactive modes enabled on the same rule, AWS's own pricing example shows the proactive evaluations on that rule running at $0 — only the detective-mode evaluations are charged. It's a genuinely easy detail to miss when you're estimating a bill, because "proactive mode" sounds like it should always be free, and it isn't, unless it's paired with detective mode on the same rule.

Take AWS's published example directly: 10,000 configuration items, 25,000 detective-mode evaluations, and 50,000 proactive-mode evaluations, all from rules with both modes enabled. The CI cost is 10,000 × $0.003 = $30. The rule cost is only the 25,000 detective evaluations at $0.001 each = $25 — the 50,000 proactive evaluations cost nothing. Total: $55. Swap those same 50,000 proactive evaluations onto proactive-only rules instead, and they'd cost $50 on their own, nearly doubling the bill for identical evaluation volume.

⚠️ What this actually breaks

Conformance packs multiply fast. A pack with 10 rules, each evaluated 300 times, is 3,000 evaluations — deploy that same pack five times across five accounts or Regions and you're at 15,000 evaluations before a single custom rule runs. Conformance packs are convenient precisely because they bundle many rules at once; that convenience is also exactly what runs the evaluation meter up quickly if you deploy the same pack redundantly.

Global Resources, IAM, and Duplicate-Charge Traps

Most AWS resources are Regional — an EC2 instance exists in one Region and one Region only. A handful are global: they can be accessed the same way from anywhere, with no Region parameter. AWS Config's rules for global resources changed the recording behavior in a way that catches people off guard.

For global resource types onboarded to Config after February 2022 — Amazon ECR Public, AWS Global Accelerator, Amazon Route 53 hosted zones and health checks, Amazon CloudFront distributions, and AWS WAF web ACLs — configuration items are only recorded in that service's designated home Region (US East, N. Virginia for most; US West, Oregon for Global Accelerator). You genuinely cannot see those CIs from any other Region, so there's no benefit — and no extra cost — to trying to record them elsewhere.

The IAM global types onboarded before February 2022 — AWS::IAM::Group, AWS::IAM::Policy, AWS::IAM::Role, AWS::IAM::User — work differently, and this is where duplicate charges creep in. These can be recorded in any Region that supported Config before that cutoff. If you turn recording on for IAM resources in more than one of those Regions, you get duplicate configuration items for the exact same underlying resource, plus periodic rules that check IAM compliance running redundant evaluations in every Region where you enabled the recording. AWS's own guidance is direct about this: record the global IAM resource types in exactly one Region, and deploy the rules that check them to that same Region only.

Amazon Aurora global clusters (AWS::RDS::GlobalCluster) are the odd one out — this resource type is recorded in every Region where you have a customer managed recorder enabled, automatically, the moment you turn recording on for it in any one Region. If you don't want that fan-out, you either exclude it explicitly (using the console's "Exclude from recording" override, or EXCLUSION_BY_RESOURCE_TYPES in the API) or record specific resource types and leave it off the list.

Aggregators: Centralizing Multi-Account Visibility Without Extra Cost

If you're managing more than a handful of accounts, checking Config compliance one account at a time doesn't scale — that's what aggregators exist to fix. An aggregator is a Config resource that pulls configuration and compliance data from multiple source accounts and Regions into a single account, so a central security or platform team can query and view everything from one place. There are two kinds: an individual account aggregator, where you list specific source accounts and each one has to authorize the aggregator to pull its data, and an organization aggregator, which automatically covers every account in your AWS Organization without needing per-account authorization.

Here's the fact worth knowing before you assume aggregation adds to your bill: AWS's own documentation states plainly that using aggregators does not incur any additional cost. The aggregator itself is a read-only replication layer — it can't deploy rules or push data back into a source account or Region, and it doesn't run its own evaluations. What you're still paying for is exactly what you were already paying for in each source account: the configuration items that account's recorder generates, and the rule evaluations that account's rules run. Pointing an aggregator at 50 accounts doesn't multiply your Config bill by 50; it just gives you one dashboard to see what those 50 accounts were already costing individually.

That said, aggregation can indirectly increase spend in one specific way: it makes noisy accounts visible for the first time. A central team that couldn't previously see which of its 50 accounts was generating the most configuration items now can — and that visibility is often what triggers someone to finally audit a runaway recorder that's been sitting on default settings, continuously recording every resource type, since the account was created.

Service-Linked Recorders — the Charge You Didn't Turn On

There are two flavors of configuration recorder. The customer managed recorder is the one you configure — resource types, frequency, all of it, set by you, one per account per Region. A service-linked recorder is created automatically by another AWS service that uses Config under the hood — currently, Amazon CloudWatch Observability Admin and AWS Security Hub (both the standard and CSPM editions). You don't set its resource types or frequency directly; the linked service controls that, and service-linked recorders are always recording.

Each service-linked recorder has a recording scope, set by the linked service: INTERNAL means the configuration items it generates never appear in your delivery channel and aren't billed; PAID means they do appear and are billed exactly like customer managed CIs. Here's the trap: when a customer managed recorder and a service-linked recorder with PAID scope both track the same resource type, the higher recording frequency wins for that resource type. If your customer managed recorder is set to daily and you then enable a service (like Security Hub) whose service-linked recorder records that same resource type continuously, that resource type gets billed at the continuous rate — even though your customer managed recorder's console page still shows "Daily recording."

⚠️ What this actually breaks

You can do everything right on your customer managed recorder — set it to daily, exclude the noisy types — and still get billed at continuous rates for EC2 instances the moment you turn on a feature that quietly enables a service-linked recorder underneath it. The console setting you changed is still true; it's just no longer the whole story for that resource type. There's one piece of good news: you're only ever charged once per configuration item, no matter how many recorders — customer managed or service-linked — generated it.

Jake asked the obvious follow-up: "So how do I even know if a service-linked recorder is running?" Ethan's answer: "Check whichever service you turned on recently — Security Hub, CloudWatch's Observability Admin — for a setting about resource discovery or asset visibility. That's usually the feature that spins up the recorder behind the scenes. It's not hidden exactly, it's just filed under the other service's settings, not Config's."

A Worked Example: Tuning Jake's Setup

Take AWS's own combined pricing example as the starting bill: 10,000 configuration items recorded in a month, 50,000 rule evaluations in detective mode, and five conformance packs with 10 rules each evaluated 300 times (15,000 conformance pack evaluations). Run the numbers as published: CIs cost 10,000 × $0.003 = $30. The first 50,000 rule evaluations fall entirely inside the first pricing tier, so 50,000 × $0.001 = $50. The 15,000 conformance pack evaluations, also inside the first tier, cost 15,000 × $0.001 = $15. Total: $95.

Here's how Jake would work down that bill using the levers above, in the order that gives the biggest return for the least risk:

  1. Identify which resource types generated the 10,000 CIs. If a large share came from a handful of Auto Scaling groups or Spot Instances cycling constantly, that's the first place to look — not the account as a whole.
  2. Move those specific resource types to daily recording (or exclude them entirely if their history genuinely isn't needed) while leaving IAM, security groups, and S3 bucket policies on continuous. Based on the earlier 1,000-item example, moving high-churn types to daily can realistically cut that portion of the CI cost by more than half.
  3. Audit which of the five conformance packs are actually deployed more than once across accounts or Regions for the same compliance scope. Each redundant deployment adds another 3,000 evaluations at the same rate.
  4. Confirm no service-linked recorder is quietly forcing continuous recording on a resource type you just switched to daily — otherwise the setting change won't show up in the bill at all.
  5. If Jake is managing more than one AWS account, point an organization aggregator at all of them first — since aggregation itself is free, it costs nothing to find out which account is actually driving the bill before tuning anything.
  6. Re-check the bill after one full billing cycle, since the first month after any recorder change will still include some of the prior period's evaluation backlog.

None of that requires abandoning compliance coverage — it's the difference between recording everything at the same frequency out of habit, and recording the sensitive things closely while letting the noisy, low-value things settle for a daily snapshot.

What Happens When You Turn the Recorder Off

Stopping the customer managed recorder does stop new configuration items from being billed. It does not, however, give you a clean slate. AWS Config's documentation is explicit about the tradeoff: with the recorder off, Config can't track changes to the resources you specified — including their deletions. That means if you stop recording and then delete a resource, Config never sees the deletion, and any prior compliance evaluation result for that resource can sit there as stale, unresolved data, because Config has no way to know the resource is gone.

There's also a resource type you never have to think about turning off: AWS::Config::ConfigurationRecorder itself is a system resource type that tracks the recorder's own state — whether it's been started, stopped, or had its resource types changed. Recording of this type is on by default in every supported Region, and AWS Config's documentation states plainly that it comes with no additional charge. It exists specifically so you can detect drift in your own recorder configuration, which is a genuinely useful thing to audit if more than one person on your team has console access.

Frequently Asked Questions

What does AWS Config actually charge me for?

Three separate meters: the number of configuration items recorded, the number of AWS Config rule evaluations run, and the number of conformance pack evaluations run. Each has its own rate, and they run independently of each other.

Is continuous recording or daily recording cheaper?

It depends entirely on how often your resources change, not on the per-item price alone. Continuous costs $0.003 per item but bills every change event; daily costs $0.012 per item but bills at most one item per resource per day. For resources that change more than about four times a day, daily recording is typically the cheaper option overall — AWS's own published example shows a 100-instance workload costing $3.00 under continuous recording and $1.20 under daily.

How do I see how many configuration items I'm generating before turning Config on?

Query AWS CloudTrail Lake for the management API events (create, update, delete) that would generate a configuration item for the resource types you're considering. It's not a perfect count — some resource types aren't captured this way — but it gives you a real volume estimate instead of a guess. Note that running the CloudTrail Lake query itself is billed separately under CloudTrail's pricing.

What's a configuration item, exactly?

A configuration item is a record of what one resource looked like at one point in time — its settings, its relationships to other resources, and the timestamp of that state. AWS Config writes a new one whenever the resource is created, changed, or deleted, subject to the recording frequency you've set.

Does turning off the recorder stop all charges?

It stops new configuration items and rule evaluations from being billed going forward. It does not delete your existing history, and it does mean AWS Config can no longer detect deletions of resources you were tracking, which can leave stale compliance results in place for resources that no longer exist.

Why did my bill spike in the first month?

AWS Config runs a full evaluation pass across every resource you've selected for recording during the initial bootstrapping process, which is why activity — and cost — is typically higher in your first month than in the months after.

Do I get charged for resources I exclude from recording?

No. If a resource type isn't recorded, AWS Config only captures its creation and deletion as a notification, with no configuration detail and no cost. You lose the historical configuration data for that resource type, but you also don't pay for it.

What's the difference between recording strategy and recording frequency?

Recording strategy controls which resource types get recorded at all — all supported types, a specific list, or all types with named exclusions. Recording frequency controls how often a recorded resource type generates a billable item — continuous (every change) or daily (once per 24-hour period, if changed). They're independent settings you can mix per resource type.

Are proactive rule evaluations free?

Only under a specific condition. If a rule has both detective and proactive modes enabled, the proactive-mode evaluations on that rule are billed at $0 — only the detective-mode evaluations are charged. If a rule has proactive mode enabled on its own, without detective mode, its proactive evaluations are billed at the normal tiered rate, same as any other evaluation.

What are conformance packs and how are they billed?

A conformance pack is a collection of AWS Config rules deployed together, typically to check a compliance framework like PCI-DSS or CIS benchmarks. Each rule inside the pack evaluates resources just like a standalone rule, and each of those evaluations bills at the same tiered rate as regular rule evaluations — $0.001 for the first 100,000, $0.0008 for the next 400,000, and $0.0005 beyond that, per Region.

Does Security Hub or CloudWatch Observability Admin add extra AWS Config charges?

It can. Both services use a service-linked configuration recorder to gather the data they need. If that recorder's scope is set to "PAID" rather than "INTERNAL," the configuration items it generates are billed the same as any customer managed recorder's items, and it can also raise your effective recording frequency for any resource type it shares with your own recorder.

Why am I being charged continuous rates when my recorder says "Daily recording"?

Because a service-linked recorder with "PAID" scope and continuous recording is also tracking that resource type, and when a customer managed recorder and a paid service-linked recorder overlap on a resource type, the higher recording frequency takes precedence for that resource type's billing — even though the customer managed recorder's own setting still displays "Daily."

Do I get charged extra for using an aggregator across multiple accounts?

No. AWS Config's documentation states that using aggregators does not incur any additional cost. You still pay for the configuration items and rule evaluations each source account generates on its own; the aggregator only replicates that data into a central view without running its own evaluations or adding a separate charge.

Should I record global IAM resource types in every Region?

No. IAM groups, policies, roles, and users are global resources that can be recorded in more than one Region, but doing so produces duplicate configuration items for the same underlying resource and redundant rule evaluations in every Region where recording is enabled. AWS's own guidance is to record global IAM resource types in exactly one Region.

Is there a free tier for AWS Config?

AWS's own pricing page describes Config as pay for only what you use, with no minimums or upfront commitments — it doesn't describe a free usage tier the way some other AWS services do. The closest thing to "free" recording is the AWS::Config::ConfigurationRecorder system resource type, which tracks the recorder's own configuration at no charge, and any resource type you choose not to record, which only generates a free creation/deletion notification instead of a billed configuration item.

📚 Also Read :

Revision note. Written September 2026, covering the AWS Config pricing model, recording frequency and strategy settings, aggregator behavior, and service-linked recorder interactions current as of August 2026. AWS periodically adjusts per-Region rates and evaluation tiers, so treat the dollar figures here as the structure of the bill rather than a permanent number, and check the AWS Config pricing page for your own Region before budgeting. If your bill is already higher than it should be, you're not the first person this has happened to — and every lever above works on an account that's already been running a while, not just a fresh one Happy learning!.

Related