Exploring AWS EC2: Instance Setup and Security Group Configuration

Hello Network!🌸

Recently, I dabbled in cloud computing through an interactive exercise at AltSchool Africa using an Infrastructure-as-a-Service (IaaS) platform.

IaaS provides access to scalable, cost-effective, and secure computing resources such as virtual machines, storage, networking, databases, and load balancers.

For this exercise, I explored Amazon Web Services (AWS) and worked with Elastic Compute Cloud (EC2), creating instances and security groups.

An instance is a virtual computer that runs in the cloud. EC2 allows users to have virtual servers for various applications, from small test environments to enterprise-level deployments.

A security group acts as a virtual firewall that controls inbound and outbound traffic to an instance based on defined rules.

Before I could start setting up my EC2 instance, I encountered an interesting feature—AWS partitions accounts.

My AWS Skill Builder account, which I use to access AWS learning materials, could not be used to log in to the AWS Management Console.

Instead, I had to create an AWS Identity and Access Management (IAM) account for this exercise.

AWS's partitioning feature enhances security by preventing unauthorized access, protecting data, controlling costs, and reducing accidental security risks by keeping infrastructure accounts separate from other accounts.

Now, to the exercise. The main goal was to create two EC2 instances—one allowing SSH access and the other denying it—to explore security configurations in cloud environments.

SSH (Secure Shell) is a network protocol that allows secure remote access and management of devices over an encrypted connection.

This exercise is useful for scenarios where administrators need controlled remote access to critical systems while keeping certain instances isolated for security purposes.

To achieve this, I created the instances, configured their instance types and Amazon Machine Image (AMI), generated key pairs in both .pem (Privacy-Enhanced Mail) and .ppk (PuTTY Private Key) formats, created security groups with specific inbound and outbound rules, assigned them to their respective instances, and accessed the instances via SSH clients.

The Amazon Machine Image (AMI) serves as a preconfigured blueprint for virtual machines, containing the necessary components such as the operating system and server configurations.

AWS provides both public and private AMIs, depending on the intended use. For this setup, I used the Amazon Linux 2 AMI, a publicly managed AMI by AWS.

The key pair, consisting of a public and private key, ensures secure access and authentication via SSH.

For the first security group, I:

• Allowed SSH in the inbound rule by selecting the SSH type, which is automatically set to TCP port 22.
• Restricted access to my IP address only for security purposes.
• Left the outbound rule as default to allow external access for updates and API requests.

For the second security group, I:

• Did not configure inbound or outbound rules, effectively blocking all connections, including SSH.

Upon launching the first instance, I noticed it was automatically assigned a “launch wizard” security group. This is a default security group AWS creates when an instance is launched. Since its rules interfered with my custom security group, I temporarily removed it and assigned my own security group.

To test the security configurations, I accessed the instances using SSH clients, including Git Bash and PuTTY.

Using Git Bash, I connected to the first instance with the .pem private key following the SSH commands provided in the AWS EC2 interface. Since no errors were generated, it confirmed that my private key was secure, and I could successfully connect.

When I attempted to connect to the second instance using its private key, the SSH connection timed out. This confirmed that the security group effectively blocked SSH access.

Testing access via PuTTY: Since PuTTY requires .ppk keys, I used PuTTYgen to convert the .pem file to .ppk format and set up a passphrase for added security. After loading the .ppk key, I successfully connected to the first instance, while the second instance remained inaccessible, verifying the security configurations.

After completing the exercise, I terminated the instances to prevent unnecessary resource consumption and avoid AWS charges.

Through this process, I learnt that SSH should only be allowed when necessary, such as for administrative access, troubleshooting, or secure remote management. Additionally, access should always be restricted to specific IP addresses or internal networks to reduce security risks.

Many thanks to Victor Akinode for his guidance on this setup. This experience has given me a deeper understanding of cloud security and infrastructure management.

Till next time,

Chinwendu.