How to Launch an AWS EC2 Instance for a Website
%203.png&w=256&q=75){kind=small}
Choose the Right AMI and Instance Type
Launching a server on AWS EC2 involves more decisions upfront than a simple VPS provider like DigitalOcean or Vultr, where you mostly just pick a plan and an OS. The first real decision in the EC2 console is the AMI (Amazon Machine Image) — the base operating system image your instance boots from. Pick "Ubuntu Server 22.04 LTS" from the Quick Start list, not Amazon Linux 2 or Amazon Linux 2023. Amazon Linux is AWS's own distribution and, while perfectly capable, it is not the OS CloudStick's stack is built and tested against — Nginx, Apache, PHP-FPM, and MariaDB all install and behave predictably on Ubuntu 22.04, which is why it is the safe default for anything you plan to run a website on.
For instance type, t3.small (2 vCPU, 2 GB RAM) is a reasonable floor for a low-traffic brochure site or small WordPress install, and t3.medium (2 vCPU, 4 GB RAM) gives you comfortable headroom for a WooCommerce store or anything expecting steadier traffic. Pair either with a gp3 EBS root volume of at least 20–30 GB — the default 8 GB volume on some AMIs fills up fast once you add a database, backups, and log files. You can resize the instance type or volume later without rebuilding the server, so it is fine to start modest and scale up once you see real traffic numbers.
Understand How Burstable "t" Instances Throttle CPU
The t3 family is "burstable" — each instance earns CPU credits over time at a fixed baseline rate and spends them faster than they accrue whenever CPU usage goes above that baseline. This is exactly what makes t3 instances cheap: AWS is betting most workloads are idle most of the time. The catch is that if your site gets a sustained spike — a traffic surge, a big cron job, a WordPress cache rebuild — and you burn through your accumulated credit balance faster than you earn it back, AWS throttles the CPU down to the baseline percentage no matter how much load is queued up. The site does not crash, it just gets slow, and the cause is easy to miss if you are not watching CPU credits specifically.
If you notice this happening, there are two ways out. Enable T3 Unlimited mode on the instance, which lets it burst past its credit balance and simply bills you a small additional charge for the surplus CPU used, rather than throttling — a good short-term fix while you confirm whether the spike was a one-off. If the higher load is sustained rather than occasional, the better long-term move is resizing to a non-burstable type in the m-series, such as m6i.large, which gives you full, consistent CPU performance at all times instead of a credit-based allowance.
Create a Key Pair for SSH Access
Unlike some VPS providers that let you set a root password at creation, EC2 uses key-based SSH authentication by default and expects you to supply or create a key pair during launch. In the "Key pair" section of the launch wizard, either pick an existing key pair or create a new one — AWS generates the private half and forces a one-time download of a .pem file, which is the only copy you will ever get. Store it somewhere safe immediately; there is no way to re-download it from the console later.
Before you can use it, the key file's permissions have to be locked down, or SSH will refuse to use it and print an "UNPROTECTED PRIVATE KEY FILE" warning.
Configure the Security Group Correctly
A Security Group is AWS's equivalent of a firewall, attached to the instance rather than the OS, and by default it only allows outbound traffic — nothing inbound is open until you add rules explicitly. This trips up a lot of people coming from providers that ship with a more permissive default: on EC2, if you launch without adding rules for ports 22, 80, and 443, you will not even be able to SSH in, let alone serve a website.
Open 80 and 443 to the world since that is the point of running a website, but scope the SSH rule down to your own IP address rather than leaving it open to everyone — a wide-open port 22 is one of the most commonly scanned and attacked ports on the internet. You can edit these rules at any time after launch without restarting the instance, so it is easy to tighten or loosen access later as your setup changes.
Launch the Instance and Connect via SSH
With the AMI, instance type, key pair, and Security Group all set, click Launch Instance and wait for the instance state to show "Running" and its status checks to read 2/2 passed — usually under a minute. Grab the public IPv4 address from the instance details page, then connect over SSH using the key pair you downloaded earlier.
The default login user on the Ubuntu AMI is ubuntu, not root — this is a common stumbling point for anyone used to DigitalOcean or a self-managed VPS, where root login is often enabled out of the box. Amazon Linux AMIs use ec2-user instead, which is one more reason to be deliberate about which AMI you picked in the first step. The ubuntu user has full sudo access without a password prompt, so it is functionally equivalent to root for anything you need to install or configure.
If SSH hangs instead of connecting, check the Security Group rule for port 22 first — a hang almost always means the port is not open to your current IP, whereas a "Permission denied (publickey)" error means either the wrong username was used or the .pem file permissions were not set to 400.
Attach an Elastic IP So Your Address Doesn't Change
A regular EC2 public IP is only guaranteed for as long as the instance keeps running — stop it and start it again, even without rebooting, and AWS hands out a new one. That silently breaks your DNS A records, any SSH scripts pointing at the old IP, and the Security Group rule you scoped to a specific address if it referenced the instance rather than a fixed IP. An Elastic IP fixes this: it is a static, account-owned address you allocate once and associate with the instance, and it stays the same across stops, starts, and even instance replacements.
In the EC2 console, go to Elastic IPs, allocate a new address, then associate it with your running instance. It is free while it is attached to a running instance, but AWS does charge a small hourly fee if you allocate one and leave it unattached, so only grab one when you are ready to use it. Point your domain's DNS A record at this address, and it will not need to change again for the life of the server.
Connect the Instance to CloudStick
At this point you have a running Ubuntu server with a fixed IP and a working SSH connection — but it is still just a bare EC2 instance, with none of Nginx, PHP, MariaDB, or a firewall installed. AWS is a supported provider inside CloudStick, so instead of installing and hardening that stack by hand, add the server in the CloudStick dashboard and use Direct Install with the same Elastic IP and SSH key pair you already have. CloudStick connects over SSH and provisions Nginx 1.24, Apache 2.4.53 for PHP on port 81, PHP-FPM, MariaDB 10.6, Redis, and the CSF firewall automatically, matching the exact stack this guide assumed you would end up with anyway.
From that point forward, day-to-day site work — adding websites, issuing SSL certificates, switching PHP versions, scheduling backups, managing cron jobs — happens entirely from the CloudStick dashboard, so you rarely need to open the AWS console again once the instance is running. To recap the full path: pick the Ubuntu 22.04 LTS AMI and a t3.small or t3.medium instance type, create and secure a key pair, open ports 22, 80, and 443 in the Security Group, launch and connect over SSH as the ubuntu user, attach an Elastic IP, and finally connect the server to CloudStick to take over everything else from a single dashboard instead of the AWS console.
