How to place EC2 instance in both public and private subnet? - amazon-web-services

Is it possible to connect an EC2 instance in AWS VPC to both a private and a public subnet using ENIs? I'm aware of the bastion host concept from public/private subnet communication, but curious as anything that will prevent me from configuring an EC2 instance to reside in both public and private subnets.

Yes you can do it. You simply have to attach two Network interfaces. Those two network interfaces needs to be placed in two subnets. Here is the official documentation for that https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html

Yes you can have multiple ENI's in different subnets and the same can be associated with a single instance, however the instance will once have a single ENI associated with it(from the OS perspective it will have eth0 and eth1). In this case the instance will assume the role(subnet) of the ENI which the OS is associated with it(it is generally eth0).

Related

Multiple ENIs on EC2 use case

I created 2 private subnets PRIVATEA and PRIVATEB in a custom VPC. These subnets are in different availability zones. Added an EC2 instance in PRIVATEA. The instance already has an ENI eth0 attached to it. Next I created an ENI in the other PRIVATEB subnet and attached it to EC2 instance in PRIVATEB subnet. The setup is successful. Basically I followed a blog tutorial for this setup. It said that secondary interface will allow traffic for another group i.e. Management.
But I am not able to relate any use case with it. Could anyone please explain when do we use such a setup ? Is this the correct question to ask in this forum here ?
Thanks
An Elastic Network Interface (ENI) is a virtual network card that connects an Amazon EC2 instance to a subnet in an Amazon VPC. In fact, ENIs are also used by Amazon RDS databases, AWS Lambda functions, Amazon Redshift databases and any other resource that connects to a VPC.
Additional ENIs can be attached to an Amazon EC2 instance. These extra ENIs can be attached to different subnets in the same Availability Zone. The operating system can then route traffic out to different ENIs.
Security Groups are actually associated with ENIs (not instances). Thus, different ENIs can have different rules about traffic that goes in/out of an instance.
An example for using multiple ENIs is to create a DMZ, which acts as a perimeter through which traffic must pass. For example:
Internet --> DMZ --> App Server
In this scenario, all traffic must pass through the DMZ, where traffic is typically inspected before being passed onto the server. This can be implemented by using multiple ENIs, where one ENI connects to a public subnet to receive traffic and another ENI connects to a private subnet to send traffic. The Network ACLs on the subnets can be configured to disallow traffic passing between the subnets, so that the only way traffic can flow from the public subnet to the private subnet is via the DMZ instance, since it is connected to both subnets.
Another use-case is software that attaches a license to a MAC address. Some software products do this because MAC addresses are (meant to be) unique across all networking devices (although some devices allow it to be changed). Thus, they register their software under the MAC address attached to a secondary ENI. If that instance needs to be replaced, the secondary ENI can be moved to another instance without the MAC address changing.

Launching AWS EC2 instances in public subnet

What is the security concern in launching AWS EC2 instances in public subnet. I assume when an EC2 instance is launched in public subnet , it will have access to outside world provided security groups allow it. Is all traffic from internet allowed to public subnet? I assume even this could be restricted via NACLs.
About launching the ec2 instance in public subnet, it is recommended that EC2 instances which need direct Internet access need to be placed in the public subnet, else instances that need direct access to internal networks must be placed in a private subnet with routes to a virtual private gateway.
About NACL, you can control incoming and outgoing traffic at subnet level through NACL.
By default, NACL allows all inbound and outbound traffic.
Can customize NACL with required rules in order to provide the extra security at the subnet level.

Can we move ec2 instances from private subnet to public subnet directly?

I want to move my ec2-instances from private subnet to public subnet. Is there is a way to do that other than creating AMI of those instances and then launching new instances from those AMI's and attaching volumes and elastic ips with them?
An Amazon EC2 instance is permanently connected to a subnet. (Well, the Primary interface is.)
Some options:
You could modify the subnet so that the subnet 'becomes' a public subnet (by configuring the Route Table to send traffic to an Internet Gateway). This does not require any changes to the instance itself.
You could add a secondary Elastic Network Interface (ENI) that connects it to a public subnet. You then need to configure the operating system to use the secondary ENI.
You could launch a new instance in a public subnet, stop it, detach its disks, then attach the disks from the 'private' instance, then start it. It will probably start up okay, and it would then be in a public subnet.

Do we need NAT gateway/instance in public subnet when we want to distribute traffic from ELB to private subnet instances?

I have configured lots of time, when my instance is in public subnet, I can distribute ELB traffic to them but instances in private subnet, it goes out of service. I had configure perfect SG between ELB to private instances and for ELB. Also added public subnet in ELB as same AZ where my private instances existing. I have done everything as per below URLs.
Amazon ELB for EC2 instances in private subnet in VPC
https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
As per first URLs, we don't require NAT in public subnet if we don't require to access any other service from private instances, "havak5" and "been Whaley" also commented afor same, still some websites tell that in this scenario, we need NAT gateway or instance in public subset for return traffic.
http://thebluenode.com/exposing-private-ec2-instances-behind-public-elastic-load-balancer-elb-aws
I had tried as per AWS URLs mention above but not work. So can any one tell me that really how this scenario work?
You can refer the following link from aws to understand use of NAT:
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html
If we want to make any kind of interaction with instances placed in private subnet we should use NAT

Amazon EC2: instace in public subnetwork without public IP vs instance in private subnetwork

I have a VPC created according to scenario 2: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
When creating an instance in the public subnet, I'm given the choice of:
1- Not associating a public IP to the instance
2- Associating a public IP that can change when the instance is restarted
3- Associating an Elastic IP
My question is: what is the difference, security-wise, between creating an instance in the public subnet but without a public IP (option 1) and creating the instance in the private subnet? I know that private instances are behind a NAT, but does this really add a relevant layer of security? Wouldn't I be as protected with a public instance without a public IP belonging to a sound security group?
Check out this answer about the difference between private and public subnets in AWS.
In short, the distinction is at the networking layer with the resulting security posture being similar. The instance on the public subnet without a publicly routable address will not be able to receive inbound connections nor make outbound connections without an attached EIP address -- even if the security group would otherwise allow it. (So, for example, you'd have to attach an EIP just to SSH into the instance.) In effect, it's a blanket block whereas the NAT allows you to fine tune access like you would normally expect.
You can also read more about instance addressing in the AWS User Guide.