AWS for Games Blog

Protect Multiplayer Game Servers From DDoS Attacks Using Amazon GameLift

Today’s most successful multiplayer games connect millions of gamers around the world. The spirit of competition and gameplay is amplified when players connect online. With the rise of multiplayer gaming, there has been an increase in the frequency and intensity of cyber-attacks that disconnect players from their favorite games and leave them disappointed. A common type of malicious attack that blocks players from game servers is a distributed denial of service (DDoS).

DDoS attacks work by targeting a game’s network layer, flooding servers with massive numbers of requests until performance grinds to a halt. These attacks can severely limit a game’s availability for players and degrade the player experience for those who can connect. Game developers’ inability to prevent attacks–or quickly respond to and mitigate them–can erode the trust they have earned with customers.

This blog post uses a typical game server architecture to highlight DDoS attack vulnerabilities, and discusses how to stay protected using AWS’s built-in cloud security, AWS security best practices, and Amazon GameLift’s security features.

Multiplayer Games on Amazon GameLift
Most games hosted on GameLift follow a typical architecture, as shown in Figure 1. To use GameLift, game developers take the following steps:

  1. Integrate the Amazon GameLift SDK into their game server and upload it to GameLift.
  2. Set up a fleet of EC2 instances in the GameLift console.
  3. Enable a game client to communicate with the GameLift service and connect to GameLift-hosted game servers.
  4. Optionally, set up developer-managed auxiliary game services, such as for matchmaking or player authentication.
  5. Manage GameLift fleets over time, including scaling resources to meet changing player demand.

Figure 1. Game server architecture using Amazon GameLift

As illustrated in Figure 1, the Amazon GameLift service and game server computing resources used by GameLift are built on AWS infrastructure. AWS protects the availability of the AWS global infrastructure, as well as services like GameLift and Amazon EC2.

AWS infrastructure is DDoS-resilient by design and is supported by DDoS mitigation systems that can automatically detect and filter malicious traffic. Attacks against the AWS infrastructure can be large scale and consist of layer 3 attacks (e.g. UDP reflection) or layer 4 attacks (e.g. SYN floods). These attacks are designed to flood the network, causing legitimate requests to be dropped or delayed. Layer 3 and 4 attacks generally have clear, unambiguous signatures. AWS continually monitors our global infrastructure and engages our DDoS mitigation capabilities as needed to protect the targeted service.

Although game servers that are hosted on AWS benefit from AWS infrastructure protections, game servers have their own points of vulnerability. Attackers may try to use valid requests to consume all available resources, making them inaccessible to legitimate players. They may also try to directly bombard game servers with invalid requests in an attempt to crash or compromise the server. While it is impossible to protect against all conceivable DDoS attacks, there are a number of steps you can take to reduce your risk.

