Amazon GuardDuty pricing and cost optimization (FinOps): decompose the billing model, cut waste, and predict the bill

"GuardDuty — how much does it cost if I turn on all the protection plans?" — in the place of being consulted on AWS security budgets, it's not rare for the money question to come up before threat detection itself. And in many cases, the true identity of that anxiety is "because the pricing scheme isn't decomposed, you can't read the bill's breakdown."

GuardDuty's pricing is, in fact, surprisingly mechanical. Billing can be decomposed into the product of "the feature you enabled × the amount that feature monitored," and once you grasp each unit (a million events, GB, vCPU-hours) and the unit price, you can produce a rough estimate before seeing the invoice. Conversely, turn everything on "for now" without decomposing this and you'll keep paying usage-based fees even for targets with thin detection value.

This article is an implementation guide to introducing GuardDuty at production quality and then designing, predicting, and optimizing its cost with FinOps manners. The design of threat detection itself (protection-plan selection, organization-wide enabling, EventBridge automated response) is left to the sister article GuardDuty production-design guide; this article goes all-in on the cost axis. It decomposes the billing model per component, identifies the dominant drivers, visualizes actual usage, predicts the bill from the trial, and separates effective waste-cutting from ineffective. As material, I also weave in my experience cross-implementing IAM, observability, and DR on a multi-account AWS serverless payment platform and putting multi-account cost allocation and bill prediction into operation.

Rules for this article: the pricing scheme, billing units, and trial spec are based on the AWS official documentation / pricing page (as of June 2026). Prices are revised and differ by region. The amounts in the text are reference values for US East (N. Virginia) (as of June 2026, varying by region/revision) and are not a guaranteed current price — before production rollout, always confirm the latest values for your own region in the official pricing page and the AWS Pricing Calculator. And one more — GuardDuty is one layer of defense-in-depth. Cost optimization is a trade-off with security comprehensiveness, and "making a detection hole to cut cost" defeats the purpose. This article aims to "cut low-value monitoring and keep high-value monitoring."

0. Mental model: GuardDuty's cost is "what you enabled × the amount monitored"

Before starting optimization, fix GuardDuty's billing in one line. This is the foundation of all judgment.

GuardDuty's cost = Σ (each enabled feature × the amount that feature analyzed/monitored × the region unit price). It's not the count of findings nor the number of detected threats but usage-based billing for "the amount of data analyzed."

From here come 3 conclusions effective for FinOps.

1. Cost is proportional not to "the monitoring switch" but to "the amount of monitoring." Billing doesn't start the moment you turn on S3 Protection; you're billed only for the S3 data events analyzed. So you can't read the bill unless you look not at "did you enable it" but at "how much is flowing." This is the reason to look at the Usage page and get-usage-statistics described later.
2. Billing occurs for "data-source analysis," not findings. This is the biggest misconception point. Suppressing a finding (a Suppression Rule) doesn't lower the cost by one yen. Because what's billed is "the act of analyzing the data source," not "the act of generating/displaying a finding" (detailed in chapter 7).
3. The dominant drivers are few. Even with 9 billing components, most bills can be explained by the top 2-3 — Runtime Monitoring (vCPU-hours), CloudTrail management-event volume, and VPC Flow Logs/DNS bytes. FinOps is not "cut everything evenly" but "identify the drivers and hit there." (the driver table in chapter 2).

Grasp these 3 and GuardDuty cost optimization falls into the standard FinOps cycle of "① decompose the billing model → ② identify the drivers by looking at actual usage → ③ cut only the low-value-vs-cost monitoring → ④ predict and monitor the bill." Let me build it in order.

1. Decompose the billing model: components and units

GuardDuty's pricing is independent per feature (protection plan), each with its own billing unit. First, grasp just the units accurately (unit prices come as reference values in chapter 2).

There are 3 structures important for FinOps here.

