Mixing
AWS Security Group - how to allow Public IP from another Security Group
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
I have two instances in a VPC distinct security groups, each with their own public IP. I would like instance one to be able to connect to instance two on it's Public IP. I discovered that granting access to the security group, only allows access to the private IP, not the Public IP.
I have now defined my Security Group to allow access to the Public IP of the instance which resides in the other Security Group. However, this is inconvenient, as I can't easily automate this (think Ansible), since I will first need to perform a lookup of the DNS name, before I can add it to the group.
Does anyone know of a simpler way of doing this?
To summarize:
- Instance 1 -> 1.2.3.4
- Instance 2 -> 5.6.7.8
Instance 1 is required to access Instance 2 on it's Public IP.
I currenty end up having to manually lookup what the IP of instance 1 is and in turn add that to the security group of Instance 2.
amazon-web-services amazon-ec2 amazon-elastic-ip security-groups
edited 15 mins ago
MLu
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
4
down vote
favorite
I have two instances in a VPC distinct security groups, each with their own public IP. I would like instance one to be able to connect to instance two on it's Public IP. I discovered that granting access to the security group, only allows access to the private IP, not the Public IP.
I have now defined my Security Group to allow access to the Public IP of the instance which resides in the other Security Group. However, this is inconvenient, as I can't easily automate this (think Ansible), since I will first need to perform a lookup of the DNS name, before I can add it to the group.
Does anyone know of a simpler way of doing this?
To summarize:
- Instance 1 -> 1.2.3.4
- Instance 2 -> 5.6.7.8
Instance 1 is required to access Instance 2 on it's Public IP.
I currenty end up having to manually lookup what the IP of instance 1 is and in turn add that to the security group of Instance 2.
amazon-web-services amazon-ec2 amazon-elastic-ip security-groups
edited 15 mins ago
MLu
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I have two instances in a VPC distinct security groups, each with their own public IP. I would like instance one to be able to connect to instance two on it's Public IP. I discovered that granting access to the security group, only allows access to the private IP, not the Public IP.
I have now defined my Security Group to allow access to the Public IP of the instance which resides in the other Security Group. However, this is inconvenient, as I can't easily automate this (think Ansible), since I will first need to perform a lookup of the DNS name, before I can add it to the group.
Does anyone know of a simpler way of doing this?
To summarize:
- Instance 1 -> 1.2.3.4
- Instance 2 -> 5.6.7.8
Instance 1 is required to access Instance 2 on it's Public IP.
I currenty end up having to manually lookup what the IP of instance 1 is and in turn add that to the security group of Instance 2.
amazon-web-services amazon-ec2 amazon-elastic-ip security-groups
edited 15 mins ago
MLu
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I have two instances in a VPC distinct security groups, each with their own public IP. I would like instance one to be able to connect to instance two on it's Public IP. I discovered that granting access to the security group, only allows access to the private IP, not the Public IP.
I have now defined my Security Group to allow access to the Public IP of the instance which resides in the other Security Group. However, this is inconvenient, as I can't easily automate this (think Ansible), since I will first need to perform a lookup of the DNS name, before I can add it to the group.
Does anyone know of a simpler way of doing this?
To summarize:
- Instance 1 -> 1.2.3.4
- Instance 2 -> 5.6.7.8
Instance 1 is required to access Instance 2 on it's Public IP.
I currenty end up having to manually lookup what the IP of instance 1 is and in turn add that to the security group of Instance 2.
amazon-web-services amazon-ec2 amazon-elastic-ip security-groups
amazon-web-services amazon-ec2 amazon-elastic-ip security-groups
edited 15 mins ago
MLu
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 15 mins ago
MLu
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 15 mins ago
MLu
4,13311632
edited 15 mins ago
MLu
4,13311632
edited 15 mins ago
MLu
4,13311632
4,13311632
asked 8 hours ago
darkl0rd
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 8 hours ago
darkl0rd
212
asked 8 hours ago
darkl0rd
212
212
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
darkl0rd is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
3
down vote
I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs.
However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this should do:
- name: Create Instance 1
ec2:
key_name: mykey
instance_type: t2.micro
image: ami-123456
wait: yes
assign_public_ip: yes <<< Assign Public IP
register: ec2
And then you can add it as a source to the Instance 2 Security Group:
- name: Instance 2 SG
ec2_group:
name: ...
rules:
- proto: tcp
ports:
- 80
cidr_ip: " ec2.instances.public_ip " <<< Use it here
Something along these lines should let you do the automation with Ansible.
Hope that helps :)
answered 7 hours ago
MLu
4,13311632
add a comment |Â
up vote
2
down vote
Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports.
Final picture:
- All instances needed to communicate with each other have the
created security groupattached. - The
created security groupcontains rules which state inbound fromcreated security grouptodestination port you need - Often there are no outbound rules included, as secutity groups are stateful. But feel free to add what is needed.
So basically not even a single ip is needed, and allow/deny can be controlled by attaching the security group to resources where access is needed. This method also works nicely with dynamic environments (e.g. autoscaled).
answered 7 hours ago
hargut
65916
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
add a comment |Â
up vote
1
down vote
Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses.
I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service.example.com that points to the target instance's public DNS name that is provided by AWS. The public DNS name will look something like ec2-public-ipv4-address.compute-1.amazonaws.com.
AWS provides split-horizon DNS resolution. When my-service.example.com is resolved on the public internet, the public IP is returned. When my-service.example.com is resolved in your VPC, the private IP is returned. Therefore your source instance will connect to the target instance using a private IP and your Security Group rules will work as expected.
This sort of DNS configuration isn't always possible or practical, so you may need to whitelist the source instance's public IP address. In this case, make sure that it is an Elastic IP Address - otherwise the public IP will change if the server shuts down.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs.
However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this should do:
- name: Create Instance 1
ec2:
key_name: mykey
instance_type: t2.micro
image: ami-123456
wait: yes
assign_public_ip: yes <<< Assign Public IP
register: ec2
And then you can add it as a source to the Instance 2 Security Group:
- name: Instance 2 SG
ec2_group:
name: ...
rules:
- proto: tcp
ports:
- 80
cidr_ip: " ec2.instances.public_ip " <<< Use it here
Something along these lines should let you do the automation with Ansible.
Hope that helps :)
answered 7 hours ago
MLu
4,13311632
add a comment |Â
up vote
3
down vote
I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs.
However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this should do:
- name: Create Instance 1
ec2:
key_name: mykey
instance_type: t2.micro
image: ami-123456
wait: yes
assign_public_ip: yes <<< Assign Public IP
register: ec2
And then you can add it as a source to the Instance 2 Security Group:
- name: Instance 2 SG
ec2_group:
name: ...
rules:
- proto: tcp
ports:
- 80
cidr_ip: " ec2.instances.public_ip " <<< Use it here
Something along these lines should let you do the automation with Ansible.
Hope that helps :)
answered 7 hours ago
MLu
4,13311632
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs.
However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this should do:
- name: Create Instance 1
ec2:
key_name: mykey
instance_type: t2.micro
image: ami-123456
wait: yes
assign_public_ip: yes <<< Assign Public IP
register: ec2
And then you can add it as a source to the Instance 2 Security Group:
- name: Instance 2 SG
ec2_group:
name: ...
rules:
- proto: tcp
ports:
- 80
cidr_ip: " ec2.instances.public_ip " <<< Use it here
Something along these lines should let you do the automation with Ansible.
Hope that helps :)
answered 7 hours ago
MLu
4,13311632
I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs.
However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this should do:
- name: Create Instance 1
ec2:
key_name: mykey
instance_type: t2.micro
image: ami-123456
wait: yes
assign_public_ip: yes <<< Assign Public IP
register: ec2
And then you can add it as a source to the Instance 2 Security Group:
- name: Instance 2 SG
ec2_group:
name: ...
rules:
- proto: tcp
ports:
- 80
cidr_ip: " ec2.instances.public_ip " <<< Use it here
Something along these lines should let you do the automation with Ansible.
Hope that helps :)
answered 7 hours ago
MLu
4,13311632
answered 7 hours ago
MLu
4,13311632
answered 7 hours ago
MLu
4,13311632
answered 7 hours ago
MLu
4,13311632
4,13311632
add a comment |Â
add a comment |Â
up vote
2
down vote
Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports.
Final picture:
- All instances needed to communicate with each other have the
created security groupattached. - The
created security groupcontains rules which state inbound fromcreated security grouptodestination port you need - Often there are no outbound rules included, as secutity groups are stateful. But feel free to add what is needed.
So basically not even a single ip is needed, and allow/deny can be controlled by attaching the security group to resources where access is needed. This method also works nicely with dynamic environments (e.g. autoscaled).
answered 7 hours ago
hargut
65916
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
add a comment |Â
up vote
2
down vote
Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports.
Final picture:
- All instances needed to communicate with each other have the
created security groupattached. - The
created security groupcontains rules which state inbound fromcreated security grouptodestination port you need - Often there are no outbound rules included, as secutity groups are stateful. But feel free to add what is needed.
So basically not even a single ip is needed, and allow/deny can be controlled by attaching the security group to resources where access is needed. This method also works nicely with dynamic environments (e.g. autoscaled).
answered 7 hours ago
hargut
65916
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports.
Final picture:
- All instances needed to communicate with each other have the
created security groupattached. - The
created security groupcontains rules which state inbound fromcreated security grouptodestination port you need - Often there are no outbound rules included, as secutity groups are stateful. But feel free to add what is needed.
So basically not even a single ip is needed, and allow/deny can be controlled by attaching the security group to resources where access is needed. This method also works nicely with dynamic environments (e.g. autoscaled).
answered 7 hours ago
hargut
65916
Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports.
Final picture:
- All instances needed to communicate with each other have the
created security groupattached. - The
created security groupcontains rules which state inbound fromcreated security grouptodestination port you need - Often there are no outbound rules included, as secutity groups are stateful. But feel free to add what is needed.
So basically not even a single ip is needed, and allow/deny can be controlled by attaching the security group to resources where access is needed. This method also works nicely with dynamic environments (e.g. autoscaled).
answered 7 hours ago
hargut
65916
edited 7 hours ago
answered 7 hours ago
hargut
65916
answered 7 hours ago
hargut
65916
answered 7 hours ago
hargut
65916
65916
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
add a comment |Â
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
I'm not sure if Security Group ID works as a source for traffic over Public IPs. I don't think so, but I may be wrong.
– MLu
7 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
@MLu you are correct. Security Group ID does not work as a source for traffic over Public IPs
– Greg
2 hours ago
add a comment |Â
up vote
1
down vote
Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses.
I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service.example.com that points to the target instance's public DNS name that is provided by AWS. The public DNS name will look something like ec2-public-ipv4-address.compute-1.amazonaws.com.
AWS provides split-horizon DNS resolution. When my-service.example.com is resolved on the public internet, the public IP is returned. When my-service.example.com is resolved in your VPC, the private IP is returned. Therefore your source instance will connect to the target instance using a private IP and your Security Group rules will work as expected.
This sort of DNS configuration isn't always possible or practical, so you may need to whitelist the source instance's public IP address. In this case, make sure that it is an Elastic IP Address - otherwise the public IP will change if the server shuts down.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
add a comment |Â
up vote
1
down vote
Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses.
I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service.example.com that points to the target instance's public DNS name that is provided by AWS. The public DNS name will look something like ec2-public-ipv4-address.compute-1.amazonaws.com.
AWS provides split-horizon DNS resolution. When my-service.example.com is resolved on the public internet, the public IP is returned. When my-service.example.com is resolved in your VPC, the private IP is returned. Therefore your source instance will connect to the target instance using a private IP and your Security Group rules will work as expected.
This sort of DNS configuration isn't always possible or practical, so you may need to whitelist the source instance's public IP address. In this case, make sure that it is an Elastic IP Address - otherwise the public IP will change if the server shuts down.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses.
I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service.example.com that points to the target instance's public DNS name that is provided by AWS. The public DNS name will look something like ec2-public-ipv4-address.compute-1.amazonaws.com.
AWS provides split-horizon DNS resolution. When my-service.example.com is resolved on the public internet, the public IP is returned. When my-service.example.com is resolved in your VPC, the private IP is returned. Therefore your source instance will connect to the target instance using a private IP and your Security Group rules will work as expected.
This sort of DNS configuration isn't always possible or practical, so you may need to whitelist the source instance's public IP address. In this case, make sure that it is an Elastic IP Address - otherwise the public IP will change if the server shuts down.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses.
I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service.example.com that points to the target instance's public DNS name that is provided by AWS. The public DNS name will look something like ec2-public-ipv4-address.compute-1.amazonaws.com.
AWS provides split-horizon DNS resolution. When my-service.example.com is resolved on the public internet, the public IP is returned. When my-service.example.com is resolved in your VPC, the private IP is returned. Therefore your source instance will connect to the target instance using a private IP and your Security Group rules will work as expected.
This sort of DNS configuration isn't always possible or practical, so you may need to whitelist the source instance's public IP address. In this case, make sure that it is an Elastic IP Address - otherwise the public IP will change if the server shuts down.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 hours ago
Greg
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 hours ago
Greg
1114
answered 2 hours ago
Greg
1114
1114
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Greg is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
add a comment |Â
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
2
2
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
Bonus with this solution: data transfer between instances in the same VPC using public IPs incurs an additonal per-GB charge because the traffic passes through more AWS network infrastructure. This configuration avoids that charge.
– Michael - sqlbot
2 hours ago
add a comment |Â
darkl0rd is a new contributor. Be nice, and check out our Code of Conduct.
darkl0rd is a new contributor. Be nice, and check out our Code of Conduct.
darkl0rd is a new contributor. Be nice, and check out our Code of Conduct.
darkl0rd is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f938758%2faws-security-group-how-to-allow-public-ip-from-another-security-group%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password