I am trying to deploy Spring Boot Application with AWS Elastic Beanstalk. Instead of using default settings for the environment, I modified something under "VPC". After picking availability zone and one of the security groups for the VPC, I created the environment.
However when I looked at the instance detail after it is created, I noticed it is tied to two security groups. Other than the one I chose sg-98c031f3, it has another newly-generated security group sg-72b94919.
Why does it create two security groups for the environment when I selected only one group? Is there a way to remove one of them since one security group is enough to handle all the rules.
Elastic Beanstalk will always create and utilize one security group that gets attached to the EC2 instance. This group is managed by Elastic Beanstalk and it's primary purpose is to allow inbound connections from your load balancer.
(It also has a secondary purpose of allowing inbound SSH connections if you have selected a keypair for your EC2 instances)
Elastic Beanstalk allows you to select 0 or more additional security groups to attach to your EC2 instances. Note that you do not need to select any security groups if you don't want to. This is so that you can add additional inbound/outbound rules for your EC2 instances without needing to modify the EB-managed one.
Some reasons why you might want to add additional security groups:
To allow more inbound ports (for example, RDP)
To allow outbound network connections (for example, NTP)
To act as sources and targets for other security group rules (for example, allow connections from your selected security group into your RDS instances)
Related
i have a jupyter notebook on one ec2 instance that want to get the data from data service that is deployed on other ec2 instance. should i put ingress and egress rules for each other on both instances? I'm quite new on the field, so any explanations are appreciated! :)
Yes, you can create 2 different security groups and attach to each one.
You can allow inbound traffic from a particular security group, all instances that have the security group attached can send traffic to the instance on the port you specify.
Another important thing no notice is that security groups are stateful, when you set outbound rules the response traffic is allowed regardless of the inbound rules.
Security Group Outbound rules allow all traffic by default. Typically, you should not modify these settings.
The best way to configure you setup is:
Create a Jupyter-SG security group and associate it with your Jupyter EC2 instance. Add whatever rules you use to connect with the instance (eg SSH).
Create a Data-SG security group and associate it with your "Data Service" EC2 instance. Add a rule permitting inbound access on the desired port, with Source set to the Security Group ID of Jupyter-SG.
This tells the Data-SG security group to permit inbound access from the Jupyter instance (or, more accurately, from any instance that is associated with the Jupyter-SG security group).
I should start by saying that this is only me playing with AWS, which is why there is nothing about configuring VPC and subnets.
I'd like to launch 2 EC2 instances with an Apache server inside through a Scaling Group. I'd also like these instances get registered with an ELB and be only reachable through the ELB (so no direct access to instances). I associated ELB with both VPC's default Security Group and a custom one that allows inbound requests from my IP via part 80. On the other hand, I configured a Launch Configuration (as part of creating the Scaling Group) that associates instances with only VPC's default security group.
Problems
1- ELB can't reach instances and fails health check. If I create another Launch Configuration that associate instances with both default and my custom security groups, ELB can then reach instances. Why? The custom security group has only inbound rules from my IP.
2- Even if I change the instances' network configuration directly and associate the custom Security Group, it makes no difference. I have to recreate the Launch Configuration and Scaling Group with new configuration so that when created, the the new association gets propagated to instances. Is this an expected behaviour? Why wouldn't AWS console then disable the options to edit instance's config if they're launched through Scaling Groups.
I want to launch a single ec2 instance. The challenge that I am facing is I need to configure security group for this instance and I want only the instances coming from an Auto scale group to be allowed to access this. How do I set the inbound in such a case, since the instances coming from an Auto Scale will vary?
Security groups can refer to each other.
For example, if you had a load Balancer and an Auto Scaling group of Amazon EC2 instances, you would need to create two security groups:
A Load Balancer security group (let's call it LB-SG)
A Web Server security group (Web-SG) that is referenced by the Auto Scaling launch configuration
Configure your Web-SG to permit incoming traffic from the LB-SG. This can be referenced by name or by sg-xxxx identifier.
Permitting traffic from another security group is a way of saying "permit traffic from any instance that is associated with that security group". This includes the security group assigned to instances from Auto Scaling.
If you have another instance that should accept incoming traffic from instances in the auto scaling group, create another security group (eg Backend-SG) and permit incoming traffic from Web-SG.
Here is a sample diagram from a Rackspace article on Network Segregation in AWS. Notice how each security group refers to the one 'above' it:
You can add the source ID of load balancer security group in the inbound rule for needed protocols (HTTP, HTTPs). Then delete all the other inbound rules.
Ref: AWS Documentation
I have an Amazon Beanstalk Load Balancer setup which adds / removes ec2 servers as needed. The security group for this load balancer is called prod-sc.
I also have an Amazon EC2 instance using security group elasticsearch-sc.
Now I need elasticsearch-sc to allow port 9200 to be accessed from prod-sc
However everytime I try to configure this in the elasticsearch-sc by providing the prod-sc Group ID, I get an error saying
Could not update your security group rules (No changes were made): You may not define rules between a VPC group and a non-VPC group.
How can I give prod-sc access to elasticsearch-sc?
Can you try creating elasticsearch-sc as a VPC security group?
Read the guide for more details.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
http://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html
So for reasons Id rather not go into, my DB is on an EC2 instance in eu-west-1 and I have created a beanstalk app on us-east-1. Id like my app to talk to that EC2 instance on a MySQL port (3306).
Can anyone assist with how Id set this up, what ingress rules I need to setup on the EC2 security group? Given that I will have multiple versions of the app in beanstalk, the IP address may change regularly (after environment rebuilds etc).
The important concept regarding Security Group Rules you might be missing is, that you do not necessarily specify IP addresses as traffic sources alone, rather regularly will refer to other security groups as well:
The source can be an individual IP address (203.0.113.1), a range of
addresses (e.g., 203.0.113.0/24), or an EC2 security group. The
security group can be another group in your AWS account, a group in
another AWS account, or the security group itself.
By specifying a security group as the source, you allow incoming
traffic from all instances that belong to the source security group.
[...] You might specify another security group in your account if you're creating a
three-tier web service (see Creating a Three-Tier Web Service).
[emphasis mine]
Consequently you'll simply need to add the Beanstalk app instances security group as a traffic source for TCP port 3306 within the MySQL instance security group.
Taking this further
An additional concept to make oneself familiar with is, that you can have multiple security groups assigned to an instance, thus enabling (possibly dynamic) composition of the resulting firewall.
For example, a recommended practice for larger architectures suggests to specify a dedicated security group per 'role' your instances have (rather than accumulating several rules within one security group as usual), e.g. we have security groups like 'role-ssh' (TCP port 22) and 'role-mysql' (TCP port 3306), which are assigned to EC2 instances as needed in turn. You can read more about this concept in e.g. Security Groups - Most Underappreciated Feature of Amazon EC2.