EC2 8th‑gen nested virtualization: VMs inside VMs without bare metal

AWS nested virtualization, finally on virtual EC2 For years, AWS customers who wanted to run a hypervisor inside an EC2 instance – to host VMs inside VMs were forced onto expensive bare‑metal instance types. With the 2026 release of nested virtualization on 8th‑gen Intel virtual EC2 instances, AWS now lets you run KVM or Hyper‑V inside standard C8i, M8i, R8i and related families without touching bare metal. In practice, this means you can build full lab environments, microVM platforms, and emulator farms using normal virtual instances that fit your price/performance envelope instead of specialized hardware hosts. What nested virtualization actually is Nested virtualization lets you run a hypervisor (for example KVM or Hyper‑V) inside an EC2 instance, and then create additional virtual machines inside that guest. AWS documentation describes a three‑layer architecture: the physical AWS infrastructure and Nitro hypervisor at level L0, your EC2 instance running its own hypervisor at L1, and one or more nested VMs at L2. The Nitro System passes processor‑level virtualization extensions like Intel VT‑x into the guest, so your L1 hypervisor can use hardware virtualization to run L2 VMs with reasonable performance. Supported EC2 instance families Nested virtualization is currently supported only on specific x86 instance types, primarily 8th‑generation Intel families. AWS lists support for C8i, M8i, R8i, their “flex” variants, and disk‑optimized siblings like C8id, M8id, R8id, as well as some 7th‑gen Intel types such as C7i, M7i, R7i, C7i‑flex, M7i‑flex, X8i, and I7i. Graviton (ARM) instances are not currently supported, so any nested virtualization design today has to target these Intel families. According to AWS, there is no additional EC2 surcharge for enabling nested virtualization itself, you pay the usual instance pricing. From bare metal only to virtual instances Before this update, the only officially supported way to run nested VMs on EC2 was to use bare‑metal instances, which expose the physical hardware directly and tend to be significantly more expensive. Many teams resorted to EC2 Mac instances and other low‑end bare‑metal types as a workaround just to get VT‑x access for test labs and microVM experimentation. With nested virtualization on virtual instances, AWS now exposes the same processor features via Nitro to standard EC2 types, so you can choose instance sizes based on workload requirements instead of being locked into bare metal purely for hardware virtualization. Supported hypervisors and tooling AWS explicitly supports KVM and Hyper‑V as the L1 hypervisors inside nested‑virtualization‑enabled EC2 instances. That covers the most common Linux and Windows workflows, where you might be running QEMU/KVM on Linux hosts or Hyper‑V on Windows Server or Windows workstations. In practice, this unlocks a wide toolchain: Docker Desktop, Windows Subsystem for Linux 2 (WSL2), Android Studio emulators, Firecracker, Kata Containers, and other microVM or VM‑based runtimes that rely on hardware virtualization extensions. Key use cases for DevOps and platform teams AWS and early adopters highlight several concrete use cases that nested virtualization on 8th‑gen EC2 enables. Enabling nested virtualization on EC2 AWS exposes nested virtualization as a CPU option on supported instance types. When launching a new instance via the API or CLI, you can set the NestedVirtualization=enabled flag in CpuOptions on compatible Intel families like c8i, m8i, or r8i. For existing instances, AWS documentation notes that you can turn on nested virtualization after stopping the instance, provided the instance type supports the feature. Once the instance is up, you install and configure KVM or Hyper‑V as usual, and then create L2 VMs using your preferred tooling (libvirt, virt‑manager, Hyper‑V Manager, etc.). Limitations and caveats you need to know There are a few important constraints and trade‑offs to factor into your designs. Architectural patterns unlocked by nested virtualization From an architectural point of view, nested virtualization on virtual EC2 closes a gap that has existed between AWS and other clouds that already supported VMs‑inside‑VMs on standard instance types. It means you can now keep complex virtualization‑dependent tooling – emulator farms, microVM platforms, and full lab environments – centralized on EC2 without bespoke bare‑metal clusters. You can design patterns like “hypervisor hosts as pets, nested VMs as cattle”: use C8i/M8i/R8i instances as L1 hypervisor nodes, spin up L2 VMs on demand for ephemeral dev/test environments, and tear them down as easily as containers. For organizations investing in multi‑tenant sandbox platforms or heavy QA pipelines, this drastically reduces the friction of moving those workloads into AWS. How Cloudwork can help you adopt this feature At Cloudwork, we already work with teams that want disposable lab environments, complex CI pipelines, and sandboxed domain‑intelligence workloads on AWS. Nested virtualization on 8th‑gen EC2 gives us a more flexible tool for those designs. We can help you: If you’ve been avoiding nested virtualization on AWS because bare‑metal instances were too costly, this 8th‑gen EC2 update is the moment to revisit that decision, and we can work with you to make sure your architecture, security model, and performance profile are ready for VMs inside VMs in the cloud.

