Module types

Source

Expand description

Data structures used by operation inputs/outputs.

Modules§

builders: Builders
error: Error types that Amazon GameLift can respond with.

Structs§

Alias

Properties that describe an alias resource.

Related actions

All APIs by task

AnywhereConfiguration

Amazon GameLift Servers configuration options for your Anywhere fleets.

AttributeValue

Values for use in player attribute key-value pairs. This object lets you specify an attribute value using any of the valid data types: string, number, string array, or data map. Each AttributeValue object can use only one of the available properties.

AwsCredentials

Amazon Web Services account security credentials that allow interactions with Amazon GameLift Servers resources. The credentials are temporary and valid for a limited time span. You can request fresh credentials at any time.

Amazon Web Services security credentials consist of three parts: an access key ID, a secret access key, and a session token. You must use all three parts together to authenticate your access requests.

You need Amazon Web Services credentials for the following tasks:

To upload a game server build directly to Amazon GameLift Servers S3 storage using CreateBuild. To get access for this task, call https://docs.aws.amazon.com/gamelift/latest/apireference/API_RequestUploadCredentials.html.
To remotely connect to an active Amazon GameLift Servers fleet instances. To get remote access, call https://docs.aws.amazon.com/gamelift/latest/apireference/API_GetComputeAccess.html.

Build

Properties describing a custom game build.

All APIs by task

CertificateConfiguration

Determines whether a TLS/SSL certificate is generated for a fleet. This feature must be enabled when creating the fleet. All instances in a fleet share the same certificate. The certificate can be retrieved by calling the Amazon GameLift Servers Server SDK operation GetInstanceCertificate.

ClaimFilterOption

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Filters which game servers may be claimed when calling ClaimGameServer.

Compute

An Amazon GameLift Servers compute resource for hosting your game servers. Computes in an Amazon GameLift Servers fleet differs depending on the fleet's compute type property as follows:

For managed EC2 fleets, a compute is an EC2 instance.
For Anywhere fleets, a compute is a computing resource that you provide and is registered to the fleet.

ConnectionPortRange

The set of port numbers to open on each instance in a container fleet. Connection ports are used by inbound traffic to connect with processes that are running in containers on the fleet.

ContainerAttribute

A unique identifier for a container in a container fleet compute.

Returned by: DescribeCompute

ContainerDependency

A container's dependency on another container in the same container group. The dependency impacts how the dependent container is able to start or shut down based the status of the other container.

For example, ContainerA is configured with the following dependency: a START dependency on ContainerB. This means that ContainerA can't start until ContainerB has started. It also means that ContainerA must shut down before ContainerB.

Part of: GameServerContainerDefinition, GameServerContainerDefinitionInput, SupportContainerDefinition, SupportContainerDefinitionInput

ContainerEnvironment

An environment variable to set inside a container, in the form of a key-value pair.

Part of: GameServerContainerDefinition, GameServerContainerDefinitionInput, SupportContainerDefinition, SupportContainerDefinitionInput

ContainerFleet

Describes an Amazon GameLift Servers managed container fleet.

ContainerFleetLocationAttributes

Details about a location in a multi-location container fleet.

ContainerGroupDefinition

The properties that describe a container group resource. You can update all properties of a container group definition properties. Updates to a container group definition are saved as new versions.

Used with: CreateContainerGroupDefinition

Returned by: DescribeContainerGroupDefinition, ListContainerGroupDefinitions, UpdateContainerGroupDefinition

ContainerHealthCheck

Instructions on when and how to check the health of a support container in a container fleet. These properties override any Docker health checks that are set in the container image. For more information on container health checks, see HealthCheck command in the Amazon Elastic Container Service API. Game server containers don't have a health check parameter; Amazon GameLift Servers automatically handles health checks for these containers.

The following example instructs the container to initiate a health check command every 60 seconds and wait 10 seconds for it to succeed. If it fails, retry the command 3 times before flagging the container as unhealthy. It also tells the container to wait 100 seconds after launch before counting failed health checks.

{"Command": \[ "CMD-SHELL", "ps cax | grep "processmanager" || exit 1" \], "Interval": 60, "Timeout": 10, "Retries": 3, "StartPeriod": 100 }

