Premium network tier cost is the best-known example of a default that pays without being asked: Google Cloud routes external traffic over the Premium Tier by default, Azure creates storage accounts geo-redundant through the CLI by default and OS disks on Premium SSD, databases come out of templates with Business Critical or Enterprise Plus, and function apps with a Premium plan because the wizard suggested it. The saving comes from the standard tier being enough for most non-production environments and many production services, and from the default being changed in one place, the template, and applying to every new resource from then on. The fix belongs to the team that maintains the infrastructure templates.

Symptom

The bill shows premium lines in environments with no requirement for them. On AWS there is no network tier, but the same mechanics in templates: the RDS production wizard picks Multi-AZ and provisioned IOPS, CloudFront uses all edge locations by default, and io2 instead of gp3 sits in many a module; the lines read Multi-AZUsage, VolumeP-IOPS and DataTransfer-Out per price class. On Azure GRS, RA-GRS and GZRS sit in the storage meters, Premium SSD Managed Disks on the OS disks of test servers, Business Critical in the MeterSubCategory of SQL databases and Elastic Premium on function plans. On Google Cloud Networking carries the SKU Premium Tier Internet Egress instead of Standard Tier, and Cloud SQL the SKUs of the Enterprise Plus edition. Which architecture decisions avoid cost is in architecture choices and cost; this page covers the decisions nobody took.

A default picks the tier:the production wizard,a module, the provider'sdefaultNobody takesthe decisionPremium lines:Multi-AZUsage, VolumeP-IOPS,GRS and GZRS, Premium SSD,Business Critical, ElasticPremium, Premium TierInternet Egress,Enterprise PlusIn an environment withno requirement for them
A wizard, module or provider default picks the premium tier, so the premium lines land in environments that never needed them

How to detect it

AWS

The resources where a template chose the dearer option:

aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,StorageType,Iops,DBInstanceClass]' --output table
aws cloudfront list-distributions --query 'DistributionList.Items[].[Id,PriceClass,Comment]' --output table
aws ec2 describe-volumes --filters Name=volume-type,Values=io1,io2 --query 'Volumes[].[VolumeId,VolumeType,Size,Iops,Attachments[0].InstanceId]' --output table

PriceClass_All on CloudFront, io2 without a latency requirement and Multi-AZ in an account with a non-production tag are the candidates; the details are in high availability in non-production and over-provisioned IOPS and throughput. Trusted Advisor and Compute Optimizer do not find the default, only its consequences. In billing data the candidate is a premium line in an account classified as non-production (AWS Cost and Usage Report).

Azure

Storage accounts, disks, databases and plans by tier:

az storage account list --query "[?sku.name!='Standard_LRS' && sku.name!='Standard_ZRS'].{name:name, rg:resourceGroup, sku:sku.name, env:tags.env}" -o table
az disk list --query "[?sku.name=='Premium_LRS' && osType!=null].{name:name, rg:resourceGroup, gb:diskSizeGb, vm:managedBy}" -o table
az sql db list --server <server> --resource-group <rg> --query "[?currentSku.tier=='BusinessCritical' || currentSku.tier=='Premium'].{name:name, tier:currentSku.tier, sku:currentSku.name}" -o table
az functionapp plan list --query "[?sku.tier=='ElasticPremium'].{name:name, rg:resourceGroup, sku:sku.name}" -o table

az storage account create creates an account without --sku as Standard_RAGRS, read-access geo-redundant, and az vm create takes the disk type from --storage-sku (read on 2026-10-21, az storage account create, az vm create); a module without these parameters inherits the default. Azure Advisor recommends the move to premium in one direction only, at a high transaction share, and does not rate geo-redundancy. In the cost export the candidate is a GRS, Premium or Business Critical meter in a resource group with a non-production tag (Azure cost exports).

Google Cloud

The project's network tier and that of its addresses, and the edition of the databases:

gcloud compute project-info describe --format="value(defaultNetworkTier)"
gcloud compute addresses list --format="table(name,region.basename(),address,networkTier,users.list())"
gcloud sql instances list --format="table(name,databaseVersion,settings.edition,settings.tier,settings.availabilityType)"

