I finally hosted my first-ever WordPress website on AWS! This feels like quite an achievement for a beginner who has just set out to conquer the vast sea of AWS services.
This isn’t my first time creating a WordPress website. In fact, I’ve built several before, but this is my first time hosting one on a cloud platform. I decided to deploy my website on an EC2 instance rather than use AWS-managed solutions like Lightsail or Elastic Beanstalk because I wanted more control over the underlying infrastructure and, more importantly, the opportunity to learn how everything works behind the scenes.
I went with the default Amazon Linux AMI and a t3.micro instance, hoping to keep costs within the AWS Free Tier for now. Eventually, I plan to experiment with Amazon EFS and load balancing, allowing multiple EC2 instances to share the same WordPress files while improving redundancy and availability.
Everything went smoothly at first. The EC2 instance launched successfully, and I was ready to connect to it via SSH. But when I attempted to establish a connection, I was greeted with a connection timeout error.
What could possibly be wrong?
I had selected the correct key pair and double-checked the public IPv4 address, yet the issue persisted. Frustrated, I took another look at the error message:
“connect to host … port 22: Connection timed out.”
Port 22! I forgot to allow inbound SSH traffic on port 22!
Now, some of you might be reading this and thinking, “What a rookie mistake!”
And you know what? I agree!
But it genuinely hadn’t crossed my mind that inbound traffic needed to be explicitly allowed through the instance’s security group. Coming from a background where I was accustomed to simply connecting to servers over SSH, this was a small but valuable lesson in how AWS handles network security.
Armed with this newfound knowledge, I headed straight to my EC2 instance’s security group settings and added an inbound SSH rule, restricting access to my public IP address instead of leaving port 22 open to the entire internet.
While I was there, I also added inbound rules for HTTP (port 80) and HTTPS (port 443) to allow visitors to access my website. Two birds, one security group!
At least now, if my blog isn’t getting any visitors, I know it’s not because I forgot to open the ports. My humor, on the other hand, is still under investigation.
Now comes the next challenge: resisting the temptation to get carried away with designing a world-class website. After all, I created this blog to learn AWS cloud engineering and document my journey, not to become a full-time web designer!
Lesson learned: Sometimes, the smallest configuration details carry the most weight.