Hands-On with Amazon EC2: Launching, Securing, Monitoring and Scaling a Cloud Server
Cloud computing becomes much easier to understand when you move beyond reading about it and actually deploy something.
Cloud computing becomes much easier to understand when you move beyond reading about it and actually deploy something.
Recently, I completed a hands-on AWS lab focused on Amazon Elastic Compute Cloud (Amazon EC2). The lab gave me an opportunity to work with a cloud-based virtual server and go through several stages of its lifecycle—from launching and configuring the instance to monitoring, securing, resizing, and eventually terminating it.
The experience helped me connect several cloud computing concepts that I had previously encountered theoretically, particularly compute resources, networking, security groups, storage, monitoring, automation, scalability, and resource lifecycle management.
According to the lab, Amazon EC2 provides resizable compute capacity in the cloud and allows users to obtain and configure computing resources with minimal friction.
Here is what I learned from the hands-on experience.
Setting Up the EC2 Instance
The first stage was to launch an EC2 instance.
For the exercise, I used an Amazon Linux 2023 AMI and selected a t3.micro instance type. The lab notes that the t3.micro instance provides 2 virtual CPUs and 1 GiB of memory.
I also placed the instance inside the provided Lab VPC and Public Subnet 1.
This part helped reinforce an important concept: an EC2 instance doesn't exist in isolation. It operates within a networking environment, and the VPC, subnet, and security group determine how that instance communicates with other resources and external networks.
I also enabled termination protection during the launch process. This was particularly useful later in the lab when I tested what happens when someone attempts to terminate a protected instance.
Automating the Web Server with User Data
One of the most interesting parts of the lab was using EC2 User Data.
Instead of manually logging into the server and installing a web server, I provided a shell script during instance creation.
The script installed Apache, enabled the service, started it, and created a simple HTML page:
1
2
3
4
5
dnf -y install httpd
systemctl enable httpd
systemctl start httpd
echo '<html><h1>Hello From Your Web Server!</h1></html>' > /var/www/html/index.html
The lab explains that User Data can be used to perform common automated configuration tasks and run scripts when an instance starts.
This was a valuable demonstration of automation in cloud infrastructure.
Rather than manually repeating the same configuration steps every time a server is deployed, configuration can be provided as code and executed automatically.
That concept becomes increasingly important when managing multiple servers or larger cloud environments.
Monitoring the Instance
After launching the instance, I monitored its status through the EC2 console.
The instance went through the normal launch process before reaching the Running state, with the required status checks passing.
I then explored several monitoring and troubleshooting features available for EC2.
These included:
- Instance status checks
- CloudWatch monitoring metrics
- System logs
- Instance screenshots
The system log was particularly useful because it provided visibility into the instance's startup process. I could see evidence that the Apache package had been installed through the User Data script.
The lab also demonstrated how an instance screenshot can provide useful visibility when an instance cannot be reached through normal remote access methods.
This reinforced something important about cloud infrastructure:
Deploying a server is only the beginning. Monitoring its health and understanding how to troubleshoot it are equally important.
Understanding Security Groups
The networking and security portion of the lab was one of the most useful parts for me.
After launching the web server, I attempted to access it using its public IPv4 address.
However, the web page was initially inaccessible.
The reason was that the security group did not permit inbound HTTP traffic on port 80.
This was a practical demonstration of how an AWS security group works as a virtual firewall.
I updated the inbound rules to allow HTTP traffic and then refreshed the web page.
After the rule was added, the browser displayed:
"Hello From Your Web Server!"
This simple exercise made the relationship between application availability and network security controls much clearer.
A web server can be running correctly, but if the network rules do not allow the required traffic, users still won't be able to reach it.
A Security Lesson
The lab used an HTTP rule with Anywhere-IPv4 as the source, which allows traffic from
0.0.0.0/0.The lab explicitly notes that using "Anywhere" is not recommended as a best practice for production workloads.
This is an important security consideration.
In a real production environment, network access should be restricted according to the application's requirements rather than simply exposing services broadly to the internet.
Scaling the EC2 Instance
The next stage was resizing the infrastructure.
Initially, the instance was running as a t3.micro. I stopped the instance and changed its instance type to t3.small.
The lab explains that resizing an instance requires stopping it first. After changing the instance type, the instance could be started again with the new configuration.
I also modified the attached EBS volume.
The original root volume was 8 GiB, and I increased it to 10 GiB.
This demonstrated two different dimensions of scaling:
- Compute scaling — increasing the instance resources.
- Storage scaling — increasing the disk capacity.
This was a useful reminder that infrastructure requirements can change as workloads grow.
A cloud environment provides flexibility to adjust resources according to changing requirements rather than being permanently tied to a fixed physical server configuration.
Testing Termination Protection
The final practical exercise involved termination protection.
Because I had enabled termination protection when launching the instance, I attempted to terminate it while the protection was still active.
The termination attempt failed with an error indicating that the instance's termination protection needed to be disabled first.
I then disabled termination protection and terminated the instance successfully.
This demonstrated a simple but important operational safeguard.
In cloud environments, destructive actions can sometimes happen accidentally. Having additional controls around resource deletion can help reduce the risk of unintentionally removing important infrastructure.
Of course, termination protection is not a substitute for proper backups, infrastructure-as-code practices, or broader operational controls. But the lab provided a straightforward demonstration of how one layer of protection works.
A complete lifecycle includes:
Provision → Configure → Monitor → Scale → Secure → Decommission
The lab allowed me to experience each of these stages in a controlled environment.
This hands-on EC2 lab gave me a better understanding of what happens behind the scenes when deploying a server in the cloud.
Before doing the practical exercise, concepts such as AMI, instance types, VPCs, security groups, EBS, User Data, monitoring, scaling, and termination protection could easily feel like separate AWS services and features.
Working through the environment helped me see how they fit together.
I launched a Linux-based web server, automated its initial configuration, monitored its health, configured network access, tested the web application, increased its compute and storage capacity, and finally tested its protection against accidental termination before decommissioning the instance.
For me, the biggest takeaway is that cloud computing is not just about creating resources. It is about designing, securing, monitoring, scaling, and managing those resources throughout their lifecycle.
This lab was another practical step in my journey toward building stronger cloud and cybersecurity skills, and it has given me a better foundation for exploring more advanced AWS services and cloud security concepts.
Check out the complete walkthrough on my Github account :
https://github.com/devmuhakeem/Amazon-EC2/tree/main
Hands-on experience continues to be one of the best ways to turn cloud concepts into practical skills.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article