Premium is the default network tier, Standard is priced lower and available to resources with regional external addresses, not to global load balancers, Cloud VPN and Cloud CDN (network service tiers). On Cloud SQL, Enterprise Plus brings a data cache, a 99.99 percent availability commitment and shorter maintenance interruptions, and is the default for MySQL 8.4 and 9.7 (Cloud SQL editions). There is no recommender for the tier. In the billing export the candidate is a Premium Tier egress SKU or an Enterprise Plus SKU in a project with a non-production label (Google Cloud billing export).

How to fix it

  1. Decide per tier when it is right: premium network for services with users on several continents, geo-redundancy for data with a cross-region recovery requirement, Business Critical and Enterprise Plus for databases with a latency or availability commitment, premium function plans for functions with VNet integration or no tolerance for cold starts. Everything else gets the standard tier, and the rule sits in the cost policy.
  2. Change the default where the provider has one: gcloud compute project-info update --default-network-tier=STANDARD for a project without global load balancers, and --network-tier=STANDARD for new resources; on Azure --sku Standard_LRS and --storage-sku StandardSSD_LRS as parameters in every module that creates storage or VMs.
  3. Convert existing resources: az storage account update --name <account> --resource-group <rg> --sku Standard_LRS, az disk update --sku StandardSSD_LRS with the VM deallocated, az sql db update --server <server> --resource-group <rg> --name <db> --edition GeneralPurpose --family Gen5 --capacity 2, az functionapp plan to a Consumption or Flex plan by recreation; on Google Cloud a new regional address with --network-tier=STANDARD and gcloud sql instances patch <instance> --edition=ENTERPRISE. Without a dry run; the list and a latency test stand in for it.
  4. Have the template checked: a step in the infrastructure code review that holds every premium tier against the rule from step 1, with tools such as Infracost that write the price of a change into the pull request (cost in the development lifecycle).

Converting a resource takes effect from the change; the template takes effect with every new resource.

yesnoPer tier, when it is right:users on several continents,cross-region recovery, alatency or availabilitycommitment, VNet integrationor no cold-start toleranceDoes the environmentmeet the rule?The premium tier staysThe standard tier, bythe cost policyChange the default wherethe provider has one: theproject's network tier, SKUparameters in every moduleConvert existing resources:no dry run, the list and alatency test stand inHave the template checked:a review step holds everypremium tier against therule, the price of a changein the pull request
The rule per tier is decided first, the default and the existing resources follow it, and the review holds every new premium tier against it

Risks and side effects

  • The Standard network tier hands traffic to the public internet earlier; latency and routing change, and users outside the region notice first. A comparison of response times comes before the conversion.
  • Switching geo-redundancy off deletes the second copy; an account that holds the only backup needs another one first.
  • An edition change on databases is a restart with a maintenance window, and features such as the data cache or zone redundancy fall away; the availability commitment falls with them.
  • A function plan does not change in place; the app moves to a new plan, with new scaling and new cold starts.
  • The standard tier is not always cheaper: a Standard HDD with many transactions costs more than a Standard SSD, and CloudFront in a lower price class pays the detour for users outside the class.

How to verify the saving

Before: per resource, the premium line in the last full month, Premium Tier Internet Egress, GRS meters, Premium SSD meters, Business Critical vCores, Elastic Premium hours, Enterprise Plus SKUs, with the environment from tag or account. After: the same resource in the first full month after the conversion with the standard line, and the number of new resources with a premium tier and no justification, which has to stay at zero after the template change. The difference from the price list is the estimate, the team's release makes it accepted, the conversion implemented, and the following month's invoice realises it in the pattern of estimated, accepted, implemented, verified. The share of premium lines in non-production environments is the figure for the cost review.

Sources

Read on 2026-10-21. Google Cloud network service tiers, Cloud SQL editions, gcloud compute project-info, az storage account, az vm, Azure Advisor cost recommendations, aws cloudfront list-distributions.