Module types

Data structures used by operation inputs/outputs.

Modules

builders

Builders

error

Error types that AWS Network Firewall can respond with.

Structs

ActionDefinition

A custom action to use in stateless rule actions settings. This is used in CustomAction.

Address

A single IP address specification. This is used in the MatchAttributes source and destination specifications.

AnalysisReport

A report that captures key activity from the last 30 days of network traffic monitored by your firewall.

You can generate up to one report per traffic type, per 30 day period. For example, when you successfully create an HTTP traffic report, you cannot create another HTTP traffic report until 30 days pass. Alternatively, if you generate a report that combines metrics on both HTTP and HTTPS traffic, you cannot create another report for either traffic type until 30 days pass.

AnalysisResult

The analysis result for Network Firewall's stateless rule group analyzer. Every time you call CreateRuleGroup, UpdateRuleGroup, or DescribeRuleGroup on a stateless rule group, Network Firewall analyzes the stateless rule groups in your account and identifies the rules that might adversely effect your firewall's functionality. For example, if Network Firewall detects a rule that's routing traffic asymmetrically, which impacts the service's ability to properly process traffic, the service includes the rule in a list of analysis results.

The AnalysisResult data type is not related to traffic analysis reports you generate using StartAnalysisReport. For information on traffic analysis report results, see AnalysisTypeReportResult.

AnalysisTypeReportResult

The results of a COMPLETED analysis report generated with StartAnalysisReport.

For an example of traffic analysis report results, see the response syntax of GetAnalysisReportResults.

Attachment

The definition and status of the firewall endpoint for a single subnet. In each configured subnet, Network Firewall instantiates a firewall endpoint to handle network traffic.

This data type is used for any firewall endpoint type:

• For Firewall.SubnetMappings, this Attachment is part of the FirewallStatus sync states information. You define firewall subnets using CreateFirewall and AssociateSubnets.

• For VpcEndpointAssociation, this Attachment is part of the VpcEndpointAssociationStatus sync states information. You define these subnets using CreateVpcEndpointAssociation.

AvailabilityZoneMapping

Defines the mapping between an Availability Zone and a firewall endpoint for a transit gateway-attached firewall. Each mapping represents where the firewall can process traffic. You use these mappings when calling CreateFirewall, AssociateAvailabilityZones, and DisassociateAvailabilityZones.

To retrieve the current Availability Zone mappings for a firewall, use DescribeFirewall.

AvailabilityZoneMetadata

High-level information about an Availability Zone where the firewall has an endpoint defined.

AzSyncState

The status of the firewall endpoint defined by a VpcEndpointAssociation.

CapacityUsageSummary

The capacity usage summary of the resources used by the ReferenceSets in a firewall.

CheckCertificateRevocationStatusActions

Defines the actions to take on the SSL/TLS connection if the certificate presented by the server in the connection has a revoked or unknown status.

CidrSummary

Summarizes the CIDR blocks used by the IP set references in a firewall. Network Firewall calculates the number of CIDRs by taking an aggregated count of all CIDRs used by the IP sets you are referencing.

CustomAction

An optional, non-standard action to use for stateless packet handling. You can define this in addition to the standard action that you must specify.

You define and name the custom actions that you want to be able to use, and then you reference them by name in your actions settings.

You can use custom actions in the following places:

• In a rule group's StatelessRulesAndCustomActions specification. The custom actions are available for use by name inside the StatelessRulesAndCustomActions where you define them. You can use them for your stateless rule actions to specify what to do with a packet that matches the rule's match attributes.

• In a FirewallPolicy specification, in StatelessCustomActions. The custom actions are available for use inside the policy where you define them. You can use them for the policy's default stateless actions settings to specify what to do with packets that don't match any of the policy's stateless rules.

Dimension

The value to use in an Amazon CloudWatch custom metric dimension. This is used in the PublishMetrics CustomAction. A CloudWatch custom metric dimension is a name/value pair that's part of the identity of a metric.

Network Firewall sets the dimension name to CustomAction and you provide the dimension value.

For more information about CloudWatch custom metric dimensions, see Publishing Custom Metrics in the Amazon CloudWatch User Guide.

EncryptionConfiguration

