AWS Builder Center

Builder Center

Migrating Tenable Nessus from a Public subnet to a Private subnet in AWS using AMI

This article demonstrates how to securely migrate a Tenable Nessus deployment from a public subnet to a private subnet in AWS using an AMI-based approach. It covers re-registering the Nessus license, enabling secure access through AWS Systems Manager, and ensuring controlled outbound connectivity for plugin updates while eliminating direct internet exposure.

J.R. De Guzman

AWS Authorized Instructor (AAI) | Former Network Engineer | Cybsecurity Support Engineer

Introduction

In a previous article, I demonstrated how to install and securely access Tenable Nessus Professional on Amazon Linux 2023 using AWS Systems Manager:
https://builder.aws.com/content/3Az1em6D8CiwHy5KxJM9Pk24mig/installing-tenable-nessus-professional-on-amazon-linux-2023-in-aws-with-secure-remote-access 
While that setup provides secure access without exposing management ports, the instance was deployed in a public subnet. From a security perspective, it is more appropriate to run vulnerability scanners inside a private subnet, where they are not directly accessible from the internet.
Many Tenable customers deploy Nessus in cloud environments to assess internal workloads. In such cases, placing the scanner in a private subnet aligns better with security best practices by reducing unnecessary exposure while still allowing controlled access.
In this article, we migrate the existing Nessus installation to a private subnet using an Amazon Machine Image (AMI) and reconfigure access using AWS Systems Manager.

Architecture Overview

The diagram illustrates the migration of a Tenable Nessus deployment from a public subnet to a private subnet within an AWS environment, along with the associated access and networking components. The architecture is deployed inside a single AWS Region and VPC, spanning two Availability Zones. In the initial setup, an Amazon Linux 2023 EC2 instance running Nessus is placed in a public subnet. This instance is associated with an IAM role that enables AWS Systems Manager (SSM) access and is reachable for administrative purposes. To support outbound internet connectivity, a NAT Gateway is deployed in the public subnet and connected to an Internet Gateway. This allows instances in private subnets to access external services such as Nessus plugin updates without exposing them to inbound internet traffic. An Amazon Machine Image (AMI) is created from the original EC2 instance in the public subnet. This AMI is then used to launch a new EC2 instance in a private subnet located in a different Availability Zone. The new instance retains the Nessus installation and configuration from the original host. The private EC2 instance does not have a public IP address and is not directly accessible from the internet. Instead, access is performed securely using AWS Systems Manager Session Manager. From the local workstation, the user establishes port forwarding sessions to the instance for both: VNC access (port 5901) for graphical interface Nessus web interface (port 8834) for vulnerability management All traffic between the local machine and the EC2 instances is routed through AWS Systems Manager, eliminating the need to open inbound ports such as SSH or HTTPS. The route table associated with the private subnet directs outbound traffic to the NAT Gateway, enabling the instance to download Nessus plugins and updates while remaining isolated from direct internet exposure. Overall, the diagram highlights a secure architecture where: Nessus is migrated from a public to a private subnet using an AMI Administrative access is handled through Systems Manager No inbound internet access is required Outbound connectivity is controlled via NAT Gateway This design aligns with common AWS security best practices by reducing the attack surface while maintaining operational accessibility.
Lab Architecture

Prerequisites

Before proceeding, ensure:
  • Existing EC2 instance with Nessus installed (public subnet)
  • Private subnet configured
  • NAT Gateway deployed in a public subnet
  • Private route table configured:
    • 0.0.0.0/0 → NAT Gateway
  • IAM role attached to EC2:
    • AmazonSSMManagedInstanceCore

Step 1 - Create an AMI from the Existing Instance

To preserve the Nessus installation and configuration, create an AMI from the current instance.
Navigate to:
EC2 > Instances > Select instance > Actions > Image and templates > Create image
  • Provide a name:
1
Nessus-AMI
Leave the reboot option enabled to ensure a consistent image.
Wait until the AMI status becomes Available.

Step 2 - Launch a new EC2 instance in the private subnet

Go to EC2 > AMIs, select the AMI you created from the original Nessus instance, and launch a new instance from it.
Configure the instance using the same core settings as the original EC2 instance in the public subnet, except for the subnet placement.
Use the following configuration:
  • VPC: Select the same VPC as the original EC2 instance in the public subnet
  • Subnet: Select the private subnet
  • Auto-assign Public IP: Disabled
  • Security Group: Select the same security group used by the original EC2 instance in the public subnet, unless adjustments are required
  • IAM Profile: Select the same IAM profile used by the original EC2 instance in the public subnet
  • Instance Type: Use the same instance type as the original instance if capacity is available
  • Storage: Review and retain the storage configuration from the AMI
In some cases, you may encounter an error indicating that the selected instance type is not available in the chosen Availability Zone. For example:
1
We currently do not have sufficient capacity in the Availability Zone you requested.
If this occurs, you can resolve it by either:
  • Selecting a different Availability Zone within the same region (for example, switching from us-east-1a to us-east-1b), or
  • Choosing an alternative instance type with available capacity
After adjusting the configuration, proceed to launch the instance.

Step 3 - Connect using AWS Systems Manager

Since the instance is deployed in a private subnet and does not have a public IP address, you can connect to it using AWS Systems Manager.
In the AWS Management Console:
  • Go to EC2 > Instances
  • Select your newly launched EC2 instance
  • Click Connect
  • Choose the Session Manager tab
  • Click Connect
This will open a browser-based shell session to the instance without requiring SSH access or a key pair.

Step 4 - Verify Nessus installation

Confirm that Nessus is present:
1
ls /opt/nessus
Check service status:
1
sudo systemctl status nessusd
If the service is not running:
1
2
sudo systemctl start nessusd
sudo systemctl enable nessusd

Step 5 - Reset Nessus state

After migration, Nessus must be reset before re-registering the license.
1
2
sudo systemctl stop nessusd
sudo /opt/nessus/sbin/nessuscli fix --reset
This step:
  • Clears the plugin database
  • Removes existing registration
  • Prepares Nessus for a fresh activation

Step 6 - Reset Activation Code in Tenable

Log in to:
https://account.tenable.com/products/purchased 
Locate your Nessus Professional activation code:
  • Click the menu (⋯)
  • Select Reset Activation
  • Confirm the action
This releases the license from the previous instance.

Step 7 - Re-register Nessus

Register Nessus using your activation code:
1
sudo /opt/nessus/sbin/nessuscli fetch --register <ACTIVATION_CODE>

Step 8 - Start Nessus Service

1
sudo systemctl start nessusd

Step 9 – Access Nessus via AWS Systems Manager

From your local machine, start a port forwarding session:
1
2
3
4
aws ssm start-session \
--target INSTANCE_ID \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber=8834,localPortNumber=8834"
Then open your web browser and navigate to:
1
https://localhost:8834
Once the Nessus interface loads, log in using the same username and password that were configured during the initial Nessus setup on the original instance.
After logging in, Nessus will continue with plugin initialization if it has not yet completed.

Conclusion

In this article, we migrated a Tenable Nessus deployment from a public subnet to a private subnet using an AMI-based approach.
For many Tenable customers operating in AWS, this design provides a more secure way to run vulnerability scanning workloads while maintaining controlled access through AWS Systems Manager.
By combining private subnet deployment, NAT-based outbound access, and IAM-driven connectivity, this approach aligns with common cloud security practices and reduces unnecessary exposure of critical security tools.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article