Launching Your First EC2 Instance from the AWS Console

I walked through launching an EC2 instance entirely from the AWS Console: naming it, picking an AMI and instance type, bootstrapping it with a user data script that installs Apache, and then debugging why the page wouldn't load on the first try. Here's the full path, shortcuts and all.

Starting from the EC2 Console

For this walkthrough, I stuck to the AWS Management Console instead of the CLI. There's a version of this same task using the AWS CLI coming in the next lesson, and it's worth doing both — the console gives you a visual model of what's actually happening, and the CLI teaches you how to automate it later. But for a first pass, the console is the right place to build intuition.

I opened the EC2 panel and started a new instance, naming it "my web server." Naming your instances sounds trivial, but once you have more than one or two running, a descriptive name is the difference between confidently terminating the right resource and sweating over which one you meant to click.

For the AMI, I went with Amazon Linux, and for the instance type, T3 micro. Both of these are commonly listed as Free Tier eligible, which is why they're a natural default for a tutorial like this — you can follow along without worrying about a surprise bill. That said, AWS changes its Free Tier terms and eligible instance types over time, so before you launch anything in your own account, it's worth double-checking current Free Tier eligibility against AWS's pricing page rather than assuming last year's rules still apply.

Skipping the key pair — a shortcut, not a best practice

Here's where I made a deliberate simplification: I proceeded without generating a key pair. Normally, a key pair is how you'd SSH into an instance securely, and AWS will nag you about it if you skip it. I skipped it anyway, and I want to be upfront about why: it's purely to keep this tutorial simple. There's no SSH access happening in this lesson, so there was nothing to lose by omitting it here.

But I don't want that choice to travel with you into a real project. If you're standing up an instance you intend to actually manage — install packages on later, debug, poke around in — you want a key pair from the start. Skipping it is a fine move for a five-minute demo instance you're going to delete anyway; it's not a pattern to carry into anything you plan to keep running.

From there I moved into the advanced configuration options, which is also where I want to flag a general philosophy I follow: keep storage and files as modular, separate entities from the instance itself wherever you can. I didn't attach an additional file system at this stage, because for a stateless little Apache demo, the instance's own root volume is plenty. But the broader habit — decoupling your data from the compute that happens to be running it this week — pays off the moment you need to resize, replace, or recreate an instance without losing anything.

Bootstrapping the server with a user data script

The part that actually makes this instance useful is the user data field. Whatever you paste in there runs automatically when the instance boots — no manual SSH session required, no clicking around after the fact. I pasted in a small bash script that does three things: installs the Apache (HTTPD) web server, enables and starts it, and writes a simple index.html file with a "Hello from EC2" message.

I'll be honest that I didn't walk through every line of that script in detail — the point of this lesson is the console workflow around launching an instance, not a bash scripting deep dive. But I do want to flag that explicitly: if you're copying a user data script like this into your own account, take a minute to actually read what it's doing before you run it. This one is simple and safe, but that's a habit worth having regardless of the script.

User data scripts like this are genuinely one of the more useful patterns in EC2, because they turn "launch a blank server and configure it by hand" into "launch a server that configures itself." That's the difference between a one-off instance and something you could reproduce, or eventually template into infrastructure-as-code.

The first page load — and why it failed

Once the instance was up and running, I grabbed its public IPv4 address from the instance details panel and tried loading it in a browser. Nothing. The page just hung and eventually failed to load.

This wasn't staged — it's a genuinely common first-timer moment, and I think it's more useful to show it happening than to edit it out. The instance was running, Apache was almost certainly running too since the user data script had already executed, but the browser still couldn't reach it. When that happens, the instinct to blame the server itself is usually wrong. The far more common culprit is the network path in front of it, and specifically the security group.

Fixing the security group

Sure enough, that's exactly what was going on. The security group attached to this instance only had an inbound rule allowing SSH (port 22) — the AWS default when you launch an instance without specifying anything else. There was no rule allowing HTTP traffic on port 80, so even though Apache was serving the page just fine internally, nothing outside the instance could reach it.

I went into the instance's security group settings and added an inbound rule allowing HTTP traffic. For simplicity, I opened that rule to all CIDR blocks — effectively, the entire internet. That's a completely standard choice for a public-facing web server; you generally want anyone to be able to load your homepage. But I'll note that I didn't discuss narrowing that scope further, and it's worth knowing that this same "allow all CIDR blocks" pattern deserves more thought for anything other than a genuinely public HTTP/HTTPS listener. For SSH, database ports, or admin interfaces, you'd want to scope inbound rules to specific IP ranges instead.

It's also worth pointing out that this fix could have been done at instance launch, in the same step where I configured the AMI and instance type — there's usually a security group configuration screen right there. I chose to hit the problem live instead, mostly because walking through the failure and the fix teaches the underlying concept better than getting it right on the first try would have. Security groups aren't a formality you configure once and forget; they're the actual gate that decides what can reach your instance, and this is exactly the kind of thing that trips people up on their first EC2 launch.

Confirming it worked

With the HTTP rule in place, I reloaded the same public IP address, and this time the page came right up: "Hello from EC2." Small payoff, but a real one — it confirms the whole chain worked end to end. The instance launched, the user data script ran on boot and stood up Apache, the index.html file got written where Apache expected it, and once the security group actually allowed the traffic through, the page was reachable from a browser outside AWS entirely.

This instance was intentionally short-lived — built for this walkthrough and torn down shortly after — which is part of why some of the shortcuts here (no key pair, wide-open HTTP rule) were reasonable trade-offs rather than mistakes. It's also set up as the foundation for a follow-up lesson that revisits this same server, this time through the AWS CLI instead of the console, so if you're following the series, this instance isn't quite done yet.

Conclusion

If you're following along, the best next step is to reproduce this in your own AWS account — launch an Amazon Linux instance, paste in a similar user data script, and see the same "page won't load" moment firsthand before you fix it. Debugging that failure yourself is what makes security groups click in a way that just reading about them never quite does. Just remember to check current Free Tier terms before you launch, and to tighten up the key pair and inbound rule choices once you're working outside of a demo.