AWS AmazonECS documentation change
Summary
Improved grammar, clarified networking mode requirements, and enhanced IAM role best practices documentation
Security assessment
The change strengthens security guidance by emphasizing IAM role segregation ('Define each task definition with its own IAM role') as a best practice for least privilege access. However, this is a routine documentation improvement rather than a response to a specific security vulnerability.
Diff
diff --git a/AmazonECS/latest/developerguide/application_architecture.md b/AmazonECS/latest/developerguide/application_architecture.md index 61ac5bb99..20e8a5786 100644 --- a//AmazonECS/latest/developerguide/application_architecture.md +++ b//AmazonECS/latest/developerguide/application_architecture.md @@ -15 +15 @@ When you use the EC2 launch type, you also choose the instance type. For some in - * The networking mode to use for the containers in your task + * The networking mode to use for the containers in your task. @@ -19 +19 @@ The networking mode determines how your task communicates over the network. -For tasks that run on EC2 instance, there are multiple options, but we recommend that you use the `awsvpc` network mode. The `awsvpc` network mode simplifies container networking, because you have more control over how your applications communicate with each other and other services within your VPCs. +For tasks that run on EC2 instances, there are multiple options, but we recommend that you use the `awsvpc` network mode. The `awsvpc` network mode simplifies container networking by giving you more control over how your applications communicate with each other and other services within your VPCs. @@ -21 +21 @@ For tasks that run on EC2 instance, there are multiple options, but we recommend -For tasks that run on Fargate, you can only use the `awsvpc` network mode. +For tasks that run on Fargate, you must use the `awsvpc` network mode. @@ -36 +36 @@ Use the following guidelines when you create your task definitions: -If you group multiple types of application container together in the same task definition, you can’t independently scale those containers. For example, it's unlikely that both a website and an API require scaling out at the same rate. As traffic increases, there will be a different number of web containers required than API containers. If these two containers are being deployed in the same task definition, every task runs the same number of web containers and API containers. +If you group multiple types of application containers together in the same task definition, you can't independently scale those containers. For example, a website and an API typically require different scaling patterns. As traffic increases, you might need a different number of web containers than API containers. If these two containers are deployed in the same task definition, every task runs the same number of web containers and API containers. @@ -40 +40 @@ If you group multiple types of application container together in the same task d -Within a task definition family, consider each task definition revision as a point in time snapshot of the settings for a particular container image. This is similar to how the container is a snapshot of all the things that are needed to run a particular version of your application code. +Within a task definition family, each task definition revision represents a point-in-time snapshot of the settings for a particular container image. This is similar to how the container is a snapshot of all the components needed to run a particular version of your application code. @@ -42 +42 @@ Within a task definition family, consider each task definition revision as a poi -Make sure that there's a one-to-one mapping between a version of application code, a container image tag, and a task definition revision. A typical release process involves a git commit that gets turned into a container image that's tagged with the git commit SHA. Then, that container image tag gets its own Amazon ECS task definition revision. Last, the Amazon ECS service is updated to tell it to deploy the new task definition revision. +Create a one-to-one mapping between a version of application code, a container image tag, and a task definition revision. A typical release process involves a git commit that gets turned into a container image that's tagged with the git commit SHA. Then, that container image tag gets its own Amazon ECS task definition revision. Last, the Amazon ECS service is updated to deploy the new task definition revision. @@ -46 +46 @@ Make sure that there's a one-to-one mapping between a version of application cod -Define each task definition with its own IAM role. This recommendation should be done in tandem with our recommendation for providing each business component its own task definition family. By implementing both of these best practices, you can limit how much access each service has to resources in your AWS account. For example, you can give your authentication service access to connect to your passwords database. At the same time, you can also ensure that only your order service has access to the credit card payment information. +Define each task definition with its own IAM role. Implement this practice along with providing each business component its own task definition family. By implementing both of these best practices, you can limit how much access each service has to resources in your AWS account. For example, you can give your authentication service access to connect to your passwords database. At the same time, you can ensure that only your order service has access to the credit card payment information.