Part of: SupportContainerDefinition, SupportContainerDefinitionInput

ContainerIdentifier

A unique identifier for a container in a compute on a managed container fleet instance. This information makes it possible to remotely connect to a specific container on a fleet instance.

Related to: ContainerAttribute

Use with: GetComputeAccess

ContainerMountPoint

A mount point that binds a container to a file or directory on the host system.

Part of: GameServerContainerDefinition, https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameServerContainerDefinitionInput.html, SupportContainerDefinition, https://docs.aws.amazon.com/gamelift/latest/apireference/API_SupportContainerDefinitionInput.html

ContainerPortConfiguration

A set of port ranges that can be opened on the container. A process that's running in the container can bind to a port number, making it accessible to inbound traffic when it's mapped to a container fleet's connection port.

Each container port range specifies a network protocol. When the configuration supports more than one protocol, we recommend that you use a different range for each protocol. If your ranges have overlapping port numbers, Amazon GameLift Servers maps a duplicated container port number to different connection ports. For example, if you include 1935 in port ranges for both TCP and UDP, it might result in the following mappings:

container port 1935 (tcp) => connection port 2001
container port 1935 (udp) => connection port 2002

Part of: GameServerContainerDefinition, GameServerContainerDefinitionInput, SupportContainerDefinition, SupportContainerDefinitionInput

ContainerPortRange

A set of one or more port numbers that can be opened on the container, and the supported network protocol.

Part of: ContainerPortConfiguration

DeploymentConfiguration

Set of rules for processing a deployment for a container fleet update.

DeploymentDetails

Information about the most recent deployment for the container fleet.

DesiredPlayerSession

Player information for use when creating player sessions using a game session placement request.

Ec2InstanceCounts

Resource capacity settings. Fleet capacity is measured in Amazon EC2 instances. Pending and terminating counts are non-zero when the fleet capacity is adjusting to a scaling event or if access to resources is temporarily affected.

Ec2InstanceLimit

The Amazon GameLift Servers service limits for an Amazon EC2 instance type and current utilization. Amazon GameLift Servers allows Amazon Web Services accounts a maximum number of instances, per instance type, per Amazon Web Services Region or location, for use with Amazon GameLift Servers. You can request an limit increase for your account by using the Service limits page in the Amazon GameLift Servers console.

Event

Log entry describing an event that involves Amazon GameLift Servers resources (such as a fleet). In addition to tracking activity, event codes and messages can provide additional information for troubleshooting and debugging problems.

FilterConfiguration

A list of fleet locations where a game session queue can place new game sessions. You can use a filter to temporarily exclude specific locations from receiving placements. For queues that have multi-location fleets, you can use a filter configuration allow placement with some, but not all, of a fleet's locations.

FleetAttributes

Describes an Amazon GameLift Servers fleet of game hosting resources. Attributes differ based on the fleet's compute type, as follows:

EC2 fleet attributes identify a Build resource (for fleets with customer game server builds) or a Script resource (for Amazon GameLift Servers Realtime fleets).
Amazon GameLift Servers Anywhere fleets have an abbreviated set of attributes, because most fleet configurations are set directly on the fleet's computes. Attributes include fleet identifiers and descriptive properties, creation/termination time, and fleet status.

Returned by: https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetAttributes

FleetCapacity

Current resource capacity settings for managed EC2 fleets and managed container fleets. For multi-location fleets, location values might refer to a fleet's remote location or its home Region.

Returned by: DescribeFleetCapacity, DescribeFleetLocationCapacity, UpdateFleetCapacity

FleetDeployment

Describes a container fleet deployment with updates to the fleet.

FleetUtilization

Current resource utilization statistics in a specified fleet or location. The location value might refer to a fleet's remote location or its home region.

GameProperty

This key-value pair can store custom data about a game session. For example, you might use a GameProperty to track a game session's map, level of difficulty, or remaining time. The difficulty level could be specified like this: {"Key": "difficulty", "Value":"Novice"}.

You can set game properties when creating a game session. You can also modify game properties of an active game session. When searching for game sessions, you can filter on game property keys and values. You can't delete game properties from a game session.

For examples of working with game properties, see Create a game session with properties.

