From 3be771ecf35ec6db93f8c0c127176eb78a248458 Mon Sep 17 00:00:00 2001
From: awstools Security Hub provides you with a comprehensive view of the security state of
-your Amazon Web Services environment and resources. It also provides you with the readiness
-status of your environment based on controls from supported security standards. Security Hub collects security data from Amazon Web Services accounts, services, and
-integrated third-party products and helps you analyze security trends in your environment
-to identify the highest priority security issues. For more information about Security Hub, see the
-Security Hub User
-Guide
-. When you use operations in the Security Hub API, the requests are executed only in
+ Security Hub provides you with a comprehensive view of your security state in Amazon Web Services and helps
+you assess your Amazon Web Services environment against security industry standards and best practices. Security Hub collects security data across Amazon Web Services accounts, Amazon Web Services, and
+supported third-party products and helps you analyze your security trends and identify the highest priority security
+issues. To help you manage the security state of your organization, Security Hub supports multiple security standards.
+These include the Amazon Web Services Foundational Security Best Practices (FSBP) standard developed by Amazon Web Services,
+and external compliance frameworks such as the Center for Internet Security (CIS), the Payment Card Industry Data
+Security Standard (PCI DSS), and the National Institute of Standards and Technology (NIST). Each standard includes
+several security controls, each of which represents a security best practice. Security Hub runs checks against
+security controls and generates control findings to help you assess your compliance against security best practices. In addition to generating control findings, Security Hub also receives findings from other Amazon Web Services,
+such as Amazon GuardDuty and Amazon Inspector, and
+supported third-party products. This gives you a single pane of glass into a variety of security-related issues. You
+can also send Security Hub findings to other Amazon Web Services and supported third-party products. Security Hub offers automation features that help you triage and remediate security issues. For example,
+you can use automation rules to automatically update critical findings when a security check fails. You can also leverage the integration with
+Amazon EventBridge to trigger automatic responses to specific findings. This guide, the Security Hub API Reference, provides
+information about the Security Hub API. This includes supported resources, HTTP methods, parameters,
+and schemas. If you're new to Security Hub, you might find it helpful to also review the
+Security Hub User Guide
+. The
+user guide explains key concepts and provides procedures
+that demonstrate how to use Security Hub features. It also provides information about topics such as
+integrating Security Hub with other Amazon Web Services. In addition to interacting with Security Hub by making calls to the Security Hub API, you can
+use a current version of an Amazon Web Services command line tool or SDK. Amazon Web Services provides tools
+and SDKs that consist of libraries and sample code for various languages and platforms, such as PowerShell,
+Java, Go, Python, C++, and .NET. These tools and SDKs provide convenient, programmatic access to
+Security Hub and other Amazon Web Services . They also handle tasks such as signing requests,
+managing errors, and retrying requests automatically. For information about installing and using the Amazon Web Services tools
+and SDKs, see Tools to Build on Amazon Web Services. With the exception of operations that are related to central configuration, Security Hub API requests are executed only in
the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change
that results from the operation is applied only to that Region. To make the same change in
-other Regions, run the same command for each Region in which you want to apply the change. For example, if your Region is set to The following throttling limits apply to using Security Hub API operations.us-west-2
, when you use CreateMembers
to add a member account to Security Hub, the association of
-the member account with the administrator account is created only in the us-west-2
-Region. Security Hub must be enabled for the member account in the same Region that the invitation
-was sent from.
The following throttling limits apply to Security Hub API operations.
diff --git a/clients/client-securityhub/src/SecurityHub.ts b/clients/client-securityhub/src/SecurityHub.ts index 4c667fc75b77..05aab4d3b41a 100644 --- a/clients/client-securityhub/src/SecurityHub.ts +++ b/clients/client-securityhub/src/SecurityHub.ts @@ -1744,23 +1744,47 @@ export interface SecurityHub { } /** - *
Security Hub provides you with a comprehensive view of the security state of - * your Amazon Web Services environment and resources. It also provides you with the readiness - * status of your environment based on controls from supported security standards. Security Hub collects security data from Amazon Web Services accounts, services, and - * integrated third-party products and helps you analyze security trends in your environment - * to identify the highest priority security issues. For more information about Security Hub, see the - * Security Hub User - * Guide - * .
- *When you use operations in the Security Hub API, the requests are executed only in + *
Security Hub provides you with a comprehensive view of your security state in Amazon Web Services and helps + * you assess your Amazon Web Services environment against security industry standards and best practices.
+ *Security Hub collects security data across Amazon Web Services accounts, Amazon Web Services, and + * supported third-party products and helps you analyze your security trends and identify the highest priority security + * issues.
+ *To help you manage the security state of your organization, Security Hub supports multiple security standards. + * These include the Amazon Web Services Foundational Security Best Practices (FSBP) standard developed by Amazon Web Services, + * and external compliance frameworks such as the Center for Internet Security (CIS), the Payment Card Industry Data + * Security Standard (PCI DSS), and the National Institute of Standards and Technology (NIST). Each standard includes + * several security controls, each of which represents a security best practice. Security Hub runs checks against + * security controls and generates control findings to help you assess your compliance against security best practices.
+ *In addition to generating control findings, Security Hub also receives findings from other Amazon Web Services, + * such as Amazon GuardDuty and Amazon Inspector, and + * supported third-party products. This gives you a single pane of glass into a variety of security-related issues. You + * can also send Security Hub findings to other Amazon Web Services and supported third-party products.
+ *Security Hub offers automation features that help you triage and remediate security issues. For example, + * you can use automation rules to automatically update critical findings when a security check fails. You can also leverage the integration with + * Amazon EventBridge to trigger automatic responses to specific findings.
+ *This guide, the Security Hub API Reference, provides + * information about the Security Hub API. This includes supported resources, HTTP methods, parameters, + * and schemas. If you're new to Security Hub, you might find it helpful to also review the + * Security Hub User Guide + * . The + * user guide explains key concepts and provides procedures + * that demonstrate how to use Security Hub features. It also provides information about topics such as + * integrating Security Hub with other Amazon Web Services.
+ *In addition to interacting with Security Hub by making calls to the Security Hub API, you can + * use a current version of an Amazon Web Services command line tool or SDK. Amazon Web Services provides tools + * and SDKs that consist of libraries and sample code for various languages and platforms, such as PowerShell, + * Java, Go, Python, C++, and .NET. These tools and SDKs provide convenient, programmatic access to + * Security Hub and other Amazon Web Services . They also handle tasks such as signing requests, + * managing errors, and retrying requests automatically. For information about installing and using the Amazon Web Services tools + * and SDKs, see Tools to Build on Amazon Web Services.
+ *With the exception of operations that are related to central configuration, Security Hub API requests are executed only in * the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change * that results from the operation is applied only to that Region. To make the same change in - * other Regions, run the same command for each Region in which you want to apply the change.
- *For example, if your Region is set to us-west-2
, when you use CreateMembers
to add a member account to Security Hub, the association of
- * the member account with the administrator account is created only in the us-west-2
- * Region. Security Hub must be enabled for the member account in the same Region that the invitation
- * was sent from.
The following throttling limits apply to using Security Hub API operations.
+ * other Regions, call the same API operation in each Region in which you want to apply the change. When you use central configuration, + * API requests for enabling Security Hub, standards, and controls are executed in the home Region and all linked Regions. For a list of + * central configuration operations, see the Central configuration + * terms and concepts section of the Security Hub User Guide. + *The following throttling limits apply to Security Hub API operations.
*diff --git a/clients/client-securityhub/src/SecurityHubClient.ts b/clients/client-securityhub/src/SecurityHubClient.ts index 5d59097b05c3..75bdf7914e9f 100644 --- a/clients/client-securityhub/src/SecurityHubClient.ts +++ b/clients/client-securityhub/src/SecurityHubClient.ts @@ -636,23 +636,47 @@ export type SecurityHubClientResolvedConfigType = __SmithyResolvedConfiguration< export interface SecurityHubClientResolvedConfig extends SecurityHubClientResolvedConfigType {} /** - *
Security Hub provides you with a comprehensive view of the security state of - * your Amazon Web Services environment and resources. It also provides you with the readiness - * status of your environment based on controls from supported security standards. Security Hub collects security data from Amazon Web Services accounts, services, and - * integrated third-party products and helps you analyze security trends in your environment - * to identify the highest priority security issues. For more information about Security Hub, see the - * Security Hub User - * Guide - * .
- *When you use operations in the Security Hub API, the requests are executed only in + *
Security Hub provides you with a comprehensive view of your security state in Amazon Web Services and helps + * you assess your Amazon Web Services environment against security industry standards and best practices.
+ *Security Hub collects security data across Amazon Web Services accounts, Amazon Web Services, and + * supported third-party products and helps you analyze your security trends and identify the highest priority security + * issues.
+ *To help you manage the security state of your organization, Security Hub supports multiple security standards. + * These include the Amazon Web Services Foundational Security Best Practices (FSBP) standard developed by Amazon Web Services, + * and external compliance frameworks such as the Center for Internet Security (CIS), the Payment Card Industry Data + * Security Standard (PCI DSS), and the National Institute of Standards and Technology (NIST). Each standard includes + * several security controls, each of which represents a security best practice. Security Hub runs checks against + * security controls and generates control findings to help you assess your compliance against security best practices.
+ *In addition to generating control findings, Security Hub also receives findings from other Amazon Web Services, + * such as Amazon GuardDuty and Amazon Inspector, and + * supported third-party products. This gives you a single pane of glass into a variety of security-related issues. You + * can also send Security Hub findings to other Amazon Web Services and supported third-party products.
+ *Security Hub offers automation features that help you triage and remediate security issues. For example, + * you can use automation rules to automatically update critical findings when a security check fails. You can also leverage the integration with + * Amazon EventBridge to trigger automatic responses to specific findings.
+ *This guide, the Security Hub API Reference, provides + * information about the Security Hub API. This includes supported resources, HTTP methods, parameters, + * and schemas. If you're new to Security Hub, you might find it helpful to also review the + * Security Hub User Guide + * . The + * user guide explains key concepts and provides procedures + * that demonstrate how to use Security Hub features. It also provides information about topics such as + * integrating Security Hub with other Amazon Web Services.
+ *In addition to interacting with Security Hub by making calls to the Security Hub API, you can + * use a current version of an Amazon Web Services command line tool or SDK. Amazon Web Services provides tools + * and SDKs that consist of libraries and sample code for various languages and platforms, such as PowerShell, + * Java, Go, Python, C++, and .NET. These tools and SDKs provide convenient, programmatic access to + * Security Hub and other Amazon Web Services . They also handle tasks such as signing requests, + * managing errors, and retrying requests automatically. For information about installing and using the Amazon Web Services tools + * and SDKs, see Tools to Build on Amazon Web Services.
+ *With the exception of operations that are related to central configuration, Security Hub API requests are executed only in * the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change * that results from the operation is applied only to that Region. To make the same change in - * other Regions, run the same command for each Region in which you want to apply the change.
- *For example, if your Region is set to us-west-2
, when you use CreateMembers
to add a member account to Security Hub, the association of
- * the member account with the administrator account is created only in the us-west-2
- * Region. Security Hub must be enabled for the member account in the same Region that the invitation
- * was sent from.
The following throttling limits apply to using Security Hub API operations.
+ * other Regions, call the same API operation in each Region in which you want to apply the change. When you use central configuration, + * API requests for enabling Security Hub, standards, and controls are executed in the home Region and all linked Regions. For a list of + * central configuration operations, see the Central configuration + * terms and concepts section of the Security Hub User Guide. + *The following throttling limits apply to Security Hub API operations.
*diff --git a/clients/client-securityhub/src/index.ts b/clients/client-securityhub/src/index.ts index e4e964347478..d65db4faa3b3 100644 --- a/clients/client-securityhub/src/index.ts +++ b/clients/client-securityhub/src/index.ts @@ -1,23 +1,47 @@ // smithy-typescript generated code /* eslint-disable */ /** - *
Security Hub provides you with a comprehensive view of the security state of - * your Amazon Web Services environment and resources. It also provides you with the readiness - * status of your environment based on controls from supported security standards. Security Hub collects security data from Amazon Web Services accounts, services, and - * integrated third-party products and helps you analyze security trends in your environment - * to identify the highest priority security issues. For more information about Security Hub, see the - * Security Hub User - * Guide - * .
- *When you use operations in the Security Hub API, the requests are executed only in + *
Security Hub provides you with a comprehensive view of your security state in Amazon Web Services and helps + * you assess your Amazon Web Services environment against security industry standards and best practices.
+ *Security Hub collects security data across Amazon Web Services accounts, Amazon Web Services, and + * supported third-party products and helps you analyze your security trends and identify the highest priority security + * issues.
+ *To help you manage the security state of your organization, Security Hub supports multiple security standards. + * These include the Amazon Web Services Foundational Security Best Practices (FSBP) standard developed by Amazon Web Services, + * and external compliance frameworks such as the Center for Internet Security (CIS), the Payment Card Industry Data + * Security Standard (PCI DSS), and the National Institute of Standards and Technology (NIST). Each standard includes + * several security controls, each of which represents a security best practice. Security Hub runs checks against + * security controls and generates control findings to help you assess your compliance against security best practices.
+ *In addition to generating control findings, Security Hub also receives findings from other Amazon Web Services, + * such as Amazon GuardDuty and Amazon Inspector, and + * supported third-party products. This gives you a single pane of glass into a variety of security-related issues. You + * can also send Security Hub findings to other Amazon Web Services and supported third-party products.
+ *Security Hub offers automation features that help you triage and remediate security issues. For example, + * you can use automation rules to automatically update critical findings when a security check fails. You can also leverage the integration with + * Amazon EventBridge to trigger automatic responses to specific findings.
+ *This guide, the Security Hub API Reference, provides + * information about the Security Hub API. This includes supported resources, HTTP methods, parameters, + * and schemas. If you're new to Security Hub, you might find it helpful to also review the + * Security Hub User Guide + * . The + * user guide explains key concepts and provides procedures + * that demonstrate how to use Security Hub features. It also provides information about topics such as + * integrating Security Hub with other Amazon Web Services.
+ *In addition to interacting with Security Hub by making calls to the Security Hub API, you can + * use a current version of an Amazon Web Services command line tool or SDK. Amazon Web Services provides tools + * and SDKs that consist of libraries and sample code for various languages and platforms, such as PowerShell, + * Java, Go, Python, C++, and .NET. These tools and SDKs provide convenient, programmatic access to + * Security Hub and other Amazon Web Services . They also handle tasks such as signing requests, + * managing errors, and retrying requests automatically. For information about installing and using the Amazon Web Services tools + * and SDKs, see Tools to Build on Amazon Web Services.
+ *With the exception of operations that are related to central configuration, Security Hub API requests are executed only in * the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change * that results from the operation is applied only to that Region. To make the same change in - * other Regions, run the same command for each Region in which you want to apply the change.
- *For example, if your Region is set to us-west-2
, when you use CreateMembers
to add a member account to Security Hub, the association of
- * the member account with the administrator account is created only in the us-west-2
- * Region. Security Hub must be enabled for the member account in the same Region that the invitation
- * was sent from.
The following throttling limits apply to using Security Hub API operations.
+ * other Regions, call the same API operation in each Region in which you want to apply the change. When you use central configuration, + * API requests for enabling Security Hub, standards, and controls are executed in the home Region and all linked Regions. For a list of + * central configuration operations, see the Central configuration + * terms and concepts section of the Security Hub User Guide. + *The following throttling limits apply to Security Hub API operations.
*
diff --git a/clients/client-securityhub/src/models/models_0.ts b/clients/client-securityhub/src/models/models_0.ts
index 1de451f450f4..4fe4bb2f7548 100644
--- a/clients/client-securityhub/src/models/models_0.ts
+++ b/clients/client-securityhub/src/models/models_0.ts
@@ -387,17 +387,65 @@ export interface AwsApiCallAction {
AffectedResources?: Record An ISO8601-formatted timestamp that indicates when the API call was first
+ * A timestamp that indicates when the API call was first
* observed. A correctly formatted example is This field accepts only the specified formats. Timestamps
+ * can end with
+ *
+ *
+ *
+ *
+ * An ISO8601-formatted timestamp that indicates when the API call was most recently
+ * A timestamp that indicates when the API call was most recently
* observed. A correctly formatted example is This field accepts only the specified formats. Timestamps
+ * can end with
+ *
+ *
+ *
+ *
+ * A timestamp that provides the start date for the date filter. A correctly formatted example is This field accepts only the specified formats. Timestamps
+ * can end with
+ *
+ *
+ *
+ *
+ * A timestamp that provides the end date for the date filter. A correctly formatted example is This field accepts only the specified formats. Timestamps
+ * can end with
+ *
+ *
+ *
+ *
+ * 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ *
* @public
*/
FirstSeen?: string;
/**
- * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ *
* @public
*/
LastSeen?: string;
@@ -1430,16 +1478,62 @@ export interface DateRange {
export interface DateFilter {
/**
* YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
.
- * For more information, see RFC 3339 section 5.6, Internet Date/Time Format.Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ *
* @public
*/
Start?: string;
/**
* YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
.
- * For more information, see RFC 3339 section 5.6, Internet Date/Time Format.Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ *
* @public
*/
End?: string;
@@ -1611,9 +1705,31 @@ export interface AutomationRulesFindingFilters {
* A timestamp that indicates when the potential security issue captured by a
* finding was first observed by the security findings product.
* YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* Array Members: Minimum number of 1 item. Maximum number of 20 items. *
@@ -1626,9 +1742,31 @@ export interface AutomationRulesFindingFilters { * A timestamp that indicates when the potential security issue captured by a finding * was most recently observed by the security findings product. * - *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* Array Members: Minimum number of 1 item. Maximum number of 20 items. *
@@ -1640,9 +1778,31 @@ export interface AutomationRulesFindingFilters { ** A timestamp that indicates when this finding record was created. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* Array Members: Minimum number of 1 item. Maximum number of 20 items. *
@@ -1654,9 +1814,31 @@ export interface AutomationRulesFindingFilters { ** A timestamp that indicates when the finding record was most recently updated. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* Array Members: Minimum number of 1 item. Maximum number of 20 items. *
@@ -1930,10 +2112,32 @@ export interface AutomationRulesFindingFilters { /** *
- * The timestamp of when the note was updated. Uses the date-time format specified in
- * RFC 3339 section 5.6, Internet Date/Time Format. The value cannot contain spaces.
- * For example, 2020-03-22T13:22:13.933Z
.
- *
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* Array Members: Minimum number of 1 item. Maximum number of 20 items. *
@@ -2092,9 +2296,31 @@ export interface AutomationRulesConfig { ** A timestamp that indicates when the rule was created. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* A timestamp that indicates when the rule was most recently updated. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* A timestamp that indicates when the rule was created. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
* A timestamp that indicates when the rule was most recently updated. *
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the API was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was most recently updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the API was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was most recently updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the auto scaling group was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The creation date and time for the launch configuration.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the renewal summary was last updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was requested.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was imported. Provided if the certificate type is
* IMPORTED
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was issued. Provided if the certificate type is
* AMAZON_ISSUED
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The time after which the certificate becomes invalid.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The time before which the certificate is not valid.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when that the distribution was last modified.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
If the billing mode is PAY_PER_REQUEST
, indicates when the billing mode was
* set to that value.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the provisioned throughput was last decreased.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the provisioned throughput was last increased.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates the point in time that the table was restored to.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
If the key is inaccessible, the date and time when DynamoDB detected that the key was * inaccessible.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the table was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the instance was launched.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the attachment initiated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the volume was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date and time of the last change in status.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date and time when the image was pushed to the repository.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the load balancer was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the load balancer was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the session was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the IAM access key was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the IAM group was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the role was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the instance profile was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the version was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
When the policy was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
When the policy was most recently updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the role was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the user was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the KMS key was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the function was last updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The layer's compatible runtimes. Maximum number of five items.
- *Valid values: nodejs10.x
| nodejs12.x
| java8
|
- * java11
| python2.7
| python3.6
|
- * python3.7
| python3.8
| dotnetcore1.0
|
- * dotnetcore2.1
| go1.x
| ruby2.5
|
- * provided
+ *
The layer's compatible function runtimes.
+ *The following list includes deprecated runtimes. For more information, see Runtime deprecation policy in the Lambda Developer Guide.
+ *Array Members: Maximum number of 5 items.
+ *Valid Values: nodejs | nodejs4.3 | nodejs6.10 | nodejs8.10 | nodejs10.x | nodejs12.x | nodejs14.x | nodejs16.x | java8 | java8.al2 | java11 | python2.7 | python3.6 | python3.7 | python3.8 | python3.9 | dotnetcore1.0 | dotnetcore2.0 | dotnetcore2.1 | dotnetcore3.1 | dotnet6 | nodejs4.3-edge | go1.x | ruby2.5 | ruby2.7 | provided | provided.al2 | nodejs18.x | python3.10 | java17 | ruby3.2 | python3.11 | nodejs20.x | provided.al2023 | python3.12 | java21
*
Indicates when the version was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the snapshot was taken.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB instance was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Specifies the latest time to which a database can be restored with point-in-time * restore.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The datetime when the event notification subscription was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The end of the time window for which maintenance was deferred.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The start of the time window for which maintenance was deferred.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The last time when logs failed to be delivered.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The last time that logs were delivered successfully.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the cluster was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the next snapshot is expected to be taken. The cluster must have a valid * snapshot schedule and have backups enabled.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates the start of the next maintenance window.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A date on which to transition objects to the specified storage class. If you provide Date
, you cannot provide Days
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date when objects are moved or deleted.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the S3 bucket was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the object was last modified.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The timestamp of when the note was updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
A timestamp that indicates when the note was updated.
+ *This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the operation started.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the operation completed.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the process was launched.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the process was terminated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the container started.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the most recent instance of a threat intelligence indicator was * observed.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the vulnerability advisory was created.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the vulnerability advisory was last updated.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider first observed the potential security * issue that a finding captured.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider most recently observed the potential * security issue that a finding captured.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider created the potential security issue that * a finding captured.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider last updated the finding record.
- *Uses the date-time
format specified in RFC 3339 section 5.6, Internet
- * Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,
- * 2020-03-22T13:22:13.933Z
.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when Security Hub received a finding and begins to process it.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A imestamp that indicates when Security Hub received a finding and begins to process it.
+ *This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider first + *
A timestamp that indicates when the security findings provider first * observed the potential security issue that a finding captured.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider most + *
A timestamp that indicates when the security findings provider most * recently observed the potential security issue that a finding captured.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider - * captured the potential security issue that a finding captured.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider + * created the potential security issue that a finding reflects.
+ *This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider last - * updated the finding record.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider last + * updated the finding record.
+ *This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the process was launched.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the process was terminated.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the container was started.
- *A correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO 8601-formatted timestamp that indicates when Security Hub + *
A timestamp that indicates when Security Hub * processed the updated finding record.
- *A correctly formatted example is
- * 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and
- * time should be separated by T
. For more information, see RFC 3339 section 5.6,
- * Internet Date/Time Format.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
- * An ISO 8601-formatted timestamp that indicates the start time of the requested finding history. A correctly formatted
- * example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated
- * by T
. For more information, see RFC 3339
- * section 5.6, Internet Date/Time Format.
A timestamp that indicates the start time of the requested finding history.
*If you provide values for both StartTime
and EndTime
,
* Security Hub returns finding history for the specified time period. If you
* provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at
@@ -7841,17 +8226,39 @@ export interface GetFindingHistoryRequest {
* provide neither StartTime
nor EndTime
, Security Hub
* returns finding history from the CreatedAt timestamp of the finding to the time at which
* the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is
- * limited to 90 days.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
- * An ISO 8601-formatted timestamp that indicates the end time of the requested finding history. A correctly formatted
- * example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated
- * by T
. For more information, see RFC 3339
- * section 5.6, Internet Date/Time Format.
If you provide values for both StartTime
and EndTime
,
* Security Hub returns finding history for the specified time period. If you
* provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at
@@ -7861,6 +8268,31 @@ export interface GetFindingHistoryRequest {
* returns finding history from the CreatedAt timestamp of the finding to the time at which
* the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is
* limited to 90 days.
This field accepts only the specified formats. Timestamps
+ * can end with Z
or ("+" / "-") time-hour [":" time-minute]
. The time-secfrac after seconds is limited
+ * to a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
+ * YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
+ * YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
+ * YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
+ * YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
One or more attributes used to filter the findings included in the insight. The insight - * only includes findings that match the criteria defined in the filters.
+ *One or more attributes used to filter the findings included in the insight. You can filter by up to ten finding attributes. For each attribute, you can provide up to 20 filter values. + * The insight only includes findings that match the criteria defined in the filters.
* @public */ Filters: AwsSecurityFindingFilters | undefined; diff --git a/codegen/sdk-codegen/aws-models/securityhub.json b/codegen/sdk-codegen/aws-models/securityhub.json index dd1f1927d80f..d5b05c062772 100644 --- a/codegen/sdk-codegen/aws-models/securityhub.json +++ b/codegen/sdk-codegen/aws-models/securityhub.json @@ -759,13 +759,13 @@ "CreatedAt": { "target": "com.amazonaws.securityhub#Timestamp", "traits": { - "smithy.api#documentation": "\n A timestamp that indicates when the rule was created.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n A timestamp that indicates when the rule was created.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n A timestamp that indicates when the rule was most recently updated.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n A timestamp that indicates when the rule was most recently updated.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n A timestamp that indicates when the potential security issue captured by a \n finding was first observed by the security findings product.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" + "smithy.api#documentation": "\n A timestamp that indicates when the potential security issue captured by a \n finding was first observed by the security findings product.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" } }, "LastObservedAt": { "target": "com.amazonaws.securityhub#DateFilterList", "traits": { - "smithy.api#documentation": "\n A timestamp that indicates when the potential security issue captured by a finding \n was most recently observed by the security findings product.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" + "smithy.api#documentation": "\n A timestamp that indicates when the potential security issue captured by a finding \n was most recently observed by the security findings product.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" } }, "CreatedAt": { "target": "com.amazonaws.securityhub#DateFilterList", "traits": { - "smithy.api#documentation": "\n A timestamp that indicates when this finding record was created.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" + "smithy.api#documentation": "\n A timestamp that indicates when this finding record was created.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" } }, "UpdatedAt": { "target": "com.amazonaws.securityhub#DateFilterList", "traits": { - "smithy.api#documentation": "\n A timestamp that indicates when the finding record was most recently updated. \n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" + "smithy.api#documentation": "\n A timestamp that indicates when the finding record was most recently updated. \n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" } }, "Confidence": { @@ -1036,7 +1036,7 @@ "NoteUpdatedAt": { "target": "com.amazonaws.securityhub#DateFilterList", "traits": { - "smithy.api#documentation": "\n The timestamp of when the note was updated. Uses the date-time format specified in \n RFC 3339 section 5.6, Internet Date/Time Format. The value cannot contain spaces. \n For example, 2020-03-22T13:22:13.933Z
.\n
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" + "smithy.api#documentation": "\n The timestamp of when the note was updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n \t\tArray Members: Minimum number of 1 item. Maximum number of 20 items.\n \t
" } }, "NoteUpdatedBy": { @@ -1116,13 +1116,13 @@ "CreatedAt": { "target": "com.amazonaws.securityhub#Timestamp", "traits": { - "smithy.api#documentation": "\n A timestamp that indicates when the rule was created.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n A timestamp that indicates when the rule was created.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n A timestamp that indicates when the rule was most recently updated.\n
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces. For example,\n 2020-03-22T13:22:13.933Z
.
\n A timestamp that indicates when the rule was most recently updated.\n
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the API call was first\n observed.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the API call was first\n observed.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the API call was most recently\n observed.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the API call was most recently\n observed.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the API was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the API was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the stage was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was most recently updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the stage was most recently updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the API was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the API was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the stage was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the stage was most recently updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the stage was most recently updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the auto scaling group was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the auto scaling group was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The creation date and time for the launch configuration.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The creation date and time for the launch configuration.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was requested.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the certificate was requested.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was imported. Provided if the certificate type is\n IMPORTED
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the certificate was imported. Provided if the certificate type is\n IMPORTED
.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the certificate was issued. Provided if the certificate type is\n AMAZON_ISSUED
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the certificate was issued. Provided if the certificate type is\n AMAZON_ISSUED
.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The time after which the certificate becomes invalid.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The time after which the certificate becomes invalid.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The time before which the certificate is not valid.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The time before which the certificate is not valid.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the renewal summary was last updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the renewal summary was last updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when that the distribution was last modified.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when that the distribution was last modified.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
If the billing mode is PAY_PER_REQUEST
, indicates when the billing mode was\n set to that value.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
If the billing mode is PAY_PER_REQUEST
, indicates when the billing mode was\n set to that value.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the table was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the table was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the provisioned throughput was last decreased.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the provisioned throughput was last decreased.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the provisioned throughput was last increased.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the provisioned throughput was last increased.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates the point in time that the table was restored to.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates the point in time that the table was restored to.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
If the key is inaccessible, the date and time when DynamoDB detected that the key was\n inaccessible.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
If the key is inaccessible, the date and time when DynamoDB detected that the key was\n inaccessible.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the instance was launched.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the instance was launched.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the attachment initiated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the attachment initiated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the volume was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the volume was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date and time of the last change in status.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The date and time of the last change in status.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date and time when the image was pushed to the repository.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The date and time when the image was pushed to the repository.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the load balancer was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the load balancer was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the load balancer was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the load balancer was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the IAM access key was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the IAM access key was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the session was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the session was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the IAM group was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the IAM group was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the instance profile was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the instance profile was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the role was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the role was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
When the policy was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
When the policy was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
When the policy was most recently updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
When the policy was most recently updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the version was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the version was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the role was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the role was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the user was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the user was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the KMS key was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the KMS key was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the function was last updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the function was last updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The layer's compatible runtimes. Maximum number of five items.
\nValid values: nodejs10.x
| nodejs12.x
| java8
|\n java11
| python2.7
| python3.6
|\n python3.7
| python3.8
| dotnetcore1.0
|\n dotnetcore2.1
| go1.x
| ruby2.5
|\n provided
\n
The layer's compatible function runtimes.
\nThe following list includes deprecated runtimes. For more information, see Runtime deprecation policy in the Lambda Developer Guide.
\nArray Members: Maximum number of 5 items.
\nValid Values: nodejs | nodejs4.3 | nodejs6.10 | nodejs8.10 | nodejs10.x | nodejs12.x | nodejs14.x | nodejs16.x | java8 | java8.al2 | java11 | python2.7 | python3.6 | python3.7 | python3.8 | python3.9 | dotnetcore1.0 | dotnetcore2.0 | dotnetcore2.1 | dotnetcore3.1 | dotnet6 | nodejs4.3-edge | go1.x | ruby2.5 | ruby2.7 | provided | provided.al2 | nodejs18.x | python3.10 | java17 | ruby3.2 | python3.11 | nodejs20.x | provided.al2023 | python3.12 | java21
\n
Indicates when the version was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the version was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the snapshot was taken.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the snapshot was taken.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the DB cluster was created, in Universal Coordinated Time (UTC).
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the DB instance was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the DB instance was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Specifies the latest time to which a database can be restored with point-in-time\n restore.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Specifies the latest time to which a database can be restored with point-in-time\n restore.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The datetime when the event notification subscription was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The datetime when the event notification subscription was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The end of the time window for which maintenance was deferred.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The end of the time window for which maintenance was deferred.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The start of the time window for which maintenance was deferred.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The start of the time window for which maintenance was deferred.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the cluster was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the cluster was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the next snapshot is expected to be taken. The cluster must have a valid\n snapshot schedule and have backups enabled.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the next snapshot is expected to be taken. The cluster must have a valid\n snapshot schedule and have backups enabled.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates the start of the next maintenance window.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates the start of the next maintenance window.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The last time when logs failed to be delivered.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The last time when logs failed to be delivered.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The last time that logs were delivered successfully.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The last time that logs were delivered successfully.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
The date when objects are moved or deleted.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
The date when objects are moved or deleted.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A date on which to transition objects to the specified storage class. If you provide Date
, you cannot provide Days
.
Uses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
A date on which to transition objects to the specified storage class. If you provide Date
, you cannot provide Days
.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the S3 bucket was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the S3 bucket was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the object was last modified.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the object was last modified.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider first observed the potential security\n issue that a finding captured.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the security findings provider first observed the potential security\n issue that a finding captured.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider most recently observed the potential\n security issue that a finding captured.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the security findings provider most recently observed the potential\n security issue that a finding captured.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider created the potential security issue that\n a finding captured.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the security findings provider created the potential security issue that\n a finding captured.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the security findings provider last updated the finding record.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the security findings provider last updated the finding record.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when Security Hub received a finding and begins to process it.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A imestamp that indicates when Security Hub received a finding and begins to process it.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider first\n observed the potential security issue that a finding captured.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider first\n observed the potential security issue that a finding captured.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider most\n recently observed the potential security issue that a finding captured.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider most\n recently observed the potential security issue that a finding captured.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider\n captured the potential security issue that a finding captured.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider\n created the potential security issue that a finding reflects.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO8601-formatted timestamp that indicates when the security findings provider last\n updated the finding record.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that indicates when the security findings provider last\n updated the finding record.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the process was launched.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that identifies when the process was launched.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the process was terminated.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that identifies when the process was terminated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that identifies when the container was started.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that identifies when the container was started.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the container started.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the container started.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that provides the start date for the date filter.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. \n For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that provides the start date for the date filter.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
A timestamp that provides the end date for the date filter.
\nA correctly formatted example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated by T
. \n For more information, see RFC 3339 section 5.6, Internet Date/Time Format.
A timestamp that provides the end date for the date filter.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
An ISO 8601-formatted timestamp that indicates when Security Hub \n processed the updated finding record.
\nA correctly formatted example is\n 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and\n time should be separated by T
. For more information, see RFC 3339 section 5.6,\n Internet Date/Time Format.
A timestamp that indicates when Security Hub \n processed the updated finding record.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n An ISO 8601-formatted timestamp that indicates the start time of the requested finding history. A correctly formatted \n example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated \n by T
. For more information, see RFC 3339 \n section 5.6, Internet Date/Time Format.
If you provide values for both StartTime
and EndTime
,\n Security Hub returns finding history for the specified time period. If you\n provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at\n which the API is called. If you provide a value for EndTime
but not for\n StartTime
, Security Hub returns finding history from the CreatedAt timestamp of the finding to the EndTime
. If you\n provide neither StartTime
nor EndTime
, Security Hub\n returns finding history from the CreatedAt timestamp of the finding to the time at which\n the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is \n limited to 90 days.
A timestamp that indicates the start time of the requested finding history.
\nIf you provide values for both StartTime
and EndTime
,\n Security Hub returns finding history for the specified time period. If you\n provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at\n which the API is called. If you provide a value for EndTime
but not for\n StartTime
, Security Hub returns finding history from the CreatedAt timestamp of the finding to the EndTime
. If you\n provide neither StartTime
nor EndTime
, Security Hub\n returns finding history from the CreatedAt timestamp of the finding to the time at which\n the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is \n limited to 90 days.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
\n An ISO 8601-formatted timestamp that indicates the end time of the requested finding history. A correctly formatted \n example is 2020-05-21T20:16:34.724Z
. The value cannot contain spaces, and date and time should be separated \n by T
. For more information, see RFC 3339 \n section 5.6, Internet Date/Time Format.
If you provide values for both StartTime
and EndTime
,\n Security Hub returns finding history for the specified time period. If you\n provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at\n which the API is called. If you provide a value for EndTime
but not for\n StartTime
, Security Hub returns finding history from the CreatedAt timestamp of the finding to the EndTime
. If you\n provide neither StartTime
nor EndTime
, Security Hub\n returns finding history from the CreatedAt timestamp of the finding to the time at which\n the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is \n limited to 90 days.
\n An ISO 8601-formatted timestamp that indicates the end time of the requested finding history.
\nIf you provide values for both StartTime
and EndTime
,\n Security Hub returns finding history for the specified time period. If you\n provide a value for StartTime
but not for EndTime
, Security Hub returns finding history from the StartTime
to the time at\n which the API is called. If you provide a value for EndTime
but not for\n StartTime
, Security Hub returns finding history from the CreatedAt timestamp of the finding to the EndTime
. If you\n provide neither StartTime
nor EndTime
, Security Hub\n returns finding history from the CreatedAt timestamp of the finding to the time at which\n the API is called. In all of these scenarios, the response is limited to 100 results, and the maximum time period is \n limited to 90 days.
This field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
One or more attributes used to filter the findings included in the insight. The insight\n only includes findings that match the criteria defined in the filters.
", + "smithy.api#documentation": "One or more attributes used to filter the findings included in the insight. You can filter by up to ten finding attributes. For each attribute, you can provide up to 20 filter values. \n The insight only includes findings that match the criteria defined in the filters.
", "smithy.api#required": {} } }, @@ -29219,7 +29219,7 @@ "target": "com.amazonaws.securityhub#NonEmptyString", "traits": { "smithy.api#clientOptional": {}, - "smithy.api#documentation": "The timestamp of when the note was updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
A timestamp that indicates when the note was updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the operation started.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the operation started.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the operation completed.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the operation completed.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the process was launched.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the process was launched.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the process was terminated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the process was terminated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Security Hub provides you with a comprehensive view of the security state of\n your Amazon Web Services environment and resources. It also provides you with the readiness\n status of your environment based on controls from supported security standards. Security Hub collects security data from Amazon Web Services accounts, services, and\n integrated third-party products and helps you analyze security trends in your environment\n to identify the highest priority security issues. For more information about Security Hub, see the \n Security Hub User \nGuide\n .
\nWhen you use operations in the Security Hub API, the requests are executed only in\n the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change\n that results from the operation is applied only to that Region. To make the same change in\n other Regions, run the same command for each Region in which you want to apply the change.
\nFor example, if your Region is set to us-west-2
, when you use CreateMembers
to add a member account to Security Hub, the association of\n the member account with the administrator account is created only in the us-west-2
\n Region. Security Hub must be enabled for the member account in the same Region that the invitation\n was sent from.
The following throttling limits apply to using Security Hub API operations.
\n\n BatchEnableStandards
- RateLimit
of 1 request per\n second. BurstLimit
of 1 request per second.
\n GetFindings
- RateLimit
of 3 requests per second.\n BurstLimit
of 6 requests per second.
\n BatchImportFindings
- RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
\n BatchUpdateFindings
- RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
\n UpdateStandardsControl
- RateLimit
of 1 request per\n second. BurstLimit
of 5 requests per second.
All other operations - RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
Security Hub provides you with a comprehensive view of your security state in Amazon Web Services and helps \n you assess your Amazon Web Services environment against security industry standards and best practices.
\nSecurity Hub collects security data across Amazon Web Services accounts, Amazon Web Services, and \n supported third-party products and helps you analyze your security trends and identify the highest priority security \n issues.
\nTo help you manage the security state of your organization, Security Hub supports multiple security standards. \n These include the Amazon Web Services Foundational Security Best Practices (FSBP) standard developed by Amazon Web Services, \n and external compliance frameworks such as the Center for Internet Security (CIS), the Payment Card Industry Data \n Security Standard (PCI DSS), and the National Institute of Standards and Technology (NIST). Each standard includes \n several security controls, each of which represents a security best practice. Security Hub runs checks against \n security controls and generates control findings to help you assess your compliance against security best practices.
\nIn addition to generating control findings, Security Hub also receives findings from other Amazon Web Services, \n such as Amazon GuardDuty and Amazon Inspector, and \n supported third-party products. This gives you a single pane of glass into a variety of security-related issues. You \n can also send Security Hub findings to other Amazon Web Services and supported third-party products.
\nSecurity Hub offers automation features that help you triage and remediate security issues. For example, \n you can use automation rules to automatically update critical findings when a security check fails. You can also leverage the integration with \n Amazon EventBridge to trigger automatic responses to specific findings.
\nThis guide, the Security Hub API Reference, provides\n information about the Security Hub API. This includes supported resources, HTTP methods, parameters,\n and schemas. If you're new to Security Hub, you might find it helpful to also review the \n Security Hub User Guide\n . The\n user guide explains key concepts and provides procedures\n that demonstrate how to use Security Hub features. It also provides information about topics such as\n integrating Security Hub with other Amazon Web Services.
\nIn addition to interacting with Security Hub by making calls to the Security Hub API, you can\n use a current version of an Amazon Web Services command line tool or SDK. Amazon Web Services provides tools \n and SDKs that consist of libraries and sample code for various languages and platforms, such as PowerShell,\n Java, Go, Python, C++, and .NET. These tools and SDKs provide convenient, programmatic access to\n Security Hub and other Amazon Web Services . They also handle tasks such as signing requests, \n managing errors, and retrying requests automatically. For information about installing and using the Amazon Web Services tools\n and SDKs, see Tools to Build on Amazon Web Services.
\nWith the exception of operations that are related to central configuration, Security Hub API requests are executed only in\n the Amazon Web Services Region that is currently active or in the specific Amazon Web Services Region that you specify in your request. Any configuration or settings change\n that results from the operation is applied only to that Region. To make the same change in\n other Regions, call the same API operation in each Region in which you want to apply the change. When you use central configuration, \nAPI requests for enabling Security Hub, standards, and controls are executed in the home Region and all linked Regions. For a list of \ncentral configuration operations, see the Central configuration \nterms and concepts section of the Security Hub User Guide.
\nThe following throttling limits apply to Security Hub API operations.
\n\n BatchEnableStandards
- RateLimit
of 1 request per\n second. BurstLimit
of 1 request per second.
\n GetFindings
- RateLimit
of 3 requests per second.\n BurstLimit
of 6 requests per second.
\n BatchImportFindings
- RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
\n BatchUpdateFindings
- RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
\n UpdateStandardsControl
- RateLimit
of 1 request per\n second. BurstLimit
of 5 requests per second.
All other operations - RateLimit
of 10 requests per second.\n BurstLimit
of 30 requests per second.
Indicates when the most recent instance of a threat intelligence indicator was\n observed.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the most recent instance of a threat intelligence indicator was\n observed.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the vulnerability advisory was created.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the vulnerability advisory was created.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)
Indicates when the vulnerability advisory was last updated.
\nUses the date-time
format specified in RFC 3339 section 5.6, Internet\n Date/Time Format. The value cannot contain spaces, and date and time should be separated by T
. For example,\n 2020-03-22T13:22:13.933Z
.
Indicates when the vulnerability advisory was last updated.
\nThis field accepts only the specified formats. Timestamps \ncan end with Z
or (\"+\" / \"-\") time-hour [\":\" time-minute]
. The time-secfrac after seconds is limited \nto a maximum of 9 digits. The offset is bounded by +/-18:00. Here are valid timestamp formats with examples:
\n YYYY-MM-DDTHH:MM:SSZ
(for example, 2019-01-31T23:00:00Z
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmmZ
(for example, 2019-01-31T23:00:00.123456789Z
)
\n YYYY-MM-DDTHH:MM:SS+HH:MM
(for example, 2024-01-04T15:25:10+17:59
)
\n YYYY-MM-DDTHH:MM:SS-HHMM
(for example, 2024-01-04T15:25:10-1759
)
\n YYYY-MM-DDTHH:MM:SS.mmmmmmmmm+HH:MM
(for example, 2024-01-04T15:25:10.123456789+17:59
)