DEV Community

Cover image for 🔒 AWS 102: Building Your Digital Bouncer - Creating an Essential Security Group
Hritik Raj
Hritik Raj

Posted on

🔒 AWS 102: Building Your Digital Bouncer - Creating an Essential Security Group

#aws #securitygroup #devops #100daysofcloud

AWS

🛡️ AWS Security Groups: The Virtual Firewall Every Server Needs

Hey Cloud Architects and DevOps Rookies! 👋

Welcome to Day 2 of the #100DaysOfCloud Challenge: Create Security Group! We’re continuing our journey of breaking down massive cloud migration tasks into digestible steps from the awesome folks at KodeKloud Engineer.

KodeKloud Engineer

If our last task was about the key to the server (the Key Pair), today's task is about the security guard standing in front of it: the AWS Security Group (SG)!

A Security Group acts as a virtual firewall for your EC2 instances to control incoming (inbound) and outgoing (outbound) traffic. No rules, no traffic! It's an absolutely non-negotiable part of cloud networking.

1. Introduction: Why Security Groups Are Your Best Friend 💡

Think of an AWS Security Group as an access control list that you can assign to one or more virtual servers (EC2 instances).

  • Stateful Filtering: If you allow traffic in (inbound), the Security Group automatically allows the response traffic out (outbound) without a specific rule. This is called "stateful" operation.
  • Security First: By default, a Security Group denies all inbound traffic. You must explicitly create rules for any traffic you want to allow. This is known as the "principle of least privilege."
  • Today's Mission: We need a Security Group named nautilus-sg to allow two critical types of access from anywhere on the internet (0.0.0.0/0):
    1. HTTP (Port 80): So the public can access our web application.
    2. SSH (Port 22): So developers and administrators can securely manage the servers.

Let's dive into the AWS Console and set up our fortress! 🏰

2. Step-by-Step Guide: Creating the Nautilus Security Group

We will use the AWS Management Console to create and configure our firewall rules.

Step 2.1: Navigate to the VPC Dashboard

Security Groups live within the VPC (Virtual Private Cloud) service.

  1. Log in to the AWS Console.

  2. In the AWS console search bar, type VPC and click on the first result to open the VPC Dashboard.

  3. In the left-hand navigation menu, scroll down and click on "Security Groups".

Step 2.2: Create the Security Group

  1. Click the orange "Create security group" button.

  2. Fill out the Basic details section with the required information:

    • Security group name: nautilus-sg
    • Description: Security group for Nautilus App Servers
    • VPC: Select your Default VPC. (This is usually labeled (default) and has a description like default VPC).

Step 2.3: Add the Inbound Rules

Now for the critical part: defining what traffic is allowed in.

Rule 1: Allow HTTP Access

  1. In the Inbound rules section, click "Add rule".

  2. Configure the first rule for web traffic:

    • Type: Select HTTP (This automatically sets the port to 80).
    • Source: Select Anywhere-IPv4 from the dropdown. This automatically fills the CIDR block with 0.0.0.0/0.

Rule 2: Allow SSH Access

  1. Click "Add rule" again to create a second rule.

  2. Configure the rule for administrative access:

    • Type: Select SSH (This automatically sets the port to 22).
    • Source: Select Anywhere-IPv4 from the dropdown. This automatically fills the CIDR block with 0.0.0.0/0.

Step 2.4: Finalize and Create

  1. Review your settings. You should have two inbound rules listed: Port 80 and Port 22, both open to 0.0.0.0/0. (The Outbound rules section defaults to allowing all traffic, which is fine for this task.)

  2. Click the "Create security group" button at the bottom right.

You have successfully created and configured the nautilus-sg firewall! This Security Group is now ready to be attached to your application servers. 🎉

3. Key Takeaways 📝

  • Default Deny: If you don't explicitly allow traffic in an Inbound rule, it is automatically blocked.
  • CIDR Block Magic: 0.0.0.0/0 means "the entire internet." Use this sparingly in real-world scenarios!
  • Security Group vs. NACL: Security Groups are instance-level (apply to a server) and stateful. NACLs (Network Access Control Lists) are subnet-level and stateless.

4. Common Mistakes to Avoid 🚫

  1. Forgetting SSH (Port 22): The most common mistake! If you don't allow SSH traffic, you won't be able to log in and manage your server after launching it.
  2. Using 0.0.0.0/0 for SSH: While required for this task, in a professional environment, you should restrict SSH access to only your company's public IP address (or range) for maximum security. Never open SSH to the world unless absolutely necessary.
  3. Attaching to the Wrong Instance: Always double-check that you assign the correct Security Group to the correct EC2 instance during launch or modification.

5. Conclusion + Call to Action! 🌟

You are now officially a gatekeeper of your cloud infrastructure! Mastering Security Groups is a massive leap forward in building robust, secure, and accessible cloud environments. Keep crushing the 100 Days of Cloud Challenge!

If you found this guide helpful, please:

  • 💬 Let’s connect on LinkedIn: Cloud, DevOps, consistency, and learning in public—let’s build together!
    👉 Hritik Raj

  • ⭐ Support my journey on GitHub: Follow my #100DaysOfCloud challenge with real AWS tasks and hands-on learning
    👉 GitHub – 100 Days of Cloud

Next up, we might even launch a server using the Key Pair and Security Group we just created! Happy fire-walling! 💻

Top comments (0)