Counting engineer hours and support fees in cloud TCO

One application's share of the account

Start from one application, because a provider quotes an environment and an AWS account holds several. Pull its cost from Cost Explorer grouped by your activated application tag, on the amortized metric, over the last three full months. The end date is exclusive, so this window covers June through August:

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-09-01 \
  --granularity MONTHLY --metrics AmortizedCost \
  --group-by Type=TAG,Key=app

Amortized cost spreads an upfront reservation fee across the term it pays for. By default, Cost Explorer books the whole fee as a spike on the day it was charged, so one month looks expensive and the next eleven look cheap. Azure Cost Management offers the same choice between Actual cost and Amortized cost, and only the amortized view shows the UnusedReservation and UnusedSavingsPlan charges.

The group keyed app$, with nothing after the dollar sign, holds spend with no tag value. Shared charges collect there: NAT gateway data processing, CloudWatch log ingestion, a load balancer in front of several services. Trace the pieces that carry this application's traffic and add them to its total. Tags label spend only from the day they are applied. A cost allocation tag backfill (aws ce start-cost-allocation-tag-backfill) reaches back up to twelve months, and it fills in only the months when the tag already sat on the resource.

Then reprice the application after the cleanup you could do without leaving AWS: instances rightsized, and dev and QA stopped overnight and on weekends. Those savings belong on the AWS side of the comparison.

How Business Support+ and Enterprise fees fall on a smaller bill

AWS's pricing page lists Business Support+ at the greater of $29 a month per account or 9 percent of monthly charges up to $10,000, 7 percent from $10,000 to $80,000, 5 percent to $250,000 and 3 percent above that. Enterprise Support bills the greater of $5,000 a month or 10 percent up to $150,000, then bands of 7, 5 and 3 percent. Three rules on the same page change the math for a migration:

• Business Support+ is calculated for each account separately. Enterprise uses the total across every subscribed account.
• Both plans use gross charges before discounts or credits, so a negotiated discount does not lower the fee.
• An upfront reservation payment counts in full in the month you buy it, and a reservation's recurring fee keeps counting until its term ends, whether or not anything still runs on it.

Take an account with $62,000 of monthly charges and move out an application worth $16,700 of them. The Business Support+ fee on the remaining bill falls from $4,540 to $3,371, a drop of $1,169. Enterprise goes from $6,200 to $5,000, a drop of $1,200, where a flat 10 percent share would have claimed $1,670. An Enterprise account already under $50,000 a month pays the $5,000 minimum, and moving an application out of it leaves the support line at $5,000.

Price the plan that will exist during the comparison period. Developer Support and Business Support end on January 1, 2027, outside AWS GovCloud (US), and accounts on them have to opt in to Business Support+ before that date.

Azure's published plans charge a flat fee whatever the bill: $29 a month for Developer, $100 for Standard and $1,000 for Professional Direct, so a partial migration leaves that line where it is. Microsoft publishes no price for Unified Enterprise, and a Unified customer has to ask how a smaller footprint changes the renewal.

Support fees on either cloud buy help with the provider's own services. AWS Support excludes system administration and remote access to your systems, and under the shared responsibility model the guest operating system on EC2, patches included, stays with your team. That work shows up in the engineer hours.

Which infrastructure tasks leave with the migration?

If infrastructure work runs through tickets, the ticket history already records most of it. Export 90 days of infrastructure tickets, paging history and merged changes to the Terraform or deployment repository for this one application. Then spend half an hour with the engineers who did the work to add what never got a ticket, such as patch windows and the afternoon spent in Cost Explorer. Multiply the hours by the loaded hourly rate your finance team uses.

Sort every hour into three columns:

• Tasks the provider's proposal names in writing. Credit nothing else to this column.
• Work that stays with your team either way, such as deploys, pipeline changes, schema migrations and debugging the application on its servers.
• New coordination work, mostly filing and following tickets and granting the provider access.

Our customers file tickets with us for database work, backups and restores, because the people on their side are developers. Those tasks go in the first column when a proposal names them, along with guest OS patching and image rebuilds.

Reading the bill takes hours as well. One of our customers still employs a person whose only job is reviewing its AWS invoice, and that job is one reason it began hosting dev and QA with us. Those hours go in the first column only when the proposal names bill review, and only for this application's share, since the rest of the AWS account still needs someone reading it.

Google's SRE book describes toil as work that scales linearly as a service grows. Patching, image rebuilds and restore drills grow with server count, so project those hours at the instance count you expect over the comparison period.

Hours in the first column are capacity. They turn into cash only when a payroll or contractor line changes, so show them apart from charges that stop, and let finance decide what the capacity is worth.

