AWS Elastic Beanstalk Backend Security Group and Key Pair

A practical walkthrough of securing backend services for a Beanstalk-based application by using a dedicated backend security group, self-referencing rules, and a key pair for troubleshooting.

In this part of the vProfile re-architecture project, the main focus was preparing the backend access rules before deploying the application. The application will run on Elastic Beanstalk, while backend services like RDS, Amazon MQ, and ElastiCache should stay private inside AWS.

The goal was simple: let trusted services talk to each other securely without exposing databases, caches, or message brokers to the public internet.

Architecture idea: User → Load Balancer → Beanstalk EC2 instances → Backend services like RDS, MQ, and ElastiCache.

Why Create a Separate Backend Security Group?

Instead of managing separate network rules on every backend service, the instructor created one dedicated backend security group. That group can later be attached to all backend resources, keeping the design cleaner and easier to manage.

At this stage, the backend services included:

  • Amazon RDS for the database
  • Amazon MQ for messaging
  • ElastiCache for caching

These services may need to communicate internally, but they should not be publicly reachable. A dedicated security group makes that possible.

Step 1: Create the Security Group in EC2

The instructor opened the AWS console in the North Virginia region, went to EC2, and created a new security group. Even though the resources are RDS, MQ, and ElastiCache, security groups are managed at the VPC level and are often configured from the EC2 section.

  1. Open AWS Management Console
  2. Go to EC2
  3. Open Security Groups
  4. Click Create security group

The security group was named something like:

vprofile-rearch-backend-sg

This naming keeps it clear that the group belongs to the re-architected vProfile backend setup.

Important: no inbound rule was added during the initial creation. The group was created first, then edited after AWS assigned it an ID.

Why No Rule at First?

The instructor wanted to allow traffic from the security group to itself. AWS needs the actual security group ID for that, and you only get that after the group exists.

So the sequence becomes:

  1. Create the security group
  2. Get its security group ID
  3. Edit inbound rules
  4. Add a rule that uses the same security group as the source

Step 2: Allow All Traffic Within the Same Group

After creation, the inbound rules were updated with a self-referencing rule like this:

Type: All Traffic Source: This same security group ID Description: Backend services internal communication

This means any resource using this backend security group can talk to another resource that also uses it.

If these resources all use the same SG:

  • RDS
  • Amazon MQ
  • ElastiCache

then they can communicate privately with each other.

Useful AWS pattern: instead of exposing ports to the internet, use security group references to allow only trusted internal communication.

What Does “Allow All Traffic Within Itself” Mean?

If a security group allows all traffic from itself, any AWS resource using that group can send traffic to another resource using the same group.

RDS → ElastiCache OK MQ → RDS OK App → RDS Not yet

At this point, only backend-to-backend communication is allowed. The application layer will be trusted later.

Step 3: Save the Rule

Once the rule was added and saved, the backend security group was ready for this stage. No public inbound rule like 0.0.0.0/0 was added, because backend resources should stay private.

Bad practice to avoid: do not open databases, caches, or message brokers publicly unless there is a very specific and well-secured reason.

Step 4: Beanstalk Will Be Added Later

The instructor explained that after Elastic Beanstalk creates the environment, AWS will also create security groups for the Beanstalk EC2 instances and the load balancer.

That usually leads to this relationship:

  • Load balancer security group sends traffic to app instances
  • Beanstalk EC2 instances receive traffic from the load balancer

But one more backend rule will still be needed later:

Allow traffic from Beanstalk EC2 security group → backend security group

That future rule is what allows the application layer to connect to RDS, MQ, and ElastiCache.

Simple Traffic Flow

The full flow is easy to picture like this:

  1. User sends a request
  2. Load balancer receives it
  3. Load balancer forwards it to Beanstalk EC2
  4. The app needs data, cache, or messaging support
  5. The app connects to RDS, MQ, or ElastiCache

So Beanstalk must eventually be trusted by the backend security group, but that trust comes only after Beanstalk exists.

Step 5: Create a Key Pair for Troubleshooting

After the security group setup, the instructor created a key pair. This is used for SSH access to the EC2 instances launched by Elastic Beanstalk.

  1. Go to EC2
  2. Open Key Pairs
  3. Click Create key pair
  4. Name it something like vprofile-rearch-key
  5. Download the private key and store it safely

The key pair is not required for normal Beanstalk operation, but it becomes very useful when troubleshooting.

Why Is the Key Pair Useful?

SSH access helps when deployment issues happen, for example:

  • The app does not start
  • Environment variables are wrong
  • A required service is unreachable
  • Logs contain unexpected errors
  • A package or process failed during deployment

After logging in, troubleshooting might include commands like:

cat /var/log/eb-engine.log cat /var/log/web.stdout.log ps aux df -h env
Real-world takeaway: in managed platforms like Elastic Beanstalk, you may not need SSH every day, but when something breaks, access to the instance can save a lot of time.

Security Thinking Behind This Lesson

This part of the project is really about network isolation and controlled trust.

Good cloud architecture separates resources by role:

  • Public layer → load balancer
  • Application layer → EC2 / Beanstalk
  • Private backend layer → database, cache, broker

Each layer should only talk to the layers it actually needs. That reduces risk and makes the overall design easier to secure.

What I Learned from This Lecture

  • Security groups are a major part of AWS architecture design
  • Backend services should usually stay in a private backend SG
  • Self-referencing SG rules allow controlled internal communication
  • Elastic Beanstalk creates security groups for app and load balancer layers
  • The backend SG must later trust the app SG
  • Key pairs help with SSH-based troubleshooting

My Practical Takeaway

This lesson made security groups feel much more important than just another AWS setting. They are a design tool that controls which part of the application can talk to which other part.

Instead of thinking only in terms of servers and services, I now see the architecture more clearly in terms of who can access what, which services remain private, and how trust is added in stages.

Conclusion

This was a small setup step, but it matters a lot for the full architecture. First the backend security group was created, then a self-referencing inbound rule was added so backend services could communicate internally, and finally a key pair was created for possible troubleshooting of the Beanstalk EC2 instances.

In the next stage of the project, backend services can be launched with this security group and the Beanstalk application layer can later be allowed to connect to them securely.

← Back to Blogs