Server Security for Beginners: 10 Essential Steps to Protect Your First Server

Server Security for Beginners: 10 Essential Steps to Protect Your First Server Renting your first server is exciting, until you realize that the moment it’s online, it is being scanned and probed by bots and opportunistic attackers.The good news is that a handful of practical steps will take you from “default and exposed” to “reasonably hardened” in a timely manner. In this guide, we’ll walk through a beginner‑friendly, real‑world checklist you can apply to any Linux server, whether you are on Hetzner, AWS, or another cloud provider.We’ll cover both operating‑system hardening and cloud‑level security controls like security groups, provider firewalls, VPNs, and Cloudflare Zero Trust. 1. Update Your Server Before Doing Anything Else Newly provisioned images are often weeks or months behind on patches, even if they were just created from your provider’s panel.Unpatched services are one of the most common ways attackers gain remote code execution within hours of a new vulnerability (CVE) being published. On day one: Security guidance consistently lists “apply OS and software updates immediately” as step one when bringing up a new server, for good reason. 2. Lock Down SSH: Keys, No Root, Limited Acces For most self‑hosted setups, SSH is the main way you manage your server and a prime target for brute‑force attacks and credential stuffing.Hardening SSH closes one of the easiest doors into your system. Implement the following: Industry best practices and security checklists repeatedly highlight SSH key‑based auth plus disabled root login as a baseline requirement for secure servers. 3. Turn On a Host‑Based Firewall (UFW, firewalld, nftables) A firewall should be configured to allow only the ports and protocols your application actually needs, blocking everything else by default.On Linux, that usually means enabling UFW (on Ubuntu/Debian) or firewalld/nftables (on many other distributions). At minimum: Guides from hosting providers and security vendors consistently treat “configure a local firewall” as a must‑do step when setting up a new server. 4. Use Cloud‑Level Firewalls and Security Groups Relying only on iptables/UFW on the instance itself is not enough in modern cloud environments.Cloud‑level firewalls add an extra protection layer that filters traffic before it ever reaches your VM’s network stack. Examples: Provider‑level firewalls and security groups are repeatedly mentioned in cloud security discussions as core building blocks for enforcing least‑privilege network access. 5. Add Brute‑Force Protection With Fail2ban or CrowdSec Even with keys, your server will see constant login attempts and vulnerability scans, especially on SSH and common web ports.Tools like Fail2ban or CrowdSec monitor logs for suspicious behavior and automatically block abusive IPs using firewall rules. Typical protections: Community and provider guides almost always pair local firewalls with Fail2ban‑style tools to reduce attack noise and slow down opportunistic attackers. 6. Secure Remote Access With VPNs and Cloudflare Zero Trust Where possible, keep your admin interfaces (SSH, control panels, internal tools) off the public internet entirely.Instead, expose them only through a VPN or a Zero Trust access layer. Two practical options: Zero Trust and VPN‑based controls are widely recommended as more modern alternatives to exposing admin surfaces directly with simple IP allow-lists. 7. Apply the Principle of Least Privilege to Users and Services Most production incidents are either configuration mistakes or misuse of powerful credentials, not just exotic exploits.Applying least privilege reduces the blast radius when something inevitably goes wrong. On a single server: In the cloud control plane: Security references consistently emphasise least privilege and regular access reviews as critical “day one” practices for securing new servers. 8. Encrypt Data in Transit and at Rest Even a well‑hardened server leaks value if traffic or sensitive data is exposed in plain text.Strong encryption—in transit and at rest—is a non‑negotiable baseline today. Key actions: Best‑practice server guides repeatedly call out TLS and encryption at rest as essential when storing customer data or handling payments, logins, or internal secrets. 9. Monitor Logs, Deploy IDS/IPS, and Set Up Alerts If you never look at logs, you’ll likely only discover a compromise once it impacts uptime or customers.Basic monitoring plus intrusion detection dramatically improves your chances of catching issues early. Start with: 10. Do Not Forget Backups and Recovery Testing Security is not just about keeping attackers out, it is also about being able to recover quickly when something breaks or data is lost.Ransomware, accidental rm -rf, application data corruption or a compromised admin account can all be mitigated by robust, tested backups. Follow these principles: Security and hosting guides consistently treat backups as part of the security story, not a separate operational concern. If you are just starting with your first server, focus on getting the basics right instead of chasing every advanced hardening trick.A server that is updated, locked down via SSH, protected with both host and cloud firewalls, behind a VPN or Zero Trust layer, monitored, and backed up is already far ahead of most internet‑connected machines. From there, you can iterate: add container isolation, mandatory access control (SELinux/AppArmor), secret management (Vault, AWS Secrets Manager), and more as your infrastructure grows.The important part is to treat server security as an ongoing practice, not a one‑time checklist you complete and forget. Cloudwork is here to help you design, automate, and harden your infrastructure from day one.