A complex type that contains optional Amazon Web Services Key Management Service (KMS) encryption settings for your Network Firewall resources. Your data is encrypted by default with an Amazon Web Services owned key that Amazon Web Services owns and manages for you. You can use either the Amazon Web Services owned key, or provide your own customer managed key. To learn more about KMS encryption of your Network Firewall resources, see Encryption at rest with Amazon Web Services Key Managment Service in the Network Firewall Developer Guide.

Firewall

A firewall defines the behavior of a firewall, the main VPC where the firewall is used, the Availability Zones where the firewall can be used, and one subnet to use for a firewall endpoint within each of the Availability Zones. The Availability Zones are defined implicitly in the subnet specifications.

In addition to the firewall endpoints that you define in this Firewall specification, you can create firewall endpoints in VpcEndpointAssociation resources for any VPC, in any Availability Zone where the firewall is already in use.

The status of the firewall, for example whether it's ready to filter network traffic, is provided in the corresponding FirewallStatus. You can retrieve both the firewall and firewall status by calling DescribeFirewall.

FirewallMetadata

High-level information about a firewall, returned by operations like create and describe. You can use the information provided in the metadata to retrieve and manage a firewall.

FirewallPolicy

The firewall policy defines the behavior of a firewall using a collection of stateless and stateful rule groups and other settings. You can use one firewall policy for multiple firewalls.

This, along with FirewallPolicyResponse, define the policy. You can retrieve all objects for a firewall policy by calling DescribeFirewallPolicy.

FirewallPolicyMetadata

High-level information about a firewall policy, returned by operations like create and describe. You can use the information provided in the metadata to retrieve and manage a firewall policy. You can retrieve all objects for a firewall policy by calling DescribeFirewallPolicy.

FirewallPolicyResponse

The high-level properties of a firewall policy. This, along with the FirewallPolicy, define the policy. You can retrieve all objects for a firewall policy by calling DescribeFirewallPolicy.

FirewallStatus

Detailed information about the current status of a Firewall. You can retrieve this for a firewall by calling DescribeFirewall and providing the firewall name and ARN.

The firewall status indicates a combined status. It indicates whether all subnets are up-to-date with the latest firewall configurations, which is based on the sync states config values, and also whether all subnets have their endpoints fully enabled, based on their sync states attachment values.

Flow

Any number of arrays, where each array is a single flow identified in the scope of the operation. If multiple flows were in the scope of the operation, multiple Flows arrays are returned.

FlowFilter

Defines the scope a flow operation. You can use up to 20 filters to configure a single flow operation.

FlowOperation

Contains information about a flow operation, such as related statuses, unique identifiers, and all filters defined in the operation.

Flow operations let you manage the flows tracked in the flow table, also known as the firewall table.

A flow is network traffic that is monitored by a firewall, either by stateful or stateless rules. For traffic to be considered part of a flow, it must share Destination, DestinationPort, Direction, Protocol, Source, and SourcePort.

FlowOperationMetadata

An array of objects with metadata about the requested FlowOperation.

FlowTimeouts

Describes the amount of time that can pass without any traffic sent through the firewall before the firewall determines that the connection is idle and Network Firewall removes the flow entry from its flow table. Existing connections and flows are not impacted when you update this value. Only new connections after you update this value are impacted.

Header

The basic rule criteria for Network Firewall to use to inspect packet headers in stateful traffic flow inspection. Traffic flows that match the criteria are a match for the corresponding StatefulRule.

Hits

Attempts made to a access domain.

IpSet

A list of IP addresses and address ranges, in CIDR notation. This is part of a RuleVariables.

IpSetMetadata

General information about the IP set.

IpSetReference

Configures one or more IP set references for a Suricata-compatible rule group. This is used in CreateRuleGroup or UpdateRuleGroup. An IP set reference is a rule variable that references resources that you create and manage in another Amazon Web Services service, such as an Amazon VPC prefix list. Network Firewall IP set references enable you to dynamically update the contents of your rules. When you create, update, or delete the resource you are referencing in your rule, Network Firewall automatically updates the rule's content with the changes. For more information about IP set references in Network Firewall, see Using IP set references in the Network Firewall Developer Guide.

Network Firewall currently supports Amazon VPC prefix lists and resource groups in IP set references.

LogDestinationConfig

Defines where Network Firewall sends logs for the firewall for one log type. This is used in LoggingConfiguration. You can send each type of log to an Amazon S3 bucket, a CloudWatch log group, or a Firehose delivery stream.

Network Firewall generates logs for stateful rule groups. You can save alert, flow, and TLS log types.