Best Practices for Protecting your Game Servers on Amazon GameLift
To increase protections for your game servers, consider implementing the following best practices. These measures include taking advantage of special GameLift features and applying a set of AWS Best Practices for DDoS Resiliency to securing your game servers hosted on GameLift.

      1. Deploy your game to multiple regions
        Deploying your game server in multiple regions provides redundancy that makes it more challenging for an attacker to take down your entire game globally. Figure 2 shows the regions supported by Amazon GameLift.

        Figure 2. Amazon GameLift Region Availability

      2. Distribute players across many instances
        By using Amazon GameLift, you have the opportunity to distribute player load across many instances. This distribution prevents your game from experiencing a 100% outage for all players in the event that an instance gets compromised. Setting your fleet’s minimum capacity to two or more instances ensures that only a fraction of your players are affected if any one instance fails.
      3. Pick an adequately large instance size with additional capacity to absorb malicious traffic
        When creating an Amazon GameLift fleet of computing resources to host your game servers, choose an instance type with the size and computing power that best suits your game. GameLift supports many different AWS instance types to choose from to build your fleet, such as t2.micro, c3.large, and r3.8xlarge. Each instance type has different capacity for compute, memory, storage and network bandwidth. In order to determine which instance type to use, you should run your game server under valid stress scenarios (e.g. connect a maximum number of players to the game server) and ensure that your game server can process the request with additional capacity to spare. The amount of additional capacity you allow will determine the size of the attack your server can tolerate without impacting the players.
      4. Autoscale your server capacity to absorb a DDoS attack
        Use Amazon GameLift’s autoscaling feature to quickly increase capacity to absorb a DDoS attack. GameLift allows you to configure autoscaling rules in order to horizontally scale your fleet to satisfy an increase in player requests. Increasing capacity by allowing your fleet to scale up provides you with additional time to respond to the attack. When autoscaling with GameLift, a maximum capacity limit is required to prevent over-spending. See the Amazon GameLift documentation for more information on how to Set Up Fleet AutoScaling.
      5. Enable resource protection for your game
        Amazon GameLift’s resource protection feature prevents one player from creating an excessive number of game sessions and consuming your available resources. GameLift lets you set a resource creation limit policy, which specifies the maximum number of game sessions that one player can create within a specified period of time. A policy applies to all resources in a fleet.

          1. To add a resource creation limit policy to an existing fleet, use the AWS CLI command update-fleet-attributes. The example below sets a fleet’s resource creation limit policy such that no one player can create more than two game sessions within a five-minute period. If the request is successful, the fleet ID is returned.
            --Enable resource protection on a fleet--
            PS H:\>aws gamelift update-fleet-attributes --region us-west-2 --fleet-id 
            fleet-b3f84103-8928-48cb-89c2-2c1cd0f9d35e --resource-creation-limit-policy 
            "FleetId": "fleet-b3f84103-8928-48cb-89c2-2c1cd0f9d35e"

            Figure 3. Enable resource protection on a fleet

          2. To view an existing resource creation limit policy for a fleet, use the AWS CLI command describe-fleet-attributes. If successful, a set of attributes for the specified fleet is returned, including any resource creation limit policy in force.
            -View the resource creation limit policy on a fleet-
            PS H:\>aws gamelift describe-fleet-attributes --region us-west-2 --fleet-id
             "FleetAttributes": [
              "Status": "ACTIVE",
              "Description": "Test fleet",
              "BuildId": "build-14719bed-30ec-4c59-9da7-ac03437d0689",
              "CreationTime": 1478131210.71,
              "NewGameSessionProtectionPolicy": "NoProtection",
              "FleetId": "fleet-b3f84103-8928-48cb-89c2-2c1cd0f9d35e",
              "ResourceCreationLimitPolicy": {
               "NewGameSessionsPerCreator": 2,
               "PolicyPeriodInMinutes": 5
              "LogPaths": ["C:\\game\\serverErr.log",
              "OperatingSystem": "WINDOWS_2012",
              "Name": "Test_0b1dd591-2318-4691-9314-c01c42f3da36_Fleet"

            Figure 4. View an existing resource creation limit policy on a fleet

      6. Validate new player connection requests
        In Amazon GameLift, a player joins a game by sending a request to the GameLift service, receiving game session information, and then connecting directly to the game server. When GameLift receives a join request, it finds an open player slot in a game session and reserves it for the player, then responds with the game session’s IP address, port, and a player session ID. When connecting to the game session, the game client includes the player session ID. As a best practice, your game server should validate the player session ID with GameLift before allowing the player to join the game. Validating the player session ID prevents other game clients from joining the game and stealing the reserved slot. This is done with a call to the Server API action AcceptPlayerSession.The C++ code snippet in Figure 5 illustrates how to verify that a new player connection is using a valid player session ID.

        -On your game server, validate the playerSessionId-
        void ReceiveConnectingPlayerSessionID (Connection& connection, const Aws::String&
         Aws::GameLift::GenericOutcome connectOutcome = 
                connectionToSessionMap.emplace(connection, playerSessionId);

        Figure 5. C++ code to validate the player session ID

      7. Detect and filter out invalid or malicious requests
        We recommend that you design your game server to take steps to detect and filter out malicious traffic as soon as possible. Here are our recommended steps (to be done in order):

        1. Ensure that your server keeps running even when capacity is exceeded. The first and cheapest way is to decline any excessive requests that the server cannot process. This can be done by enforcing a maximum number of concurrent requests at the server or, if possible, at the load balancer.
        2. Authenticate new player connections before processing a request. Authenticating players gives you an easy way to filter out any requests from non-signed-in users. Additionally, it gives you an identity you can use to track the player’s request pattern. Choose a player authentication mechanism that is difficult to automate. This makes it much harder for attackers to generate the high number of players needed to DDoS your server. Two good methods for proving that human processing has occurred during sign-in are captchas and proof-of-work, which requires the player to perform a non-negligible computational task.
        3. Define your game application network protocol and validate the input thoroughly to filter out any malformed requests. Invalid requests can cause the server to crash; this is one way an attacker can inject malicious code to run on the server and cause buffer overflow. We recommend that you perform extensive penetration testing against your network protocol to ensure that only valid inputs are processed.
        4. Limit the scope of access granted to a player. For example, a regular player should not be able to successfully call administrative operations.

While it is impossible to build a game server architecture that is completely resistant to DDoS attacks, you can deploy game servers that are not easily impacted using AWS and Amazon GameLift. This blog lays out a three-tiered approach to prevent or mitigate DDoS attacks: (1) rely on the built-in protections of AWS infrastructure and services, (2) take advantage of GameLift-specific features such as resource protection, autoscaling, and new player validation, and (3) implement some core best practices, such as those described in Best Practices for DDoS Resiliency to stop malicious requests and prevent them from sneaking through.

Hok Peng Leung joined Amazon in 2014 as the Head of Software Development for Amazon GameLift. He’s spent 11 years building large scale gaming services that have set industry standards for online gameplay experiences. Prior to Amazon, Hok worked at Microsoft and helped to ship both Xbox 360 and Xbox One.