• The units are disparate (event count, GB, vCPU, ACU, object count). So you can't compare "which feature is expensive" unless you normalize to a monetary amount. get-usage-statistics returns usage in estimated dollar conversion, which works (chapter 4).
• Many are "tiered by volume." VPC Flow Logs, S3 data events, EKS audit logs, and Runtime Monitoring are a staircase where the unit price drops as volume rises. That is, "at large scale the GB/event unit price drops," but "even at small scale the first tier's unit price is high." The smaller the environment you start with, the more expensive the unit price feels.
• There's no 'zero-extra-charge' area in the foundational data sources — but Extended Threat Detection (ETD) is completely free (below). The foundational detection (analysis of CloudTrail/VPC Flow Logs/DNS) is usage-based, but the correlation engine (ETD) that rides on top isn't billed. The fact that the highest-value layer of "bundle weak signals into a Critical attack sequence" is free directly connects to the optimization policy (below).

An easily-misunderstood free boundary: "If I enable GuardDuty, won't the storage fee for CloudTrail or VPC Flow Logs be charged separately?" — it won't. GuardDuty directly consumes the foundational data sources as "independent duplicate streams," and you don't need to create a CloudTrail trail, enable VPC Flow Logs, or store them in S3. Only GuardDuty's analysis fee is billed. For details, see the mental model in the production-design guide.

2. Rank the cost drivers: what dominates the bill

Looking at the 9 components evenly isn't FinOps. Rank "which typically dominates the bill" and decide where to focus. Below is a driver table with US East (N. Virginia) reference unit prices (as of June 2026, varying by region/revision; confirm).

How to treat reference prices (repeated, important): the table above is reference values for US East (N. Virginia) as of June 2026. Other regions including Tokyo (ap-northeast-1) differ, and prices are revised. As the pricing page clearly notes "effective February 1, 2025" for Malware Protection for S3's $0.09/GB, it's an area where revision actually happens. For a production estimate, always confirm your region, latest in the official pricing page and the Pricing Calculator.

The practical conclusion is simple. In most cases, 80% of the bill can be explained by the top 3 (Runtime Monitoring / CloudTrail management events / VPC Flow Logs). So in FinOps, start from looking at the actual usage of these 3. The next chapter builds how to look at it.

3. "See" actual usage: the Usage page and CloudWatch metrics

The premise of optimization is measurement. GuardDuty provides multiple paths to see usage.

3.1 The console's Usage page

The GuardDuty console has a Usage page that displays estimated usage cost per data source / feature. During the 30-day free trial of a newly-enabled region, here you can confirm the estimated monthly amount of "how much at production volume" per data source. The first thing to do is open this page — you can tell at a glance "which feature is eating the money."

3.2 CloudWatch usage metrics (the foundation of alerts and history)

GuardDuty publishes usage to the CloudWatch AWS/GuardDuty namespace hourly (reflected within 24 hours). This is the foundation of the cost-monitoring dashboard and alarms. The main metrics:

For an organization, these are aggregated and published to the delegated-admin account (the org-wide sum; the dimension is DataSource). A standalone account emits to its own account with the AccountId, DataSource dimension.

A FinOps implementation point: line MonitoredVcpuHours and AnalyzedBytes up on a CloudWatch dashboard and you can pre-empt "Runtime's vCPU-hours jumped from last week = cost jumps" without waiting for the invoice. To convert byte metrics to money, convert with 1 GB = 1,073,741,824 bytes (the Pricing Calculator uses the same conversion).

4. Decompose usage: get-usage-statistics (bash)

If the Usage page is "see," aws guardduty get-usage-statistics is the API to "mechanically decompose, compare, and automate." It returns usage in estimated dollar conversion, by data source / feature / account / resource. It's suited for automating FinOps reports and alerts.

# 前提: 委任管理者(または対象アカウント)の detector-id を取得しておく。
DETECTOR_ID=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)

# ① データソース別の使用量を集計する（どの基盤データソースが高いか）。
#    DataSources の有効値: FLOW_LOGS | CLOUD_TRAIL | DNS_LOGS | S3_LOGS
#                          | KUBERNETES_AUDIT_LOGS | EC2_MALWARE_SCAN
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_DATA_SOURCE \
  --usage-criteria 'DataSources=CLOUD_TRAIL,FLOW_LOGS,DNS_LOGS,S3_LOGS'