LoggingConfiguration

Defines how Network Firewall performs logging for a Firewall.

MatchAttributes

Criteria for Network Firewall to use to inspect an individual packet in stateless rule inspection. Each match attributes set can include one or more items such as IP address, CIDR range, port number, protocol, and TCP flags.

PerObjectStatus

Provides configuration status for a single policy or rule group that is used for a firewall endpoint. Network Firewall provides each endpoint with the rules that are configured in the firewall policy. Each time you add a subnet or modify the associated firewall policy, Network Firewall synchronizes the rules in the endpoint, so it can properly filter network traffic. This is part of a SyncState for a firewall.

PolicyVariables

Contains variables that you can use to override default Suricata settings in your firewall policy.

PortRange

A single port range specification. This is used for source and destination port ranges in the stateless rule MatchAttributes, SourcePorts, and DestinationPorts settings.

PortSet

A set of port ranges for use in the rules in a rule group.

PublishMetricAction

Stateless inspection criteria that publishes the specified metrics to Amazon CloudWatch for the matching packet. This setting defines a CloudWatch dimension value to be published.

ReferenceSets

Contains a set of IP set references.

RuleDefinition

The inspection criteria and action for a single stateless rule. Network Firewall inspects each packet for the specified matching criteria. When a packet matches the criteria, Network Firewall performs the rule's actions on the packet.

RuleGroup

The object that defines the rules in a rule group. This, along with RuleGroupResponse, define the rule group. You can retrieve all objects for a rule group by calling DescribeRuleGroup.

Network Firewall uses a rule group to inspect and control network traffic. You define stateless rule groups to inspect individual packets and you define stateful rule groups to inspect packets in the context of their traffic flow.

To use a rule group, you include it by reference in an Network Firewall firewall policy, then you use the policy in a firewall. You can reference a rule group from more than one firewall policy, and you can use a firewall policy in more than one firewall.

RuleGroupMetadata

High-level information about a rule group, returned by ListRuleGroups. You can use the information provided in the metadata to retrieve and manage a rule group.

RuleGroupResponse

The high-level properties of a rule group. This, along with the RuleGroup, define the rule group. You can retrieve all objects for a rule group by calling DescribeRuleGroup.

RuleOption

Additional settings for a stateful rule. This is part of the StatefulRule configuration.

RuleSummary

A complex type containing details about a Suricata rule. Contains:

• SID

• Msg

• Metadata

Summaries are available for rule groups you manage and for active threat defense Amazon Web Services managed rule groups.

RuleVariables

Settings that are available for use in the rules in the RuleGroup where this is defined. See CreateRuleGroup or UpdateRuleGroup for usage.

RulesSource

The stateless or stateful rules definitions for use in a single rule group. Each rule group requires a single RulesSource. You can use an instance of this for either stateless rules or stateful rules.

RulesSourceList

Stateful inspection criteria for a domain list rule group.

For HTTPS traffic, domain filtering is SNI-based. It uses the server name indicator extension of the TLS handshake.

By default, Network Firewall domain list inspection only includes traffic coming from the VPC where you deploy the firewall. To inspect traffic from IP addresses outside of the deployment VPC, you set the HOME_NET rule variable to include the CIDR range of the deployment VPC plus the other CIDR ranges. For more information, see RuleVariables in this guide and Stateful domain list rule groups in Network Firewall in the Network Firewall Developer Guide.

ServerCertificate

Any Certificate Manager (ACM) Secure Sockets Layer/Transport Layer Security (SSL/TLS) server certificate that's associated with a ServerCertificateConfiguration. Used in a TLSInspectionConfiguration for inspection of inbound traffic to your firewall. You must request or import a SSL/TLS certificate into ACM for each domain Network Firewall needs to decrypt and inspect. Network Firewall uses the SSL/TLS certificates to decrypt specified inbound SSL/TLS traffic going to your firewall. For information about working with certificates in Certificate Manager, see Request a public certificate or Importing certificates in the Certificate Manager User Guide.

ServerCertificateConfiguration

Configures the Certificate Manager certificates and scope that Network Firewall uses to decrypt and re-encrypt traffic using a TLSInspectionConfiguration. You can configure ServerCertificates for inbound SSL/TLS inspection, a CertificateAuthorityArn for outbound SSL/TLS inspection, or both. For information about working with certificates for TLS inspection, see Using SSL/TLS server certficiates with TLS inspection configurations in the Network Firewall Developer Guide.

