Choosing and governing flavors across an organization. Flavors look simple but drive both performance and ~60% of the BDT bill.

Picking the right family¶

A 30-second decision tree:

Workload	Family	Why
Web/app, K8s worker, mixed	std-*	1:4 is the everyman ratio
Postgres/MySQL > 32 GiB shared_buffers	mem-*	Avoid wasting cores you'll never use
Redis, OpenSearch JVM heap	mem-*	Same
Build farm, video transcode, HPC, compression	cpu-*	Saturates cores; RAM mostly idle
Bastion / jump-box	std-1x4	Minimum viable

If you're not sure, start std-* and migrate after 7 days of metrics. Cross-family resize is supported (with a reboot).

Right-sizing policy¶

Quarterly, review these metrics per VM:

Metric	Threshold	Action
cpu.busy p95	< 20% for 30 days	Resize down one step
cpu.busy p95	> 75% for 14 days	Resize up, or move to scaling group
mem.committed p95	> 85% of allocation	Resize up (mem family if 1:4 was wrong)
mem.committed p95	< 40% for 30 days	Cross-family to cpu-* or smaller std-*

The console Cost Explorer → Right-sizing report does this automatically and proposes a BDT savings figure.

Flavor allowlists¶

For larger orgs: restrict which flavors which projects can launch. Useful when:

• A small team keeps creating std-48x192 for "future use"
• You want prod-only access to cpu-96x192

Define in Project → Policies → Compute → Allowed flavors, or via API:

bash cd project policy set acme-prod \ --allowed-flavors 'std-*,mem-*,cpu-{2..16}x*'

Wildcards are glob-style. Denied flavors return FlavorNotAllowed at create time with the policy name in the error.

Commitment plans¶

Commitments are flavor-family-agnostic — you commit vCPU-hours, GiB-RAM-hours, and net-Gbps-hours separately. The platform applies the discount to whichever VMs are running.

Term	Discount range	Withdraw penalty
1-year	20–30%	50% of remaining
3-year	35–55%	70% of remaining

Only commit your baseline — the always-on floor. Above-baseline goes on-demand or into scaling groups.

vNUMA and pinning¶

For VMs ≥ 16 vCPU, the guest sees a vNUMA topology that mirrors the hypervisor socket layout. To take advantage:

```bash

Inside the guest — pin a latency-sensitive process to NUMA node 0¶

numactl --cpunodebind=0 --membind=0 ./trading-engine ```

The platform does not allow custom vcpupin from the API — that would break live migration. Latency-sensitive workloads should run on Dedicated Hosts with numa=strict.

Related¶

• VM flavors — Operation
• VM flavors — Troubleshooting
• Pricing

Running flavor changes safely: planning the reboot, validating performance afterwards, and tracking commitment utilization.

Resize procedure¶

Same-family (no stop):

```bash cd compute vm resize --vm web-01 --flavor std-4x16

VM: Running → Resizing → Rebooting → Running (~45 s)¶

```

Cross-family (stop required):

```bash cd compute vm stop --vm db-01 cd compute vm resize --vm db-01 --flavor mem-8x64 cd compute vm start --vm db-01

Total downtime: ~90 s typical¶

```

The Console UX hides the stop step, but the API requires it explicitly — automation should wait --for stopped before resize.

Validation checklist after a resize¶

1. VM lifecycle is Running in console and via cd compute vm show.
2. Inside the guest: bash nproc # should match new vCPU count free -h # total RAM matches
3. For mem-family targets: verify your app's heap/buffer config has been updated — Postgres shared_buffers, JVM -Xmx, etc. The OS sees the new RAM but apps usually don't unless configured.
4. Metrics flow — confirm cpu.busy and mem.used are still emitting in console.
5. Network bandwidth — bigger flavors have higher Gbps caps; if you're network-bound this is where you'll see the win.

Live migration and flavor changes¶

The platform may live-migrate a VM during hypervisor maintenance. Same-flavor target host is guaranteed — your VM never lands on a host that can't satisfy it. If no compatible target is available in the AZ, the platform schedules the maintenance for off-hours and notifies the project owner 72 h in advance.

Commitment plan utilization¶

Track via console Financial → Commitments:

Field	What it means
Committed vCPU-h	What you're paying for, per hour
Used vCPU-h	What you're actually consuming
Utilization %	Used ÷ Committed × 100
Wasted BDT (MTD)	The discount you'd have gotten if you matched usage

Target utilization > 90%. Below 70% sustained means you over-committed — wait for renewal and recommit lower.

Per-second billing edge cases¶

• VMs stopped via API stop billing for vCPU/RAM immediately. Volumes keep billing — that's separate.
• Reboot does not stop billing.
• Resize via stop/resize/start doesn't reset the 60-second billing minimum if you re-start within the same second-bucket.

Capacity planning¶

Each AZ publishes a public capacity gauge in the status page: green / yellow / red per flavor family. Treat yellow as "spread your fleet across AZs"; red as "don't launch large fleets there this week — open a capacity reservation request instead."

Capacity reservations: paid placeholder reservations that guarantee N flavors of family X in AZ Y for a window. Use for known events (Eid traffic, fiscal-year close).

Related¶

• VM flavors — Administration
• VM flavors — Troubleshooting
• Auto Scaling Groups

Resize failures, performance regressions, and quota surprises.

FlavorNotAllowed¶

Error at VM create / resize:

ERROR: FlavorNotAllowed: flavor 'cpu-96x192' is not in the project policy 'acme-prod'

The project has a flavor allowlist. Either:

• Use an allowed flavor (cd project policy show <project> to list)
• Or, if you're the project admin, amend the policy

InsufficientCapacity¶

The chosen flavor isn't available in that AZ right now:

Action	When to use
Retry in another AZ (bd-dha-1-az2 etc.)	Quickest; works most of the time
Step down one size (std-32x128 → std-16x64)	When the workload fits
Open a Capacity Reservation	For known fleet expansion
Open a Support ticket	Sustained red on the status page

Resize succeeded but app didn't grow¶

After resizing to a mem-* flavor, your app is still using the old memory footprint. Common cases:

• Postgres shared_buffers is set in postgresql.conf — it doesn't auto-scale. Edit, restart.
• JVM -Xmx is hardcoded in systemd unit / launch script. Edit, restart.
• Redis maxmemory config directive needs updating.

Verify the OS sees the RAM (free -h), then check the app's runtime config — not the kernel side.

Performance regression after resize¶

Symptom	Likely cause	Check
Higher latency on same load	Hypervisor with different CPU SKU	cd compute vm show --vm <id> --json \| jq .placement.cpu_model — compare before/after
Lower IOPS on same volume	Volume queue-depth not scaled with vCPU	Inside guest: echo 256 > /sys/block/vda/queue/nr_requests
Network throughput plateaus at old cap	App's connection pool too small	Increase pool size, retest

vNUMA misconfiguration¶

Symptom: a 32-vCPU VM uses only 16 cores effectively, or memory access is 2× slower than expected.

```bash

Check vNUMA topology the guest sees¶

numactl --hardware

Should show as many nodes as the platform exposed (usually 2 for ≥ 16 vCPU)¶

```

If you see only 1 node on a ≥ 16 vCPU VM: the guest is ignoring the SLIT/SRAT tables. Common with old kernels (RHEL 7, Ubuntu 18.04). Upgrade, or use NUMA-naive flavors (≤ 8 vCPU).

Quota errors on resize¶

ERROR: QuotaExceeded: project vcpu quota 200, current 196, requested +8

Resize counts the delta against the project quota. Free another VM (or shrink one) or request a quota bump. The error message includes the delta and current usage.

Commitment plan "wasted BDT"¶

If Wasted BDT (MTD) is climbing month-over-month: you're under-utilizing the commitment. Options:

1. Wait for renewal, recommit lower
2. Migrate eligible workloads from on-demand to the committed family
3. Sell the commitment back in a 50–70% penalty exit (rarely worth it)

The platform does not auto-extend commitments. Set a calendar reminder 30 days before expiry.

Related¶

• VM flavors — Administration
• VM flavors — Operation
• Virtual Machines — Troubleshooting