AWS EC2 for Beginners: Launch and Secure Your First Instance (2026 Guide)

August 07, 2026 Khimananda Oli 8 min read Database

By Khimananda Oli | Last reviewed: August 2026

The AWS console has hundreds of services, and the first time you open EC2 the wizard throws AMIs, instance types, key pairs, and security groups at you before you have launched anything. This guide on AWS EC2 for beginners cuts that noise down to the decisions that matter: pick the right image and size, create a key pair you will not lock yourself out with, open only the ports you need, connect over SSH, pin a stable address with an Elastic IP, and harden the box before it faces the internet. If you would rather have the whole stack built and secured for you, the cloud and DevOps deployment services cover exactly this.

Quick answer: To launch your first AWS EC2 instance, choose an Ubuntu AMI and a small instance type like t3.micro, create and download a key pair, attach a security group that allows SSH only from your IP plus ports 80 and 443, launch, then connect with ssh -i key.pem ubuntu@your-ip and harden it.

Your first EC2 instance in context: it runs inside a VPC behind a security group, you unlock SSH with a key pair, and an EBS volume holds the root disk.

What do you need before launching your first EC2 instance?

EC2 (Elastic Compute Cloud) is a virtual server you rent by the second. Before you click Launch, it helps to know the four building blocks the wizard asks about, because each one is a separate decision:

AMI (Amazon Machine Image) — the operating system template the instance boots from. For a first server, pick Ubuntu Server 24.04 LTS; it is free-tier eligible, well documented, and long-term supported.
Instance type — the CPU and memory size. A t3.micro (2 vCPU, 1 GB) is a fine starting point and is covered by the free tier in most regions; resize later without rebuilding.
Key pair — the SSH credential. AWS keeps the public key and gives you the private .pem file once. Lose it and you lose SSH access to that instance.
Security group — a stateful firewall attached to the instance that decides which inbound ports are open.

You also want a region close to your users (for example ap-south-1 in Mumbai for a Nepal or South Asia audience) so latency stays low.

How do you create a key pair and launch the instance?

The key pair is where most beginners trip up, so create it first. In the console go to EC2 → Key Pairs → Create key pair, choose the ED25519 type and .pem format, and your browser downloads the private key once. You can also do the whole thing from the AWS CLI, which is worth learning early:

aws ec2 create-key-pair \
  --key-name my-first-key \
  --key-type ed25519 \
  --query 'KeyMaterial' \
  --output text > my-first-key.pem

chmod 400 my-first-key.pem

The chmod 400 matters — SSH refuses to use a key file that other users can read. Now launch an instance against that key, an Ubuntu AMI, and a security group (created in the next section). Using the CLI keeps the choices explicit:

aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/canonical/ubuntu/server/24.04/stable/current/amd64/hvm/ebs-gp3/ami-id \
  --instance-type t3.micro \
  --key-name my-first-key \
  --security-group-ids sg-0abc123def4567890 \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-first-server}]'

That resolve:ssm: path asks AWS for the latest official Ubuntu 24.04 AMI in your region, so you never paste a stale image ID. The block-device mapping gives the root EBS volume 20 GB of gp3 storage — more on EBS below.

How should you configure the security group for a new server?

A security group is the single most important control between your server and the internet. The rule that keeps beginners safe: open SSH (port 22) only to your own IP address, never to 0.0.0.0/0. Web ports can be open to everyone, because that is the point of a web server.

Inbound security group rules for a first EC2 instance: SSH is restricted to your own IP, HTTP and HTTPS are open to everyone, and every other port is denied by default.

Create the group and add exactly three inbound rules from the CLI (replace 203.0.113.10 with your public IP, which you can find at checkip.amazonaws.com):

SG_ID=$(aws ec2 create-security-group \
  --group-name my-first-sg \
  --description "First EC2 server" \
  --query 'GroupId' --output text)

aws ec2 authorize-security-group-ingress --group-id "$SG_ID" \
  --protocol tcp --port 22 --cidr 203.0.113.10/32

aws ec2 authorize-security-group-ingress --group-id "$SG_ID" \
  --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress --group-id "$SG_ID" \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Security groups are stateful and deny by default: you only list what to allow inbound, and matching return traffic is permitted automatically. There is no need to add outbound rules for normal use. If your home IP changes often, update the port-22 rule rather than widening it to the whole internet.

How do you SSH in and assign an Elastic IP?

Once the instance shows running, connect with the private key and the default Ubuntu username. The first login also confirms your security group and key pair are correct:

ssh -i my-first-key.pem [email protected]

There is a catch: a plain instance gets a public IP that changes every time you stop and start it. For anything you will point a domain at, allocate an Elastic IP — a static public address — and associate it with the instance so the address stays put:

EIP_ALLOC=$(aws ec2 allocate-address --query 'AllocationId' --output text)

aws ec2 associate-address \
  --instance-id i-0abc123def4567890 \
  --allocation-id "$EIP_ALLOC"

An Elastic IP is free while it is attached to a running instance, but AWS charges a small hourly fee for one that is allocated and left unused — so release any you no longer need. If you plan to put a real application here next, the guide to hosting a Laravel app on AWS EC2, RDS and S3 picks up right where this leaves off.

How do you secure a fresh EC2 instance?

A brand-new instance is reachable and unpatched, so harden it before installing anything else. These first steps apply to any Ubuntu server, and the initial Ubuntu server setup guide covers the same hardening in more depth for any VPS:

Patch immediately — sudo apt update && sudo apt upgrade -y closes known holes on first boot.
Create a non-root sudo user and stop working as the default account for day-to-day tasks.
Disable password authentication so only your key can log in.
Enable a host firewall with UFW as a second layer behind the security group.
Add Fail2ban to throttle brute-force SSH attempts.

sudo apt update && sudo apt upgrade -y

sudo adduser deploy
sudo usermod -aG sudo deploy
sudo rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' \
  /etc/ssh/sshd_config
sudo systemctl restart ssh

sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw --force enable

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Open a second SSH session as the new deploy user to confirm key login works before you close the original one — locking yourself out of a hardened box is a rite of passage worth skipping.

What is EBS, and what is the difference between stop and terminate?

Your instance's disk is an EBS (Elastic Block Store) volume — network-attached storage that lives independently of the instance's compute. That separation drives the two actions beginners most often confuse:

Stop — powers the instance off. Compute billing pauses, but the EBS volume is kept, so your data and installed software survive. You keep paying for the EBS storage (and any unattached Elastic IP). Start it again and everything is as you left it.
Terminate — permanently deletes the instance. By default the root EBS volume is deleted with it, so the data is gone unless you took a snapshot. This is irreversible.

For cost control, stop instances you are only using occasionally rather than leaving them running, and take an EBS snapshot before any risky change so you can restore. Snapshots are cheap incremental backups stored in S3 behind the scenes. Only terminate when you are certain you want the server and its disk gone for good.

The launch-to-serve checklist for your first EC2 instance: choose the image and size, create a key pair, set the security group, launch with an EBS root volume, attach an Elastic IP, SSH in, then harden and serve.

Conclusion

Launching your first AWS EC2 instance comes down to a short, repeatable checklist: pick an Ubuntu AMI and a t3.micro, create and protect a key pair, allow SSH only from your IP, attach an Elastic IP, then patch and harden before you serve any traffic. Understand EBS and the stop-versus-terminate distinction and you will avoid both surprise bills and accidental data loss. When you are ready to run a real application on this foundation, browse the AWS deployment case studies to see the pattern in production, or get in touch to have your EC2 environment built and secured for you.

Frequently Asked Questions

An EC2 instance is a virtual server you rent from AWS by the second. You choose an operating system image and a size, and AWS gives you a machine you can SSH into and run any software on, just like a physical server but created and destroyed on demand.

Ubuntu Server 24.04 LTS is the safest first choice. It is free-tier eligible, supported until 2029, and has the largest pool of tutorials and community answers, so almost any problem you hit is already documented online.

Start with a t3.micro (2 vCPU, 1 GB), which is free-tier eligible in most regions and enough for learning, a small site, or a test app. Because compute is separate from storage, you can resize to a larger type later without rebuilding the server.

A key pair is the SSH credential for your instance. AWS keeps the public key and gives you the private .pem file exactly once at creation. You need that private key to log in, so store it safely — if you lose it you cannot SSH into that instance again.

Use the private key and the AMI's default user, for example ssh -i my-key.pem ubuntu@your-public-ip. First run chmod 400 my-key.pem so SSH accepts the key file. The default username is ubuntu for Ubuntu AMIs and ec2-user for Amazon Linux.

The usual causes are a security group that does not allow port 22 from your IP, wrong key-file permissions (needs chmod 400), the wrong username, or using the instance's private IP instead of its public or Elastic IP. Check the security group rule first.

A security group is a stateful virtual firewall attached to your instance. It denies all inbound traffic by default and permits only the ports you explicitly allow. Return traffic for allowed connections is automatically permitted, so you rarely need to touch outbound rules.

No. Restrict port 22 to your own IP address (for example 203.0.113.10/32), never 0.0.0.0/0. Leaving SSH open to everyone invites constant brute-force attempts. Open only ports 80 and 443 to the public, because those are meant for web traffic.

An Elastic IP is a static public IPv4 address you can attach to an instance. A default instance's public IP changes on every stop and start, so use an Elastic IP whenever you point a domain at the server or need the address to stay constant.

An Elastic IP is free while attached to a running instance, but AWS charges a small hourly fee for one that is allocated but idle or attached to a stopped instance. As of 2026 AWS also bills for in-use public IPv4 addresses, so release any you no longer need.

EBS (Elastic Block Store) is network-attached disk storage for your instance. The root volume that holds the operating system is an EBS volume, and it exists independently of the compute, which is why your data can survive a stop or be captured in a snapshot.

Stopping powers the instance off but keeps its EBS volume and data, pausing compute charges so you can start it again later. Terminating permanently deletes the instance and, by default, its root EBS volume. Terminate is irreversible, so snapshot anything you might need first.

Stay on free-tier-eligible types, stop instances you are not actively using so compute billing pauses, delete unattached EBS volumes and idle Elastic IPs, and set a billing alarm in AWS Budgets. Snapshots and stopped-instance storage still cost a little, so clean up what you no longer need.

Patch it immediately with apt upgrade, create a non-root sudo user, disable SSH password authentication so only your key works, enable the UFW host firewall as a second layer, and add Fail2ban to block repeated failed logins. Do this before installing your application.

AWS offers a free tier that covers 750 hours per month of a t3.micro (or t2.micro in some regions) for the first 12 months, plus a small amount of EBS storage. Beyond those limits, or for larger types, you pay per second of use plus storage and data-transfer charges.