# ② 機能(保護プラン)別の使用量を集計する（Runtime Monitoring 等の新しい機能を含む）。
#    注意: 列挙値は SUM_BY_FEATURES（複数形）。SUM_BY_FEATURE ではないので注意。
#    Features の有効値(抜粋): FLOW_LOGS | CLOUD_TRAIL | DNS_LOGS | S3_DATA_EVENTS
#      | EKS_AUDIT_LOGS | EBS_MALWARE_PROTECTION | RDS_LOGIN_EVENTS
#      | LAMBDA_NETWORK_LOGS | EKS_RUNTIME_MONITORING | EC2_RUNTIME_MONITORING
#      | FARGATE_RUNTIME_MONITORING | RDS_DBI_PROTECTION_PROVISIONED
#      | RDS_DBI_PROTECTION_SERVERLESS
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_FEATURES \
  --usage-criteria 'Features=EC2_RUNTIME_MONITORING,EKS_RUNTIME_MONITORING,FARGATE_RUNTIME_MONITORING'

# ③ アカウント別の使用量（委任管理者が「どのメンバーアカウントが高いか」を出す）。
#    組織のコスト配分(showback/chargeback)に直結する分解軸。
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type SUM_BY_ACCOUNT \
  --usage-criteria 'AccountIds=123456789012,210987654321'

# ④ コスト上位リソースを出す（どの EC2/リソースが Runtime コストを牽引しているか）。
#    "犯人探し"に有効。usage-criteria が不要なら空オブジェクトを渡す。
aws guardduty get-usage-statistics \
  --detector-id "$DETECTOR_ID" \
  --usage-statistic-type TOP_RESOURCES \
  --usage-criteria '{}' \
  --output json

The valid values of --usage-statistic-type are SUM_BY_ACCOUNT / SUM_BY_DATA_SOURCE / SUM_BY_RESOURCE / TOP_RESOURCES / SUM_BY_FEATURES / TOP_ACCOUNTS_BY_FEATURE.

The delegated admin's leverage: an organization's GuardDuty delegated admin can produce usage per member account with SUM_BY_ACCOUNT, and "which feature, which account drives it" in one shot with TOP_ACCOUNTS_BY_FEATURE. Since you can tie cost accountability to "account = team," it becomes the foundation of showback/chargeback. For account separation and delegated-admin design in an organization, see the multi-account governance guide. In an environment like a payment platform where accounts are split into production/staging/audit, this per-account decomposition is the cost allocation itself.

5. Predict the production bill from the trial (30-day free trial)

GuardDuty provides a 30-day free trial per newly-enabled account × region. The trial covers, in addition to foundational detection (Foundational Threat Detection), each protection plan of S3 / EKS / Runtime Monitoring / RDS / Lambda, and GuardDuty-triggered Malware Protection for EC2 scans.

More than "a period to use for free," this trial is valuable in FinOps terms as "a period to observe the bill at production volume before being billed." The procedure is this.

1. Run the trial in a state close to production load. The trial's usage accumulates in GuardDuty's Usage metrics / console. "Enable with a minimal configuration and go to production after the trial" misaligns the prediction, so observe at as production-equivalent volume as possible.
2. Put the observed usage into the AWS Pricing Calculator. Select Amazon GuardDuty in the Pricing Calculator, specify your region, and enter the usage of each feature observed in CloudWatch/Usage (vCPU-hours, event count, GB), and the monthly amount after the trial comes out. Convert byte metrics to GB before entering.
3. After the trial ends, confirm the actual amount in AWS Billing. Review the difference between the prediction and the actual amount, and if it's off, revisit the driver (usually Runtime's vCPU-hours).

The trial's pitfall: the trial is per region. The official recommends "enabling in all regions" (to monitor global-service events), but each region's trial is independent. Enabling/disabling Security Hub doesn't extend or re-grant the trial — an account that has used up the trial doesn't get a new one.

5.1 Grasp the "order" by hand: a worksheet (reference values, confirm)

The Pricing Calculator is the formal estimate, but grasping the order by hand lets you instantly verify whether the Calculator's output or the trial's estimate is "reasonable." Below is a worksheet built with US East reference unit prices (as of June 2026, varying by region/revision; just an example of order). Replace with your own numbers.

