Everything You Need to Know About EC2 Dedicated Instances

Summary:

• EC2 Dedicated Instances provide hardware isolation at the physical server level while AWS manages host placement. This offers a middle ground between shared tenancy and Dedicated Hosts for compliance and security requirements.
• The pricing model combines a per-region dedicated fee (starting at $2/hour) plus standard instance charges. Cost analysis is critical before adoption.
• Unlike Dedicated Hosts, Dedicated Instances do not expose socket or core visibility. This limits their use for certain BYOL scenarios but simplifies operational overhead.
• Tenancy changes between dedicated and default modes carry specific restrictions that impact migration strategies and long-term architecture decisions.
• Supported instance families now include Graviton4 and U7i types, expanding options for performance-sensitive workloads requiring isolation.

When regulatory auditors ask how you guarantee that your production workloads never share physical hardware with another AWS customer, the answer often comes down to one architectural decision: EC2 Dedicated Instances. This tenancy model sits at a critical intersection of compliance requirements, cost optimization, and operational simplicity that many engineering teams misunderstand or overlook entirely. Whether you are preparing for a SOC 2 audit, navigating healthcare data regulations, or simply need deterministic performance isolation, understanding the nuances of dedicated tenancy will shape your infrastructure strategy for years to come.

The following diagram illustrates how EC2 Dedicated Instances fit within the broader AWS tenancy model. It shows the relationship between physical hosts, the Nitro System hypervisor, and instance placement.

What are EC2 Dedicated Instances

EC2 Dedicated Instances are virtual machines that run on hardware dedicated exclusively to a single AWS account. Unlike shared tenancy where your instances might coexist on the same physical server with workloads from other customers, dedicated tenancy guarantees that the underlying host belongs solely to your organization. AWS manages the placement, maintenance, and lifecycle of these hosts automatically. This abstracts away the operational complexity while delivering the isolation benefits your compliance team demands.

The technical foundation relies on the AWS Nitro System, which provides the hypervisor layer separating your instances from the physical hardware. When you launch a Dedicated Instance, AWS allocates capacity from a pool of hosts reserved for your account within the specified Availability Zone. Your instances receive dedicated vCPU allocation, memory, and network bandwidth without contention from external workloads. This isolation extends to the physical cores and sockets of the underlying server, though you do not gain visibility into these hardware details.

The key distinction from standard EC2 instances lies in the tenancy attribute you specify at launch time. Setting tenancy to “dedicated” ensures your instance lands on single-tenant hardware. You can configure this at the VPC level to enforce dedicated tenancy for all instances within that network boundary, or specify it per-instance for more granular control. After clarifying these foundational concepts, the next critical consideration becomes understanding how this isolation model affects your AWS bill.

Pricing structure and cost analysis

The billing model for EC2 Dedicated Instances introduces a two-component cost structure that differs significantly from shared tenancy pricing. First, you pay a per-region dedicated fee of $2 per hour for any hour during which at least one Dedicated Instance runs in that region. Second, you pay the standard On-Demand, Reserved Instance, or Savings Plans rate for each instance based on its type and size. This structure means running a single t3.micro as a Dedicated Instance costs substantially more per hour than its shared equivalent.

Breaking down the cost components

Consider the following cost breakdown for a typical deployment scenario:

• Region dedication fee: $2/hour applies once per region regardless of how many Dedicated Instances you run. This makes consolidation within fewer regions more cost-effective.
• Instance hourly rate: Standard pricing applies. An m7g.xlarge Dedicated Instance costs the same hourly rate as its shared counterpart plus the region fee overhead.
• Data transfer and storage: These charges remain identical to shared tenancy, with no premium for dedicated hardware.

The economics shift favorably when you run multiple Dedicated Instances in the same region. That $2/hour fee amortizes across all instances, reducing the per-instance premium as your fleet grows. For organizations running dozens of instances requiring isolation, the incremental cost becomes marginal compared to the compliance and security benefits gained.

Cost comparison with alternatives

The following table contrasts the pricing models across tenancy options to help you evaluate the right fit for your workload requirements and budget constraints.

Understanding these cost dynamics prepares you to make informed decisions about when dedicated tenancy justifies its premium. The next section explores the specific enterprise scenarios where this investment delivers measurable value.

Enterprise use cases and compliance scenarios