If a server certificate that's associated with your TLSInspectionConfiguration is revoked, deleted, or expired it can result in client-side TLS errors.

ServerCertificateScope

Settings that define the Secure Sockets Layer/Transport Layer Security (SSL/TLS) traffic that Network Firewall should decrypt for inspection by the stateful rule engine.

SourceMetadata

High-level information about the managed rule group that your own rule group is copied from. You can use the the metadata to track version updates made to the originating rule group. You can retrieve all objects for a rule group by calling DescribeRuleGroup.

StatefulEngineOptions

Configuration settings for the handling of the stateful rule groups in a firewall policy.

StatefulRule

A single Suricata rules specification, for use in a stateful rule group. Use this option to specify a simple Suricata rule with protocol, source and destination, ports, direction, and rule options. For information about the Suricata Rules format, see Rules Format.

StatefulRuleGroupOverride

The setting that allows the policy owner to change the behavior of the rule group within a policy.

StatefulRuleGroupReference

Identifier for a single stateful rule group, used in a firewall policy to refer to a rule group.

StatefulRuleOptions

Additional options governing how Network Firewall handles the rule group. You can only use these for stateful rule groups.

StatelessRule

A single stateless rule. This is used in StatelessRulesAndCustomActions.

StatelessRuleGroupReference

Identifier for a single stateless rule group, used in a firewall policy to refer to the rule group.

StatelessRulesAndCustomActions

Stateless inspection criteria. Each stateless rule group uses exactly one of these data types to define its stateless rules.

SubnetMapping

The ID for a subnet that's used in an association with a firewall. This is used in CreateFirewall, AssociateSubnets, and CreateVpcEndpointAssociation. Network Firewall creates an instance of the associated firewall in each subnet that you specify, to filter traffic in the subnet's Availability Zone.

Summary

A complex type containing summaries of security protections provided by a rule group.

Network Firewall extracts this information from selected fields in the rule group's Suricata rules, based on your SummaryConfiguration settings.

SummaryConfiguration

A complex type that specifies which Suricata rule metadata fields to use when displaying threat information. Contains:

• RuleOptions - The Suricata rule options fields to extract and display

These settings affect how threat information appears in both the console and API responses. Summaries are available for rule groups you manage and for active threat defense Amazon Web Services managed rule groups.

SyncState

The status of the firewall endpoint and firewall policy configuration for a single VPC subnet. This is part of the FirewallStatus.

For each VPC subnet that you associate with a firewall, Network Firewall does the following:

• Instantiates a firewall endpoint in the subnet, ready to take traffic.

• Configures the endpoint with the current firewall policy settings, to provide the filtering behavior for the endpoint.

When you update a firewall, for example to add a subnet association or change a rule group in the firewall policy, the affected sync states reflect out-of-sync or not ready status until the changes are complete.

Tag

A key:value pair associated with an Amazon Web Services resource. The key:value pair can be anything you define. Typically, the tag key represents a category (such as "environment") and the tag value represents a specific value within that category (such as "test," "development," or "production"). You can add up to 50 tags to each Amazon Web Services resource.

TcpFlagField

TCP flags and masks to inspect packets for, used in stateless rules MatchAttributes settings.

TlsCertificateData

Contains metadata about an Certificate Manager certificate.

TlsInspectionConfiguration

The object that defines a TLS inspection configuration. This, along with TLSInspectionConfigurationResponse, define the TLS inspection configuration. You can retrieve all objects for a TLS inspection configuration by calling DescribeTLSInspectionConfiguration.

Network Firewall uses a TLS inspection configuration to decrypt traffic. Network Firewall re-encrypts the traffic before sending it to its destination.

To use a TLS inspection configuration, you add it to a new Network Firewall firewall policy, then you apply the firewall policy to a firewall. Network Firewall acts as a proxy service to decrypt and inspect the traffic traveling through your firewalls. You can reference a TLS inspection configuration from more than one firewall policy, and you can use a firewall policy in more than one firewall. For more information about using TLS inspection configurations, see Inspecting SSL/TLS traffic with TLS inspection configurations in the Network Firewall Developer Guide.

TlsInspectionConfigurationMetadata

High-level information about a TLS inspection configuration, returned by ListTLSInspectionConfigurations. You can use the information provided in the metadata to retrieve and manage a TLS configuration.

TlsInspectionConfigurationResponse

