In EC2, what is the difference between Dedicated Instances and a Dedicated Host, and in what situation does that difference actually matter?

## Three tenancy values Every EC2 instance is launched with a tenancy, set on the instance or inherited from its VPC: - **`default`** — shared tenancy. Your instance shares physical hardware with other AWS customers, isolated by the hypervisor. This is what almost everything runs on. - **`dedicated`** — Dedicated Instances. The physical server carries no other customer's instances. - **`host`** — Dedicated Host. You allocate a specific physical server and place instances onto it explicitly. The interview question is why the last two both exist, since both sound like "our own hardware". ## Dedicated Instances: isolation, and nothing more A Dedicated Instance is an ordinary instance with a guarantee attached: no other AWS account's instances run on the same physical server. Other instances from *your own* account may share it. What you do **not** get is any relationship with the hardware. AWS decides where each instance lands. Stop and start an instance and it may come back on entirely different hardware. You cannot see how many sockets or physical cores the server has, and you cannot ask for two instances to be co-located or kept apart on a specific box. Dedicated Instances also carry an additional per-Region hourly charge on top of the instance rate, levied once per Region rather than per instance. They exist for one kind of requirement: a compliance or policy statement that says our workloads must not share physical hardware with other organisations. That is a real requirement in some regulated environments, and Dedicated Instances satisfy it with almost no operational change. ## Dedicated Hosts: the physical server as a managed resource A Dedicated Host is a different mental model. You allocate a physical server into your account, and it becomes a resource you manage: - You can see its **socket count and physical core count**, and how many instances of each supported size it can hold. - You choose which instances run on it. **Auto-placement** controls whether untargeted launches may land there; **host affinity** binds an instance to a host so that stopping and starting it returns it to the same physical machine rather than somewhere new. - You pay for the host itself, whether or not it is fully packed. Filling it well is now your problem — and your opportunity. ## Why anyone accepts that extra work: licensing The dominant real-world driver is software licensed **per physical socket or per physical core**, typically under bring-your-own-licence terms carried over from a data centre. Such a licence needs two things the cloud does not normally provide: a countable number of physical cores and sockets, and evidence that the software ran on hardware you can identify over time. Dedicated Hosts supply exactly those — the visible socket and core counts, and affinity so the instance keeps returning to the same identified machine. Vendors' licence-mobility rules often require precisely this arrangement. AWS License Manager sits on top of this: you define a licence configuration with rules such as a core or socket limit, associate it with an AMI, and it tracks and enforces consumption across hosts, with host resource groups automating host allocation. That is the machinery that turns "we own 32 cores of this database licence" into something enforceable. A secondary driver is regulatory or contractual obligations that pin workloads to identified physical hardware, or the desire to control instance placement on a box for reasons of your own — but licensing is the reason that comes up in interviews. ## Choosing between them Ask what the requirement actually says. - **"No other customers on our hardware."** → Dedicated Instances. You get the isolation without taking on capacity planning of a physical server. - **"Our licence is per physical core and must be reported against identified hardware."** → Dedicated Host. Nothing else can answer it. - **"We want predictable performance."** → Usually neither. On modern Nitro-based instances the hypervisor overhead and noisy-neighbour effects that this reasoning assumes are largely gone; the right answers are choosing an appropriate instance type, or placement groups if the concern is network locality or fault isolation. Reaching for dedicated tenancy for performance is a common misdiagnosis. ## Cost Both options cost more than shared tenancy, in different shapes. Dedicated Instances add the per-Region hourly charge on top of per-instance rates. A Dedicated Host is billed as a whole server — so it can actually come out cheaper if you pack many instances onto it *and* it lets you use licences you already own instead of paying AWS's licence-included rates. That licence arbitrage, not the compute rate, is usually what makes the numbers work.