Dedicated Instances address specific technical and regulatory requirements that shared tenancy cannot satisfy. The most common drivers include compliance mandates, licensing constraints, and performance isolation needs. Each scenario demands careful evaluation of whether Dedicated Instances or Dedicated Hosts better serve your objectives.

Compliance and regulatory requirements

Industries subject to strict data handling regulations often require demonstrable hardware isolation. Healthcare organizations operating under HIPAA, financial institutions meeting PCI-DSS requirements, and government contractors adhering to FedRAMP guidelines frequently mandate single-tenant infrastructure. Dedicated Instances provide auditable evidence that your workloads never share physical resources with external parties.

The isolation guarantee extends beyond the hypervisor layer. When your compliance framework requires attestation that no other organization’s code executes on the same physical processor, Dedicated Instances deliver that assurance without requiring you to manage host-level operations. Your audit documentation can reference the tenancy attribute and AWS’s infrastructure controls as evidence of isolation.

Bring your own license considerations

Software licensing represents a nuanced decision point for dedicated tenancy. Some enterprise software agreements, particularly those from Oracle and Microsoft, include terms tied to physical core or socket counts. Dedicated Instances do not expose this information, which limits their applicability for certain BYOL scenarios.

However, many license agreements simply require single-tenant hardware without specific core visibility. In these cases, Dedicated Instances satisfy the licensing terms while avoiding the operational overhead of Dedicated Hosts. The following considerations help determine the right approach:

1. Review your license agreement: Identify whether terms reference physical cores, sockets, or simply require dedicated hardware.
2. Consult your vendor: Microsoft and Oracle have specific guidance for AWS deployments that may influence your tenancy choice.
3. Document your configuration: Maintain records of your tenancy settings and instance placements for license audit purposes.
4. Consider License Manager: AWS License Manager can track license consumption across Dedicated Hosts but offers limited functionality for Dedicated Instances.

The diagram below illustrates the decision tree for selecting between Dedicated Instances and Dedicated Hosts based on licensing requirements.

With licensing and compliance scenarios clarified, the technical constraints around tenancy changes become the next critical consideration for architects planning migrations or infrastructure evolution.

Tenancy change limitations and migration strategies

AWS imposes specific restrictions on modifying instance tenancy that directly impact your migration planning and long-term architecture flexibility. Understanding these constraints prevents costly mistakes during infrastructure transitions and ensures your deployment strategy accounts for tenancy lock-in scenarios.

Tenancy modification rules

The rules governing tenancy changes depend on your starting point and target configuration. Instances launched with default (shared) tenancy can be modified to dedicated tenancy, but the reverse operation carries restrictions. Once an instance runs as dedicated, changing it back to shared tenancy requires stopping the instance. Certain instance types may not support this transition at all.

VPC-level tenancy settings add another layer of complexity. When you create a VPC with dedicated tenancy, all instances launched within that VPC inherit dedicated tenancy. However, you can still override this at launch by specifying host tenancy for Dedicated Hosts. You can change a VPC’s tenancy attribute from dedicated to default after creation (using the AWS CLI, SDK, or API), but you cannot change it from default to dedicated. This means if you initially create a dedicated VPC, you have an escape hatch to convert it to default tenancy later, but not vice versa.

Migration considerations

Planning a migration to or from Dedicated Instances requires careful sequencing to minimize downtime and cost impact. The following strategies address common migration scenarios:

• Shared to dedicated migration: Stop the instance, use the EC2 ModifyInstancePlacement API to change the tenancy attribute to dedicated, then restart. The instance is unavailable during the transition as AWS relocates it to dedicated hardware.
• Dedicated to shared migration: Stop the instance, modify the tenancy attribute, then restart. Verify your instance type supports this transition before planning the maintenance window.
• Cross-VPC migration: If you need to move instances to a VPC with different network configuration or if you created a VPC with default tenancy and later need dedicated tenancy, use AMI-based migration or AWS Application Migration Service to facilitate this transition.

The AWS documentation on Dedicated Instances provides the authoritative reference for current tenancy modification capabilities and restrictions. These constraints directly influence performance characteristics, which the next section examines in detail.

Performance implications and isolation benefits

The performance profile of Dedicated Instances differs from shared tenancy in ways that matter for latency-sensitive and throughput-intensive workloads. While AWS does not guarantee performance improvements from dedicated tenancy alone, the elimination of noisy neighbor effects provides more predictable resource availability.