The verification trick: MonitoredVcpuHours is "vCPU-hours," so dividing the monthly sum by 720 (the rough number of hours/month) gives "average vCPU-month." In the example above, "28,800 vCPU-hours total ÷ 720 ≈ 40 vCPU." If VPC Flow Logs looks dominant, recalculate before and after enabling the 6.3 double-billing exemption (the EC2 portion with Runtime is free) — the exemption reduces VPC Flow Logs' AnalyzedBytes itself, so the GB in the formula above shrinks. Note that this rough estimate is a crude multiply by the "first-tier unit price," and once volume enters a tiered tier, the actual amount is lower. Always finalize with the Pricing Calculator.

6. Effective cost optimization: cut only low-value monitoring

Here's the core of practice. Here are the tactics of "lowering cost without making a security hole," in order of effectiveness.

6.1 Add protection plans only where assets exist (YAGNI)

The biggest waste is the state of "enabling a protection plan even though no monitoring target exists." Turn on EKS Protection in an account not operating EKS and not a single detection comes out, and only the audit-log-analysis billing can ride. The principle is the same as the production-design guide — S3 Protection default-on in nearly all accounts handling sensitive data, EKS/RDS/Lambda only in accounts with the relevant assets, Runtime Monitoring limited to production's important workloads. This is the "security-budget allocation problem" itself.

6.2 Limit Runtime Monitoring to important workloads (the biggest lever)

Runtime Monitoring is billed by the number of protected vCPUs × uptime, and even at the upper tier its unit price is high vs. other features, tending to be the biggest cost driver. Deploy it uniformly across all containers and all EC2 and it swells at once. The standard is to limit it to "workloads where a runtime compromise would be fatal to the business." Let GuardDuty auto-manage agent placement while scoping the monitoring target by tag or cluster. The structure of vCPU billing and the agent design on EKS/ECS-Fargate/EC2 are detailed in the Runtime Monitoring implementation guide.

6.3 Leverage the VPC Flow Logs double-billing exemption (often overlooked)

This is a point where the bill changes by whether you know it. While the Runtime Monitoring security agent runs on an EC2 instance and GuardDuty receives that instance's runtime events, GuardDuty doesn't bill the VPC Flow Logs analysis of that EC2 instance (avoiding double billing).

As the official puts it, this exemption works as long as the agent is actually sending runtime event data, and when the agent stops sending, it returns to VPC Flow Logs billing. In the CloudWatch usage metrics too, you can observe VPC Flow Logs usage dropping when you enable Runtime Monitoring.

The design implication: "Runtime Monitoring is expensive" is half true, but since VPC Flow Logs analysis becomes free on an EC2 with Runtime, the more network-active the EC2, the more the offset works. It's accurate to look at Runtime's cost evaluation not only as "the increment of vCPU billing" but also together with "the decrement of VPC Flow Logs billing."

6.4 Malware Protection for S3's free tier and standalone use

Malware Protection for S3 has a free tier of 1,000 requests + 1GB/month and can also be used standalone without enabling GuardDuty itself. For the use of "I want to scan only uploaded files," you can introduce it in a minimal configuration without paying the foundational-detection cost.

6.5 ETD is free — leverage the "strongest layer that works for free"

Extended Threat Detection (ETD) has no extra charge. The highest-value layer that correlates weak signals in a 24-hour window and bundles a multi-stage attack into one AttackSequence:* (always Critical) finding is free. That is, there's no reason whatsoever to cut ETD for cost optimization. Rather, the right design is "introduce S3 Protection to widen ETD's correlation" — maximizing free correlation value with inexpensive features.

6.6 Ineffective waste-cutting (detailed in the next chapter)

On the other hand, there are optimizations that "seem to work but don't." The representatives are Suppression Rule and the Trusted IP list. These reduce noise but don't lower cost. Because the reason is important, I handle it in a separate chapter.

7. Measures that don't lower cost: the misconception of suppression rules (most important)

In FinOps, the most common misconception is this.

A Suppression Rule only "archives" a finding and doesn't lower GuardDuty's cost.

