I am currently preparing for the AWS SysOps Administrator Associate exam using the study guide book (https://www.amazon.com/dp/1119561558/).
In the review question for chapter 8 - Bastion Hosts there are two questions about "Private VPC" which I cannot get my head around:
"2) Which of the following does a bastion host provide to a private VPC?"
My Answer: Access to the resources in the VPC through a host inside the VPC
Correct Answer: Access to the resources in the VPC through a host outside the VPC
"15) You have just inherited a new network architecture that has a private VPC with numerous resources within it and a bastion host for administrative access. Which of the following would you do first?"
My Answer: Remove any Internet gateways on the private VPC.
Correct Answer: Whitelist any IPs that need to access the bastion host.
As far as I understand it, a typical VPC architecture is to have a public subnet, with an Internet Gateway and the bastion host in it, and a private subnet with neither.
But what exactly is meant with "private VPC" here? If it is a VPC that is not accessible from the outside at all? But how can a bastion host outside the VPC then access it? Or do they really mean a private subnet? But how can a subnet be really private, if it has an Internet Gateway in it? In other courses the IG is defined as exactly the thing that makes a subnet public...
Am I totally misunderstand something conceptually here?
2)
Your answer and understanding is correct. Bastion host is inside vpc. This is also written in aws docs:
A Linux bastion host in each public subnet with an Elastic IP address to allow inbound Secure Shell (SSH) access to EC2 instances in public and private subnets.
15)
I would agree with: "Whitelist any IPs that need to access the bastion host". The rationale is that removing internet gateway can have many negative consequences, most notably, not being able to login to bastion host to do any admin work, instances in private subnets not being able to download patches, or newly launch instances in ASG not being able to download software they need by means of User Data.
So removing old IPs from Security Group of bastion host belonging to old admin and adding your own IP makes most sense.
Don't know what is meant here by "private VPC". For myself, a private VPC would be one only accessible through a peering connection, one which does not have any public subnet, or one which only provides access to your app through VPC PrivateLink. In such cases you could use SSH Session Manager to login to the instances without the need for any bastion host and internet gateway.
Related
I have just started my career in the IT field and currently learning new technologies like AWS.
I have a small doubt and it will be really helpful for me if anyone can help me with it.
"Can we connect ec2 instance which is having only private IP with the other ec2 instance with a public IP"
In Putty, I have logged into an EC2 instance (With public IP) and tried to ssh into other EC2 instances (which is having only private IP) by mentioning its private IP Address, but I wasn't able to login to that.
Thank you in advance :)
You can do this (providing security groups and network configuration allows).
The first method (and more prefered) is through a private to private connection, just because an instance has a public IP does not mean it is inaccessible from private inbound connections. If they share the same VPC as long as your security groups/NACLs allow inbound from the private IP range you will be able to connect to the instance via its private IP.
If the instances share a different VPC (or even account) you can connect between using either transit gateway or a single peering connection, then whitelist the IP range of the source. A caveat is that these separate networks cannot be peered if they have a crossover in network address ranges (you would need to create a secondary range to deal with this).
The alternative is to use either a NAT Gateway or NAT instance and then bind this to the route table for your instance for the 0.0.0.0/0 route. You would then need to whitelist in the public instances security group the public EIP of the NAT. This is less preferable as it requires communication across the internet.
I'm learning AWS and how to configure networking for EC2 instances and have a few questions. I'm using CentOS 7 in t2.micro instances.
The private IP is tied to the NIC in the instance as shown by ifconfig -a. The purpose seems to be a single point of contact for the server. Adding another network interface does NOT add another NIC as shown by ifconfig -a. Since the primary network interface cannot be a static IP, a secondary network interface is necessary for most configurations. For example, to connect the application to the database server, use the static IP assigned to the second network interface. Am I understanding this correctly?
The public IP is shown in the AWS console and provides a means to connect to the instance via SSH, assuming you configure the SG. The public IP also provides a means to access the internet for system updates. This seems to contradict the AWS documentation for NAT. If the public IP already provides internet access, why is a NAT (instance or gateway) needed? This is in reference to system updates which the documentation references.
You can use a NAT device to enable instances in a private subnet to connect to the Internet (for example, for software updates) or other AWS services, but prevent the Internet from initiating connections with the instances. A NAT device forwards traffic from the instances in the private subnet to the Internet or other AWS services, and then sends the response back to the instances.
Is a public IP and private IP are always assigned to each instance? I haven't walked through the process of creating an [new] AMI to verify if there's an option to not have a public IP. If the instance doesn't have a public IP, will the AWS console Connect button still allow you to connect to it to administer the server? Under what scenario will an instance NOT have a public IP? How do you connect to that instance to administer it?
I have read the NAT Gateway documentation and understand much of it. I'm having trouble understanding the pieces that state a NAT gateway or internet gateway is necessary to enable internet access, when it seems this is enabled by default. What am I missing?
I think your confusion stems from your third question. A public IP is not always assigned to an instance. Public IP is an option that you can enable or disable in public VPC subnets, and in private VPC subnets public IP isn't an option at all. For EC2 instances without a public IP a NAT gateway (or NAT instance) is required in order to access anything outside of the VPC.
You may want to place something like a database server in a private subnet so that nothing outside your VPC can ever access it. However you might want the database server to be able to access the Internet to download patches or something, or you may want it to access the AWS API in order to copy backups to S3 or something, in which case you would need a NAT Gateway to provide the server access to resources outside your VPC.
We're setting up an Amazon VPC in which we will provision (for now) a single EC2 instance and one RDS instance. This is to 'extend our data center', and should only be using private subnet(s).
So actually, we have this setup, and it is working well (insert smiley face icon). For all intents and purposes, we're mirroring the VPC scenario 4 outlined by Amazon here: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario4.html
tl;dr: A single VCP, with a VPN connecting to our corporate network. The VPN uses a Virtual Private Gateway (VPC end) and Customer Gateway (our end) to allow us access as necessary to the EC2, which contains a webserver connecting to the RDS instance as needed. Anyone on our network has access to the web server running on the EC2 via a URL. All this is working as expected.
The problem comes when the EC2 instance needs to access a resource on the Internet - The idea is for us to NOT have any public subnets, but to route all traffic from the EC2 instance through our VPN and out the 'standard' path of our corporate Internet access. However we're having trouble setting this up.
The fact that it can be done is hightlighted in Amazon's FAQ here:
https://aws.amazon.com/vpc/faqs/
Q. How do instances without public IP addresses access the Internet?
Instances without public IP addresses can access the Internet in one of two ways:
Instances without public IP addresses can route their traffic through a NAT gateway or a NAT instance to access the Internet. These instances use the public IP address of the NAT gateway or NAT instance to traverse the Internet. The NAT gateway or NAT instance allows outbound communication but doesn’t allow machines on the Internet to initiate a connection to the privately addressed instances.
For VPCs with a hardware VPN connection or Direct Connect connection, instances can route their Internet traffic down the virtual private gateway to your existing datacenter. From there, it can access the Internet via your existing egress points and network security/monitoring devices.
We are trying to avoid option #1 as there is a cost involved (along with complexity and security issues). #2 is the perfect resolution for us, but understanding the process to set it up has been eluding us for a while.
Can anyone walk us through what we need to do (or point us to the correct resources) to ensure the EC2 instance* can access the Internet by routing the traffic down the VPN, through our corporate datacenter, and our our existing Internet access point?
* and anything within the private subnet for that matter
If you are using scenario #2, then all there is to do on the AWS end is to ensure that traffic destined for the internet, 0.0.0.0/0 is routed to your Virtual Private Gateway.
Once traffic heads there, it will go to your Customer Gateway, and into your corporate datacenter. It's up to your local IT guys on that end to get Internet-destined traffic heading out, if it's even possible. But at that point, it's no longer an AWS issue.
I started to mess around with aws a couple days ago and I have a question about VPCs.
I'm considering two options to make "private" a subnet and I want to know your opinion:
OPTION 1:
A subnet with an ig attached (a public subnet really) with an ACL to only allow traffic from the VPC.
Pros: cheaper!
Cons: public ip for each instance (is this a real problem?), different public Ip for each instance (a kind of messy stuff for ip's whitelists)
OPTION 2:
A subnet without an ig attached using a Nat gateway.
Pros: more secure?, same public Ip for each instance.
Cons: more expensive.
I consider the Option 2 the best technical solution, only a bit more expensive. But, do you consider the option 1 a bad practice? Has more pitfalls that I'm not seeing?
It appears that your requirements are:
Run some Amazon EC2 instances
Keep them "private" from the Internet (no direct access from the Internet to the instances)
Allow the instances to access the Internet (eg to download updates, or to communicate with AWS API endpoints)
Your Option 1 is a public subnet, made private by modifying the Network ACLs to allow traffic only within the subnet. You are giving public IP addresses to the instances, presumably so they can access the Internet. This will not work. The Network ACLs that limit access to the VPC will also block traffic from the instances to the Internet.
Your Option 2 is a private subnet, with instances accessing the Internet via a NAT gateway. There is no need to assign public IP addresses to these instances, since they are in a private subnet. Yes, this will work but, as you note, there is the extra expense of the NAT Gateway (or a NAT instance).
An alternative is to use a Public Subnet with Security Groups:
Use a public subnet and give instances auto-assigned public IP addresses. This will allow them to access the Internet. (Note: This is different to an Elastic IP Address, which is limited to 5 per region per AWS account.)
Use a Security Group on each instance to block Inbound access. The instances will still be able to initiate outbound access to the Internet (and responses will come back because Security Groups are stateful)
See documentation: Amazon EC2 Security Groups for Linux Instances
Of course, since the instances now block inbound traffic, you will need a way to connect to them. This is typically done by launching a Bastion Server (Jump Box) in your public subnet. You can connect to the Bastion Server via public IP address, then connect to the private servers via their private IP address. To allow this, configure the Security Group on the private instances to permit inbound traffic from the IP range of the VPC, or from the Security Group associated with the Bastion Server.
I'm setting up a test VPC on AWS to see how I like different configurations.
Using the default Scenario 2 configuration:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
I'm not sure what the best practice process for accessing members of the subnet is. You can ssh into the NAT and then ssh into the instance in the subnet, but this of course requires having the pem keys for that instance on the NAT, which makes me uncomfortable.
Have I miss understood the configurations of the security groups, and should be able to ssh directly into the members of the subnet?
In general, instances in private VPC subnets do not have inbound access from the Internet and cannot be accessed directly. You can assign elastic IPs to instances in private subnets and inbound traffic would be routed to it. However, outbound return traffic would never reach the source since the NAT won't route asymmetric traffic.
There are at least two options for accessing those systems via SSH:
Use a bastion host in a public subnet to jump to the instances in the private subnet. The NAT could serve as this bastion, or you could set up another instance. You can have your private key on the bastion, or you can use the ForwardAgent option in your SSH configuration to use the private key from the bastion without requiring the key file to be present.
Establish a VPN from your network to the VPC using a VPN gateway. Allow access in the VPC security groups from your network's address space to the instances in the private subnet. You can then SSH to the private instances as if they're local to your network.
Leaving the private keys on the bastion host shouldn't make you uncomfortable if you harden the bastion sufficiently using security group rules, local firewalls, and other standard system security techniques.