Resource isolation characteristics

On shared tenancy, your instance competes with other customers’ workloads for access to the physical host’s cache hierarchy, memory bandwidth, and network interface capacity. Dedicated Instances eliminate this contention by ensuring all instances on the underlying host belong to your account. The practical impact varies by workload type:

• CPU-bound workloads: More consistent performance during sustained computation as cache eviction from external workloads disappears.
• Memory-intensive applications: Reduced variability in memory access latency, particularly beneficial for in-memory databases and caching layers.
• Network-sensitive services: More predictable network throughput as the Elastic Network Adapter serves only your instances.

The following diagram shows the resource isolation boundaries for Dedicated Instances compared to shared tenancy.

Performance isolation benefits become most apparent under sustained load conditions. Benchmark testing in your specific environment remains essential because the magnitude of improvement depends heavily on workload characteristics and the baseline contention level in your region’s shared capacity pool. Consider the following section’s coverage of supported instance types when selecting hardware for performance-critical deployments.

Supported instance types and recent AWS updates

AWS continuously expands the instance families available for dedicated tenancy, with recent additions including the latest Graviton4-based and high-memory instance types. Staying current with supported configurations ensures your architecture can leverage new capabilities as they become available.

Current instance family support

As of 2025, dedicated tenancy supports the vast majority of EC2 instance families across general purpose, compute optimized, memory optimized, and accelerated computing categories. Notable recent additions include:

• Graviton4 instances (R8g, M8g, C8g): The latest ARM-based processors offering improved price-performance for compatible workloads.
• U7i instances: High-memory instances supporting up to 32 TiB of RAM for large-scale in-memory databases and SAP HANA deployments.
• Trn2 instances: AWS Trainium-based instances for machine learning training workloads requiring dedicated hardware isolation.

The EC2 instance types documentation maintains the authoritative list of supported configurations. Some instance types, particularly those in preview or limited availability, may not support dedicated tenancy immediately upon launch.

Dedicated Instances versus Dedicated Hosts comparison

The following comprehensive comparison helps architects select the appropriate tenancy model based on technical requirements and operational preferences.

How to launch and manage Dedicated Instances

Deploying Dedicated Instances requires configuration at either the VPC level or individual instance level, with management handled through standard EC2 tools and APIs. The implementation approach depends on whether you need blanket dedicated tenancy or selective isolation for specific workloads.

Launch configuration options

You can enable dedicated tenancy through multiple interfaces. The AWS Management Console provides the most straightforward approach for initial deployments. Infrastructure as Code tools like Terraform or AWS CloudFormation enable repeatable, version-controlled configurations.

For instance-level configuration, specify the tenancy attribute during launch:

1. Console method: In the EC2 launch wizard, expand Advanced Details and set Tenancy to Dedicated.
2. CLI method: Include --placement Tenancy=dedicated in your run-instances command.
3. CloudFormation: Set the Tenancy property to dedicated in your AWS::EC2::Instance resource.

For VPC-level enforcement, configure the tenancy attribute when creating the VPC. All instances launched in a dedicated-tenancy VPC automatically inherit dedicated placement regardless of individual instance settings.

Conclusion

EC2 Dedicated Instances occupy a strategic position in the AWS tenancy spectrum, delivering hardware isolation without the operational complexity of managing individual hosts. The key architectural takeaways center on three considerations. First, the pricing model favors deployments with multiple instances per region where the $2/hour dedication fee amortizes effectively. Second, tenancy change restrictions require upfront planning, particularly when VPC-level settings create permanent constraints. Third, the lack of socket and core visibility limits BYOL applicability compared to Dedicated Hosts.

Looking ahead, AWS continues expanding instance family support for dedicated tenancy, with Graviton4 and specialized accelerator instances now available for isolation-sensitive workloads. The October 2024 introduction of live migration for Dedicated Hosts signals AWS’s ongoing investment in reducing operational friction across tenancy models. Similar improvements may extend to Dedicated Instances in future releases.

For engineering teams navigating compliance requirements or performance isolation needs, Dedicated Instances provide a pragmatic middle path. They eliminate noisy neighbor concerns and satisfy single-tenant mandates while keeping infrastructure management squarely in AWS’s domain. The decision ultimately hinges on whether your licensing and compliance frameworks require the additional visibility that only Dedicated Hosts provide.