Best Practices Guide - Docs.aws.amazon
Amazon Elastic Container ServiceBest Practices Guide
Amazon Elastic Container Service Best Practices GuideAmazon Elastic Container Service: Best Practices GuideCopyright 2022 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.Amazon's trademarks and trade dress may not be used in connection with any product or service that is notAmazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages ordiscredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who mayor may not be affiliated with, connected to, or sponsored by Amazon.
Amazon Elastic Container Service Best Practices GuideTable of ContentsIntroduction . 1Running your application . 2Container image . 2Make container images complete and static . 3Maintain fast container launch times by keeping container images as small as possible . 3Only run a single application process with a container image . 4Handle SIGTERM within the application . 5Configure containerized applications to write logs to stdout and stderr . 6Version container images using tags . 7Task definition . 7Use each task definition family for only one business purpose . 7Match each application version with a task definition revision within a task definition family . 9Use different IAM roles for each task definition family . 9Amazon ECS service . 10Use awsvpc network mode and give each service its own security group . 10Enable Amazon ECS managed tags and tag propagation . 11Networking . 12Connecting to the internet . 12Using a public subnet and internet gateway . 13Using a private subnet and NAT gateway . 14Receiving inbound connections from the internet . 15Application Load Balancer . 15Network Load Balancer . 16Amazon API Gateway HTTP API . 18Choosing a network mode . 19Host mode . 19Bridge mode . 20AWSVPC mode . 22Connecting to AWS services . 26NAT gateway . 26AWS PrivateLink . 27Networking between Amazon ECS services . 27Using service discovery . 28Using an internal load balancer . 29Using a service mesh . 30Networking services across AWS accounts and VPCs . 31Optimizing and troubleshooting . 31CloudWatch Container Insights . 31AWS X-Ray . 32VPC Flow Logs . 33Network tuning tips . 33Auto scaling and capacity management . 34Determining task size . 34Stateless applications . 34Other applications . 35Configuring service auto scaling . 35Characterizing your application . 35Capacity and availability . 38Maximizing scaling speed . 39Handling demand shocks . 40Cluster capacity . 41Choosing Fargate task sizes . 42Speeding up cluster auto scaling . 42Capacity provider step scaling sizes . 42iii
Amazon Elastic Container Service Best Practices GuideInstance warm-up period .Spare capacity .Choosing the Amazon EC2 instance type .Using Amazon EC2 Spot and FARGATE SPOT .Persistent storage .Choosing the right storage type .Amazon EFS .Security and access controls .Performance .Throughput .Cost optimization .Data protection .Use cases .Docker volumes .Amazon EBS volume lifecycle .Amazon EBS data availability .Docker volume plugins .FSx for Windows File Server .Security and access controls .Use cases .Speeding up task launch .Task launch workflow .Service workflow .Speeding up deployment .Load balancer health check parameters .Load balancer connection draining .SIGTERM responsiveness .Container image type .Container image pull behavior .Container image pull behavior for Fargate launch types .Container image pull behavior for Windows AMIs on Fargate launch types .Container image pull behavior for Amazon EC2 launch types .Task deployment .Operating at scale .Service quotas and API throttling limits .Elastic Load Balancing .Elastic network interfaces .AWS Cloud Map .Handling throttling issues .Synchronous throttling .Asynchronous throttling .Monitoring throttling .Using CloudWatch to monitor throttling .Security .Shared responsibility model .AWS Identity and Access Management .Managing access to Amazon ECS .Recommendations .Using IAM roles with Amazon ECS tasks .Task execution role .Amazon EC2 container instance role .Service-linked roles .Recommendations .Network security .Encryption in transit .Task networking 57778797980818182
Amazon Elastic Container Service Best Practices GuideService mesh and Mutual Transport Layer Security (mTLS) .AWS PrivateLink .Amazon ECS container agent settings .Recommendations .Secrets management .Recommendations .Additional resources .Using temporary security credentials with API operations .Compliance .Payment Card Industry Data Security Standards (PCI DSS) .HIPAA (U.S. Health Insurance Portability and Accountability Act) .Recommendations .Logging and monitoring .Container logging with Fluent Bit .Custom log routing - FireLens for Amazon ECS .AWS Fargate security .Use AWS KMS to encrypt ephemeral storage .SYS PTRACE capability for kernel syscall tracing .AWS Fargate security considerations .Task and container security .Recommendations .Runtime security .Recommendations .AWS Partners .Document history 96
Amazon Elastic Container Service Best Practices GuideIntroductionAmazon Elastic Container Service (Amazon ECS) is a highly scalable and fast container managementservice that you can use to manage containers on a cluster. This guide covers many of the mostimportant operational best practices for Amazon ECS. It also describes several core concepts that areinvolved in how Amazon ECS based applications work. The goal is to provide a concrete and actionableapproach to operating and troubleshooting Amazon ECS based applications.This guide is revised regularly to incorporate new Amazon ECS best practices as they're established. Ifyou have any questions or comments about any of the content in this guide, raise an issue in the GitHubrepository. For more information, see Amazon ECS Best Practices Guide on GitHub. Best Practices - Running your application with Amazon ECS (p. 2) Best Practices - Networking (p. 12) Best Practices - Auto scaling and capacity management (p. 34) Best Practices - Persistent storage (p. 45) Best Practices - Speeding up task launch (p. 55) Best Practices - Speeding up deployments (p. 58) Best Practices - Operating Amazon ECS at scale (p. 67) Best Practices - Security (p. 73)1
Amazon Elastic Container Service Best Practices GuideContainer imageBest Practices - Running yourapplication with Amazon ECSBefore you run an application using Amazon Elastic Container Service, make sure that you understandhow the various aspects of your application work with features in Amazon ECS. This guide covers themain Amazon ECS resources types, what they're used for, and best practices for using each of theseresource types.Container imageA container image holds your application code and all the dependencies that your application coderequires to run. Application dependencies include the source code packages that your application coderelies on, a language runtime for interpreted languages, and binary packages that your dynamicallylinked code relies on.Container images go through a three-step process.1. Build - Gather your application and all its dependencies into one container image.2. Store - Upload the container image to a container registry.3. Run - Download the container image on some compute, unpack it, and start the application.When you create your own container image, keep in mind the best practices described in the followingsections.2
Amazon Elastic Container Service Best Practices GuideMake container images complete and staticMake container images complete and staticIdeally, a container image is intended to be a complete snapshot of everything that the applicationrequires to function. With a complete container image, you can run an application by downloading onecontainer image from one place. You don't need to download several separate pieces from differentlocations. Therefore, as a best practice, store all application dependencies as static files inside thecontainer image.At the same time, don't dynamically download libraries, dependencies, or critical data during applicationstartup. Instead, include these things as static files in the container image. Later on, if you want tochange something in the container image, build a new container image with the changes applied to it.There are a few reasons why we recommend this best practice. Including all dependencies as static files in the container image reduces the number of potentiallybreaking events that can happen during deployments. As you scale out to tens, hundreds, or eventhousands of copies of your container, downloading a single container image rather than downloadingfrom two or three different places simplifies your workload by limiting potential breaking points.For example, assume that you're deploying 100 copies of your application, and each copy of theapplication has to download pieces from three different sources. There are 300 downloads that canfail. If you're downloading a container image, there's only 100 dependencies that can break. Container image downloads are optimized for downloading the application dependencies in parallel.By default, a container image is made up of layers that can be downloaded and unpacked in parallel.This means that a container image download can get all of your dependencies onto your computefaster than a hand coded script that downloads each dependency in a series. By keeping all your dependencies inside of the image, your deployments are more reliable andreproducible. If you change a dynamically loaded dependency, it might break the application inside thecontainer image. However, if the container is truly standalone, you can always redeploy it, even in thefuture. This is because it already has the right versions and right dependencies inside of it.Maintain fast container launch times by keepingcontainer images as small as possibleComplete containers hold everything that's needed to run your application, but they don't need toinclude your build tools. Consider this example. Assume that you're building a container for a Node.jsapplication. You must have the NPM package manager to download packages for your application.However, you no longer need NPM itself when the application runs. You can use a multistage Dockerbuild to solve this.The following is an example of what such a multistage Dockerfile might look like for a Node.jsapplication that has dependencies in NPM.FROM node:14 AS build3
Amazon Elastic Container Service Best Practices GuideOnly run a single applicationprocess with a container imageWORKDIR /srvADD package.json .RUN npm installFROM node:14-slimCOPY --from build /srv .ADD . .EXPOSE 3000CMD ["node", "index.js"]The first stage uses a full Node.js environment that has NPM, and a compiler for building native codebindings for packages. The second stage includes nothing but the Node.js runtime. It can copy thedownloaded NPM packages out of the first stage. The final product is a minimal image that has theNode.js runtime, the NPM packages, and the application code. It doesn't include the full NPM buildtoolchain.Keep your container images as small as possible and use shared layers. For example, if you have multipleapplications that use the same data set, you can create a shared base image that has that data set. Then,build two different image variants off of the same shared base image. This allows the container imagelayer with the dataset to be downloaded one time, rather than twice.The main benefit of using smaller container images is that these images can be downloaded ontocompute hardware faster. This allows your application to scale out faster and quickly recover fromunexpected crashes or restarts.Only run a single application process with a containerimageIn a traditional virtual machine environment, it's typical to run a high-level daemon like systemd as theroot process. This daemon is then responsible for starting your application process, and restarting theapplication process if it crashes. We don't recommend this when using containers. Instead, only run asingle application process with a container.If the application process crashes or ends, the container also ends. If the application must be restarted oncrash, let Amazon ECS manage the application restart externally. The Amazon ECS agent reports to theAmazon ECS control plane that the application container crashed. Then, the control plane determineswhether to launch a replacement container, and if so where to launch it. The replacement container maybe placed onto the same host, or onto a different host in the cluster.Treat containers as ephemeral resources. They only last for the lifetime of the main application process.Don't keep restarting application processes inside of a container, to try to keep the container up andrunning. Let Amazon ECS replace containers as needed.4
Amazon Elastic Container Service Best Practices GuideHandle SIGTERM within the applicationThis best practice has two key benefits. It mitigates scenarios where an application crashed because of a mutation to the local containerfilesystem. Instead of reusing the same mutated container environment, the orchestrator launches anew container based off the original container image. This means that you can be confident that thereplacement container is running a clean, baseline environment. Crashed processes are replaced through a centralized decision making process in the Amazon ECScontrol plane. The control plane makes smarter choices about where to launch the replacementprocess. For example, the control plane can attempt to launch the replacement onto differenthardware in a different Availability Zone. This makes the overall deployment more resilient than if eachindividual compute instance attempts to relaunch its own processes locally.Handle SIGTERM within the applicationWhen you're following the guidance of the previous section, you're allowing Amazon ECS to replacetasks elsewhere in the cluster, rather than restart the crashing application. There are other times when atask may be stopped that are outside the application's control. Tasks may be stopped due to applicationerrors, health check failures, completion of business workflows or even manual termination by a user.When a task is stopped by ECS, ECS follows the steps and configuration shown in SIGTERMresponsiveness (p. 61).To prepare your application, you need to identify how long it takes your application to complete its work,and ensure that your applications handles the SIGTERM signal. Within the application's signal handling,you need to stop the application from taking new work and complete the work that is in-progress, orsave unfinished work to storage outside of the task if it would take too long to complete.After sending the SIGTERM signal, Amazon ECS will wait for the time specified in the StopTimeout inthe task definition. Then, the SIGKILL signal will be sent. Set the StopTimeout long enough that yourapplication completes the SIGTERM handler in all situations before the SIGKILL is sent.For web applications, you also need to consider open connections that are idle. See the following page ofthis guide for more details Network Load Balancer (p. 16).5
Amazon Elastic Container Service Best Practices GuideConfigure containerized applicationsto write logs to stdout and stderrIf you use an init process in your container, use a lightweight init process such as tini. This init processtakes on the responsibility of reaping zombie processes if your application spawns worker processes. Ifyour application doesn't handle the SIGTERM signal properly, tini can catch that signal for you andterminate your application process. However, if your application process crashes tini doesn't restart it.Instead tini exits, allowing the container to end and be replaced by container orchestration. For moreinformation, see tini on GitHub.Configure containerized applications to write logs tostdout and stderrThere are many different ways to do logging. For some application frameworks, it's common to use anapplication logging library that writes directly to disk files. It's also common to use one that streamslogs directly to an ELK (OpenSearch, Logstash, Kibana) stack or a similar logging setup. However, werecommend that, when an application is containerized, you configure it to write application logs directlyto the stdout and stderr streams.Docker includes a variety of logging drivers that take the stdout and stderr log streams and handlethem. You can choose to write the streams to syslog, to disk on the local instance that's runningthe container, or use a logging driver to send the logs to Fluentd, Splunk, CloudWatch, and otherdestinations. With Amazon ECS, you can choose to configure the FireLens logging driver. This drivercan attach Amazon ECS metadata to logs, filter logs, and route logs to different destinations based oncriteria su
This guide is revised regularly to incorporate new Amazon ECS best practices as they're established. If you have any questions or comments about any of the content in this guide, raise an issue in the GitHub repository. For more information, see Amazon ECS Best Practices Guide on GitHub. Best Practices - Running your application with Amazon .
4 AWS Training & Services AWS Essentials Training AWS Cloud Practitioner Essentials (CP-ESS) AWS Technical Essentials (AWSE) AWS Business Essentials (AWSBE) AWS Security Essentials (SEC-ESS) AWS System Architecture Training Architecting on AWS (AWSA) Advanced Architecting on AWS (AWSAA) Architecting on AWS - Accelerator (ARCH-AX) AWS Development Training
AWS SDK for JavaScript AWS SDK for JavaScript code examples AWS SDK for .NET AWS SDK for .NET code examples AWS SDK for PHP AWS SDK for PHP code examples AWS SDK for Python (Boto3) AWS SDK for Python (Boto3) code examples AWS SDK for Ruby AWS SDK for Ruby co
AWS Directory Amazon Aurora R5 instance Service AWS Server Migration Service AWS Snowball AWS Deep Amazon GameLift Learning AMIs AWS CodeBuild AWS CodeDeploy AWS Database Migration Service Amazon Polly 26 26 20 40 12 0 5 10 15 20 25 30 35 40 45 2018 Q1 2018 Q2 2018 Q3 2018 Q4 2019 Q1 New Services& Features on AWS
AWS instances with Nessus while in development and operations, before publishing to AWS users. Tenable Network Security offers two products on the AWS environment: Nessus for AWS is a Nessus Enterprise instance already available in the AWS Marketplace. Tenable Nessus for AWS provides pre-authorized scanning in the AWS cloud via AWS instance ID.
pa/1g pa/1f pb/2f pc/2g pd/4f 156 pf/3g pf/3f pg/3g pg/3f en: pcfileur welding positions aws: 1g en: pa aws: 1f aws: 2g en: pc aws: 2f en: pb aws: 3g en: pg down en: pf up aws: 3f down en: pf aws: 4g en: pe aws: 4f en: pd 156
AWS Serverless Application Model Developer Guide Benefits of using AWS SAM What is the AWS Serverless Application Model (AWS SAM)? The AWS Serverless Application Model (AWS SAM) is an open-source framework that you can use to build serverless applications on AWS.
BSR/AWS B5.16-200x, Specification for the Qualification of Welding Engineers (revision of ANSI/AWS B5.16-2001) Obtain an electronic copy from: roneill@aws.org Order from: R. O’Neill, AWS; roneill@aws.org Send comments (with copy to BSR) to: Andrew Davis, AWS; adavis@aws.org; roneill@aws.org Single copy price: 25.00
Amazon Web Services Cloud Platform The Cloud Computing Difference AWS Cloud Economics AWS Virtuous Cycle AWS Cloud Architecture Design Principles Why AWS for Big Data - Reasons Why AWS for Big Data - Challenges Databases in AWS Relational vs Non-Relational Databases Data Warehousing in AWS Services for Collecting, Processing, Storing, and .
