Customer needed a solution to host containers on AWS. These containers will be running internal applications that don’t require inbound communication from the internet. However, the applications might require outbound communication to the internet so they can do tasks such as download updates from internet sources. The customer must use their own custom Amazon Machine Image (AMI) for the cluster that hosts the containers, and they must also have SSH access to underlying instances. For these reasons, Morgan chose Amazon Elastic Container Service (Amazon ECS) as the container orchestration tool and Amazon Elastic Compute Cloud (Amazon EC2) as the launch type. I also chose to include a NAT gateway in the architecture so that private instances could download information from the internet.
Amazon ECS launch types
After you choose which container orchestration tool you want to use — either Amazon ECS or Amazon Elastic Kubernetes Services (Amazon EKS) — there are two launch types to pick from:
- EC2: Deploy and manage your own cluster of EC2 instances for running the containers
- AWS Fargate: Run containers directly, without any EC2 instances
Both launch types are good compute options for hosting your containers in a scalable and reliable way. Which launch type you choose will depend on which factors you want to optimize for.
I chose the EC2 launch type for containers that were being run by Amazon ECS. I chose the EC2 launch type because the customer wants to use a custom AMI. The customer also wants to maintain SSH access to underlying instances so they could try to have similar management operations across workloads. AWS Fargate doesn’t support either of these options. Therefore, EC2 was the correct choice for this use case.
EC2 launch type
You can use the EC2 launch type to run your containerized applications on EC2 instances, which you register to your Amazon ECS cluster and manage yourself.
The following diagram shows the general architecture.
The diagram shows that the ECS agent is installed on each EC2 instance in the cluster. The ECS agent enables the orchestration tool that Amazon ECS uses to manage nodes.
Fargate launch type
You can use the Fargate launch type to run your containerized applications without the need to provision and manage the underlying infrastructure. AWS Fargate is the serverless way to host your Amazon ECS workloads.
The following diagram shows the general architecture.
For more resources about containers on AWS, see the following:
- For general information about AWS container services, see Containers at AWS or the Customers FAQs on the AWS Containers site.
- For more information about ECS launch types, see Amazon ECS launch types.
NAT devices
You can use a NAT device to allow resources in private subnets to connect to the internet, other VPCs, or on-premises networks. These instances can communicate with services outside the VPC, but they can’t receive unsolicited connection requests.
The NAT device replaces the source IPv4 address of the instances with the address of the NAT device. When the NAT device sends response traffic to the instances, the device translates the addresses back to the original source IPv4 addresses.
You can use a managed NAT device that’s offered by AWS, which is called a NAT gateway. You can also create your own NAT device on an EC2 instance, which is called a NAT instance. We recommend that you use NAT gateways because they provide better availability and bandwidth, and administering NAT gateways requires less effort on your part. You can manage how the traffic flows from the private resources to the NAT device by using route tables.
NAT instances
You can create your own AMI that provides network address translation, and use your AMI to launch an EC2 instance as a NAT instance. You can launch a NAT instance in a public subnet so that instances in a private subnet can initiate outbound IPv4 traffic to the internet or other AWS services without receiving inbound traffic that was initiated on the internet.
NAT gateways
A NAT gateway is a NAT service. You can use a NAT gateway so that instances in a private subnet can connect to services that are outside your VPC, but external services can’t initiate a connection with those instances.
When you create a NAT gateway, you specify one of the following connectivity types:
- Public (default): Instances in private subnets can connect to the internet through a public NAT gateway, but can’t receive unsolicited inbound connections from the internet. You create a public NAT gateway in a public subnet, and you must associate an elastic IP address with the NAT gateway at creation. You route traffic from the NAT gateway to the internet gateway for the VPC. Alternatively, you can use a public NAT gateway to connect to other VPCs or your on-premises network. In this case, you route traffic from the NAT gateway through a transit gateway or a virtual private gateway.
- Private: Instances in private subnets can connect to other VPCs or your on-premises network through a private NAT gateway. You can route traffic from the NAT gateway through a transit gateway or a virtual private gateway. You can’t associate an elastic IP address with a private NAT gateway. You can attach an internet gateway to a VPC with a private NAT gateway, but if you route traffic from the private NAT gateway to the internet gateway, the internet gateway drops the traffic.
The NAT gateway replaces the source IP address of the instances with the IP address of the NAT gateway. For a public NAT gateway, this is the elastic IP address of the NAT gateway. For a private NAT gateway, this is the private IP address of the NAT gateway. When the NAT device sends response traffic to the instances, it translates the addresses back to the original source IP address.For more resources about NAT devices, see the following:
- For more information, see Connect to the internet or other networks using NAT devices.
- For information comparing NAT devices, see Compare NAT gateways and NAT instances.