GameServer

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Properties describing a game server that is running on an instance in a game server group.

A game server is created by a successful call to RegisterGameServer and deleted by calling DeregisterGameServer. A game server is claimed to host a game session by calling ClaimGameServer.

GameServerContainerDefinition

Describes the game server container in an existing game server container group. A game server container identifies a container image with your game server build. A game server container is automatically considered essential; if an essential container fails, the entire container group restarts.

You can update a container definition and deploy the updates to an existing fleet. When creating or updating a game server container group definition, use the property https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameServerContainerDefinitionInput.

Part of: ContainerGroupDefinition

Returned by: DescribeContainerGroupDefinition, ListContainerGroupDefinitions, UpdateContainerGroupDefinition

GameServerContainerDefinitionInput

Describes the configuration for a container that runs your game server executable. This definition includes container configuration, resources, and start instructions. Use this data type when creating or updating a game server container group definition. For properties of a deployed container, see GameServerContainerDefinition. A game server container is automatically considered essential; if an essential container fails, the entire container group restarts.

Use with: CreateContainerGroupDefinition, UpdateContainerGroupDefinition

GameServerContainerGroupCounts

The number and status of game server container groups that are deployed across a container fleet. Combine this count with the number of server processes that each game server container group runs to learn how many game sessions the fleet is capable of hosting concurrently. For example, if a fleet has 50 game server container groups, and the game server container in each group runs 1 game server process, then the fleet has the capacity to run host 50 game sessions at a time.

Returned by: https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetCapacity.html, https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetLocationCapacity.html

GameServerGroup

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Properties that describe a game server group resource. A game server group manages certain properties related to a corresponding Amazon EC2 Auto Scaling group.

A game server group is created by a successful call to CreateGameServerGroup and deleted by calling DeleteGameServerGroup. Game server group activity can be temporarily suspended and resumed by calling SuspendGameServerGroup and ResumeGameServerGroup, respectively.

GameServerGroupAutoScalingPolicy

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Configuration settings for intelligent automatic scaling that uses target tracking. These settings are used to add an Auto Scaling policy when creating the corresponding Auto Scaling group. After the Auto Scaling group is created, all updates to Auto Scaling policies, including changing this policy and adding or removing other policies, is done directly on the Auto Scaling group.

