Tutorial Highlights & Transcript
00:00 - What is EC2 Instance Connect Endpoint?
Today, I’m going to talk about EC2 Instance Connect Endpoint. Some of you might have heard of EC2 Instance Connect, which was the previous evolution of this service—and EC2 Instance Connect, this is still available on AWS. But EC2 Instance Connect is quite recent, and it’s pretty interesting. So let’s dive into it.
What is the service? EC2 Instance Connect Endpoint allows you to connect an instance via SSH or RDP protocol. For those who are not familiar, RDP is basically SSH protocol but allows you to connect with UI. Maybe you’re familiar with a service called AWS Workspaces. It’s basically a good example for it. And all of this can be done without requiring the instance to have a public IP. This is pretty cool because we can connect to an instance only by using the private IP. That means we don’t have to expose any endpoint to the internet.
And how does this work? First, we can see this diagram: We have our user that is connected to an Instance Connect Endpoint. This is within the AWS cloud. The Instance Connect Endpoint connects to an endpoint created within the AWS VPC and private or public subnet. In this case, we have it in private. And since we have instances on the same VPC, we can connect to those instances from that endpoint. You can see that we can reach four instances using just one endpoint, right?
02:15 - Why should you use it?
Why? Remembering that, as we said in the previous slide, this service allows you to connect to any instance without having to need a public IP address, that means that you don’t have to expose your IPs or do other processes that we would use in the past.
For example, in the past, we would use a bastion host. So basically, a bastion host is an EC2 running on a public instance that can reach resources and private subnets. And a VPN also runs in a public subnet. It’s in the same network and can reach those resources in private subnets. That might take time, and in some cases, depending on the services that we are using, can cause the most costs. So this is one of the main reasons why AWS decided to create an EC2 Instance Connect Endpoint: to make our life easier. Basically.
03:38 - Features of EIC
Ok! One of the main attributes or main features we have with EC2 Instance Connect (or AWS EIC, the short name) is that we can control the access by doing identity-based and network-based, which means we can grant access by IAM roles or user by IAM permissions.
The second thing we can do is control in isolation. We can have better isolation because we do not need to publish any IP or any endpoint. So that’s pretty cool.
Also, the third point, it’s actually very interesting because we can connect from our AWS CLI in our AWS console. That means that within our AWS console, with a few simple clicks, we can connect to a private instance. But it makes it more interesting that we can do that from our AWS CLI. That’s if we need to, I don’t know, let’s say, create a script, or maybe work from our local computer. That’s pretty cool. For me, that’s an attribute that’s pretty awesome.
The final point is that we have better logging. AWS has some tools for logging that make our lives easier. For example, VPC flow logs. Since this is an endpoint, those logs are also captured by the service, which, well, gives us a better view of what’s going on.
05:22 - Demo of EC2 Instance Connect Endpoint
Now that we went through the principal concepts, let’s start with the demo. Right, let’s do this.
I’m in the nClouds AWS account. More specifically, I am on the BBC console. And being more specific, I am on the security group’s console. So that’s our first step. We will need to create a security group. To save time, I have already created the security group, but I will go through the inbound rules and outbound rules too. For inbound rules, I decided to allow all connections from within our VPC. That means only private connections. Since we are going to be using a security group for our endpoint and a security group for our EC2 instance, I decided to use the same. That means I can grant access from the security group itself. This might be a little complicated, but we’ll see it better when the security group is assigned to both resources. And we’ll have a better view of it.
Oh, I didn’t tell you about outbound rules. Outbound rules are pretty basic. We allow traffic to go out of our instances, but not all traffic to go inside our instances.
So the next thing is the endpoints. Ok, first, we’ll need to create the endpoint. In this case, I’m going to use Friday-demo-miguel-1. In the service category, we’ll go for EC2 Instance Connect Endpoint. For the VPC, we’ll use the same VPC where we will deploy our EC2 instance. In this case, it will be VPC Dev. We’ll select the security group that we created before. And finally, we’ll use a public subnet to deploy our VPC endpoint. In this case, I will use this one—the first one. There’s not really a preference—I’m just going for less, so you can use any of the subnets you have available. And I’m going to tag this with a task to remind me to delete this resource after the demo is done. Ok, so I’ll create the endpoint. And I can do it.
Ok, I see why. Before this demo, I have already created one endpoint. This is because when you create these endpoints, it takes around five to 10 minutes to be created. So in order to save time, I have one already created. It has the same configuration. Actually, I’m going to show you guys. It’s this one right here.
Let me show you the details. As you can see, it’s deployed on the VPC Dev and has the Friday-demo-Miguel security group attached. And it’s in the subnet that’s part of our VPC. So we’re gonna go ahead and use this endpoint. A good thing to be mentioned, in order to use this endpoint, it needs to be in available status. If not, then you’ll probably configure something wrong, or maybe it’s still deployed.
09:30 - Deploying an EC2 Instance
So, next step is to deploy an EC2 instance. In this case, I’m just gonna go for an Ubuntu image, something that I’m familiar with: a t3.micro. We just need a little instance, because it’s only for the demo purposes. Select the miguel-pair.
Here’s the deal: With network settings, we need to deploy this on the same VPC that we have deployed our endpoint. We are going to deploy this on our private subnet, and we are not going to assign a public IP. We’re going to select the security group that we have created, and that should be it. Pretty easy.
Let’s launch the instance. Let’s see a list of instances. There we go. It’s still initializing.
I’d like to mention that this is a pretty new service. It’s a pretty recent service. Perhaps like two months to three months since it’s been deployed by AWS. Pretty recent. And I think it’s very interesting because it gives us the opportunity to connect to EC2 instances in a private manner. We don’t have to deploy Bastion hosts or VPNs to connect to the resources that are in private subnets. This is pretty similar to ECR VPC endpoints. Because remember that we have VPC endpoints for different services such as S3, ECR, and secrets manager. That is because sometimes we need to reach those services from private subnets.
Ok, we should be ready to connect. To connect, you need to go to the EC2 instance connect tab. Here we have two ways of connecting. The first is to “Connect using EC2 Instance Connect.” This uses a public IP, and it’s not the way we’re looking for in this demo. We’re gonna go with “Connect using EC2 Instance Connect Endpoint.” The only thing we have to select is which endpoint we want to use. In this case, we’re going to use the one that I had already created, FR-demo-Miguel-0. Then let’s hit “Connect,” and it should be connecting in a few seconds.
There we go! Let’s run an update. It’s updating. We have an SSH connection to our EC2 instance. As you can see, we’re using the private IP because this instance—we’re using this one—does not have a public IP.
Miguel is a DevOps Engineer at nClouds and an AWS Certified Cloud Practitioner.