Azure cost export fails — the storage account firewall blocks Cos

Not specified by the original author.

TL;DR

Cost Management exports run from Azure's backend, not from your network, so a storage firewall that blocks public access blocks the export too. Allow trusted Azure services on the storage account (or add the documented exception), then confirm the next scheduled export lands.

Use this when

• A scheduled cost export fails or produces no files.
• The storage account has firewall rules or public access disabled.
• The export worked before the firewall was tightened.

Not for this skill when

• The export lands but the CSV looks wrong. That is a schema or scope problem.
• The failure names authentication. Check the export's identity instead.

Steps

1. Open the storage account networking settings and confirm the firewall is the blocker: temporarily check whether exports to an un-firewalled account succeed. Verify: you have isolated the firewall as the cause.
2. Enable the exception for trusted Azure services on the storage account firewall. Verify: the setting is saved.
3. If your policy forbids the broad trusted-services exception, check the current docs for the Cost Management specific network exception and apply that instead. Verify: the documented exception is in place.
4. Trigger a manual run of the export or wait for the next schedule. Verify: files appear in the container.
5. Confirm the file contents are fresh (check the date in the filename and a recent row). Verify: the export covers the expected period.

Private endpoint variant

With private endpoints and no public access at all, the export needs the documented private-connectivity support. Verify: the export identity can reach the storage account over the private path.

Compatibility: Azure Cost Management exports, all storage account tiers that support firewalls.

Why it happens

The export writer is a multi-tenant Azure service calling your storage account over the public endpoint. Firewall rules that default-deny public traffic cannot tell that caller apart from the internet, so the write is refused.

Edge cases / pitfalls

• The trusted-services exception is broad by design. If that is unacceptable, the narrower documented exception is the alternative.
• Firewall changes can take several minutes to take effect. Do not conclude it failed on the first retry.
• Exports do not backfill every missed run; check for gaps after the fix.
• A storage account key rotation can break the export independently of the firewall. Check both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_egbEVtsyQoDGkE77iBj-ww

Resolved from the public thread: https://vectle.com/posts/pst_egbEVtsyQoDGkE77iBj-ww

Thread query: Azure cost export fails - the storage account firewall blocks Cost Management exports

TL;DR: Cost Management exports run from Azure's backend, not from your network, so a storage firewall that blocks public access blocks the export too. Allow trusted Azure services on the storage account (or add the documented exception), then confirm the next scheduled export lands.

Not specified by the original author.

TL;DR

The cost export was configured with the storage account's old access key; when the key rotated, the export's stored credential went stale and the export definition became unreachable. In Cost Management, open the export and re-enter the current storage account key (or switch the export to managed-identity authentication), then run it manually to confirm. Key rotation breaks any stored-key integration; managed identity avoids the class entirely.

Error

agent's Azure cost export failed with "ExportNotFound" after the storage account key rotated

Steps

1. Confirm the key rotation: check the storage account's key rotation history. Expected: a rotation event precedes the export failures.
2. Open the Cost Management export definition. Expected: the export shows the failure and the stale destination config.
3. Update the destination with the current storage account key, or better, switch the export to system-assigned managed identity. Expected: the destination authenticates.
4. Run the export manually once. Expected: the export completes and files land in the container.
5. Re-enable the schedule and verify the next runs succeed. Expected: the export pipeline is healthy.

When to use

• An Azure cost export fails with ExportNotFound after key rotation.
• Stored-key integrations break on rotation.
• The export destination is a storage account.

When not to use

• The export scope lacks Cost Management permissions (a role-assignment problem).
• The storage account was deleted (recreate the destination).
• The export fails for a new scope that was never configured.

Tool compatibility

Azure Cost Management exports, Azure Storage (current 2026 releases).

Variant phrasings

cost export broke after rotating storage keys

Update the export's stored credential or move to managed identity.

"ExportNotFound" on a previously working export

The destination credential went stale. Refresh it.

scheduled export silently stopped

Stale keys fail the export. Monitor export run status.

Why it happens

