Think of EC2 as your personal engine room in the cloud. It’s where ideas stop being just code on your laptop and become running workloads that power your architecture.
With EC2 you don’t just “launch servers”—you decide how powerful they are, where they live, and how they connect. In a private subnet, your instances are shielded from the internet, accessible only through secure channels like bastion hosts or AWS Systems Manager Session Manager.
Whether you’re running sensitive databases, internal services, or backend applications, EC2 private instances give you the control and protection to keep your workloads humming quietly behind the scenes.
📌 Public Subnet? Your app is visible to the world.
📌 Private Subnet? Your workloads stay protected, humming quietly behind the scenes.
Stage 1: Define Tags and Select OS
Step 1: In the Name and tags section, define:
-Name: VM-Project-Private
-Project: demo
📌 Tags help with auditing, cost tracking, and resource organization.
Step 2: In Application and OS Images, select:
- Amazon Linux 2023 Kernel 6.1 AMI
- Architecture: 64-bit (x86)
📌 Amazon Linux is optimized for AWS, with extended support and solid performance.
Stage 2: Instance Type and Key Pair
Step 3: Choose the instance type:
t3.micro → 2 vCPUs, 1 GiB RAM, Free Tier eligible
📌 Ideal for testing or lightweight workloads.
Step 4: Select an existing PEM key pair:
-Name: vm-demo-project
-Type: RSA
-Format: .pem (compatible with OpenSSH)
📌 This existing key pair will be used for SSH access if needed. Make sure you keep the .pem file stored securely.
Stage 3: Network and Security Configuration (Private)
Step 5: Select your custom VPC:
-VPC ID: VPC-Demo-Project
-Subnet: subnet-b-private-project (20.0.4.0/24, zone us-east-1a)
-Public IP: Disabled
📌 The instance will be placed in a private subnet, without direct internet access.
Step 6: Configure the Security Group:
Name: demo-project-private
Rule: Nothing. Because it allow SSH only from the bastion host or via AWS Systems Manager Session.
📌 Secure access is restricted. No direct exposure to the internet.
Stage 4: Storage Configuration
Step 7: Configure the root volume:
-Type: gp3
-Size: 8 GiB
-IOPS: 3000
-Encryption: Enabled (recommended for private workloads)
📌 gp3 offers solid performance and is Free Tier eligible.
Stage 5: IAM Role and Advanced Settings
Step 8: Assign an IAM role:
- AmazonSSMRoleForInstancesQuickSetup
📌 Allows secure access via AWS Systems Manager (SSM) without SSH keys or public IPs.
Step 9: Configure advanced settings:
- Hostname: IP-based
- DNS: IPv4 enabled
- Metadata: version V2 with token required
📌 Modern and secure configuration for automated management.
Stage 6: Review and Launch
Step 10: In the summary screen, review:
- AMI: Amazon Linux 2023
- Instance type: t3.micro
- Storage: 8 GiB
- Security Group: private access only
📌 Everything is ready to launch the instance.
Step 11: Once checks are complete.
📌 The instance enters “initializing” state, which typically lasts 30 seconds to 2 minutes.
-Confirm the instance is in Running state.
-Upon review, I noticed that the public IP is not enabled since the instance is running in private mode
Step 12. Connect via Session Manager
- Click Connect.
- In the connection options, select Session Manager.
- Click Connect again.
📌 No public IP or SSH key is required — the connection is tunneled securely through SSM.
Step 13: Confirm the Session
-A terminal window opens directly in the AWS Console.
-By default, you are logged in as the default system user (e.g., ssm-user).
-If needed, you can elevate privileges:
sudo su
-Now you are operating as root inside the private EC2 instance.
Advantages of SSM over Public SSH:
-No public IP exposure → Reduces attack surface.
-No need to manage SSH keys → Access is controlled via IAM policies.
-Auditing and logging → All sessions can be logged in CloudWatch or S3.
-Granular permissions → Restrict who can start sessions.
🧠 Final Reflection
Using Session Manager is the recommended way to connect to private EC2 instances. It eliminates the need for bastion hosts or open SSH ports, while providing secure, auditable, and role‑based access.
👉 This complements your earlier tutorial on public EC2 access. Now you can publish this as the “EC2 Private” continuation post, showing best practices for secure architectures.
Top comments (0)