AWS AmazonECS documentation change
Summary
Rewrote service scheduling strategy documentation to focus on infrastructure compute options (capacity provider strategy vs launch type), added sections for service auto scaling, load balancing, and interconnecting services. Removed detailed explanations of daemon/replica strategies.
Security assessment
The changes restructure architectural guidance but contain no references to vulnerabilities, access controls, encryption, or security best practices. The mention of VPC Lattice for secure interconnections is a general feature description without security implementation details.
Diff
diff --git a/AmazonECS/latest/developerguide/ecs_services.md b/AmazonECS/latest/developerguide/ecs_services.md index 6d7063cf0..1ff43ab41 100644 --- a//AmazonECS/latest/developerguide/ecs_services.md +++ b//AmazonECS/latest/developerguide/ecs_services.md @@ -5 +5 @@ -Daemon strategyReplica strategy +Infrastructure compute optionService auto scalingService load balancingInterconecting services @@ -28 +28 @@ The service scheduler includes logic that throttles how often tasks are restarte -There are two service scheduler strategies available: +## Infrastructure compute option @@ -30 +30 @@ There are two service scheduler strategies available: - * `REPLICA`—The replica scheduling strategy places and maintains the desired number of tasks across your cluster. By default, the service scheduler spreads tasks across Availability Zones. You can use task placement strategies and constraints to customize task placement decisions. For more information, see Replica strategy. +There are two compute options that distribute your tasks. @@ -32 +32 @@ There are two service scheduler strategies available: - * `DAEMON`—The daemon scheduling strategy deploys exactly one task on each active container instance that meets all of the task placement constraints that you specify in your cluster. When using this strategy, there is no need to specify a desired number of tasks, a task placement strategy, or use Service Auto Scaling policies. For more information, see Daemon strategy. + * A capacity provider strategy causes Amazon ECS to distribute your tasks in one or across multiple capacity providers. @@ -34 +34 @@ There are two service scheduler strategies available: -###### Note +For the **capacity provider strategy** , the console selects a compute option by default. The following describes the order that the console uses to select a default: @@ -36 +36 @@ There are two service scheduler strategies available: -Fargate tasks do not support the `DAEMON` scheduling strategy. + * If your cluster has a default capacity provider strategy defined, it is selected. @@ -37,0 +38 @@ Fargate tasks do not support the `DAEMON` scheduling strategy. + * If your cluster doesn't have a default capacity provider strategy defined but you have the Fargate capacity providers added to the cluster, a custom capacity provider strategy that uses the `FARGATE` capacity provider is selected. @@ -38,0 +40 @@ Fargate tasks do not support the `DAEMON` scheduling strategy. + * If your cluster doesn't have a default capacity provider strategy defined but you have one or more Auto Scaling group capacity providers added to the cluster, the **Use custom (Advanced)** option is selected and you need to manually define the strategy. @@ -39,0 +42 @@ Fargate tasks do not support the `DAEMON` scheduling strategy. + * If your cluster doesn't have a default capacity provider strategy defined and no capacity providers added to the cluster, the Fargate launch type is selected. @@ -41 +44 @@ Fargate tasks do not support the `DAEMON` scheduling strategy. -## Daemon strategy + * A launch type causes Amazon ECS to launch our tasks directly on either Fargate or on the EC2 instances registered to your clusters. @@ -43 +46 @@ Fargate tasks do not support the `DAEMON` scheduling strategy. -The _daemon_ scheduling strategy deploys exactly one task on each active container instance that meets all of the task placement constraints specified in your cluster. The service scheduler evaluates the task placement constraints for running tasks, and stops tasks that don't meet the placement constraints. When you use this strategy, you don't need to specify a desired number of tasks, a task placement strategy, or use Service Auto Scaling policies. +By default the service starts in the subnets in your cluster VPC. @@ -45 +47,0 @@ The _daemon_ scheduling strategy deploys exactly one task on each active contain -Amazon ECS reserves container instance compute resources including CPU, memory, and network interfaces for the daemon tasks. When you launch a daemon service on a cluster with other replica services, Amazon ECS prioritizes the daemon task. This means that the daemon task is the first task to launch on the instances and the last task to stop after all replica tasks are stopped. This strategy ensures that resources aren't used by pending replica tasks and are available for the daemon tasks. Note that there might be times when your daemon strategy services can't start because the replica strategy service start faster and the CPU and memory resources aren't available for the strategy service. @@ -47 +48,0 @@ Amazon ECS reserves container instance compute resources including CPU, memory, -The daemon service scheduler doesn't place any tasks on instances that have a `DRAINING` status. If a container instance transitions to a `DRAINING` status, the daemon tasks on it are stopped. The service scheduler also monitors when new container instances are added to your cluster and adds the daemon tasks to them. @@ -49 +49,0 @@ The daemon service scheduler doesn't place any tasks on instances that have a `D -When you specify a deployment configuration, the value for the `maximumPercent` parameter must be `100` (specified as a percentage), which is the default value used if not set. The default value for the `minimumHealthyPercent` parameter is `0` (specified as a percentage). @@ -51 +51 @@ When you specify a deployment configuration, the value for the `maximumPercent` -You must restart the service when you change the placement constraints for the daemon service. Amazon ECS dynamically updates the resources that are reserved on qualifying instances for the daemon task. For existing instances, the scheduler tries to place the task on the instance. +## Service auto scaling @@ -53 +53 @@ You must restart the service when you change the placement constraints for the d -A new deployment starts when there is a change to the task size or container resource reservation in the task definition. A new deployment also starts when updating a service or setting a different revision of the task definition. Amazon ECS picks up the updated CPU and memory reservations for the daemon, and then blocks that capacity for the daemon task. +Service auto scaling is the ability to increase or decrease the desired number of tasks in your Amazon ECS service automatically. Amazon ECS leverages the Application Auto Scaling service to provide this functionality. @@ -55 +55 @@ A new deployment starts when there is a change to the task size or container res -If there are insufficient resources for either of the above cases, the following happens: +For more information, see [Automatically scale your Amazon ECS service](./service-auto-scaling.html). @@ -57 +57 @@ If there are insufficient resources for either of the above cases, the following - * The task placement fails. +## Service load balancing @@ -59 +59 @@ If there are insufficient resources for either of the above cases, the following - * A CloudWatch event is generated. +Amazon ECS services hosted on AWS Fargate support the Application Load Balancers, Network Load Balancers, and Gateway Load Balancers. Use the following table to learn about what type of load balancer to use. @@ -61 +61,3 @@ If there are insufficient resources for either of the above cases, the following - * Amazon ECS continues to try and schedule the task on the instance by waiting for resources to become available. +Load Balancer type | Use in these cases +---|--- +Application Load Balancer | Route HTTP/HTTPS (or layer 7) traffic.Application Load Balancers offer several features that make them attractive for use with Amazon ECS services: @@ -63 +65,4 @@ If there are insufficient resources for either of the above cases, the following - * Amazon ECS frees up any reserved instances that no longer meet the placement constraint criteria and stops the corresponding daemon tasks. + * Each service can serve traffic from multiple load balancers and expose multiple load balanced ports by specifying multiple target groups. + * They are supported by tasks hosted on both Fargate and EC2 instances. + * Application Load Balancers allow containers to use dynamic host port mapping (so that multiple tasks from the same service are allowed per container instance). + * Application Load Balancers support path-based routing and priority rules (so that multiple services can use the same listener port on a single Application Load Balancer). @@ -65,0 +71,2 @@ If there are insufficient resources for either of the above cases, the following +Network Load Balancer | Route TCP or UDP (or layer 4) traffic. +Gateway Load Balancer | Route TCP or UDP (or layer 4) traffic. Use virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems. @@ -66,0 +74 @@ If there are insufficient resources for either of the above cases, the following +For more information, see [Use load balancing to distribute Amazon ECS service traffic](./service-load-balancing.html). @@ -68 +76 @@ If there are insufficient resources for either of the above cases, the following -The daemon scheduling strategy can be used in the following cases: +## Interconecting services @@ -70 +78 @@ The daemon scheduling strategy can be used in the following cases: - * Running application containers +If you need an application to connect to other applications that run as Amazon ECS services, Amazon ECS provides the following ways to do this without a load balancer: @@ -72 +80 @@ The daemon scheduling strategy can be used in the following cases: - * Running support containers for logging, monitoring and tracing tasks + * Service Connect - Allows for service-to-service communications with automatic discovery using short names and standard ports. @@ -73,0 +82 @@ The daemon scheduling strategy can be used in the following cases: + * Service discovery - Service discovery uses Route 53 to create a namespace for your service, which allows it to be discoverable through DNS. @@ -74,0 +84 @@ The daemon scheduling strategy can be used in the following cases: + * Amazon VPC Lattice - VPC Lattice is a ully managed application networking service to connect, secure, and monitor your services across multiple accounts and VPCs. There is a cost associated with it. @@ -77 +86,0 @@ The daemon scheduling strategy can be used in the following cases: -Tasks using the Fargate launch type or the `CODE_DEPLOY` or `EXTERNAL` deployment controller types don't support the daemon scheduling strategy. @@ -79 +87,0 @@ Tasks using the Fargate launch type or the `CODE_DEPLOY` or `EXTERNAL` deploymen -When the service scheduler stops running tasks, it attempts to maintain balance across the Availability Zones in your cluster. The scheduler uses the following logic: @@ -81,37 +89 @@ When the service scheduler stops running tasks, it attempts to maintain balance - * If a placement strategy is defined, use that strategy to select which tasks to terminate. For example, if a service has an Availability Zone spread strategy defined, a task is selected that leaves the remaining tasks with the best spread. - - * If no placement strategy is defined, use the following logic to maintain balance across the Availability Zones in your cluster: - - * Sort the valid container instances. Give priority to instances that have the largest number of running tasks for this service in their respective Availability Zone. For example, if zone A has one running service task and zones B and C each have two running service task, container instances in either zone B or C are considered optimal for termination. - - * Stop the task on a container instance in an optimal Availability Zone based on the previous steps. Favoring container instances with the largest number of running tasks for this service. - - - - -## Replica strategy - -The _replica_ scheduling strategy places and maintains the desired number of tasks in your cluster. - -For a service that runs tasks on Fargate, when the service scheduler launches new tasks or stops running tasks, the service scheduler uses a best attempt to maintain a balance across Availability Zones. You don't need to specify task placement strategies or constraints. - -When you create a service that runs tasks on EC2 instances, you can optionally specify task placement strategies and constraints to customize task placement decisions. If no task placement strategies or constraints are specified, then by default the service scheduler spreads the tasks across Availability Zones. The service scheduler uses the following logic: - - * Determines which of the container instances in your cluster can support your service's task definition (for example, required CPU, memory, ports, and container instance attributes). - - * Determines which container instances satisfy any placement constraints that are defined for the service. - - * When you have a replica service that depends on a daemon service (for example, a daemon log router task that needs to be running before tasks can use logging), create a task placement constraint that ensures that the daemon service tasks get placed on the EC2 instance prior to the replica service tasks. For more information, see [Example Amazon ECS task placement constraints](./constraint-examples.html). - - * When there's a defined placement strategy, use that strategy to select an instance from the remaining candidates. - - * When there's no defined placement strategy, use the following logic to balance tasks across the Availability Zones in your cluster: - - * Sorts the valid container instances. Gives priority to instances that have the fewest number of running tasks for this service in their respective Availability Zone. For example, if zone A has one running service task and zones B and C each have zero, valid container instances in either zone B or C are considered optimal for placement. - - * Places the new service task on a valid container instance in an optimal Availability Zone based on the previous steps. Favors container instances with the fewest number of running tasks for this service. - - - - -We recommend that you use the service rebalacing feature when you use the `REPLICA` strategy because it helps ensure high availability for you service. +For more information, see [Interconnect Amazon ECS services](./interconnecting-services.html). @@ -127 +99 @@ Stopping a task -Availability Zone rebalancing +Service deployment controllers and strategies