Amazon EC2 Container Service Update: Amazon ECS Service Connect now supports Envoy access logs, providing deeper observability into request-level traffic patterns and service interactions.

Author: AWS

.changes/next-release/feature-AmazonEC2ContainerService-0711719.json

@@ -0,0 +1,6 @@
+{
+    "type": "feature",
+    "category": "Amazon EC2 Container Service",
+    "contributor": "",
+    "description": "Amazon ECS Service Connect now supports Envoy access logs, providing deeper observability into request-level traffic patterns and service interactions."
+}

services/ecs/src/main/resources/codegen-resources/service-2.json

@@ -1361,7 +1361,7 @@
     "BlockedException":{
       "type":"structure",
       "members":{},
-      "documentation":"<p>Your Amazon Web Services account was blocked. For more information, contact <a href=\"http://aws.amazon.com/contact-us/\"> Amazon Web ServicesSupport</a>.</p>",
+      "documentation":"<p>Your Amazon Web Services account was blocked. For more information, contact <a href=\"http://aws.amazon.com/contact-us/\"> Amazon Web Services Support</a>.</p>",
       "exception":true
     },
     "Boolean":{"type":"boolean"},
@@ -1848,7 +1848,7 @@
         },
         "cpu":{
           "shape":"Integer",
-          "documentation":"<p>The number of <code>cpu</code> units reserved for the container. This parameter maps to <code>CpuShares</code> in the docker container create commandand the <code>--cpu-shares</code> option to docker run.</p> <p>This field is optional for tasks using the Fargate launch type, and the only requirement is that the total amount of CPU reserved for all containers within a task be lower than the task-level <code>cpu</code> value.</p> <note> <p>You can determine the number of CPU units that are available per EC2 instance type by multiplying the vCPUs listed for that instance type on the <a href=\"http://aws.amazon.com/ec2/instance-types/\">Amazon EC2 Instances</a> detail page by 1,024.</p> </note> <p>Linux containers share unallocated CPU units with other containers on the container instance with the same ratio as their allocated amount. For example, if you run a single-container task on a single-core instance type with 512 CPU units specified for that container, and that's the only task running on the container instance, that container could use the full 1,024 CPU unit share at any given time. However, if you launched another copy of the same task on that container instance, each task is guaranteed a minimum of 512 CPU units when needed. Moreover, each container could float to higher CPU usage if the other container was not using it. If both tasks were 100% active all of the time, they would be limited to 512 CPU units.</p> <p>On Linux container instances, the Docker daemon on the container instance uses the CPU value to calculate the relative CPU share ratios for running containers. The minimum valid CPU share value that the Linux kernel allows is 2, and the maximum valid CPU share value that the Linux kernel allows is 262144. However, the CPU parameter isn't required, and you can use CPU values below 2 or above 262144 in your container definitions. For CPU values below 2 (including null) or above 262144, the behavior varies based on your Amazon ECS container agent version:</p> <ul> <li> <p> <b>Agent versions less than or equal to 1.1.0:</b> Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of 1 are passed to Docker as 1, which the Linux kernel converts to two CPU shares.</p> </li> <li> <p> <b>Agent versions greater than or equal to 1.2.0:</b> Null, zero, and CPU values of 1 are passed to Docker as 2.</p> </li> <li> <p> <b>Agent versions greater than or equal to 1.84.0:</b> CPU values greater than 256 vCPU are passed to Docker as 256, which is equivalent to 262144 CPU shares.</p> </li> </ul> <p>On Windows container instances, the CPU limit is enforced as an absolute limit, or a quota. Windows containers only have access to the specified amount of CPU that's described in the task definition. A null or zero CPU value is passed to Docker as <code>0</code>, which Windows interprets as 1% of one CPU.</p>"
+          "documentation":"<p>The number of <code>cpu</code> units reserved for the container. This parameter maps to <code>CpuShares</code> in the docker container create command and the <code>--cpu-shares</code> option to docker run.</p> <p>This field is optional for tasks using the Fargate launch type, and the only requirement is that the total amount of CPU reserved for all containers within a task be lower than the task-level <code>cpu</code> value.</p> <note> <p>You can determine the number of CPU units that are available per EC2 instance type by multiplying the vCPUs listed for that instance type on the <a href=\"http://aws.amazon.com/ec2/instance-types/\">Amazon EC2 Instances</a> detail page by 1,024.</p> </note> <p>Linux containers share unallocated CPU units with other containers on the container instance with the same ratio as their allocated amount. For example, if you run a single-container task on a single-core instance type with 512 CPU units specified for that container, and that's the only task running on the container instance, that container could use the full 1,024 CPU unit share at any given time. However, if you launched another copy of the same task on that container instance, each task is guaranteed a minimum of 512 CPU units when needed. Moreover, each container could float to higher CPU usage if the other container was not using it. If both tasks were 100% active all of the time, they would be limited to 512 CPU units.</p> <p>On Linux container instances, the Docker daemon on the container instance uses the CPU value to calculate the relative CPU share ratios for running containers. The minimum valid CPU share value that the Linux kernel allows is 2, and the maximum valid CPU share value that the Linux kernel allows is 262144. However, the CPU parameter isn't required, and you can use CPU values below 2 or above 262144 in your container definitions. For CPU values below 2 (including null) or above 262144, the behavior varies based on your Amazon ECS container agent version:</p> <ul> <li> <p> <b>Agent versions less than or equal to 1.1.0:</b> Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of 1 are passed to Docker as 1, which the Linux kernel converts to two CPU shares.</p> </li> <li> <p> <b>Agent versions greater than or equal to 1.2.0:</b> Null, zero, and CPU values of 1 are passed to Docker as 2.</p> </li> <li> <p> <b>Agent versions greater than or equal to 1.84.0:</b> CPU values greater than 256 vCPU are passed to Docker as 256, which is equivalent to 262144 CPU shares.</p> </li> </ul> <p>On Windows container instances, the CPU limit is enforced as an absolute limit, or a quota. Windows containers only have access to the specified amount of CPU that's described in the task definition. A null or zero CPU value is passed to Docker as <code>0</code>, which Windows interprets as 1% of one CPU.</p>"
         },
         "memory":{
           "shape":"BoxedInteger",
@@ -5560,7 +5560,7 @@
         },
         "runtimePlatform":{
           "shape":"RuntimePlatform",
-          "documentation":"<p>The operating system that your tasks definitions run on. A platform family is specified only for tasks using the Fargate launch type. </p>"
+          "documentation":"<p>The operating system that your tasks definitions run on.</p>"
         },
         "enableFaultInjection":{
           "shape":"BoxedBoolean",
@@ -5804,7 +5804,7 @@
       "members":{
         "cpuArchitecture":{
           "shape":"CPUArchitecture",
-          "documentation":"<p>The CPU architecture.</p> <p>You can run your Linux tasks on an ARM-based platform by setting the value to <code>ARM64</code>. This option is available for tasks that run on Linux Amazon EC2 instance or Linux containers on Fargate.</p>"
+          "documentation":"<p>The CPU architecture.</p> <p>You can run your Linux tasks on an ARM-based platform by setting the value to <code>ARM64</code>. This option is available for tasks that run on Linux Amazon EC2 instance, Amazon ECS Managed Instances, or Linux containers on Fargate.</p>"
         },
         "operatingSystemFamily":{
           "shape":"OSFamily",
@@ -6017,6 +6017,29 @@
       },
       "documentation":"<p>Details on a service within a cluster.</p>"
     },
+    "ServiceConnectAccessLogConfiguration":{
+      "type":"structure",
+      "required":["format"],
+      "members":{
+        "format":{
+          "shape":"ServiceConnectAccessLoggingFormat",
+          "documentation":"<p>The format for Service Connect access log output. Choose TEXT for human-readable logs or JSON for structured data that integrates well with log analysis tools.</p>"
+        },
+        "includeQueryParameters":{
+          "shape":"ServiceConnectIncludeQueryParameters",
+          "documentation":"<p>Specifies whether to include query parameters in Service Connect access logs.</p> <p>When enabled, query parameters from HTTP requests are included in the access logs. Consider security and privacy implications when enabling this feature, as query parameters may contain sensitive information such as request IDs and tokens. By default, this parameter is <code>DISABLED</code>.</p>"
+        }
+      },
+      "documentation":"<p>Configuration for Service Connect access logging. Access logs provide detailed information about requests made to your service, including request patterns, response codes, and timing data for debugging and monitoring purposes.</p> <note> <p>To enable access logs, you must also specify a <code>logConfiguration</code> in the <code>serviceConnectConfiguration</code>.</p> </note>"
+    },
+    "ServiceConnectAccessLoggingFormat":{
+      "type":"string",
+      "documentation":"<p>The format for Service Connect access log output. Choose TEXT for human-readable logs or JSON for structured data that integrates well with log analysis tools.</p>",
+      "enum":[
+        "TEXT",
+        "JSON"
+      ]
+    },
     "ServiceConnectClientAlias":{
       "type":"structure",
       "required":["port"],
@@ -6056,10 +6079,22 @@
           "shape":"ServiceConnectServiceList",
           "documentation":"<p>The list of Service Connect service objects. These are names and aliases (also known as endpoints) that are used by other Amazon ECS services to connect to this service. </p> <p>This field is not required for a \"client\" Amazon ECS service that's a member of a namespace only to connect to other services within the namespace. An example of this would be a frontend application that accepts incoming requests from either a load balancer that's attached to the service or by other means.</p> <p>An object selects a port from the task definition, assigns a name for the Cloud Map service, and a list of aliases (endpoints) and ports for client applications to refer to this service.</p>"
         },
-        "logConfiguration":{"shape":"LogConfiguration"}
+        "logConfiguration":{"shape":"LogConfiguration"},
+        "accessLogConfiguration":{
+          "shape":"ServiceConnectAccessLogConfiguration",
+          "documentation":"<p>The configuration for Service Connect access logging. Access logs capture detailed information about requests made to your service, including request patterns, response codes, and timing data. They can be useful for debugging connectivity issues, monitoring service performance, and auditing service-to-service communication for security and compliance purposes.</p> <note> <p>To enable access logs, you must also specify a <code>logConfiguration</code> in the <code>serviceConnectConfiguration</code>.</p> </note>"
+        }
       },
       "documentation":"<p>The Service Connect configuration of your Amazon ECS service. The configuration for this service to discover and connect to services, and be discovered by, and connected from, other services within a namespace.</p> <p>Tasks that run in a namespace can use short names to connect to services in the namespace. Tasks can connect to services across all of the clusters in the namespace. Tasks connect through a managed proxy container that collects logs and metrics for increased visibility. Only the tasks that Amazon ECS services create are supported with Service Connect. For more information, see <a href=\"https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html\">Service Connect</a> in the <i>Amazon Elastic Container Service Developer Guide</i>.</p>"
     },
+    "ServiceConnectIncludeQueryParameters":{
+      "type":"string",
+      "documentation":"<p>Controls whether query parameters are included in Service Connect access logs. Consider security and privacy implications when enabling this feature. By default, this parameter is <code>DISABLED</code>.</p>",
+      "enum":[
+        "DISABLED",
+        "ENABLED"
+      ]
+    },
     "ServiceConnectService":{
       "type":"structure",
       "required":["portName"],