The high-level properties of a TLS inspection configuration. This, along with the TLSInspectionConfiguration, define the TLS inspection configuration. You can retrieve all objects for a TLS inspection configuration by calling DescribeTLSInspectionConfiguration.

TransitGatewayAttachmentSyncState

Contains information about the synchronization state of a transit gateway attachment, including its current status and any error messages. Network Firewall uses this to track the state of your transit gateway configuration changes.

UniqueSources

A unique source IP address that connected to a domain.

VpcEndpointAssociation

A VPC endpoint association defines a single subnet to use for a firewall endpoint for a Firewall. You can define VPC endpoint associations only in the Availability Zones that already have a subnet mapping defined in the Firewall resource.

You can retrieve the list of Availability Zones that are available for use by calling DescribeFirewallMetadata.

To manage firewall endpoints, first, in the Firewall specification, you specify a single VPC and one subnet for each of the Availability Zones where you want to use the firewall. Then you can define additional endpoints as VPC endpoint associations.

You can use VPC endpoint associations to expand the protections of the firewall as follows:

• Protect multiple VPCs with a single firewall - You can use the firewall to protect other VPCs, either in your account or in accounts where the firewall is shared. You can only specify Availability Zones that already have a firewall endpoint defined in the Firewall subnet mappings.

• Define multiple firewall endpoints for a VPC in an Availability Zone - You can create additional firewall endpoints for the VPC that you have defined in the firewall, in any Availability Zone that already has an endpoint defined in the Firewall subnet mappings. You can create multiple VPC endpoint associations for any other VPC where you use the firewall.

You can use Resource Access Manager to share a Firewall that you own with other accounts, which gives them the ability to use the firewall to create VPC endpoint associations. For information about sharing a firewall, see PutResourcePolicy in this guide and see Sharing Network Firewall resources in the Network Firewall Developer Guide.

The status of the VPC endpoint association, which indicates whether it's ready to filter network traffic, is provided in the corresponding VpcEndpointAssociationStatus. You can retrieve both the association and its status by calling DescribeVpcEndpointAssociation.

VpcEndpointAssociationMetadata

High-level information about a VPC endpoint association, returned by ListVpcEndpointAssociations. You can use the information provided in the metadata to retrieve and manage a VPC endpoint association.

VpcEndpointAssociationStatus

Detailed information about the current status of a VpcEndpointAssociation. You can retrieve this by calling DescribeVpcEndpointAssociation and providing the VPC endpoint association ARN.

Enums

AttachmentStatus

When writing a match expression against AttachmentStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ConfigurationSyncState

When writing a match expression against ConfigurationSyncState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

EnabledAnalysisType

When writing a match expression against EnabledAnalysisType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

EncryptionType

When writing a match expression against EncryptionType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

FirewallStatusValue

When writing a match expression against FirewallStatusValue, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

FlowOperationStatus

When writing a match expression against FlowOperationStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

FlowOperationType

When writing a match expression against FlowOperationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

GeneratedRulesType

When writing a match expression against GeneratedRulesType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

IdentifiedType

When writing a match expression against IdentifiedType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

IpAddressType

When writing a match expression against IpAddressType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

LogDestinationType

When writing a match expression against LogDestinationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

LogType

When writing a match expression against LogType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

OverrideAction

When writing a match expression against OverrideAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

PerObjectSyncStatus

When writing a match expression against PerObjectSyncStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ResourceManagedStatus

When writing a match expression against ResourceManagedStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ResourceManagedType

When writing a match expression against ResourceManagedType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ResourceStatus

When writing a match expression against ResourceStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

RevocationCheckAction

When writing a match expression against RevocationCheckAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

RuleGroupType

When writing a match expression against RuleGroupType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

RuleOrder

When writing a match expression against RuleOrder, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

StatefulAction

When writing a match expression against StatefulAction, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

StatefulRuleDirection

When writing a match expression against StatefulRuleDirection, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

StatefulRuleProtocol

When writing a match expression against StatefulRuleProtocol, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

StreamExceptionPolicy

When writing a match expression against StreamExceptionPolicy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

SummaryRuleOption

When writing a match expression against SummaryRuleOption, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

TargetType

When writing a match expression against TargetType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

TcpFlag

When writing a match expression against TcpFlag, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

TransitGatewayAttachmentStatus

When writing a match expression against TransitGatewayAttachmentStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.