Why. Back to conclusion ② of chapter 0 — what's billed is "the act of analyzing the data source," not "the act of generating/displaying a finding." What a suppression rule does is only "auto-archive findings matching the condition and remove them from the dashboard and notifications." The analysis itself doesn't stop, so the billing doesn't stop. "There's a lot of noise and the bill is high too, so let's erase it all with suppression" — this doesn't become cost optimization.

Similarly:

• Trusted IP list: traffic from listed IPs stops generating findings, but the analysis of that traffic (VPC Flow Logs, etc.) is done and billed. Noise drops but cost doesn't.
• Threat list: a tool on the side of increasing findings with your own malicious IPs/domains, unrelated to the cost-reduction context.

In other words, suppression rules and the Trusted IP list are "tools to reduce operational noise," not "tools to reduce cost." Confuse them and you'll worry "I suppressed it but the bill doesn't drop." If you want to lower cost, the only way is to reduce the amount of data analyzed itself (= chapter 6: narrow the monitoring target, cut protection plans without assets).

The correct use of suppression vs. cost: use suppression rules for noise and ETD's correlation quality, not cost. A caution: ETD doesn't make archived findings a correlation target. "Suppress a weak signal that looks like noise on its own and you may lose even the attack sequence (Critical) it was supposed to bundle into." Limit suppression to "noise you're confident is harmless," and don't use it as a cost-reduction means — these two points are the crux (for details, the false-positive-tuning chapter of the production-design guide).

8. Predict and monitor the bill: Budgets and Cost Anomaly Detection

After optimizing, leave a mechanism to "know deviations early." Typical jumps in GuardDuty cost are "widened Runtime Monitoring to a new cluster," "added a batch that hits CloudTrail a lot" — all are changes in enabling or load. Catch these not at month-end on the invoice but at the time of occurrence.

8.1 A per-service AWS Budgets alert (Terraform)

Set a budget alert by carving out only GuardDuty's cost. The point is narrowing cost_filter's Service dimension to Amazon GuardDuty.

# ============================================================
# 目的: GuardDuty のコストだけを監視し、跳ねたら即通知する。
#   - Service フィルタで GuardDuty に限定（全体予算に埋もれさせない）
#   - 80%(実績) で気づき、100%(予測) で月中に警告
# 注意: limit_amount は自リージョン・自構成の想定額に置き換えること。
#       金額は USD。参考値ではなく、5章で予測した実額ベースで設定する。
# ============================================================
resource "aws_budgets_budget" "guardduty_monthly" {
  name         = "guardduty-monthly-cost"
  budget_type  = "COST"
  limit_amount = "300" # USD/月。← 5章のトライアル予測に基づき各自設定
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  # GuardDuty のコストだけに絞る。これがサービス単位監視の肝。
  cost_filter {
    name   = "Service"
    values = ["Amazon GuardDuty"]
  }

  # 実績80%で通知（まだ余裕があるうちに気づく）。
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 80
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_sns_topic_arns = [aws_sns_topic.cost_alert.arn]
  }

  # 予測100%で通知（月末に超過見込みなら月中でも警告）。
  # 「有効化を広げた直後」の跳ねを月初に捕まえるための予測アラート。
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_sns_topic_arns = [aws_sns_topic.cost_alert.arn]
  }
}

8.2 Cost Anomaly Detection (auto-detect abnormal jumps)

A budget alert rings when it exceeds a "threshold," but for the early stage where a threshold is hard to decide, or a case of sudden change even within expectation, AWS Cost Anomaly Detection works. Create a per-service monitor including GuardDuty and it detects spending that deviates from past patterns with machine learning and notifies. The advantage is picking up structural changes like "widened Runtime" or "CloudTrail surged" without threshold setting. Budgets (the guardian of a known ceiling) and Cost Anomaly Detection (the guardian of unknown sudden change) are standard to use together.

