Looking at this diagram one more time, there's a couple of considerations that I want to dive a little deeper into. So, let's get going. One thing is going to be EC2. You can see an EC2 here, which may not necessarily be a part of your container cluster or your deployment, but you may want to talk to this EC2. Perhaps it's not an EC2, it could be an RDS database, for example. So, there's some networking security involved in this case. So, in that case, let me switch over here and type Security groups, which I'm gonna go here with an EC2. 

Let's take this WebServerSG, for example. If I look at the rules of this particular security group, you'll see that it has SSH. You probably will not need SSH if you're deploying containers. It also has HTTP port open and HTTPS. This is more realistic. So, if you're deploying containers, you're probably going to have one of these two ports likely open for traffic, and you may have perhaps a Custom TCP port. In this case, you see 8080 here. For example, if you have a Java Tomcat application, you're most likely to have the default port, in this case 8080 for traffic purposes. So, for those reasons, you definitely need to define a security group that is going to be associated with your task definition. Another reason I mentioned to have a security group is just to be a member of the security group in the first place.

Let me explain. If you have an RDS database, that database is going to have security restrictions  as to who can access the database. In that case, you can say, I'm only going to allow traffic into this database for members of the WebServerSG or WebServer Security Group, in this case. So, just being a member of the security group allows your container to do certain things and gives you that flexibility when it comes to managing networking security.

Let's go back to our diagram here. And I mentioned endpoints, but I didn't quite show you what that looks like. So, let's dive a little deeper into endpoints. So, I'll go to VPC again, and within VPCs, I'm going to go into Route tables. I should have one here. I'll get this one, private2. If I look at routes, there's one here that says vpce private link. Let's go ahead and click on this. And as you can see, this is pointing to the S3 service in us-west-2. Let me explain what this means. If you're trying to access a service like S3, which is a public service, your application is going to try to go over the Internet to hit this endpoint and get your data. Sometimes for governance requirements or very tight security restriction, you don't want your traffic to go over a public network out into the Internet to get to the S3 service in this case. 

So, what do you do? With the help of endpoints within AWS, you can define endpoints within your VPC and this way your application can actually query, in this case the S3 service, from within the private VPC without having to get out into the public network. As I mentioned, this is a great feature, be it for governance reasons or just to have your application be more secure. Perhaps you can even do away with the NAT gateway, perhaps you don't even need Internet access at all from your application. That would make it very, very secure, and of course, endpoints can certainly help with that. Of course, it's not only for S3. You can do it for ECR as well, or as I mentioned, for getting environment variables and secrets, and things of that nature.