GameServerInstance

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Additional properties, including status, that describe an EC2 instance in a game server group. Instance configurations are set with game server group properties (see DescribeGameServerGroup and with the EC2 launch template that was used when creating the game server group.

Retrieve game server instances for a game server group by calling DescribeGameServerInstances.

GameSession

Properties describing a game session.

A game session in ACTIVE status can host players. When a game session ends, its status is set to TERMINATED.

Amazon GameLift Servers retains a game session resource for 30 days after the game session ends. You can reuse idempotency token values after this time. Game session logs are retained for 14 days.

All APIs by task

GameSessionConnectionInfo

Connection information for a new game session that is created in response to a start matchmaking request. Once a match is made, the FlexMatch engine creates a new game session for it. This information, including the game session endpoint and player sessions for each player in the original matchmaking request, is added to the matchmaking ticket.

GameSessionCreationLimitPolicy

A policy that puts limits on the number of game sessions that a player can create within a specified span of time. With this policy, you can control players' ability to consume available resources.

The policy is evaluated when a player tries to create a new game session. On receiving a CreateGameSession request, Amazon GameLift Servers checks that the player (identified by CreatorId) has created fewer than game session limit in the specified time period.

GameSessionDetail

A game session's properties plus the protection policy currently in force.

GameSessionPlacement

Represents a potential game session placement, including the full details of the original placement request and the current status.

If the game session placement status is PENDING, the properties for game session ID/ARN, region, IP address/DNS, and port aren't final. A game session is not active and ready to accept players until placement status reaches FULFILLED. When the placement is in PENDING status, Amazon GameLift Servers may attempt to place a game session multiple times before succeeding. With each attempt it creates a https://docs.aws.amazon.com/gamelift/latest/apireference/API_GameSession object and updates this placement object with the new game session properties.

GameSessionQueue

Configuration for a game session placement mechanism that processes requests for new game sessions. A queue can be used on its own or as part of a matchmaking solution.

GameSessionQueueDestination

A fleet or alias designated in a game session queue. Queues fulfill requests for new game sessions by placing a new game session on any of the queue's destinations.

Instance

Represents a virtual computing instance that runs game server processes and hosts game sessions. In Amazon GameLift Servers, one or more instances make up a managed EC2 fleet.

InstanceAccess

Information and credentials that you can use to remotely connect to an instance in an EC2 managed fleet. This data type is returned in response to a call to https://docs.aws.amazon.com/gamelift/latest/apireference/API_GetInstanceAccess.

InstanceCredentials

A set of credentials that allow remote access to an instance in an EC2 managed fleet. These credentials are returned in response to a call to https://docs.aws.amazon.com/gamelift/latest/apireference/API_GetInstanceAccess, which requests access for instances that are running game servers with the Amazon GameLift Servers server SDK version 4.x or earlier.

InstanceDefinition

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

An allowed instance type for a game server group. All game server groups must have at least two instance types defined for it. Amazon GameLift Servers FleetIQ periodically evaluates each defined instance type for viability. It then updates the Auto Scaling group with the list of viable instance types.

IpPermission

A range of IP addresses and port settings that allow inbound traffic to connect to processes on an instance in a fleet. Processes are assigned an IP address/port number combination, which must fall into the fleet's allowed ranges.

For Amazon GameLift Servers Realtime fleets, Amazon GameLift Servers automatically opens two port ranges, one for TCP messaging and one for UDP.

LaunchTemplateSpecification

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

An Amazon Elastic Compute Cloud launch template that contains configuration settings and game server code to be deployed to all instances in a game server group. The launch template is specified when creating a new game server group.

LocationAttributes

Details about a location in a multi-location fleet.

LocationConfiguration

A remote location where a multi-location fleet can deploy game servers for game hosting.

LocationModel

Properties of a location, which can include its name, ARN (for custom locations), and ping beacon information.

LocationState

A fleet location and its life-cycle state. A location state object might be used to describe a fleet's remote location or home Region. Life-cycle state tracks the progress of launching the first instance in a new location and preparing it for game hosting, and then removing all instances and deleting the location from the fleet.

NEW -- A new fleet location has been defined and desired instances is set to 1.
DOWNLOADING/VALIDATING/BUILDING/ACTIVATING -- Amazon GameLift Servers is setting up the new fleet location, creating new instances with the game build or Realtime script and starting server processes.
ACTIVE -- Hosts can now accept game sessions.
ERROR -- An error occurred when downloading, validating, building, or activating the fleet location.
DELETING -- Hosts are responding to a delete fleet location request.
TERMINATED -- The fleet location no longer exists.
NOT_FOUND -- The fleet location was not found. This could be because the custom location was removed or not created.

LocationalDeployment

For a multi-location container fleet, describes the progress of a deployment across all fleet locations.

LogConfiguration

A method for collecting container logs for the fleet. Amazon GameLift Servers saves all standard output for each container in logs, including game session logs. You can select from the following methods:

MatchedPlayerSession

Represents a new player session that is created as a result of a successful FlexMatch match. A successful match automatically creates new player sessions for every player ID in the original matchmaking request.

When players connect to the match's game session, they must include both player ID and player session ID in order to claim their assigned player slot.

MatchmakingConfiguration

Guidelines for use with FlexMatch to match players into games. All matchmaking requests must specify a matchmaking configuration.

MatchmakingRuleSet

Set of rule statements, used with FlexMatch, that determine how to build your player matches. Each rule set describes a type of group to be created and defines the parameters for acceptable player matches.

A rule set may define the following elements for a match. For detailed information and examples showing how to construct a rule set, see Build a FlexMatch rule set.

Teams -- Required. A rule set must define one or multiple teams for the match and set minimum and maximum team sizes. For example, a rule set might describe a 4x4 match that requires all eight slots to be filled.
Player attributes -- Optional. These attributes specify a set of player characteristics to evaluate when looking for a match. Matchmaking requests that use a rule set with player attributes must provide the corresponding attribute values. For example, an attribute might specify a player's skill or level.
Rules -- Optional. Rules define how to evaluate potential players for a match based on player attributes. A rule might specify minimum requirements for individual players, teams, or entire matches. For example, a rule might require each player to meet a certain skill level, each team to have at least one player in a certain role, or the match to have a minimum average skill level. or may describe an entire group--such as all teams must be evenly matched or have at least one player in a certain role.
Expansions -- Optional. Expansions allow you to relax the rules after a period of time when no acceptable matches are found. This feature lets you balance getting players into games in a reasonable amount of time instead of making them wait indefinitely for the best possible match. For example, you might use an expansion to increase the maximum skill variance between players after 30 seconds.

MatchmakingTicket

Ticket generated to track the progress of a matchmaking request. Each ticket is uniquely identified by a ticket ID, supplied by the requester, when creating a matchmaking request.

PingBeacon

Information about a UDP ping beacon that can be used to measure network latency between a player device and an Amazon GameLift Servers hosting location.

PlacedPlayerSession

Information about a player session. This object contains only the player ID and player session ID. To retrieve full details on a player session, call DescribePlayerSessions with the player session ID.

Player

Represents a player in matchmaking. When starting a matchmaking request, a player has a player ID, attributes, and may have latency data. Team information is added after a match has been successfully completed.

PlayerLatency

Regional latency information for a player, used when requesting a new game session. This value indicates the amount of time lag that exists when the player is connected to a fleet in the specified Region. The relative difference between a player's latency values for multiple Regions are used to determine which fleets are best suited to place a new game session for the player.

PlayerLatencyPolicy

Sets a latency cap for individual players when placing a game session. With a latency policy in force, a game session cannot be placed in a fleet location where a player reports latency higher than the cap. Latency policies are used only with placement request that provide player latency information. Player latency policies can be stacked to gradually relax latency requirements over time.

PlayerSession

Represents a player session. Player sessions are created either for a specific game session, or as part of a game session placement or matchmaking request. A player session can represents a reserved player slot in a game session (when status is RESERVED) or actual player activity in a game session (when status is ACTIVE). A player session object, including player data, is automatically passed to a game session when the player connects to the game session and is validated. After the game session ends, player sessions information is retained for 30 days and then removed.

Related actions

All APIs by task

PriorityConfiguration

Custom prioritization settings to use with a game session queue. Prioritization settings determine how the queue selects a game hosting resource to start a new game session. This configuration replaces the default prioritization process for queues.

By default, a queue makes game session placements based on the following criteria:

When a game session request does not include player latency data, Amazon GameLift Servers places game sessions based on the following priorities: (1) the queue's default destination order, and (2) for multi-location fleets, an alphabetic list of locations.
When a game session request includes player latency data, Amazon GameLift Servers re-orders the queue's destinations to make placements where the average player latency is lowest. It reorders based the following priorities: (1) the lowest average latency across all players, (2) the lowest hosting cost, (3) the queue's default destination order, and (4) for multi-location fleets, an alphabetic list of locations.

PriorityConfigurationOverride

An alternate list of prioritized locations for use with a game session queue. When this property is included in a StartGameSessionPlacement request, the alternate list overrides the queue's default location priorities, as defined in the queue's PriorityConfiguration setting (LocationOrder). The override is valid for an individual placement request only. Use this property only with queues that have a PriorityConfiguration setting that prioritizes LOCATION first.

A priority configuration override list does not override a queue's FilterConfiguration setting, if the queue has one. Filter configurations are used to limit placements to a subset of the locations in a queue's destinations. If the override list includes a location that's not on in the FilterConfiguration allowed list, Amazon GameLift Servers won't attempt to place a game session there.

ResourceCreationLimitPolicy

A policy that puts limits on the number of game sessions that a player can create within a specified span of time. With this policy, you can control players' ability to consume available resources.

The policy is evaluated when a player tries to create a new game session. On receiving a CreateGameSession request, Amazon GameLift Servers checks that the player (identified by CreatorId) has created fewer than game session limit in the specified time period.

RoutingStrategy

The routing configuration for a fleet alias.

Related actions

All APIs by task

RuntimeConfiguration

A set of instructions that define the set of server processes to run on computes in a fleet. Server processes run either an executable in a custom game build or a Amazon GameLift Servers Realtime script. Amazon GameLift Servers launches the processes, manages their life cycle, and replaces them as needed. Computes check regularly for an updated runtime configuration.

An Amazon GameLift Servers instance is limited to 50 processes running concurrently. To calculate the total number of processes defined in a runtime configuration, add the values of the ConcurrentExecutions parameter for each server process. Learn more about Running Multiple Processes on a Fleet.

S3Location

The location in Amazon S3 where build or script files are stored for access by Amazon GameLift Servers.

ScalingPolicy

Rule that controls how a fleet is scaled. Scaling policies are uniquely identified by the combination of name and fleet ID.

Script

Properties describing a Realtime script.

Related actions

All APIs by task

ServerProcess

A set of instructions for launching server processes on fleet computes. Server processes run either an executable in a custom game build or a Amazon GameLift Servers Realtime script. Server process configurations are part of a fleet's runtime configuration.

SupportContainerDefinition

Describes a support container in a container group. A support container might be in a game server container group or a per-instance container group. Support containers don't run game server processes.

You can update a support container definition and deploy the updates to an existing fleet. When creating or updating a game server container group definition, use the property GameServerContainerDefinitionInput.

Part of: ContainerGroupDefinition

Returned by: DescribeContainerGroupDefinition, ListContainerGroupDefinitions, UpdateContainerGroupDefinition

SupportContainerDefinitionInput

Describes a support container in a container group. You can define a support container in either a game server container group or a per-instance container group. Support containers don't run game server processes.

This definition includes container configuration, resources, and start instructions. Use this data type when creating or updating a container group definition. For properties of a deployed support container, see SupportContainerDefinition.

Use with: CreateContainerGroupDefinition, UpdateContainerGroupDefinition

Tag

A label that you can assign to a Amazon GameLift Servers resource.

Learn more

Tagging Amazon Web Services Resources in the Amazon Web Services General Reference

Amazon Web Services Tagging Strategies

Related actions

All APIs by task

TargetConfiguration

Settings for a target-based scaling policy. A target-based policy tracks a particular fleet metric specifies a target value for the metric. As player usage changes, the policy triggers Amazon GameLift Servers to adjust capacity so that the metric returns to the target value. The target configuration specifies settings as needed for the target based policy, including the target value.

TargetTrackingConfiguration

This data type is used with the Amazon GameLift Servers FleetIQ and game server groups.

Settings for a target-based scaling policy as part of a GameServerGroupAutoScalingPolicy . These settings are used to create a target-based policy that tracks the Amazon GameLift Servers FleetIQ metric "PercentUtilizedGameServers" and specifies a target value for the metric. As player usage changes, the policy triggers to adjust the game server group capacity so that the metric returns to the target value.

UdpEndpoint

The domain name and port information for a UDP endpoint.

VpcPeeringAuthorization

Represents an authorization for a VPC peering connection between the VPC for an Amazon GameLift Servers fleet and another VPC on an account you have access to. This authorization must exist and be valid for the peering connection to be established. Authorizations are valid for 24 hours after they are issued.

Related actions

All APIs by task

VpcPeeringConnection

Represents a peering connection between a VPC on one of your Amazon Web Services accounts and the VPC for your Amazon GameLift Servers fleets. This record may be for an active peering connection or a pending connection that has not yet been established.

Related actions

All APIs by task

VpcPeeringConnectionStatus

Represents status information for a VPC peering connection. Status codes and messages are provided from EC2 (see VpcPeeringConnectionStateReason). Connection status information is also communicated as a fleet event.

Enums§

AcceptanceType: When writing a match expression against AcceptanceType, 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.
BackfillMode: When writing a match expression against BackfillMode, 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.
BalancingStrategy: When writing a match expression against BalancingStrategy, 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.
BuildStatus: When writing a match expression against BuildStatus, 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.
CertificateType: When writing a match expression against CertificateType, 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.
ComparisonOperatorType: When writing a match expression against ComparisonOperatorType, 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.
ComputeStatus: When writing a match expression against ComputeStatus, 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.
ComputeType: When writing a match expression against ComputeType, 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.
ContainerDependencyCondition: When writing a match expression against ContainerDependencyCondition, 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.
ContainerFleetBillingType: When writing a match expression against ContainerFleetBillingType, 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.
ContainerFleetLocationStatus: When writing a match expression against ContainerFleetLocationStatus, 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.
ContainerFleetRemoveAttribute: When writing a match expression against ContainerFleetRemoveAttribute, 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.
ContainerFleetStatus: When writing a match expression against ContainerFleetStatus, 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.
ContainerGroupDefinitionStatus: When writing a match expression against ContainerGroupDefinitionStatus, 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.
ContainerGroupType: When writing a match expression against ContainerGroupType, 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.
ContainerMountPointAccessLevel: When writing a match expression against ContainerMountPointAccessLevel, 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.
ContainerOperatingSystem: When writing a match expression against ContainerOperatingSystem, 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.
DeploymentImpairmentStrategy: When writing a match expression against DeploymentImpairmentStrategy, 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.
DeploymentProtectionStrategy: When writing a match expression against DeploymentProtectionStrategy, 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.
DeploymentStatus: When writing a match expression against DeploymentStatus, 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.
Ec2InstanceType: When writing a match expression against Ec2InstanceType, 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.
EventCode: When writing a match expression against EventCode, 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.
FilterInstanceStatus: When writing a match expression against FilterInstanceStatus, 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.
FleetAction: When writing a match expression against FleetAction, 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.
FleetStatus: When writing a match expression against FleetStatus, 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.
FleetType: When writing a match expression against FleetType, 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.
FlexMatchMode: When writing a match expression against FlexMatchMode, 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.
GameServerClaimStatus: When writing a match expression against GameServerClaimStatus, 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.
GameServerGroupAction: When writing a match expression against GameServerGroupAction, 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.
GameServerGroupDeleteOption: When writing a match expression against GameServerGroupDeleteOption, 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.
GameServerGroupInstanceType: When writing a match expression against GameServerGroupInstanceType, 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.
GameServerGroupStatus: When writing a match expression against GameServerGroupStatus, 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.
GameServerHealthCheck: When writing a match expression against GameServerHealthCheck, 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.
GameServerInstanceStatus: When writing a match expression against GameServerInstanceStatus, 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.
GameServerProtectionPolicy: When writing a match expression against GameServerProtectionPolicy, 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.
GameServerUtilizationStatus: When writing a match expression against GameServerUtilizationStatus, 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.
GameSessionPlacementState: When writing a match expression against GameSessionPlacementState, 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.
GameSessionStatus: When writing a match expression against GameSessionStatus, 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.
GameSessionStatusReason: When writing a match expression against GameSessionStatusReason, 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.
InstanceRoleCredentialsProvider: When writing a match expression against InstanceRoleCredentialsProvider, 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.
InstanceStatus: When writing a match expression against InstanceStatus, 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.
IpProtocol: When writing a match expression against IpProtocol, 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.
ListComputeInputStatus: When writing a match expression against ListComputeInputStatus, 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.
LocationFilter: When writing a match expression against LocationFilter, 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.
LocationUpdateStatus: When writing a match expression against LocationUpdateStatus, 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.
LogDestination: When writing a match expression against LogDestination, 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.
MatchmakingConfigurationStatus: When writing a match expression against MatchmakingConfigurationStatus, 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.
MetricName: When writing a match expression against MetricName, 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.
OperatingSystem: When writing a match expression against OperatingSystem, 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.
PlacementFallbackStrategy: When writing a match expression against PlacementFallbackStrategy, 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.
PlayerSessionCreationPolicy: When writing a match expression against PlayerSessionCreationPolicy, 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.
PlayerSessionStatus: When writing a match expression against PlayerSessionStatus, 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.
PolicyType: When writing a match expression against PolicyType, 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.
PriorityType: When writing a match expression against PriorityType, 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.
ProtectionPolicy: When writing a match expression against ProtectionPolicy, 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.
RoutingStrategyType: When writing a match expression against RoutingStrategyType, 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.
ScalingAdjustmentType: When writing a match expression against ScalingAdjustmentType, 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.
ScalingStatusType: When writing a match expression against ScalingStatusType, 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.
SortOrder: When writing a match expression against SortOrder, 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.
TerminationMode: When writing a match expression against TerminationMode, 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.

Module types

Module types Copy item path

Modules§

Structs§

Enums§

Module types