Commitment end dates set the cutover month

Commitments keep billing after the servers they covered are gone. List every active one with its end date before you model a cutover:

aws savingsplans describe-savings-plans --states active \
  --query 'savingsPlans[].[savingsPlanType,commitment,end]' --output table
aws ec2 describe-reserved-instances --filters Name=state,Values=active \
  --query 'ReservedInstances[].[InstanceType,InstanceCount,End]' --output table
aws rds describe-reserved-db-instances \
  --query 'ReservedDBInstances[?State==`active`].[DBInstanceClass,DBInstanceCount,StartTime,Duration]' \
  --output table

A Savings Plan commitment applies hour by hour, and an hour's unused commitment cannot carry over. AWS accepts a return only within seven days of purchase, in the same calendar month, for a plan whose commitment is $100 an hour or less. Standard EC2 Reserved Instances can be sold on the Reserved Instance Marketplace while at least a month of the term remains. Convertible Reserved Instances and RDS and ElastiCache reservations cannot be sold.

Two monthly numbers decide the timing. A Compute Savings Plan at $9.50 an hour bills about $6,935 a month. If the servers you migrate use $3,200 a month of that coverage, the $3,200 goes unused every month until the term ends, unless other eligible usage picks it up. Suppose a provider quotes $2,500 a month under your ceiling, the highest quote that still saves money. With 20 months left on the plan, migrating production loses $700 a month, $14,000 over the remaining term, before any migration cost. Moving before a commitment ends beats waiting only when the monthly difference is larger than the commitment it strands. Otherwise, schedule the production cutover for the end date and move dev and QA first. Run aws ce get-savings-plans-utilization after each phase, because dev and QA servers can sit under the same plan.

Azure treats its two commitment types differently. Savings plan purchases are final, with no cancellation or exchange. Reservations can be refunded up to $50,000 of canceled commitment in any rolling window of 12 months, and Microsoft charges no early termination fee today.

Run the breakeven with transition costs included

Take a hypothetical field service scheduling company, Hollisbrook Dispatch, with $62,000 of monthly AWS charges on Business Support+. Its routing service and customer portal come to $16,700 a month of amortized cost once shared NAT and log charges are traced. That figure includes a No Upfront RDS reservation for the portal database at $1,150 a month, with seven months left. Ninety days of tickets and paging history show 104 infrastructure hours a month on this application, at a loaded rate of $105 an hour. A managed server proposal names patching and image rebuilds (22 hours), database work and restores (18 hours), and some of the cost review and access management (10 hours). Alarm response, pipeline work, deploys and the remaining review and access tasks (54 hours) stay with Hollisbrook, and working with the provider adds about 6 hours.

The 54 hours that stay ($5,670 a month) sit on both sides of the comparison, so they drop out of the ceiling. They still decide whether Hollisbrook's engineers have time to run the migration. If finance counts the named hours at zero until a payroll or contractor line changes, the ceiling falls to $17,869, the infrastructure and support lines alone.

Transition costs sit outside the ceiling and add up to $40,400:

• Migration engineering: 160 hours at $105, or $16,800.
• One month of the AWS side running in parallel through cutover: $16,700.
• The RDS reservation's six months left after the parallel month, which cannot be sold: $6,900.

At a quote $2,500 a month under the ceiling, those costs pay back in about 16 months, before egress.

A partial exit pays for its own egress. AWS waives data transfer out after approving a request filed before the transfer starts, and only when all of a customer's data leaves AWS or leaves one AWS service entirely. The rest of Hollisbrook's account stays on EC2 and RDS, so its egress belongs on the transition list. Azure's exit credit covers up to 60 days of egress, needs a support request filed in advance, and outside the UK applies only after every subscription on the account is canceled.

Applications cheaper to leave on AWS or Azure

The same numbers point to staying in three cases:

• Almost nothing lands in the first column of engineer hours, because the application runs on RDS and Fargate, which already hand most patching to AWS, or because your team wants to keep running its own servers. The comparison then rests on infrastructure prices alone.
• The product depends on services with no direct replacement, such as DynamoDB, Lambda event wiring or SNS and SQS fanout. Price the rebuild as transition cost before anything else.
• Users need several regions. Petrichor runs in one U.S. data center, and a product that needs more than one region belongs on a hyperscaler.

We prefer to start customers on QA or dev and leave production where it is, often on AWS. One customer started with QA servers, proved them out, and then added development servers. Starting there tests the whole comparison on the environment with the least at stake while production's commitments expire.

Bring the environment you would price first, with its ticket export and three months of amortized cost, to a call with a consultant.