Launching and Connecting to Your First AWS EC2 Instance

Launching an EC2 instance is one of those things that sounds intimidating until you've done it once. Here's exactly how I go from a blank AWS console to a running server I can SSH into — plus the one default setting that's worth pausing on before you click through it.

Starting from the console, not root

Before I touch anything in AWS, I make sure I'm logged in as a regular IAM user rather than the root account. It's a small habit, but it matters: root has unrestricted access to everything in the account, and there's no good reason to use it for day-to-day work like launching a test instance. A demo or dev user with appropriately scoped permissions is the safer default, and it's worth setting up once so you never have to think about it again.

From there, getting to EC2 is easy either way you go — I can type "EC2" into the search bar at the top of the console, or click through the services panel on the left. Both land me in the same place: the EC2 dashboard, and specifically the Instances panel, which is where all the action happens. If you've never opened this panel before, it'll be empty, which is exactly what we want to fix.

Naming the instance and choosing a size

Clicking "Launch instance" kicks off a flow that asks you for a handful of decisions up front. The first is just a name — I called mine "demo EC2 instance," nothing fancy, but naming things clearly matters more than it seems like it should once you have more than one instance running in an account.

Next comes the AMI, or Amazon Machine Image — essentially the operating system template your server boots from. I picked a standard 64-bit Amazon Linux image, which is a safe, well-supported default for this kind of exercise.

Then there's the instance type, which determines the CPU and memory you're renting. I went with a free-tier-eligible t3.micro. One thing worth flagging: the specific specs behind any instance type — how many vCPUs, how much memory — can shift as AWS updates its instance families, so I'd treat any number you read (including ones I might quote) as a starting point to confirm against AWS's current documentation rather than a fixed fact. What matters more for a first launch is just staying inside the free-tier-eligible options so you're not surprised by a bill later.

Worth noting for later: whatever default username AWS assigns to this AMI (for Amazon Linux, that's typically ec2-user) is the one you'll need when you connect over SSH. Easy to forget, annoying to rediscover, so I make a mental note of it now.

Creating a key pair

This is the step that trips people up if they haven't done it before, so it's worth slowing down for. EC2 doesn't use passwords for SSH access — it uses a public/private key pair. AWS holds onto the public key and associates it with your instance; you're responsible for keeping the private key safe on your own machine. Lose it, and you lose your only way in through that key.

I created a new RSA key pair and chose the .pem format, which is what you want if you're connecting from a Mac or Linux terminal. If you're on Windows and using PuTTY instead, you'd want the .ppk format instead. AWS immediately downloads the private key file to your computer — mine landed in Downloads — and that's the only copy you'll get. AWS doesn't retain it, so if it disappears, your only recourse is generating a new key pair and updating any instances that relied on the old one.

A couple of practical notes beyond just this one session: keep that .pem file somewhere more permanent than your Downloads folder once you're doing this for real, and think ahead about how you'd rotate or replace it if it were ever lost or exposed. The video doesn't walk through key rotation or long-term storage strategy, and neither will I here — just flagging it as a gap worth thinking through before you're relying on this key for anything beyond a quick demo.

Security group and storage — the part to slow down for

This is the step I'd genuinely encourage you to pause on rather than click through. A security group is essentially a firewall for your instance, and setting one up means deciding what traffic is allowed to reach it and from where.

To allow SSH access, the console defaults the source to "Anywhere" — 0.0.0.0/0, meaning literally any IP address on the internet. That default exists because it's the most permissive option, not because it's the recommended one. Leaving SSH open to the entire internet on a real, non-throwaway instance is a genuine security risk: it means every bot scanning for exposed port 22 will eventually find yours and start trying to log in. I changed the source to "My IP," which restricts SSH access to just my current IP address. It's a one-click change, but it's the difference between a server only I can reach and one anyone can probe.

If you're following along yourself, don't just trust that you remembered to change it — go back and actually look at the security group's inbound rules before you move on. It's an easy thing to skip past, especially if you're moving quickly through a setup flow, and it's exactly the kind of default that's fine to leave in a sandbox you'll delete in ten minutes but genuinely dangerous to leave in place on anything long-lived.

For storage, I left the default EBS (Elastic Block Storage) volume as-is — no need to add anything extra for a basic test instance like this one.

Launching and checking on it

With naming, the key pair, and the security group sorted, launching the instance itself is almost anticlimactic — one click, and AWS starts provisioning it. Back in the Instances panel, I can watch the state change to "running" fairly quickly, though the status checks underneath it take a little longer to finish initializing. That's normal; "running" and "status checks passed" are two different things, and it's worth letting both settle before you assume something's wrong if a connection attempt fails right away.

The other thing I grab from this screen is the public IPv4 address, since that's what I'll need in a moment to actually connect to the thing. It's listed right alongside the instance details, and it's specific to this particular instance — worth copying somewhere handy rather than re-finding it every time.

Connecting over SSH

This is the part that makes the whole exercise feel real — going from clicking buttons in a browser to actually being inside a running server. From a Mac terminal, the first thing I had to do was lock down the permissions on that downloaded key file with chmod 400. SSH will actually refuse to use a key file if its permissions are too open, since a world-readable private key defeats the point of having one, so this step isn't optional.

From there, the connection command follows a pattern: ssh -i /path/to/your-key.pem ec2-user@your-public-ip. The username matters here — it has to match whatever the AMI expects, which is why I noted it back when I picked the image. Get that wrong and you'll get an authentication failure that has nothing to do with your key.

The first time you connect to any new host, SSH will ask you to confirm you trust its fingerprint — a one-time prompt since your machine hasn't seen this server before. Say yes, and you're in.

Once connected, I ran a few basic commands just to confirm everything was working as expected — whoami to check the logged-in user, uptime to see how long the instance had been running, ls -la to look around the home directory. Nothing fancy, just enough to confirm I had a real, functioning shell on a real server rather than just a green checkmark in a browser tab.

Stop, reboot, or terminate — and why it matters for your bill

Once you're done poking around, what you do next actually matters, both for access and for cost. AWS bills for compute time while an instance is running, and leaving one up continuously adds up — a rough estimate for a small free-tier-type instance running 24/7 is somewhere around $7.50 a month, though that's a ballpark figure that depends on your region, the exact instance type, and AWS's current pricing, all of which shift over time. Worth checking against AWS's own pricing page rather than treating any fixed number as durable.

The three options for winding down an instance behave differently, and it's easy to mix them up. Stopping an instance pauses it without deleting it — you're not billed for compute while it's stopped, though storage charges may still apply, and when you start it again, its public IPv4 address can change unless you've attached an Elastic IP. Rebooting, by contrast, restarts the instance without releasing it, so the public IP stays the same — useful if you're troubleshooting something and don't want to lose your connection details. Terminating is permanent: the instance is deleted entirely, billing for it stops, and there's no getting it back.

One thing that genuinely surprised me: terminating doesn't pop up a real confirmation dialog beyond typing the instance's name into a field. That's a pretty thin guardrail for an irreversible action, so it's worth double-checking you've got the right instance selected before you commit. I terminated my demo instance once I was done, specifically so it wouldn't keep quietly accruing charges in the background.

Conclusion

If you haven't done this yet, the best way to make it click is to actually do it — spin up a free-tier instance in your own AWS account, walk through naming it, creating a key pair, and locking down the security group to your own IP before you SSH in. Just make sure you circle back and terminate it when you're done, so a ten-minute experiment doesn't turn into a line item on next month's bill.