This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

AWS SDK for .NET credential loading

The AWS SDKs take the complexity out of coding by providing language-specific APIs for AWS services. One of the ways the AWS SDK for .NET helps is by seamlessly loading the IAM credentials at runtime. The AWS SDK for .NET searches for credentials in a certain order and uses the first available set for the current application. In its simplest form, credential loading is transparent, as can be seen by the following code example that lists the objects in an S3 bucket.

var s3Client = new AmazonS3Client();
var listRequest = new ListObjectsRequest
{
    BucketName = "SampleBucket",
};

ListObjectsResponse response = await s3Client.ListObjectsAsync(listRequest);

foreach (var item in response.S3Objects)
{
    Console.WriteLine("key = {0} size = {1}", item.Key, item.Size);
}

The parameterless constructors for AWS service clients (AmazonS3Client in this example) rely on the FallbackCredentialsFactory to load the credentials using a well-known credential and profile resolution order and includes support for Amazon ECS. This provides a frictionless developer experience while still ensuring credentials remain secure.

This section covered the various IAM roles involved in a container’s lifecycle, including how to securely retrieve temporary credentials using the AWS SDK for .NET. Your security journey does not end here. Consider how to keep data secure both in transit and at rest.

In-flight data protection using encryption

By default, API calls to Amazon ECS travel through the public internet. To keep that traffic within the AWS global network, you can configure Amazon ECS to use an interface VPC endpoint. Interface endpoints are powered by AWS PrivateLink, a technology that enables you to privately access Amazon ECS APIs by using private IP addresses. PrivateLink restricts all network traffic between your VPC and Amazon ECS to the Amazon network. You don't need an internet gateway, NAT device, or virtual private gateway.

You can create VPC endpoints for Amazon ECS, Amazon ECS container agent, and Amazon ECS telemetry in the Region where your containers are deployed. VPC endpoints currently do not support cross-Region requests, so if you have a multi-Region deployment, consider following the recommendations in the Integrating cross VPC ECS cluster for enhanced security with AWS App Mesh blog post. For more information on building a scalable multi-Region architecture in AWS, refer to the Building a Scalable and Secure Multi-VPC AWS Network Infrastructure whitepaper. If you are using Amazon ECS’ integration with Secrets Manager or Systems Manager Parameter Store for sensitive data, you will also need to configure VPC endpoints for each of these services.

In addition to securing network traffic by restricting it to the AWS network, you can encrypt data in transit between your application and AWS services by enforcing the use of TLS 1.2 when using the AWS SDK for .NET. The following sections review the various approaches to using encryption in transit for applications running on Amazon ECS.

TLS termination at the load balancer

It’s a best practice to enforce TLS termination at the load balancer and both Application Load Balancers and Network Load Balancers support TLS termination. Terminating TLS connections at the load balancer frees up your backend containers from the work of encrypting and decrypting your traffic. Your containers handle plain HTTP requests while offloading the complexity of managing HTTPS connections to the Load Balancers.

This approach also simplifies certificate management since the certificates are now deployed to the load balancers instead of backend containers. Additionally, you can use AWS Certificate Manager at no charge to securely store, expire, rotate, and update your certificates. This process involves adding a TLS listener to your load balancer, configuring the backend container to listen on an unencrypted port, such as part 80 (HTTP), and configuring the listener on the load balancer to forward traffic to the unencrypted port used by your container. Refer to the TLS Termination for Network Load Balancers blog post for more information.

End-to-end encryption

Terminating TLS connections at the load balancer and using HTTP on the backend may be sufficient for your application. However, if you are developing an application that needs to comply with strict external regulations, you may be required to secure all network connections. You can configure the load balancer to either pass TLS traffic through untouched (terminate TLS at container), or decrypt and re-encrypt for end-to-end encryption.

Terminate TLS at the container level

This process involves adding an unencrypted listener to your load balancer, configuring backend containers to listen on the secure port and terminate HTTPS connections, and configuring the listener on the load balancer to forward traffic to the secure port used by the backend containers.

Decrypt and re-encrypt

This process involves adding a TLS listener to your load balancer, configuring backend containers to listen on the secure port, terminate HTTPS connections, using a self-signed certificate, and configuring the listener on the load balancer to forward traffic to the secure port used by the backend containers.