Understanding Azure Function App Consumption Plan and Blob Storage Costs (GPv1 vs GPv2)

Yes, GPv2 is higher in cost in terms of each call the Function App makes to the Storage Account. I have not yet migrated to GPv2. Based on the Azure Calculator, it does appear that the read and write costs for Storage are almost 10 times higher. Previously, with GPv1, the costs were only in the tens of cents, whereas with GPv2 they are around 0.1, which is a significant increase.

I was wondering if there was anything I could do to reduce these storage costs.

An AI suggested changing the singleton parameters in host.json, increasing the time, but they don't seem trivial to change.

Last night I tried changing one (lockPeriod). I'll check in the next few days to see if I get any benefits. For now, I've only noticed that, with the value of 1 minute, it sometimes doesn't write to the invocation log.

So every time you trigger a Function App, it creates a write and a read.

At the moment, how much has your cost increased per month? I am expecting maybe a few dollars in my case,

I went from €0.01 to €0.03 a day.

We're talking cents, but in percentage terms, it's a huge increase: +200%.

Well, I have not yet updated, as we have until October.

For example, in GPv1, 10,000 operations are charged at approximately US$0.00036. In GPv2, this increases to approximately US$0.050.

It would be good if someone from the Azure Team could clarify this?

The table you produced is it from the costing section

@Pravallika KV

Thank you for your reply

Have some additional questions,

When you mentioned

Logging (when you use file-based logs or the built-in file system logger)

Does this refer to the in-code command prompt–type logs? If so, what about Application Insights–type logs? I ask because my IoT Hub–triggered Function App will be triggered several hundred times per minute, so I would like to make it as efficient as possible.

As you mentioned, we can continue using GPv1. Will it still be supported beyond October 2026?

GPv1 didn’t charge for write operations in blob accounts, but GPv2 does, so if you do a lot of small writes (logs or leases) you will see some incremental cost.

How can we check what GPv2 would charge if we were to upgrade? For example, you mentioned that GPv1 does not charge for writes. Would logs be the only write operations in this case? Also, there are currently 96,328 operations. As the calculator shows reads, writes, and other operations with the same value, would it be correct to assume that this equates to around 10 units (10K operations)?

Using GPv2 purely for the purpose of a Function App, is there a minimum requirement for tier?

@DJ

Does this refer to the in-code command prompt–type logs?

Yes. Logs from things like:

log.LogInformation(...)
Console.WriteLine(...)

If Azure Application Insights is enabled, those logs go there and do not create Blob storage writes.

Blob/file writes happen only if file logging is enabled.

As you mentioned, we can continue using GPv1. Will it still be supported beyond October 2026?

No, Azure Storage General Purpose v1 will be retired Oct 13, 2026, and if you do not migrate your general-purpose v1 storage account to GPv2 by October 2026, all existing general-purpose v1 accounts will be auto migrated over to a GPv2 account, which may result in higher billing costs. Your decision not to migrate an existing general-purpose v1 account will be construed as consent for Microsoft to migrate the account on your behalf.

How can we check what GPv2 would charge if we were to upgrade?

You can check the MSDOC regarding Pricing considerations when upgrading to GPv2.

Example: 96,328 operations Pricing uses units of 10,000 operations:

96,328 / 10,000 ≈ 9.6 ≈ ~10 units

So, you would enter ~10 transaction units in the Azure Pricing Calculator.

Are logs the only write operations?

No. Even without logs, Azure Functions writes for:

• checkpoint updates (IoT/Event Hub trigger)
• partition leases
• runtime host locks

Minimum tier for GPv2 for Function Apps?

You can use below setup for Function Apps.

GPv2
Standard
Hot tier
LRS redundancy

@Pravallika KV

Thank you. So would each log entry equate to a write operation on Blob Storage?

Yes, I have enabled Application Insights, but there is a limit on how much data I capture. Once that capture limit is reached, any additional logs are not saved. How would this affect the writes to Blob Storage?

Would the automated upgrade do anything different compared to performing the upgrade manually?

When we check the calculator, is there anything else we need to include in addition to the 96,328 transaction count?

Do log entries create Blob writes?

Only logs written by the Function runtime to storage (file-based or diagnostic logs) generate Blob writes. Application Insights logs, including ILogger calls, go through telemetry and do not touch Blob storage, so they won’t increase storage transactions.

In modern Function Apps, if you’re using Application Insights, normal logs (Info, Warning, Error) do not create Blob writes. The only writes are internal runtime operations, like checkpoints, leases, or secret storage.

Application Insights capture limit reached?

Hitting the Application Insights data cap only stops new telemetry from being stored in App Insights. It does not affect Blob storage writes, because runtime operations like checkpoints and leases continue independently of Application Insights logging.

Automated vs manual GPv2 upgrade?

Automated upgrade after GPv1 retirement seamlessly converts the account to GPv2 with default settings (Standard, Hot, LRS). Manual upgrade lets you choose tiering, replication, and performance options, giving slightly more control over costs and configuration.

Calculator – what to include?

Include all storage transactions (reads, writes, lists), the total data stored in GB, and the replication/tier configuration. Your 96,328 transactions are the main component; Application Insights logs are not part of this calculation.

Thank You @Pravallika KV

Ok, how can I check that diagnostic logs or unnecessary data are not being returned? The aim is to avoid unnecessary API calls, especially if the data is not being used.

For calls such as checkpoints, leases, or secret storage, do we have any control over them from the Function App portal?

I use logs as shown

log.LogInformation($"Incoming Message {index}/{batchSize}: --> {IOTMESSAGE}");

Also, would it be best to manually perform the upgrade? I will plan to do this closer to the time.

At the moment there are 96,328 transactions. How can I verify that this does not include unnecessary logs? Are there any settings I can check in both the Azure Function App and Storage Account settings?

I understand that logs can be useful when debugging, but in this case I need to keep the costs as low as possible for this task. I want to make sure that, within the 96,328 transactions, there are no unnecessary operations being generated.