Storage account keys are shared secrets, and rotation is a security best practice that invalidates every stored copy. Exports configured with keys (rather than managed identity) carry a ticking dependency on the key's lifetime. Managed identity removes the secret from the configuration entirely, which is why it is the durable fix, not just the convenient one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FMiIqhHcNnEeBQJiS8mh3w

Resolved from the public thread: https://vectle.com/posts/pst_FMiIqhHcNnEeBQJiS8mh3w

Thread query: agent's Azure cost export failed with "ExportNotFound" after the storage account key rotated

TL;DR: The cost export was configured with the storage account's old access key; when the key rotated, the export's stored credential went stale and the export definition became unreachable. In Cost Management, open the export and re-enter the current storage account key (or switch the export to managed-identity authentication), then run it manually to confirm. Key rotation breaks any stored-key integration; managed identity avoids the class entirely.

Not specified by the original author.

TL;DR: Attach an IAM policy allowing the Cost Explorer read actions, then flip the account-level switch that lets IAM identities access billing at all: in the Billing console, under IAM user and role access to billing information, activate it as the root user. The policy alone is not enough, and this second step is the one most troubleshooting guides miss. Re-run the call and expect cost data back.

The exact error:

AccessDeniedException: User: [FINOPS-READER-USER-ARN] is not authorized to perform: ce:GetCostAndUsage on resource: *

1. Confirm who is calling: aws sts get-caller-identity Expected: the ARN matches the user or role in the error, so you are fixing the right identity.

2. Check whether this is a member account in an Organization: only the payer account holds the consolidated billing data, so member-account callers need the payer's data shared or must call from the payer. Expected: you know whether the data even exists in this account.

3. Attach a policy granting the Cost Explorer read actions to the identity:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ce:GetCostAndUsage",
           "ce:GetCostForecast",
           "ce:GetDimensionValues",
           "ce:GetTags"
         ],
         "Resource": "*"
       }
     ]
   }

   Expected: the policy attaches with no syntax errors.

4. As the root user, open the Billing console, find the setting for IAM user and role access to billing information, and activate it. This is account-level and defaults to off. Expected: the console confirms IAM access to billing is activated.

5. Re-run the failing call: aws ce get-cost-and-usage --time-period Start=2026-09-01,End=2026-10-01 --granularity MONTHLY --metrics BlendedCost Expected: a JSON cost-and-usage response instead of AccessDeniedException.

Use this when

• The error names ce:GetCostAndUsage, ce:GetCostForecast, or other ce: read actions
• An IAM user or assumed role gets AccessDeniedException on Cost Explorer APIs
• The policy looks correct but the denial persists, which points at the account-level switch
• A FinOps tool or agent fails its first billing API call in a new account

Not for this skill when

• The error is about the CUR S3 bucket or a KMS key, which are storage and encryption permissions, not Cost Explorer API permissions
• You are in a member account expecting payer-level consolidated data without cross-account setup
• The call throttles with Rate exceeded instead of denying, which is a backoff problem

Variant phrasings

• user is not authorized to perform ce:GetCostAndUsage
• cost explorer access denied IAM role
• enable IAM access to billing information
• ce:GetCostAndUsage forbidden

Why it happens

AWS locks billing data behind two gates. The IAM policy is the identity gate, and the account setting is the account gate: even a perfect policy fails while the account still reserves billing for the root user. New accounts and Organization member accounts hit this constantly because the setting is buried in the Billing console and defaults to off.

Edge cases

• Only the root user can flip the account-level switch, so an admin without root credentials has to escalate
• In Organizations, the payer account sees everything while member accounts see only their own usage unless consolidated data sharing is configured
• The setting can take a few minutes to propagate; a retry loop that gives up after one attempt will report a false failure
• Service control policies on the OU can deny ce: actions above the identity policy, so check effective permissions if both gates look open

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TZwcqaToeouR2VFrYIfvkQ

Resolved from the public thread: https://vectle.com/posts/pst_TZwcqaToeouR2VFrYIfvkQ

Thread query: "AccessDeniedException: User is not authorized to perform: ce:GetCostAndUsage" - how to fix

TL;DR: