1{2 "_what_this_is": "Azure Managed Disk -> EBS volume type and provisioning. Consumed by design-refs/compute.md and storage.md as POST-SELECTION sizing; Microsoft.Compute/disks is a Direct Mapping to EBS, so the service choice never reaches a rubric.",3 "_provenance": "Authored from published Managed Disk tier specs and published EBS volume limits. NOT verified against a live API.",4 "_plan_correction": "Plan section 0 records the breakpoint as 'gp3 to 80K IOPS, then io2'. That is WRONG: a single gp3 volume caps at 16,000 IOPS and 1,000 MiB/s. 80,000 is an instance-level aggregate, not a volume limit. The breakpoints below are per-volume, which is what a disk maps to.",5 "tier_mapping": {6 "Premium_LRS": {7 "azure": "Premium SSD (P-tier)",8 "aws":
9 "note": "Default target. gp3's 3,000 IOPS / 125 MiB/s baseline is included at every size, where Azure's P-tier couples IOPS to disk size -- so a small Azure P-tier disk often gains performance on gp3 at lower cost."
10 },
11 "PremiumV2_LRS": {
12 "azure": "Premium SSD v2",
13 "aws": "gp3",
14 "note": "Premium v2 already decouples IOPS from capacity, exactly like gp3. Carry the source's provisioned IOPS and throughput across directly -- this is the cleanest disk mapping in the file."
15 },
16 "StandardSSD_LRS": {
17 "azure": "Standard SSD (E-tier)",
18 "aws": "gp3",
19 "note": "gp3 at baseline. Do not provision extra IOPS: the source tier does not have them."
20 },
21 "Standard_LRS": {
22 "azure": "Standard HDD (S-tier)",
23 "aws": "st1",
24 "note": "st1 for sequential/throughput workloads. For a genuinely cold volume use sc1. st1 and sc1 both have a 125 GiB MINIMUM -- a 32 GiB Azure HDD becomes a 125 GiB st1, so the estimate goes UP. Check whether gp3 is cheaper at the source size before defaulting to st1."
25 },
26 "UltraSSD_LRS": {
27 "azure": "Ultra Disk",
28 "aws": "io2 Block Express",
29 "note": "Ultra Disk is the only Azure tier with independently provisioned IOPS AND latency guarantees. io2 Block Express is the counterpart."
30 },
31 "Premium_ZRS": {
32 "azure": "Premium SSD zone-redundant",
33 "aws": "gp3",
34 "note": "EBS volumes are single-AZ. ZRS has NO EBS equivalent: zone redundancy on AWS comes from the workload (multi-AZ ASG, RDS Multi-AZ), not the volume. This is a resilience DOWNGRADE at the volume layer and must be stated, not absorbed."
35 },
36 "StandardSSD_ZRS": {
37 "azure": "Standard SSD zone-redundant",
38 "aws": "gp3",
39 "note": "See Premium_ZRS."
40 }
41 },
42 "breakpoints": {
43 "_rule": "Apply in order, first match wins. These are PER-VOLUME limits.",
58 "note": "Up to 256,000 IOPS and 4,000 MiB/s per volume. Requires a Nitro instance -- check the chosen instance type supports it, or the design does not apply."
59 }
60 ],
61 "gp3_baseline": {
62 "iops": 3000,
63 "throughput_mib_s": 125,
64 "_note": "Included free at every volume size. Only provision above this when the source actually exceeded it."
65 },
66 "gp3_max": {
67 "iops": 16000,
68 "throughput_mib_s": 1000
69 },
70 "io2_max": {
71 "iops": 64000,
72 "throughput_mib_s": 1000
73 },
74 "io2_bx_max": {
75 "iops": 256000,
76 "throughput_mib_s": 4000
77 }
78 },
79 "size": {
80 "rule": "disk_size_gb from the source, carried across as GiB. EBS minimums: gp3 1 GiB, io2 4 GiB, st1 and sc1 125 GiB.",
81 "never_shrink": "Do not round down. An Azure disk cannot be shrunk in place either, so a smaller target is not a saving anyone can realise -- it is a migration that fails on first copy."
82 },
83 "os_disk_vs_data_disk": {
84 "os_disk": "Becomes the EC2 root volume. It is created by the instance, so it does NOT get its own services[] entry -- it is aws_config on the compute row, exactly as a network interface is.",
85 "data_disk": "A managed disk attached as a data disk is its own EBS volume and its own line item.",
86 "_why_this_matters": "Counting the OS disk twice -- once inside the instance and once as a standalone volume -- is the most common way a VM estate's storage cost gets inflated.",
87 "inline_os_disk": "MOST COMMON CASE, and the one that used to be lost entirely. A VM's os_disk is normally an INLINE BLOCK, not an azurerm_managed_disk, so no Microsoft.Compute/disks resource exists for it. extract-terraform.md section 'Inline blocks that are not resources' now carries it into config.os_disk; map it to the instance's root volume in aws_config using the tier_mapping above (Premium_LRS -> gp3), and NEVER to a services[] entry of its own.",
88 "absent_disk_size_gb": "When the inline block sets no disk_size_gb the size is the image default, which is NOT discoverable from Terraform. Carry size_gib null with size_source 'image_default_unstated' and surface it as a stated assumption. Substituting a remembered default (127 GiB for Windows marketplace images, 30 for many Linux ones) makes an invented number indistinguishable from a measured one, and Estimate would price it as fact."
89 },
90 "unattached_disks": {
91 "rule": "A managed disk with no VM attachment is paid-for capacity doing nothing. Map it, and raise it as a cost-optimization finding. Do NOT silently drop it: an unattached disk is often a forgotten snapshot source or a detached data volume someone still needs."