cdk-docker-image-deployment 0.0.173 → 0.0.175
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.jsii +5 -5
- package/lib/destination.js +1 -1
- package/lib/docker-image-deployment.js +1 -1
- package/lib/source.js +1 -1
- package/node_modules/@types/aws-lambda/README.md +1 -1
- package/node_modules/@types/aws-lambda/package.json +2 -2
- package/node_modules/@types/aws-lambda/trigger/api-gateway-proxy.d.ts +32 -1
- package/node_modules/aws-sdk/CHANGELOG.md +14 -1
- package/node_modules/aws-sdk/README.md +1 -1
- package/node_modules/aws-sdk/apis/appflow-2020-08-23.min.json +3 -0
- package/node_modules/aws-sdk/apis/connect-2017-08-08.min.json +2 -1
- package/node_modules/aws-sdk/apis/connectcases-2022-10-03.min.json +31 -7
- package/node_modules/aws-sdk/apis/ecs-2014-11-13.min.json +209 -182
- package/node_modules/aws-sdk/apis/iotwireless-2020-11-22.min.json +143 -116
- package/node_modules/aws-sdk/apis/location-2020-11-19.min.json +328 -18
- package/node_modules/aws-sdk/apis/location-2020-11-19.paginators.json +6 -0
- package/node_modules/aws-sdk/apis/securityhub-2018-10-26.min.json +758 -432
- package/node_modules/aws-sdk/apis/securityhub-2018-10-26.paginators.json +12 -0
- package/node_modules/aws-sdk/clients/appflow.d.ts +4 -0
- package/node_modules/aws-sdk/clients/connect.d.ts +4 -0
- package/node_modules/aws-sdk/clients/connectcases.d.ts +22 -6
- package/node_modules/aws-sdk/clients/ecs.d.ts +64 -39
- package/node_modules/aws-sdk/clients/grafana.d.ts +11 -11
- package/node_modules/aws-sdk/clients/guardduty.d.ts +34 -34
- package/node_modules/aws-sdk/clients/iotwireless.d.ts +21 -9
- package/node_modules/aws-sdk/clients/location.d.ts +336 -55
- package/node_modules/aws-sdk/clients/macie2.d.ts +40 -40
- package/node_modules/aws-sdk/clients/redshift.d.ts +9 -9
- package/node_modules/aws-sdk/clients/securityhub.d.ts +371 -7
- package/node_modules/aws-sdk/clients/servicecatalog.d.ts +10 -10
- package/node_modules/aws-sdk/clients/wafv2.d.ts +49 -49
- package/node_modules/aws-sdk/dist/aws-sdk-core-react-native.js +1 -1
- package/node_modules/aws-sdk/dist/aws-sdk-react-native.js +58 -44
- package/node_modules/aws-sdk/dist/aws-sdk.js +548 -204
- package/node_modules/aws-sdk/dist/aws-sdk.min.js +77 -77
- package/node_modules/aws-sdk/dist/xml2js.js +24 -17
- package/node_modules/aws-sdk/lib/core.js +1 -1
- package/node_modules/aws-sdk/package.json +1 -1
- package/package.json +8 -8
|
@@ -71,6 +71,18 @@
|
|
|
71
71
|
"output_token": "NextToken",
|
|
72
72
|
"limit_key": "MaxResults",
|
|
73
73
|
"result_key": "AdminAccounts"
|
|
74
|
+
},
|
|
75
|
+
"ListSecurityControlDefinitions": {
|
|
76
|
+
"input_token": "NextToken",
|
|
77
|
+
"output_token": "NextToken",
|
|
78
|
+
"limit_key": "MaxResults",
|
|
79
|
+
"result_key": "SecurityControlDefinitions"
|
|
80
|
+
},
|
|
81
|
+
"ListStandardsControlAssociations": {
|
|
82
|
+
"input_token": "NextToken",
|
|
83
|
+
"output_token": "NextToken",
|
|
84
|
+
"limit_key": "MaxResults",
|
|
85
|
+
"result_key": "StandardsControlAssociationSummaries"
|
|
74
86
|
}
|
|
75
87
|
}
|
|
76
88
|
}
|
|
@@ -2512,6 +2512,10 @@ declare namespace Appflow {
|
|
|
2512
2512
|
* Indicates whether the connector profile applies to a sandbox or production environment.
|
|
2513
2513
|
*/
|
|
2514
2514
|
isSandboxEnvironment?: Boolean;
|
|
2515
|
+
/**
|
|
2516
|
+
* If the connection mode for the connector profile is private, this parameter sets whether Amazon AppFlow uses the private network to send metadata and authorization calls to Salesforce. Amazon AppFlow sends private calls through Amazon Web Services PrivateLink. These calls travel through Amazon Web Services infrastructure without being exposed to the public internet. Set either of the following values: true Amazon AppFlow sends all calls to Salesforce over the private network. These private calls are: Calls to get metadata about your Salesforce records. This metadata describes your Salesforce objects and their fields. Calls to get or refresh access tokens that allow Amazon AppFlow to access your Salesforce records. Calls to transfer your Salesforce records as part of a flow run. false The default value. Amazon AppFlow sends some calls to Salesforce privately and other calls over the public internet. The public calls are: Calls to get metadata about your Salesforce records. Calls to get or refresh access tokens. The private calls are: Calls to transfer your Salesforce records as part of a flow run.
|
|
2517
|
+
*/
|
|
2518
|
+
usePrivateLinkForMetadataAndAuthorization?: Boolean;
|
|
2515
2519
|
}
|
|
2516
2520
|
export type SalesforceDataTransferApi = "AUTOMATIC"|"BULKV2"|"REST_SYNC"|string;
|
|
2517
2521
|
export type SalesforceDataTransferApiList = SalesforceDataTransferApi[];
|
|
@@ -6380,6 +6380,10 @@ declare namespace Connect {
|
|
|
6380
6380
|
* The identifier for the quick connect.
|
|
6381
6381
|
*/
|
|
6382
6382
|
QuickConnectId?: QuickConnectId;
|
|
6383
|
+
/**
|
|
6384
|
+
* The contactId that is related to this contact.
|
|
6385
|
+
*/
|
|
6386
|
+
RelatedContactId?: ContactId;
|
|
6383
6387
|
}
|
|
6384
6388
|
export interface StartTaskContactResponse {
|
|
6385
6389
|
/**
|
|
@@ -28,19 +28,19 @@ declare class ConnectCases extends Service {
|
|
|
28
28
|
*/
|
|
29
29
|
batchPutFieldOptions(callback?: (err: AWSError, data: ConnectCases.Types.BatchPutFieldOptionsResponse) => void): Request<ConnectCases.Types.BatchPutFieldOptionsResponse, AWSError>;
|
|
30
30
|
/**
|
|
31
|
-
* Creates a case in the specified Cases domain. Case system and custom fields are taken as an array id/value pairs with a declared data types.
|
|
31
|
+
* Creates a case in the specified Cases domain. Case system and custom fields are taken as an array id/value pairs with a declared data types. The following fields are required when creating a case: <ul> <li> <p> <code>customer_id</code> - You must provide the full customer profile ARN in this format: <code>arn:aws:profile:your AWS Region:your AWS account ID:domains/profiles domain name/profiles/profile ID</code> </p> </li> <li> <p> <code>title</code> </p> </li> </ul> </note>
|
|
32
32
|
*/
|
|
33
33
|
createCase(params: ConnectCases.Types.CreateCaseRequest, callback?: (err: AWSError, data: ConnectCases.Types.CreateCaseResponse) => void): Request<ConnectCases.Types.CreateCaseResponse, AWSError>;
|
|
34
34
|
/**
|
|
35
|
-
* Creates a case in the specified Cases domain. Case system and custom fields are taken as an array id/value pairs with a declared data types.
|
|
35
|
+
* Creates a case in the specified Cases domain. Case system and custom fields are taken as an array id/value pairs with a declared data types. The following fields are required when creating a case: <ul> <li> <p> <code>customer_id</code> - You must provide the full customer profile ARN in this format: <code>arn:aws:profile:your AWS Region:your AWS account ID:domains/profiles domain name/profiles/profile ID</code> </p> </li> <li> <p> <code>title</code> </p> </li> </ul> </note>
|
|
36
36
|
*/
|
|
37
37
|
createCase(callback?: (err: AWSError, data: ConnectCases.Types.CreateCaseResponse) => void): Request<ConnectCases.Types.CreateCaseResponse, AWSError>;
|
|
38
38
|
/**
|
|
39
|
-
* Creates a domain, which is a container for all case data, such as cases, fields, templates and layouts. Each Amazon Connect instance can be associated with only one Cases domain. This will not associate your connect instance to Cases domain. Instead, use the Amazon Connect CreateIntegrationAssociation API.
|
|
39
|
+
* Creates a domain, which is a container for all case data, such as cases, fields, templates and layouts. Each Amazon Connect instance can be associated with only one Cases domain. This will not associate your connect instance to Cases domain. Instead, use the Amazon Connect CreateIntegrationAssociation API. You need specific IAM permissions to successfully associate the Cases domain. For more information, see Onboard to Cases.
|
|
40
40
|
*/
|
|
41
41
|
createDomain(params: ConnectCases.Types.CreateDomainRequest, callback?: (err: AWSError, data: ConnectCases.Types.CreateDomainResponse) => void): Request<ConnectCases.Types.CreateDomainResponse, AWSError>;
|
|
42
42
|
/**
|
|
43
|
-
* Creates a domain, which is a container for all case data, such as cases, fields, templates and layouts. Each Amazon Connect instance can be associated with only one Cases domain. This will not associate your connect instance to Cases domain. Instead, use the Amazon Connect CreateIntegrationAssociation API.
|
|
43
|
+
* Creates a domain, which is a container for all case data, such as cases, fields, templates and layouts. Each Amazon Connect instance can be associated with only one Cases domain. This will not associate your connect instance to Cases domain. Instead, use the Amazon Connect CreateIntegrationAssociation API. You need specific IAM permissions to successfully associate the Cases domain. For more information, see Onboard to Cases.
|
|
44
44
|
*/
|
|
45
45
|
createDomain(callback?: (err: AWSError, data: ConnectCases.Types.CreateDomainResponse) => void): Request<ConnectCases.Types.CreateDomainResponse, AWSError>;
|
|
46
46
|
/**
|
|
@@ -75,6 +75,14 @@ declare class ConnectCases extends Service {
|
|
|
75
75
|
* Creates a template in the Cases domain. This template is used to define the case object model (that is, to define what data can be captured on cases) in a Cases domain. A template must have a unique name within a domain, and it must reference existing field IDs and layout IDs. Additionally, multiple fields with same IDs are not allowed within the same Template. A template can be either Active or Inactive, as indicated by its status. Inactive templates cannot be used to create cases.
|
|
76
76
|
*/
|
|
77
77
|
createTemplate(callback?: (err: AWSError, data: ConnectCases.Types.CreateTemplateResponse) => void): Request<ConnectCases.Types.CreateTemplateResponse, AWSError>;
|
|
78
|
+
/**
|
|
79
|
+
* Deletes a domain.
|
|
80
|
+
*/
|
|
81
|
+
deleteDomain(params: ConnectCases.Types.DeleteDomainRequest, callback?: (err: AWSError, data: ConnectCases.Types.DeleteDomainResponse) => void): Request<ConnectCases.Types.DeleteDomainResponse, AWSError>;
|
|
82
|
+
/**
|
|
83
|
+
* Deletes a domain.
|
|
84
|
+
*/
|
|
85
|
+
deleteDomain(callback?: (err: AWSError, data: ConnectCases.Types.DeleteDomainResponse) => void): Request<ConnectCases.Types.DeleteDomainResponse, AWSError>;
|
|
78
86
|
/**
|
|
79
87
|
* Returns information about a specific case if it exists.
|
|
80
88
|
*/
|
|
@@ -180,11 +188,11 @@ declare class ConnectCases extends Service {
|
|
|
180
188
|
*/
|
|
181
189
|
putCaseEventConfiguration(callback?: (err: AWSError, data: ConnectCases.Types.PutCaseEventConfigurationResponse) => void): Request<ConnectCases.Types.PutCaseEventConfigurationResponse, AWSError>;
|
|
182
190
|
/**
|
|
183
|
-
* Searches for cases within their associated Cases domain. Search results are returned as a paginated list of abridged case documents.
|
|
191
|
+
* Searches for cases within their associated Cases domain. Search results are returned as a paginated list of abridged case documents. For customer_id you must provide the full customer profile ARN in this format: arn:aws:profile:your AWS Region:your AWS account ID:domains/profiles domain name/profiles/profile ID.
|
|
184
192
|
*/
|
|
185
193
|
searchCases(params: ConnectCases.Types.SearchCasesRequest, callback?: (err: AWSError, data: ConnectCases.Types.SearchCasesResponse) => void): Request<ConnectCases.Types.SearchCasesResponse, AWSError>;
|
|
186
194
|
/**
|
|
187
|
-
* Searches for cases within their associated Cases domain. Search results are returned as a paginated list of abridged case documents.
|
|
195
|
+
* Searches for cases within their associated Cases domain. Search results are returned as a paginated list of abridged case documents. For customer_id you must provide the full customer profile ARN in this format: arn:aws:profile:your AWS Region:your AWS account ID:domains/profiles domain name/profiles/profile ID.
|
|
188
196
|
*/
|
|
189
197
|
searchCases(callback?: (err: AWSError, data: ConnectCases.Types.SearchCasesResponse) => void): Request<ConnectCases.Types.SearchCasesResponse, AWSError>;
|
|
190
198
|
/**
|
|
@@ -549,6 +557,14 @@ declare namespace ConnectCases {
|
|
|
549
557
|
templateId: TemplateId;
|
|
550
558
|
}
|
|
551
559
|
export type CreatedTime = Date;
|
|
560
|
+
export interface DeleteDomainRequest {
|
|
561
|
+
/**
|
|
562
|
+
* The unique identifier of the Cases domain.
|
|
563
|
+
*/
|
|
564
|
+
domainId: DomainId;
|
|
565
|
+
}
|
|
566
|
+
export interface DeleteDomainResponse {
|
|
567
|
+
}
|
|
552
568
|
export type DomainArn = string;
|
|
553
569
|
export type DomainId = string;
|
|
554
570
|
export type DomainName = string;
|
|
@@ -21,11 +21,11 @@ declare class ECS extends Service {
|
|
|
21
21
|
*/
|
|
22
22
|
createCapacityProvider(callback?: (err: AWSError, data: ECS.Types.CreateCapacityProviderResponse) => void): Request<ECS.Types.CreateCapacityProviderResponse, AWSError>;
|
|
23
23
|
/**
|
|
24
|
-
* Creates a new Amazon ECS cluster. By default, your account receives a default cluster when you launch your first container instance. However, you can create your own cluster with a unique name with the CreateCluster action. When you call the CreateCluster API operation, Amazon ECS attempts to create the Amazon ECS service-linked role for your account. This is so that it can manage required resources in other Amazon Web Services services on your behalf. However, if the
|
|
24
|
+
* Creates a new Amazon ECS cluster. By default, your account receives a default cluster when you launch your first container instance. However, you can create your own cluster with a unique name with the CreateCluster action. When you call the CreateCluster API operation, Amazon ECS attempts to create the Amazon ECS service-linked role for your account. This is so that it can manage required resources in other Amazon Web Services services on your behalf. However, if the user that makes the call doesn't have permissions to create the service-linked role, it isn't created. For more information, see Using service-linked roles for Amazon ECS in the Amazon Elastic Container Service Developer Guide.
|
|
25
25
|
*/
|
|
26
26
|
createCluster(params: ECS.Types.CreateClusterRequest, callback?: (err: AWSError, data: ECS.Types.CreateClusterResponse) => void): Request<ECS.Types.CreateClusterResponse, AWSError>;
|
|
27
27
|
/**
|
|
28
|
-
* Creates a new Amazon ECS cluster. By default, your account receives a default cluster when you launch your first container instance. However, you can create your own cluster with a unique name with the CreateCluster action. When you call the CreateCluster API operation, Amazon ECS attempts to create the Amazon ECS service-linked role for your account. This is so that it can manage required resources in other Amazon Web Services services on your behalf. However, if the
|
|
28
|
+
* Creates a new Amazon ECS cluster. By default, your account receives a default cluster when you launch your first container instance. However, you can create your own cluster with a unique name with the CreateCluster action. When you call the CreateCluster API operation, Amazon ECS attempts to create the Amazon ECS service-linked role for your account. This is so that it can manage required resources in other Amazon Web Services services on your behalf. However, if the user that makes the call doesn't have permissions to create the service-linked role, it isn't created. For more information, see Using service-linked roles for Amazon ECS in the Amazon Elastic Container Service Developer Guide.
|
|
29
29
|
*/
|
|
30
30
|
createCluster(callback?: (err: AWSError, data: ECS.Types.CreateClusterResponse) => void): Request<ECS.Types.CreateClusterResponse, AWSError>;
|
|
31
31
|
/**
|
|
@@ -45,11 +45,11 @@ declare class ECS extends Service {
|
|
|
45
45
|
*/
|
|
46
46
|
createTaskSet(callback?: (err: AWSError, data: ECS.Types.CreateTaskSetResponse) => void): Request<ECS.Types.CreateTaskSetResponse, AWSError>;
|
|
47
47
|
/**
|
|
48
|
-
* Disables an account setting for a specified
|
|
48
|
+
* Disables an account setting for a specified user, role, or the root user for an account.
|
|
49
49
|
*/
|
|
50
50
|
deleteAccountSetting(params: ECS.Types.DeleteAccountSettingRequest, callback?: (err: AWSError, data: ECS.Types.DeleteAccountSettingResponse) => void): Request<ECS.Types.DeleteAccountSettingResponse, AWSError>;
|
|
51
51
|
/**
|
|
52
|
-
* Disables an account setting for a specified
|
|
52
|
+
* Disables an account setting for a specified user, role, or the root user for an account.
|
|
53
53
|
*/
|
|
54
54
|
deleteAccountSetting(callback?: (err: AWSError, data: ECS.Types.DeleteAccountSettingResponse) => void): Request<ECS.Types.DeleteAccountSettingResponse, AWSError>;
|
|
55
55
|
/**
|
|
@@ -84,6 +84,14 @@ declare class ECS extends Service {
|
|
|
84
84
|
* Deletes a specified service within a cluster. You can delete a service if you have no running tasks in it and the desired task count is zero. If the service is actively maintaining tasks, you can't delete it, and you must update the service to a desired task count of zero. For more information, see UpdateService. When you delete a service, if there are still running tasks that require cleanup, the service status moves from ACTIVE to DRAINING, and the service is no longer visible in the console or in the ListServices API operation. After all tasks have transitioned to either STOPPING or STOPPED status, the service status moves from DRAINING to INACTIVE. Services in the DRAINING or INACTIVE status can still be viewed with the DescribeServices API operation. However, in the future, INACTIVE services may be cleaned up and purged from Amazon ECS record keeping, and DescribeServices calls on those services return a ServiceNotFoundException error. If you attempt to create a new service with the same name as an existing service in either ACTIVE or DRAINING status, you receive an error.
|
|
85
85
|
*/
|
|
86
86
|
deleteService(callback?: (err: AWSError, data: ECS.Types.DeleteServiceResponse) => void): Request<ECS.Types.DeleteServiceResponse, AWSError>;
|
|
87
|
+
/**
|
|
88
|
+
* Deletes one or more task definitions. You must deregister a task definition revision before you delete it. For more information, see DeregisterTaskDefinition. When you delete a task definition revision, it is immediately transitions from the INACTIVE to DELETE_IN_PROGRESS. Existing tasks and services that reference a DELETE_IN_PROGRESS task definition revision continue to run without disruption. Existing services that reference a DELETE_IN_PROGRESS task definition revision can still scale up or down by modifying the service's desired count. You can't use a DELETE_IN_PROGRESS task definition revision to run new tasks or create new services. You also can't update an existing service to reference a DELETE_IN_PROGRESS task definition revision. A task definition revision will stay in DELETE_IN_PROGRESS status until all the associated tasks and services have been terminated.
|
|
89
|
+
*/
|
|
90
|
+
deleteTaskDefinitions(params: ECS.Types.DeleteTaskDefinitionsRequest, callback?: (err: AWSError, data: ECS.Types.DeleteTaskDefinitionsResponse) => void): Request<ECS.Types.DeleteTaskDefinitionsResponse, AWSError>;
|
|
91
|
+
/**
|
|
92
|
+
* Deletes one or more task definitions. You must deregister a task definition revision before you delete it. For more information, see DeregisterTaskDefinition. When you delete a task definition revision, it is immediately transitions from the INACTIVE to DELETE_IN_PROGRESS. Existing tasks and services that reference a DELETE_IN_PROGRESS task definition revision continue to run without disruption. Existing services that reference a DELETE_IN_PROGRESS task definition revision can still scale up or down by modifying the service's desired count. You can't use a DELETE_IN_PROGRESS task definition revision to run new tasks or create new services. You also can't update an existing service to reference a DELETE_IN_PROGRESS task definition revision. A task definition revision will stay in DELETE_IN_PROGRESS status until all the associated tasks and services have been terminated.
|
|
93
|
+
*/
|
|
94
|
+
deleteTaskDefinitions(callback?: (err: AWSError, data: ECS.Types.DeleteTaskDefinitionsResponse) => void): Request<ECS.Types.DeleteTaskDefinitionsResponse, AWSError>;
|
|
87
95
|
/**
|
|
88
96
|
* Deletes a specified task set within a service. This is used when a service uses the EXTERNAL deployment controller type. For more information, see Amazon ECS deployment types in the Amazon Elastic Container Service Developer Guide.
|
|
89
97
|
*/
|
|
@@ -101,11 +109,11 @@ declare class ECS extends Service {
|
|
|
101
109
|
*/
|
|
102
110
|
deregisterContainerInstance(callback?: (err: AWSError, data: ECS.Types.DeregisterContainerInstanceResponse) => void): Request<ECS.Types.DeregisterContainerInstanceResponse, AWSError>;
|
|
103
111
|
/**
|
|
104
|
-
* Deregisters the specified task definition by family and revision. Upon deregistration, the task definition is marked as INACTIVE. Existing tasks and services that reference an INACTIVE task definition continue to run without disruption. Existing services that reference an INACTIVE task definition can still scale up or down by modifying the service's desired count. You can't use an INACTIVE task definition to run new tasks or create new services, and you can't update an existing service to reference an INACTIVE task definition. However, there may be up to a 10-minute window following deregistration where these restrictions have not yet taken effect. At this time, INACTIVE task definitions remain discoverable in your account indefinitely. However, this behavior is subject to change in the future. We don't recommend that you rely on INACTIVE task definitions persisting beyond the lifecycle of any associated tasks and services.
|
|
112
|
+
* Deregisters the specified task definition by family and revision. Upon deregistration, the task definition is marked as INACTIVE. Existing tasks and services that reference an INACTIVE task definition continue to run without disruption. Existing services that reference an INACTIVE task definition can still scale up or down by modifying the service's desired count. If you want to delete a task definition revision, you must first deregister the task definition revision. You can't use an INACTIVE task definition to run new tasks or create new services, and you can't update an existing service to reference an INACTIVE task definition. However, there may be up to a 10-minute window following deregistration where these restrictions have not yet taken effect. At this time, INACTIVE task definitions remain discoverable in your account indefinitely. However, this behavior is subject to change in the future. We don't recommend that you rely on INACTIVE task definitions persisting beyond the lifecycle of any associated tasks and services. You must deregister a task definition revision before you delete it. For more information, see DeleteTaskDefinitions.
|
|
105
113
|
*/
|
|
106
114
|
deregisterTaskDefinition(params: ECS.Types.DeregisterTaskDefinitionRequest, callback?: (err: AWSError, data: ECS.Types.DeregisterTaskDefinitionResponse) => void): Request<ECS.Types.DeregisterTaskDefinitionResponse, AWSError>;
|
|
107
115
|
/**
|
|
108
|
-
* Deregisters the specified task definition by family and revision. Upon deregistration, the task definition is marked as INACTIVE. Existing tasks and services that reference an INACTIVE task definition continue to run without disruption. Existing services that reference an INACTIVE task definition can still scale up or down by modifying the service's desired count. You can't use an INACTIVE task definition to run new tasks or create new services, and you can't update an existing service to reference an INACTIVE task definition. However, there may be up to a 10-minute window following deregistration where these restrictions have not yet taken effect. At this time, INACTIVE task definitions remain discoverable in your account indefinitely. However, this behavior is subject to change in the future. We don't recommend that you rely on INACTIVE task definitions persisting beyond the lifecycle of any associated tasks and services.
|
|
116
|
+
* Deregisters the specified task definition by family and revision. Upon deregistration, the task definition is marked as INACTIVE. Existing tasks and services that reference an INACTIVE task definition continue to run without disruption. Existing services that reference an INACTIVE task definition can still scale up or down by modifying the service's desired count. If you want to delete a task definition revision, you must first deregister the task definition revision. You can't use an INACTIVE task definition to run new tasks or create new services, and you can't update an existing service to reference an INACTIVE task definition. However, there may be up to a 10-minute window following deregistration where these restrictions have not yet taken effect. At this time, INACTIVE task definitions remain discoverable in your account indefinitely. However, this behavior is subject to change in the future. We don't recommend that you rely on INACTIVE task definitions persisting beyond the lifecycle of any associated tasks and services. You must deregister a task definition revision before you delete it. For more information, see DeleteTaskDefinitions.
|
|
109
117
|
*/
|
|
110
118
|
deregisterTaskDefinition(callback?: (err: AWSError, data: ECS.Types.DeregisterTaskDefinitionResponse) => void): Request<ECS.Types.DeregisterTaskDefinitionResponse, AWSError>;
|
|
111
119
|
/**
|
|
@@ -269,19 +277,19 @@ declare class ECS extends Service {
|
|
|
269
277
|
*/
|
|
270
278
|
listTasks(callback?: (err: AWSError, data: ECS.Types.ListTasksResponse) => void): Request<ECS.Types.ListTasksResponse, AWSError>;
|
|
271
279
|
/**
|
|
272
|
-
* Modifies an account setting. Account settings are set on a per-Region basis. If you change the account setting for the root user, the default settings for all of the
|
|
280
|
+
* Modifies an account setting. Account settings are set on a per-Region basis. If you change the account setting for the root user, the default settings for all of the users and roles that no individual account setting was specified are reset for. For more information, see Account Settings in the Amazon Elastic Container Service Developer Guide. When serviceLongArnFormat, taskLongArnFormat, or containerInstanceLongArnFormat are specified, the Amazon Resource Name (ARN) and resource ID format of the resource type for a specified user, role, or the root user for an account is affected. The opt-in and opt-out account setting must be set for each Amazon ECS resource separately. The ARN and resource ID format of a resource is defined by the opt-in status of the user or role that created the resource. You must turn on this setting to use Amazon ECS features such as resource tagging. When awsvpcTrunking is specified, the elastic network interface (ENI) limit for any new container instances that support the feature is changed. If awsvpcTrunking is enabled, any new container instances that support the feature are launched have the increased ENI limits available to them. For more information, see Elastic Network Interface Trunking in the Amazon Elastic Container Service Developer Guide. When containerInsights is specified, the default setting indicating whether CloudWatch Container Insights is enabled for your clusters is changed. If containerInsights is enabled, any new clusters that are created will have Container Insights enabled unless you disable it during cluster creation. For more information, see CloudWatch Container Insights in the Amazon Elastic Container Service Developer Guide.
|
|
273
281
|
*/
|
|
274
282
|
putAccountSetting(params: ECS.Types.PutAccountSettingRequest, callback?: (err: AWSError, data: ECS.Types.PutAccountSettingResponse) => void): Request<ECS.Types.PutAccountSettingResponse, AWSError>;
|
|
275
283
|
/**
|
|
276
|
-
* Modifies an account setting. Account settings are set on a per-Region basis. If you change the account setting for the root user, the default settings for all of the
|
|
284
|
+
* Modifies an account setting. Account settings are set on a per-Region basis. If you change the account setting for the root user, the default settings for all of the users and roles that no individual account setting was specified are reset for. For more information, see Account Settings in the Amazon Elastic Container Service Developer Guide. When serviceLongArnFormat, taskLongArnFormat, or containerInstanceLongArnFormat are specified, the Amazon Resource Name (ARN) and resource ID format of the resource type for a specified user, role, or the root user for an account is affected. The opt-in and opt-out account setting must be set for each Amazon ECS resource separately. The ARN and resource ID format of a resource is defined by the opt-in status of the user or role that created the resource. You must turn on this setting to use Amazon ECS features such as resource tagging. When awsvpcTrunking is specified, the elastic network interface (ENI) limit for any new container instances that support the feature is changed. If awsvpcTrunking is enabled, any new container instances that support the feature are launched have the increased ENI limits available to them. For more information, see Elastic Network Interface Trunking in the Amazon Elastic Container Service Developer Guide. When containerInsights is specified, the default setting indicating whether CloudWatch Container Insights is enabled for your clusters is changed. If containerInsights is enabled, any new clusters that are created will have Container Insights enabled unless you disable it during cluster creation. For more information, see CloudWatch Container Insights in the Amazon Elastic Container Service Developer Guide.
|
|
277
285
|
*/
|
|
278
286
|
putAccountSetting(callback?: (err: AWSError, data: ECS.Types.PutAccountSettingResponse) => void): Request<ECS.Types.PutAccountSettingResponse, AWSError>;
|
|
279
287
|
/**
|
|
280
|
-
* Modifies an account setting for all
|
|
288
|
+
* Modifies an account setting for all users on an account for whom no individual account setting has been specified. Account settings are set on a per-Region basis.
|
|
281
289
|
*/
|
|
282
290
|
putAccountSettingDefault(params: ECS.Types.PutAccountSettingDefaultRequest, callback?: (err: AWSError, data: ECS.Types.PutAccountSettingDefaultResponse) => void): Request<ECS.Types.PutAccountSettingDefaultResponse, AWSError>;
|
|
283
291
|
/**
|
|
284
|
-
* Modifies an account setting for all
|
|
292
|
+
* Modifies an account setting for all users on an account for whom no individual account setting has been specified. Account settings are set on a per-Region basis.
|
|
285
293
|
*/
|
|
286
294
|
putAccountSettingDefault(callback?: (err: AWSError, data: ECS.Types.PutAccountSettingDefaultResponse) => void): Request<ECS.Types.PutAccountSettingDefaultResponse, AWSError>;
|
|
287
295
|
/**
|
|
@@ -309,11 +317,11 @@ declare class ECS extends Service {
|
|
|
309
317
|
*/
|
|
310
318
|
registerContainerInstance(callback?: (err: AWSError, data: ECS.Types.RegisterContainerInstanceResponse) => void): Request<ECS.Types.RegisterContainerInstanceResponse, AWSError>;
|
|
311
319
|
/**
|
|
312
|
-
* Registers a new task definition from the supplied family and containerDefinitions. Optionally, you can add data volumes to your containers with the volumes parameter. For more information about task definition parameters and defaults, see Amazon ECS Task Definitions in the Amazon Elastic Container Service Developer Guide. You can specify
|
|
320
|
+
* Registers a new task definition from the supplied family and containerDefinitions. Optionally, you can add data volumes to your containers with the volumes parameter. For more information about task definition parameters and defaults, see Amazon ECS Task Definitions in the Amazon Elastic Container Service Developer Guide. You can specify a role for your task with the taskRoleArn parameter. When you specify a role for a task, its containers can then use the latest versions of the CLI or SDKs to make API requests to the Amazon Web Services services that are specified in the policy that's associated with the role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide. You can specify a Docker networking mode for the containers in your task definition with the networkMode parameter. The available network modes correspond to those described in Network settings in the Docker run reference. If you specify the awsvpc network mode, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
|
|
313
321
|
*/
|
|
314
322
|
registerTaskDefinition(params: ECS.Types.RegisterTaskDefinitionRequest, callback?: (err: AWSError, data: ECS.Types.RegisterTaskDefinitionResponse) => void): Request<ECS.Types.RegisterTaskDefinitionResponse, AWSError>;
|
|
315
323
|
/**
|
|
316
|
-
* Registers a new task definition from the supplied family and containerDefinitions. Optionally, you can add data volumes to your containers with the volumes parameter. For more information about task definition parameters and defaults, see Amazon ECS Task Definitions in the Amazon Elastic Container Service Developer Guide. You can specify
|
|
324
|
+
* Registers a new task definition from the supplied family and containerDefinitions. Optionally, you can add data volumes to your containers with the volumes parameter. For more information about task definition parameters and defaults, see Amazon ECS Task Definitions in the Amazon Elastic Container Service Developer Guide. You can specify a role for your task with the taskRoleArn parameter. When you specify a role for a task, its containers can then use the latest versions of the CLI or SDKs to make API requests to the Amazon Web Services services that are specified in the policy that's associated with the role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide. You can specify a Docker networking mode for the containers in your task definition with the networkMode parameter. The available network modes correspond to those described in Network settings in the Docker run reference. If you specify the awsvpc network mode, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
|
|
317
325
|
*/
|
|
318
326
|
registerTaskDefinition(callback?: (err: AWSError, data: ECS.Types.RegisterTaskDefinitionResponse) => void): Request<ECS.Types.RegisterTaskDefinitionResponse, AWSError>;
|
|
319
327
|
/**
|
|
@@ -421,11 +429,11 @@ declare class ECS extends Service {
|
|
|
421
429
|
*/
|
|
422
430
|
updateContainerInstancesState(callback?: (err: AWSError, data: ECS.Types.UpdateContainerInstancesStateResponse) => void): Request<ECS.Types.UpdateContainerInstancesStateResponse, AWSError>;
|
|
423
431
|
/**
|
|
424
|
-
* Modifies the parameters of a service. For services using the rolling update (ECS) you can update the desired count, deployment configuration, network configuration, load balancers, service registries, enable ECS managed tags option, propagate tags option, task placement constraints and strategies, and task definition. When you update any of these parameters, Amazon ECS starts new tasks with the new configuration. For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new CodeDeploy deployment. For more information, see CreateDeployment in the CodeDeploy API Reference. For services using an external deployment controller, you can update only the desired count, task placement constraints and strategies, health check grace period, enable ECS managed tags option, and propagate tags option, using this API. If the launch type, load balancer, network configuration, platform version, or task definition need to be updated, create a new task set For more information, see CreateTaskSet. You can add to or subtract from the number of instantiations of a task definition in a service by specifying the cluster that the service is running in and a new desiredCount parameter. If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service. The service scheduler uses the minimum healthy percent and maximum percent parameters (in the service's deployment configuration) to determine the deployment strategy. If your updated Docker image uses the same tag as what is in the existing task definition for your service (for example, my_image:latest), you don't need to create a new revision of your task definition. You can update the service using the forceNewDeployment option. The new tasks launched by the deployment pull the current image/tag combination from your repository when they start. You can also update the deployment configuration of a service. When a deployment is triggered by updating the task definition of a service, the service scheduler uses the deployment configuration parameters, minimumHealthyPercent and maximumPercent, to determine the deployment strategy. If minimumHealthyPercent is below 100%, the scheduler can ignore desiredCount temporarily during a deployment. For example, if desiredCount is four tasks, a minimum of 50% allows the scheduler to stop two existing tasks before starting two new tasks. Tasks for services that don't use a load balancer are considered healthy if they're in the RUNNING state. Tasks for services that use a load balancer are considered healthy if they're in the RUNNING state and are reported as healthy by the load balancer. The maximumPercent parameter represents an upper limit on the number of running tasks during a deployment. You can use it to define the deployment batch size. For example, if desiredCount is four tasks, a maximum of 200% starts four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). When UpdateService stops a task during a deployment, the equivalent of docker stop is issued to the containers running in the task. This results in a SIGTERM and a 30-second timeout. After this, SIGKILL is sent and the containers are forcibly stopped. If the container handles the SIGTERM gracefully and exits within 30 seconds from receiving it, no SIGKILL is sent. When the service scheduler launches new tasks, it determines task placement in your cluster with the following logic. Determine which of the container instances in your cluster can support your service's task definition. For example, they have the required CPU, memory, ports, and container instance attributes. By default, the service scheduler attempts to balance tasks across Availability Zones in this manner even though you can choose a different placement strategy. Sort the valid container instances by the fewest number of running tasks for this service in the same Availability Zone as the instance. 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. Place the new service task on a valid container instance in an optimal Availability Zone (based on the previous steps), favoring container instances with the fewest number of running tasks for this service. When the service scheduler stops running tasks, it attempts to maintain balance across the Availability Zones in your cluster using the following logic: Sort the container instances by the largest number of running tasks for this service in the same Availability Zone as the instance. For example, if zone A has one running service task and zones B and C each have two, 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. You must have a service-linked role when you update any of the following service properties. If you specified a custom
|
|
432
|
+
* Modifies the parameters of a service. For services using the rolling update (ECS) you can update the desired count, deployment configuration, network configuration, load balancers, service registries, enable ECS managed tags option, propagate tags option, task placement constraints and strategies, and task definition. When you update any of these parameters, Amazon ECS starts new tasks with the new configuration. For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new CodeDeploy deployment. For more information, see CreateDeployment in the CodeDeploy API Reference. For services using an external deployment controller, you can update only the desired count, task placement constraints and strategies, health check grace period, enable ECS managed tags option, and propagate tags option, using this API. If the launch type, load balancer, network configuration, platform version, or task definition need to be updated, create a new task set For more information, see CreateTaskSet. You can add to or subtract from the number of instantiations of a task definition in a service by specifying the cluster that the service is running in and a new desiredCount parameter. If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service. The service scheduler uses the minimum healthy percent and maximum percent parameters (in the service's deployment configuration) to determine the deployment strategy. If your updated Docker image uses the same tag as what is in the existing task definition for your service (for example, my_image:latest), you don't need to create a new revision of your task definition. You can update the service using the forceNewDeployment option. The new tasks launched by the deployment pull the current image/tag combination from your repository when they start. You can also update the deployment configuration of a service. When a deployment is triggered by updating the task definition of a service, the service scheduler uses the deployment configuration parameters, minimumHealthyPercent and maximumPercent, to determine the deployment strategy. If minimumHealthyPercent is below 100%, the scheduler can ignore desiredCount temporarily during a deployment. For example, if desiredCount is four tasks, a minimum of 50% allows the scheduler to stop two existing tasks before starting two new tasks. Tasks for services that don't use a load balancer are considered healthy if they're in the RUNNING state. Tasks for services that use a load balancer are considered healthy if they're in the RUNNING state and are reported as healthy by the load balancer. The maximumPercent parameter represents an upper limit on the number of running tasks during a deployment. You can use it to define the deployment batch size. For example, if desiredCount is four tasks, a maximum of 200% starts four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). When UpdateService stops a task during a deployment, the equivalent of docker stop is issued to the containers running in the task. This results in a SIGTERM and a 30-second timeout. After this, SIGKILL is sent and the containers are forcibly stopped. If the container handles the SIGTERM gracefully and exits within 30 seconds from receiving it, no SIGKILL is sent. When the service scheduler launches new tasks, it determines task placement in your cluster with the following logic. Determine which of the container instances in your cluster can support your service's task definition. For example, they have the required CPU, memory, ports, and container instance attributes. By default, the service scheduler attempts to balance tasks across Availability Zones in this manner even though you can choose a different placement strategy. Sort the valid container instances by the fewest number of running tasks for this service in the same Availability Zone as the instance. 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. Place the new service task on a valid container instance in an optimal Availability Zone (based on the previous steps), favoring container instances with the fewest number of running tasks for this service. When the service scheduler stops running tasks, it attempts to maintain balance across the Availability Zones in your cluster using the following logic: Sort the container instances by the largest number of running tasks for this service in the same Availability Zone as the instance. For example, if zone A has one running service task and zones B and C each have two, 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. You must have a service-linked role when you update any of the following service properties. If you specified a custom role when you created the service, Amazon ECS automatically replaces the roleARN associated with the service with the ARN of your service-linked role. For more information, see Service-linked roles in the Amazon Elastic Container Service Developer Guide. loadBalancers, serviceRegistries
|
|
425
433
|
*/
|
|
426
434
|
updateService(params: ECS.Types.UpdateServiceRequest, callback?: (err: AWSError, data: ECS.Types.UpdateServiceResponse) => void): Request<ECS.Types.UpdateServiceResponse, AWSError>;
|
|
427
435
|
/**
|
|
428
|
-
* Modifies the parameters of a service. For services using the rolling update (ECS) you can update the desired count, deployment configuration, network configuration, load balancers, service registries, enable ECS managed tags option, propagate tags option, task placement constraints and strategies, and task definition. When you update any of these parameters, Amazon ECS starts new tasks with the new configuration. For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new CodeDeploy deployment. For more information, see CreateDeployment in the CodeDeploy API Reference. For services using an external deployment controller, you can update only the desired count, task placement constraints and strategies, health check grace period, enable ECS managed tags option, and propagate tags option, using this API. If the launch type, load balancer, network configuration, platform version, or task definition need to be updated, create a new task set For more information, see CreateTaskSet. You can add to or subtract from the number of instantiations of a task definition in a service by specifying the cluster that the service is running in and a new desiredCount parameter. If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service. The service scheduler uses the minimum healthy percent and maximum percent parameters (in the service's deployment configuration) to determine the deployment strategy. If your updated Docker image uses the same tag as what is in the existing task definition for your service (for example, my_image:latest), you don't need to create a new revision of your task definition. You can update the service using the forceNewDeployment option. The new tasks launched by the deployment pull the current image/tag combination from your repository when they start. You can also update the deployment configuration of a service. When a deployment is triggered by updating the task definition of a service, the service scheduler uses the deployment configuration parameters, minimumHealthyPercent and maximumPercent, to determine the deployment strategy. If minimumHealthyPercent is below 100%, the scheduler can ignore desiredCount temporarily during a deployment. For example, if desiredCount is four tasks, a minimum of 50% allows the scheduler to stop two existing tasks before starting two new tasks. Tasks for services that don't use a load balancer are considered healthy if they're in the RUNNING state. Tasks for services that use a load balancer are considered healthy if they're in the RUNNING state and are reported as healthy by the load balancer. The maximumPercent parameter represents an upper limit on the number of running tasks during a deployment. You can use it to define the deployment batch size. For example, if desiredCount is four tasks, a maximum of 200% starts four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). When UpdateService stops a task during a deployment, the equivalent of docker stop is issued to the containers running in the task. This results in a SIGTERM and a 30-second timeout. After this, SIGKILL is sent and the containers are forcibly stopped. If the container handles the SIGTERM gracefully and exits within 30 seconds from receiving it, no SIGKILL is sent. When the service scheduler launches new tasks, it determines task placement in your cluster with the following logic. Determine which of the container instances in your cluster can support your service's task definition. For example, they have the required CPU, memory, ports, and container instance attributes. By default, the service scheduler attempts to balance tasks across Availability Zones in this manner even though you can choose a different placement strategy. Sort the valid container instances by the fewest number of running tasks for this service in the same Availability Zone as the instance. 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. Place the new service task on a valid container instance in an optimal Availability Zone (based on the previous steps), favoring container instances with the fewest number of running tasks for this service. When the service scheduler stops running tasks, it attempts to maintain balance across the Availability Zones in your cluster using the following logic: Sort the container instances by the largest number of running tasks for this service in the same Availability Zone as the instance. For example, if zone A has one running service task and zones B and C each have two, 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. You must have a service-linked role when you update any of the following service properties. If you specified a custom
|
|
436
|
+
* Modifies the parameters of a service. For services using the rolling update (ECS) you can update the desired count, deployment configuration, network configuration, load balancers, service registries, enable ECS managed tags option, propagate tags option, task placement constraints and strategies, and task definition. When you update any of these parameters, Amazon ECS starts new tasks with the new configuration. For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new CodeDeploy deployment. For more information, see CreateDeployment in the CodeDeploy API Reference. For services using an external deployment controller, you can update only the desired count, task placement constraints and strategies, health check grace period, enable ECS managed tags option, and propagate tags option, using this API. If the launch type, load balancer, network configuration, platform version, or task definition need to be updated, create a new task set For more information, see CreateTaskSet. You can add to or subtract from the number of instantiations of a task definition in a service by specifying the cluster that the service is running in and a new desiredCount parameter. If you have updated the Docker image of your application, you can create a new task definition with that image and deploy it to your service. The service scheduler uses the minimum healthy percent and maximum percent parameters (in the service's deployment configuration) to determine the deployment strategy. If your updated Docker image uses the same tag as what is in the existing task definition for your service (for example, my_image:latest), you don't need to create a new revision of your task definition. You can update the service using the forceNewDeployment option. The new tasks launched by the deployment pull the current image/tag combination from your repository when they start. You can also update the deployment configuration of a service. When a deployment is triggered by updating the task definition of a service, the service scheduler uses the deployment configuration parameters, minimumHealthyPercent and maximumPercent, to determine the deployment strategy. If minimumHealthyPercent is below 100%, the scheduler can ignore desiredCount temporarily during a deployment. For example, if desiredCount is four tasks, a minimum of 50% allows the scheduler to stop two existing tasks before starting two new tasks. Tasks for services that don't use a load balancer are considered healthy if they're in the RUNNING state. Tasks for services that use a load balancer are considered healthy if they're in the RUNNING state and are reported as healthy by the load balancer. The maximumPercent parameter represents an upper limit on the number of running tasks during a deployment. You can use it to define the deployment batch size. For example, if desiredCount is four tasks, a maximum of 200% starts four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). When UpdateService stops a task during a deployment, the equivalent of docker stop is issued to the containers running in the task. This results in a SIGTERM and a 30-second timeout. After this, SIGKILL is sent and the containers are forcibly stopped. If the container handles the SIGTERM gracefully and exits within 30 seconds from receiving it, no SIGKILL is sent. When the service scheduler launches new tasks, it determines task placement in your cluster with the following logic. Determine which of the container instances in your cluster can support your service's task definition. For example, they have the required CPU, memory, ports, and container instance attributes. By default, the service scheduler attempts to balance tasks across Availability Zones in this manner even though you can choose a different placement strategy. Sort the valid container instances by the fewest number of running tasks for this service in the same Availability Zone as the instance. 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. Place the new service task on a valid container instance in an optimal Availability Zone (based on the previous steps), favoring container instances with the fewest number of running tasks for this service. When the service scheduler stops running tasks, it attempts to maintain balance across the Availability Zones in your cluster using the following logic: Sort the container instances by the largest number of running tasks for this service in the same Availability Zone as the instance. For example, if zone A has one running service task and zones B and C each have two, 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. You must have a service-linked role when you update any of the following service properties. If you specified a custom role when you created the service, Amazon ECS automatically replaces the roleARN associated with the service with the ARN of your service-linked role. For more information, see Service-linked roles in the Amazon Elastic Container Service Developer Guide. loadBalancers, serviceRegistries
|
|
429
437
|
*/
|
|
430
438
|
updateService(callback?: (err: AWSError, data: ECS.Types.UpdateServiceResponse) => void): Request<ECS.Types.UpdateServiceResponse, AWSError>;
|
|
431
439
|
/**
|
|
@@ -549,7 +557,7 @@ declare namespace ECS {
|
|
|
549
557
|
*/
|
|
550
558
|
managedScaling?: ManagedScaling;
|
|
551
559
|
/**
|
|
552
|
-
* The managed termination protection setting to use for the Auto Scaling group capacity provider. This determines whether the Auto Scaling group has managed termination protection. The default is
|
|
560
|
+
* The managed termination protection setting to use for the Auto Scaling group capacity provider. This determines whether the Auto Scaling group has managed termination protection. The default is off. When using managed termination protection, managed scaling must also be used otherwise managed termination protection doesn't work. When managed termination protection is on, Amazon ECS prevents the Amazon EC2 instances in an Auto Scaling group that contain tasks from being terminated during a scale-in action. The Auto Scaling group and each instance in the Auto Scaling group must have instance protection from scale-in actions enabled as well. For more information, see Instance Protection in the Auto Scaling User Guide. When managed termination protection is off, your Amazon EC2 instances aren't protected from termination when the Auto Scaling group scales in.
|
|
553
561
|
*/
|
|
554
562
|
managedTerminationProtection?: ManagedTerminationProtection;
|
|
555
563
|
}
|
|
@@ -559,7 +567,7 @@ declare namespace ECS {
|
|
|
559
567
|
*/
|
|
560
568
|
managedScaling?: ManagedScaling;
|
|
561
569
|
/**
|
|
562
|
-
* The managed termination protection setting to use for the Auto Scaling group capacity provider. This determines whether the Auto Scaling group has managed termination protection. When using managed termination protection, managed scaling must also be used otherwise managed termination protection doesn't work. When managed termination protection is
|
|
570
|
+
* The managed termination protection setting to use for the Auto Scaling group capacity provider. This determines whether the Auto Scaling group has managed termination protection. When using managed termination protection, managed scaling must also be used otherwise managed termination protection doesn't work. When managed termination protection is on, Amazon ECS prevents the Amazon EC2 instances in an Auto Scaling group that contain tasks from being terminated during a scale-in action. The Auto Scaling group and each instance in the Auto Scaling group must have instance protection from scale-in actions on. For more information, see Instance Protection in the Auto Scaling User Guide. When managed termination protection is off, your Amazon EC2 instances aren't protected from termination when the Auto Scaling group scales in.
|
|
563
571
|
*/
|
|
564
572
|
managedTerminationProtection?: ManagedTerminationProtection;
|
|
565
573
|
}
|
|
@@ -675,7 +683,7 @@ declare namespace ECS {
|
|
|
675
683
|
*/
|
|
676
684
|
tags?: Tags;
|
|
677
685
|
/**
|
|
678
|
-
* The settings for the cluster. This parameter indicates whether CloudWatch Container Insights is
|
|
686
|
+
* The settings for the cluster. This parameter indicates whether CloudWatch Container Insights is on or off for a cluster.
|
|
679
687
|
*/
|
|
680
688
|
settings?: ClusterSettings;
|
|
681
689
|
/**
|
|
@@ -725,7 +733,7 @@ declare namespace ECS {
|
|
|
725
733
|
*/
|
|
726
734
|
name?: ClusterSettingName;
|
|
727
735
|
/**
|
|
728
|
-
* The value to set for the cluster setting. The supported values are enabled and disabled. If enabled is specified, CloudWatch Container Insights will be enabled for the cluster, otherwise it will be
|
|
736
|
+
* The value to set for the cluster setting. The supported values are enabled and disabled. If enabled is specified, CloudWatch Container Insights will be enabled for the cluster, otherwise it will be off unless the containerInsights account setting is turned on. If a cluster value is specified, it will override the containerInsights value set with PutAccountSetting or PutAccountSettingDefault.
|
|
729
737
|
*/
|
|
730
738
|
value?: String;
|
|
731
739
|
}
|
|
@@ -900,7 +908,7 @@ declare namespace ECS {
|
|
|
900
908
|
*/
|
|
901
909
|
workingDirectory?: String;
|
|
902
910
|
/**
|
|
903
|
-
* When this parameter is true, networking is
|
|
911
|
+
* When this parameter is true, networking is off within the container. This parameter maps to NetworkDisabled in the Create a container section of the Docker Remote API. This parameter is not supported for Windows containers.
|
|
904
912
|
*/
|
|
905
913
|
disableNetworking?: BoxedBoolean;
|
|
906
914
|
/**
|
|
@@ -940,7 +948,7 @@ declare namespace ECS {
|
|
|
940
948
|
*/
|
|
941
949
|
dockerLabels?: DockerLabelsMap;
|
|
942
950
|
/**
|
|
943
|
-
* A list of ulimits to set in the container. If a ulimit value is specified in a task definition, it overrides the default values set by Docker. This parameter maps to Ulimits in the Create a container section of the Docker Remote API and the --ulimit option to docker run. Valid naming values are displayed in the Ulimit data type. Amazon ECS tasks hosted on Fargate use the default resource limit values set by the operating system with the exception of the nofile resource limit parameter which Fargate overrides. The nofile resource limit sets a restriction on the number of open files that a container can use. The default nofile soft limit is 1024 and hard limit is 4096. This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}' This parameter is not supported for Windows containers.
|
|
951
|
+
* A list of ulimits to set in the container. If a ulimit value is specified in a task definition, it overrides the default values set by Docker. This parameter maps to Ulimits in the Create a container section of the Docker Remote API and the --ulimit option to docker run. Valid naming values are displayed in the Ulimit data type. Amazon ECS tasks hosted on Fargate use the default resource limit values set by the operating system with the exception of the nofile resource limit parameter which Fargate overrides. The nofile resource limit sets a restriction on the number of open files that a container can use. The default nofile soft limit is 1024 and the default hard limit is 4096. This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}' This parameter is not supported for Windows containers.
|
|
944
952
|
*/
|
|
945
953
|
ulimits?: UlimitList;
|
|
946
954
|
/**
|
|
@@ -1169,11 +1177,11 @@ declare namespace ECS {
|
|
|
1169
1177
|
*/
|
|
1170
1178
|
configuration?: ClusterConfiguration;
|
|
1171
1179
|
/**
|
|
1172
|
-
* The short name of one or more capacity providers to associate with the cluster. A capacity provider must be associated with a cluster before it can be included as part of the default capacity provider strategy of the cluster or used in a capacity provider strategy when calling the CreateService or RunTask actions. If specifying a capacity provider that uses an Auto Scaling group, the capacity provider must be created but not associated with another cluster. New Auto Scaling group capacity providers can be created with the CreateCapacityProvider API operation. To use a Fargate capacity provider, specify either the FARGATE or FARGATE_SPOT capacity providers. The Fargate capacity providers are available to all accounts and only need to be associated with a cluster to be used. The
|
|
1180
|
+
* The short name of one or more capacity providers to associate with the cluster. A capacity provider must be associated with a cluster before it can be included as part of the default capacity provider strategy of the cluster or used in a capacity provider strategy when calling the CreateService or RunTask actions. If specifying a capacity provider that uses an Auto Scaling group, the capacity provider must be created but not associated with another cluster. New Auto Scaling group capacity providers can be created with the CreateCapacityProvider API operation. To use a Fargate capacity provider, specify either the FARGATE or FARGATE_SPOT capacity providers. The Fargate capacity providers are available to all accounts and only need to be associated with a cluster to be used. The PutCapacityProvider API operation is used to update the list of available capacity providers for a cluster after the cluster is created.
|
|
1173
1181
|
*/
|
|
1174
1182
|
capacityProviders?: StringList;
|
|
1175
1183
|
/**
|
|
1176
|
-
* The capacity provider strategy to set as the default for the cluster. After a default capacity provider strategy is set for a cluster, when you call the
|
|
1184
|
+
* The capacity provider strategy to set as the default for the cluster. After a default capacity provider strategy is set for a cluster, when you call the CreateService or RunTask APIs with no capacity provider strategy or launch type specified, the default capacity provider strategy for the cluster is used. If a default capacity provider strategy isn't defined for a cluster when it was created, it can be defined later with the PutClusterCapacityProviders API operation.
|
|
1177
1185
|
*/
|
|
1178
1186
|
defaultCapacityProviderStrategy?: CapacityProviderStrategy;
|
|
1179
1187
|
/**
|
|
@@ -1353,7 +1361,7 @@ declare namespace ECS {
|
|
|
1353
1361
|
*/
|
|
1354
1362
|
name: SettingName;
|
|
1355
1363
|
/**
|
|
1356
|
-
* The Amazon Resource Name (ARN) of the principal. It can be an
|
|
1364
|
+
* The Amazon Resource Name (ARN) of the principal. It can be an user, role, or the root user. If you specify the root user, it disables the account setting for all users, roles, and the root user of the account unless a user or role explicitly overrides these settings. If this field is omitted, the setting is changed only for the authenticated user.
|
|
1357
1365
|
*/
|
|
1358
1366
|
principalArn?: String;
|
|
1359
1367
|
}
|
|
@@ -1423,6 +1431,22 @@ declare namespace ECS {
|
|
|
1423
1431
|
*/
|
|
1424
1432
|
service?: Service;
|
|
1425
1433
|
}
|
|
1434
|
+
export interface DeleteTaskDefinitionsRequest {
|
|
1435
|
+
/**
|
|
1436
|
+
* The family and revision (family:revision) or full Amazon Resource Name (ARN) of the task definition to delete. You must specify a revision. You can specify up to 10 task definitions as a comma separated list.
|
|
1437
|
+
*/
|
|
1438
|
+
taskDefinitions: StringList;
|
|
1439
|
+
}
|
|
1440
|
+
export interface DeleteTaskDefinitionsResponse {
|
|
1441
|
+
/**
|
|
1442
|
+
* The list of deleted task definitions.
|
|
1443
|
+
*/
|
|
1444
|
+
taskDefinitions?: TaskDefinitionList;
|
|
1445
|
+
/**
|
|
1446
|
+
* Any failures associated with the call.
|
|
1447
|
+
*/
|
|
1448
|
+
failures?: Failures;
|
|
1449
|
+
}
|
|
1426
1450
|
export interface DeleteTaskSetRequest {
|
|
1427
1451
|
/**
|
|
1428
1452
|
* The short name or full Amazon Resource Name (ARN) of the cluster that hosts the service that the task set found in to delete.
|
|
@@ -1547,7 +1571,7 @@ declare namespace ECS {
|
|
|
1547
1571
|
}
|
|
1548
1572
|
export interface DeploymentConfiguration {
|
|
1549
1573
|
/**
|
|
1550
|
-
* The deployment circuit breaker can only be used for services using the rolling update (ECS) deployment type. The deployment circuit breaker determines whether a service deployment will fail if the service can't reach a steady state. If deployment circuit breaker
|
|
1574
|
+
* The deployment circuit breaker can only be used for services using the rolling update (ECS) deployment type. The deployment circuit breaker determines whether a service deployment will fail if the service can't reach a steady state. If you use the deployment circuit breaker, a service deployment will transition to a failed state and stop launching new tasks. If you use the rollback option, when a service deployment fails, the service is rolled back to the last deployment that completed successfully. For more information, see Rolling update in the Amazon Elastic Container Service Developer Guide
|
|
1551
1575
|
*/
|
|
1552
1576
|
deploymentCircuitBreaker?: DeploymentCircuitBreaker;
|
|
1553
1577
|
/**
|
|
@@ -1848,7 +1872,7 @@ declare namespace ECS {
|
|
|
1848
1872
|
*/
|
|
1849
1873
|
accessPointId?: String;
|
|
1850
1874
|
/**
|
|
1851
|
-
* Determines whether to use the Amazon ECS task
|
|
1875
|
+
* Determines whether to use the Amazon ECS task role defined in a task definition when mounting the Amazon EFS file system. If enabled, transit encryption must be enabled in the EFSVolumeConfiguration. If this parameter is omitted, the default value of DISABLED is used. For more information, see Using Amazon EFS access points in the Amazon Elastic Container Service Developer Guide.
|
|
1852
1876
|
*/
|
|
1853
1877
|
iam?: EFSAuthorizationConfigIAM;
|
|
1854
1878
|
}
|
|
@@ -1915,7 +1939,7 @@ declare namespace ECS {
|
|
|
1915
1939
|
*/
|
|
1916
1940
|
cloudWatchLogGroupName?: String;
|
|
1917
1941
|
/**
|
|
1918
|
-
* Determines whether to use encryption on the CloudWatch logs. If not specified, encryption will be
|
|
1942
|
+
* Determines whether to use encryption on the CloudWatch logs. If not specified, encryption will be off.
|
|
1919
1943
|
*/
|
|
1920
1944
|
cloudWatchEncryptionEnabled?: Boolean;
|
|
1921
1945
|
/**
|
|
@@ -2054,7 +2078,7 @@ declare namespace ECS {
|
|
|
2054
2078
|
export type GpuIds = String[];
|
|
2055
2079
|
export interface HealthCheck {
|
|
2056
2080
|
/**
|
|
2057
|
-
* A string array representing the command that the container runs to determine if it is healthy. The string array must start with CMD to run the command arguments directly, or CMD-SHELL to run the command with the container's default shell. When you use the Amazon Web Services Management Console JSON panel, the Command Line Interface, or the APIs, enclose the list of commands in brackets. [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] You don't
|
|
2081
|
+
* A string array representing the command that the container runs to determine if it is healthy. The string array must start with CMD to run the command arguments directly, or CMD-SHELL to run the command with the container's default shell. When you use the Amazon Web Services Management Console JSON panel, the Command Line Interface, or the APIs, enclose the list of commands in double quotes and brackets. [ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ] You don't include the double quotes and brackets when you use the Amazon Web Services Management Console. CMD-SHELL, curl -f http://localhost/ || exit 1 An exit code of 0 indicates success, and non-zero exit code indicates failure. For more information, see HealthCheck in the Create a container section of the Docker Remote API.
|
|
2058
2082
|
*/
|
|
2059
2083
|
command: StringList;
|
|
2060
2084
|
/**
|
|
@@ -2070,7 +2094,7 @@ declare namespace ECS {
|
|
|
2070
2094
|
*/
|
|
2071
2095
|
retries?: BoxedInteger;
|
|
2072
2096
|
/**
|
|
2073
|
-
* The optional grace period to provide containers time to bootstrap before failed health checks count towards the maximum number of retries. You can specify between 0 and 300 seconds. By default, the startPeriod is
|
|
2097
|
+
* The optional grace period to provide containers time to bootstrap before failed health checks count towards the maximum number of retries. You can specify between 0 and 300 seconds. By default, the startPeriod is off. If a health check succeeds within the startPeriod, then the container is considered healthy and any subsequent failures count toward the maximum number of retries.
|
|
2074
2098
|
*/
|
|
2075
2099
|
startPeriod?: BoxedInteger;
|
|
2076
2100
|
}
|
|
@@ -2198,7 +2222,7 @@ declare namespace ECS {
|
|
|
2198
2222
|
*/
|
|
2199
2223
|
value?: String;
|
|
2200
2224
|
/**
|
|
2201
|
-
* The ARN of the principal, which can be
|
|
2225
|
+
* The ARN of the principal, which can be a user, role, or the root user. If this field is omitted, the account settings are listed only for the authenticated user. Federated users assume the account setting of the root user and can't have explicit account settings set for them.
|
|
2202
2226
|
*/
|
|
2203
2227
|
principalArn?: String;
|
|
2204
2228
|
/**
|
|
@@ -2714,7 +2738,7 @@ declare namespace ECS {
|
|
|
2714
2738
|
*/
|
|
2715
2739
|
appProtocol?: ApplicationProtocol;
|
|
2716
2740
|
/**
|
|
2717
|
-
* The port number range on the container that's bound to the dynamically mapped host port range.
|
|
2741
|
+
* The port number range on the container that's bound to the dynamically mapped host port range. The following rules apply when you specify a containerPortRange: You must use either the bridge network mode or the awsvpc network mode. This parameter is available for both the EC2 and Fargate launch types. This parameter is available for both the Linux and Windows operating systems. The container instance must have at least version 1.67.0 of the container agent and at least version 1.67.0-1 of the ecs-init package You can specify a maximum of 100 port ranges per container. You do not specify a hostPortRange. The value of the hostPortRange is set as follows: For containers in a task with the awsvpc network mode, the hostPort is set to the same value as the containerPort. This is a static mapping strategy. For containers in a task with the bridge network mode, the Amazon ECS agent finds open host ports from the default ephemeral range and passes it to docker to bind them to the container ports. The containerPortRange valid values are between 1 and 65535. A port can only be included in one port mapping per container. You cannot specify overlapping port ranges. The first port in the range must be less than last port in the range. Docker recommends that you turn off the docker-proxy in the Docker daemon config file when you have a large number of ports. For more information, see Issue #11185 on the Github website. For information about how to turn off the docker-proxy in the Docker daemon config file, see Docker daemon in the Amazon ECS Developer Guide. You can call DescribeTasks to view the hostPortRange which are the host ports that are bound to the container ports.
|
|
2718
2742
|
*/
|
|
2719
2743
|
containerPortRange?: String;
|
|
2720
2744
|
}
|
|
@@ -2727,7 +2751,7 @@ declare namespace ECS {
|
|
|
2727
2751
|
*/
|
|
2728
2752
|
taskArn?: String;
|
|
2729
2753
|
/**
|
|
2730
|
-
* The protection status of the task. If scale-in protection is
|
|
2754
|
+
* The protection status of the task. If scale-in protection is on for a task, the value is true. Otherwise, it is false.
|
|
2731
2755
|
*/
|
|
2732
2756
|
protectionEnabled?: Boolean;
|
|
2733
2757
|
/**
|
|
@@ -2778,7 +2802,7 @@ declare namespace ECS {
|
|
|
2778
2802
|
*/
|
|
2779
2803
|
value: String;
|
|
2780
2804
|
/**
|
|
2781
|
-
* The ARN of the principal, which can be
|
|
2805
|
+
* The ARN of the principal, which can be a user, role, or the root user. If you specify the root user, it modifies the account setting for all users, roles, and the root user of the account unless a user or role explicitly overrides these settings. If this field is omitted, the setting is changed only for the authenticated user. Federated users assume the account setting of the root user and can't have explicit account settings set for them.
|
|
2782
2806
|
*/
|
|
2783
2807
|
principalArn?: String;
|
|
2784
2808
|
}
|
|
@@ -3060,7 +3084,7 @@ declare namespace ECS {
|
|
|
3060
3084
|
*/
|
|
3061
3085
|
tags?: Tags;
|
|
3062
3086
|
/**
|
|
3063
|
-
* The family and revision (family:revision) or full ARN of the task definition to run. If a revision isn't specified, the latest ACTIVE revision is used. When you create
|
|
3087
|
+
* The family and revision (family:revision) or full ARN of the task definition to run. If a revision isn't specified, the latest ACTIVE revision is used. When you create a policy for run-task, you can set the resource to be the latest task definition revision, or a specific revision. The full ARN value must match the value that you specified as the Resource of the principal's permissions policy. When you specify the policy resource as the latest task definition version (by setting the Resource in the policy to arn:aws:ecs:us-east-1:111122223333:task-definition/TaskFamilyName), then set this value to arn:aws:ecs:us-east-1:111122223333:task-definition/TaskFamilyName. When you specify the policy resource as a specific task definition version (by setting the Resource in the policy to arn:aws:ecs:us-east-1:111122223333:task-definition/TaskFamilyName:1 or arn:aws:ecs:us-east-1:111122223333:task-definition/TaskFamilyName:*), then set this value to arn:aws:ecs:us-east-1:111122223333:task-definition/TaskFamilyName:1. For more information, see Policy Resources for Amazon ECS in the Amazon Elastic Container Service developer Guide.
|
|
3064
3088
|
*/
|
|
3065
3089
|
taskDefinition: String;
|
|
3066
3090
|
}
|
|
@@ -3348,11 +3372,11 @@ declare namespace ECS {
|
|
|
3348
3372
|
*/
|
|
3349
3373
|
name?: SettingName;
|
|
3350
3374
|
/**
|
|
3351
|
-
* Determines whether the account setting is
|
|
3375
|
+
* Determines whether the account setting is on or off for the specified resource.
|
|
3352
3376
|
*/
|
|
3353
3377
|
value?: String;
|
|
3354
3378
|
/**
|
|
3355
|
-
* The ARN of the principal. It can be
|
|
3379
|
+
* The ARN of the principal. It can be a user, role, or the root user. If this field is omitted, the authenticated user is assumed.
|
|
3356
3380
|
*/
|
|
3357
3381
|
principalArn?: String;
|
|
3358
3382
|
}
|
|
@@ -3427,7 +3451,7 @@ declare namespace ECS {
|
|
|
3427
3451
|
*/
|
|
3428
3452
|
cluster?: String;
|
|
3429
3453
|
/**
|
|
3430
|
-
* The task ID
|
|
3454
|
+
* The task ID of the task to stop.
|
|
3431
3455
|
*/
|
|
3432
3456
|
task: String;
|
|
3433
3457
|
/**
|
|
@@ -3833,6 +3857,7 @@ declare namespace ECS {
|
|
|
3833
3857
|
export type TaskDefinitionFamilyStatus = "ACTIVE"|"INACTIVE"|"ALL"|string;
|
|
3834
3858
|
export type TaskDefinitionField = "TAGS"|string;
|
|
3835
3859
|
export type TaskDefinitionFieldList = TaskDefinitionField[];
|
|
3860
|
+
export type TaskDefinitionList = TaskDefinition[];
|
|
3836
3861
|
export interface TaskDefinitionPlacementConstraint {
|
|
3837
3862
|
/**
|
|
3838
3863
|
* The type of constraint. The MemberOf constraint restricts selection to be from a group of valid candidates.
|
|
@@ -3845,7 +3870,7 @@ declare namespace ECS {
|
|
|
3845
3870
|
}
|
|
3846
3871
|
export type TaskDefinitionPlacementConstraintType = "memberOf"|string;
|
|
3847
3872
|
export type TaskDefinitionPlacementConstraints = TaskDefinitionPlacementConstraint[];
|
|
3848
|
-
export type TaskDefinitionStatus = "ACTIVE"|"INACTIVE"|string;
|
|
3873
|
+
export type TaskDefinitionStatus = "ACTIVE"|"INACTIVE"|"DELETE_IN_PROGRESS"|string;
|
|
3849
3874
|
export type TaskField = "TAGS"|string;
|
|
3850
3875
|
export type TaskFieldList = TaskField[];
|
|
3851
3876
|
export interface TaskOverride {
|
|
@@ -3862,7 +3887,7 @@ declare namespace ECS {
|
|
|
3862
3887
|
*/
|
|
3863
3888
|
inferenceAcceleratorOverrides?: InferenceAcceleratorOverrides;
|
|
3864
3889
|
/**
|
|
3865
|
-
* The Amazon Resource Name (ARN) of the task execution
|
|
3890
|
+
* The Amazon Resource Name (ARN) of the task execution role override for the task. For more information, see Amazon ECS task execution IAM role in the Amazon Elastic Container Service Developer Guide.
|
|
3866
3891
|
*/
|
|
3867
3892
|
executionRoleArn?: String;
|
|
3868
3893
|
/**
|
|
@@ -3870,7 +3895,7 @@ declare namespace ECS {
|
|
|
3870
3895
|
*/
|
|
3871
3896
|
memory?: String;
|
|
3872
3897
|
/**
|
|
3873
|
-
* The Amazon Resource Name (ARN) of the
|
|
3898
|
+
* The Amazon Resource Name (ARN) of the role that containers in this task can assume. All containers in this task are granted the permissions that are specified in this role. For more information, see IAM Role for Tasks in the Amazon Elastic Container Service Developer Guide.
|
|
3874
3899
|
*/
|
|
3875
3900
|
taskRoleArn?: String;
|
|
3876
3901
|
/**
|