Get Started with AMS

Last updated on February 5, 2026

Overview

This document describes a simple approach to getting your game up and running using AccelByte Multiplayer Servers (AMS) as the dedicated server (DS) provider.

To use AMS as a DS provider, you need to sign up for AccelByte Shared Cloud to manage your fleets and authorize your matchmaking or session service to claim dedicated servers. For your Unity or Unreal-based game, you also need to integrate the AccelByte Game Software Development Kit (SDK) into your DS so it can interact with AMS to signal when it's ready to use and respond to drain signals when your fleet needs to scale in. If your game uses a different engine it will need to implement the AMS watchdog protocol over a local websocket. The rest of this guide assumes your game engine is supported by the AccelByte Game SDK.

AccelByte Shared Cloud and DS setup

Here are the steps to follow to get set up:

1. Register an account on AccelByte Shared Cloud.
2. Once your account is created and you have logged in and activated your AMS trial, click "Set up My Game".
3. After creating the namespace, follow the AMS documentation to:
   1. Create an AMS account.
   2. Download AMS Command Line Interface (CLI) tools from the Admin Portal.
   3. Integrate your dedicated server with AMS using the AccelByte Game SDK.
   4. Upload a dedicated server build using the AMS CLI

After following the above steps, the game server is ready to run in AMS.

Claiming Dedicated Servers

There are two options for claiming dedicated servers:

1. Session management service claims the DS: Your session management or matchmaking service calls the AMS Server Claim Endpoint when a game session is created.
2. DS self-claims: The DS claims itself when it becomes active

Either way AMS will mark the DS as claimed, enabling it to scale the fleet appropriately according to the buffer settings.

Claiming dedicated servers with AGS

If you are using AGS as your backend, the AGS session service will take care of claiming each DS for you when the session is created. See Configure sessions to claim dedicated servers from AMS.

Claiming dedicated servers without AGS

Option 1: Session management service claims the DS

If your game does not use AGS and instead uses a different matchmaking or session management solution, you can integrate one of the available AGS Extend SDKs into your session management solution to facilitate claiming dedicated servers from AMS.

When using one of the SDKs, or when making a REST call directly to the claim API, an authorization token is needed. The authorization token is obtained using an OAuth client ID and secret.

To set up the IAM client which the service will use follow these steps:

1. On the AccelByte Admin Portal sidebar, go to Game Setup > IAM Clients.
2. Click Create IAM Clients, choose Create from Template, and select the Custom Backend Tooling template.
3. Fill in the secret you want to use.
4. In the Permission section, find the Dedicated Server Claim option in the AMS group and tick the update permission checkbox.
5. Click Create.

The session management service for your game can use this client ID and secret to get a token which can be used to claim dedicated servers from AMS. You can find an example which uses the Accelbyte Python Extend SDK to build a simple matchmaker which claims a DS when a match is formed in the matchmaking-server AMS samples repository.

ヒント

Your matchmaker or session management service should prevent bad actors from triggering excessive claim requests, for example, by requiring player login and restricting any logged in player to a single active matchmaking request at a time.

Option 2: DS self-claims

When using a third party session management service, it may not be open for modifications to claim a DS. In such cases a self claim approach can be used as follows:

1. On startup, the DS registers a session with a session provider (e.g., using Epic Online Services session service), or otherwise registers itself as an available server with a server browser (e.g., Steam game servers).
2. When players choose to play on a particular DS and connect to it, the server sends a claim message to the local watchdog (via the SDK if using the AccelByte SDK). This marks the DS as in-session/claimed and allows AMS to start new DS instances according to the buffer settings on the fleet.

With this approach, the DS claims itself when it becomes active, which enables AMS to scale the fleet appropriately without requiring an external service to make the claim call.

Make the DS session aware

Your DS needs to know if it is serving an active game session (as opposed to being idle, ready to serve one) so that it can behave appropriately if it gets a drain signal. The expected behavior is described in Listening to the drain signal. Depending on your game service setup, and what your game logic needs, your DS can be made aware of the session information in one of the following ways:

• If your game uses AGS as a backend, the DS should subscribe to the notification from the AGS session service.
• If there are players connected, assume there is an active session.
• After successfully claiming a DS, your session management service can use the DS IP and port information to send a message to the DS letting it know it was claimed and sharing session details.
• The DS could subscribe to a notification system by which your session management service can send the notification with session details.
• If using the DS self-claim approach (Option 2), the DS is already aware of its session state since it initiates the claim when players connect.