Skip to main content
Sumo Logic

Sumo Logic Endpoints and Firewall Security

Sumo Logic has several deployments that are assigned depending on the geographic location and the date an account is created.

Sumo Logic redirects your browser to the correct login URL and also redirects Collectors to the correct endpoint. However, if you're using an API you'll need to manually direct your API client to the correct Sumo Logic API URL.

Deployment Service Endpoint (login URL) API Endpoint Collection Endpoint Cloud Syslog Endpoint
FED Cloud syslog is not supported



Sumo Logic's FedRAMP deployment is similar to our other deployments, such as US2, except that FedRAMP is certified to comply with the United States Standards for Security Categorization of Federal Information and Information Systems (FIPS-199). In this deployment, we adhere to specific security requirements that are required for handling, storing, and transmitting data classified in the "Moderate" impact level.

How can I determine which endpoint I should use?

The easiest way to see which deployment pod your account uses is to look at the Sumo Logic URL you use. If you see "us2" that means you're running on the US2 pod. If you see "eu", "jp", "de", "in", "ca", or "au" you're on one of those pods. The US1 pod uses The following image has an example URL from the US2 pod.

sumo web address pod highlight.png

The specific collection endpoint will vary per account. The general format is:


You can also determine which deployment pod your account is using by creating an HTTP Source and looking at the provided URL.

Securing access to Sumo Logic infrastructure via DNS name or IP address

For collection to work, your firewall must allow outbound traffic to Sumo Logic. Refer to Test Connectivity for Sumo Logic Collectors for instructions on allowing outbound traffic over port 443.

  • If your firewall allows DNS entries, add the following to the whitelist in your firewall to allow outbound traffic to
    By default, the Collector contacts before it is redirected to a deployment-specific endpoint such as

  • If your firewall doesn’t allow DNS entries, you must whitelist all of the IP addresses for your deployment region. The addresses to whitelist depend on your Sumo Logic deployment. To determine the IP addresses that require whitelisting, download the JSON object provided by Amazon Web Services (AWS). Amazon advises that this file will change several times a week. For details on how the file is updated, its usage, its syntax, and downloading the JSON file see AWS IP Address Ranges.

AWS region by Sumo deployment

The following table describes the AWS regions used by each Sumo Logic deployment. See the AWS page on regions and endpoints for more information.

Sumo Logic Deployment

AWS region name

AWS Region


Asia Pacific (Sydney)



Canada (Central)



EU (Frankfurt)



EU (Ireland)



US East (N. Virginia)



Asia Pacific (Mumbai)



Asia Pacific (Tokyo)



US East (N. Virginia)



US West (Oregon)


This link provides the complete current list of AWS IP ranges or subnets or prefixes. You can limit the number of entries in a firewall by using just the IP prefixes against the AWS region that your account's Sumo deployment uses, as shown in the table.

You can run the following query against the downloaded file in Sumo Logic to determine the IP addresses for each deployment.

| parse regex "\s+\"ip_prefix\":\s+\"(?<ip_prefix>.*?)\",\n\s+\"region\":\s+\"(?<region>.*?)\",\n\s+\"service\":\s+\"(?<service>.*?)\"" multi | where service="AMAZON" and (region="us-west-2" or region="us-east-1" or region="eu-west-1" or region="ap-southeast-2") | if (region="us-west-2", "US2", region) as region | if (region="us-east-1", "PROD", region) as region | if (region="eu-west-1", "EU", region) as region | if (region="ap-southeast-2", "AU", region) as region | count by ip_prefix, region, service | fields - _count | sort by region, ip_prefix

After configuring the firewall, Collector, and Sources, confirm that the Collector and Sources are working by verifying that you can receive a given type of message (such as syslog messages) at the specified location.

Versioning and Conflict Detection 

The Collector Management API uses optimistic locking to deal with versioning and conflict detection. Any response that returns a single entity will have an ETag header which identifies the version of that entity. Subsequent updates (PUT requests) to that entity must provide the value of the ETag header in an If-Match header; if the header is missing or no longer corresponds to the latest version of the entity, the request will fail (with 403 Forbidden or 412 Precondition Failed, respectively). Clients must be prepared to handle such failures if they anticipate concurrent updates to the entities. Additionally, the value of the ETag header may be provided in an If-None-Match header in future GET requests for caching purposes.