FinOps operation design: ① predict with the trial (chapter 5) → ② set the ceiling with Budgets (8.1) → ③ pick up sudden change with Cost Anomaly Detection (8.2) → ④ on a jump, identify the driver (usually Runtime's vCPU-hours) with get-usage-statistics (chapter 4) → ⑤ cut with the tactics of chapter 6. Declare this closed loop in Terraform and cost is structurally managed without a human watching. This is exactly the "leave a mechanism in code that keeps dropping" thinking I've repeated in startup AWS cost optimization.

9. Conclusion: a GuardDuty cost-optimization cheat sheet

A quick reference for when you're lost.

• The essence of billing: GuardDuty's cost is usage-based "the feature you enabled × the amount monitored × the region unit price." You're billed for "the amount of data analyzed," not the finding count.
• Dominant drivers: most of the bill can be explained by the top 2-3 — Runtime Monitoring (vCPU-hours) / CloudTrail management-event volume / VPC Flow Logs · DNS bytes. Look here, hit here.
• Visualize actual usage: first the console's Usage page. For automation/decomposition, aws guardduty get-usage-statistics (SUM_BY_DATA_SOURCE / SUM_BY_FEATURES (plural) / SUM_BY_ACCOUNT / TOP_RESOURCES / TOP_ACCOUNTS_BY_FEATURE). CloudWatch AWS/GuardDuty for history and alerts.
• Bill prediction: put the usage during the 30-day free trial (per region × account) into the AWS Pricing Calculator and predict the monthly amount before being billed. The delegated admin can even see the estimated cost per member account.
• Effective waste-cutting: ① add protection plans only where assets exist (YAGNI) ② limit Runtime Monitoring to important workloads (the biggest lever) ③ leverage the exemption where the EC2 portion with the Runtime agent isn't double-billed for VPC Flow Logs analysis ④ Malware Protection for S3 is free tier + standalone use ⑤ ETD is free — don't cut it, leverage it.
• Ineffective waste-cutting (misconception caution): a Suppression Rule only archives a finding and doesn't lower cost. The Trusted IP list also reduces noise but not cost (what's billed is the analysis volume, not findings). To lower cost, the only way is to reduce the analysis volume itself.
• Monitoring: AWS Budgets narrowed to GuardDuty with the Service filter (known ceiling) + Cost Anomaly Detection (unknown sudden change). On a jump, the closed loop of identifying the driver with get-usage-statistics and cutting.
• The price iron rule: the amounts in the text are US East reference, as of June 2026, varying by region/revision. They're not guaranteed values. For a production estimate, always confirm your region, latest in the official pricing page and the Pricing Calculator.

GuardDuty's cost isn't "a black-box invoice" but a mechanical structure that can be predicted if decomposed and lowered if you hit the drivers. The biggest leverage is not "cut everything" but removing only low-value monitoring and maximizing the free correlation value of ETD.

On a multi-account serverless payment platform, I cross-implemented the IAM, observability, and DR of a foundation handling actual money, carbon credits, and local currency, and put multi-account cost allocation and bill prediction into operation by the structure of code. The cost design of GuardDuty is the same philosophy — ① predict the bill with the trial, ② decompose usage with get-usage-statistics, ③ cut only the low-value-vs-cost monitoring, and ④ catch deviations at the time of occurrence with Budgets and Cost Anomaly Detection. I design an allocation with a basis, neither "all on for now" nor "minimal out of anxiety."

"How much does my GuardDuty cost, where is the waste, and how to predict/monitor the bill" — from decomposing the billing model to visualizing usage, selecting protection plans, and implementing Budgets/Cost Anomaly Detection in Terraform, I can accompany you fast and safely with one person × generative AI (Claude Code). Even from the stage of "I can't take the plunge because it looks expensive if I turn everything on," feel free to reach out.

References (official documentation)

• Amazon GuardDuty pricing — usage-based billing of all components, tiers, region-specific unit prices, the 30-day free trial (prices are revised, confirm)
• Monitoring GuardDuty usage and estimating costs — CloudWatch usage metrics, the VPC Flow Logs double-billing exemption, prediction from the trial, the Pricing Calculator procedure
• GuardDuty foundational data sources — "independent duplicate streams," the point that foundational data sources have no extra storage cost, the delegated admin's per-member estimated cost, DNS only when using the AWS resolver
• get-usage-statistics (AWS CLI reference) — the valid values of --usage-statistic-type, --usage-criteria (DataSources/Features/AccountIds)
• Suppression rules — the suppression rule is a feature that archives findings (not a cost-reduction feature; its interaction with ETD)
• AWS Pricing Calculator — monthly estimate from observed usage