Endpoints and storage locations

Endpoint Types

IBM Cloud® services are connected to a three-tiered network, segmenting public, private, and management traffic.

• Private endpoints are available for most requests originating from within IBM Cloud. Private endpoints provide better performance and do not incur charges for any outgoing or incoming bandwidth even if the traffic is cross regions or across data centers. Whenever possible, it is best to use a private endpoint.
• Public endpoints can accept requests from anywhere and charges are assessed on outgoing bandwidth. Incoming bandwidth is free. Public endpoints should be used for access not originating from an IBM Cloud cloud computing resource.
• Direct endpoints are used in Bring-Your-Own-IP scenarios, generally for requests originating from resources within VPCs. Like Private endpoints, Direct endpoints provide better performance over Public endpoints and do not incur charges for any outgoing or incoming bandwidth even if the traffic is cross regions or across data centers. Directions for connecting to IBM Cloud Object Storage from VPC are available here.

Requests must be sent to the endpoint associated with a given bucket's location. If you aren't sure where a bucket is located, there is an extension to the bucket listing API that returns the location and storage class information for all buckets in a service instance. Another place to find an endpoint is to open the Bucket configuration tab in the IBM Cloud Console.

When using Virtual Private Endpoints in an application that makes requests to IBM COS, it may be necessary to add some additional configuration for authentication. The IBM COS SDKs will automatically attempt to fetch an IAM token from https://iam.cloud.ibm.com/identity/token. If you are using a virtualized endpoint for token acquisition you will need alter the IAM endpoint appropriately.

Regional Endpoints

Buckets that are created at a regional endpoint distribute data across three data centers that are spread across a metro area. Any one of these data centers can suffer an outage or even destruction without impacting availability.

Cross-Region Endpoints

Buckets that are created at a cross-region endpoint distribute data across three regions in a geographical location. Any one of these regions can suffer an outage or even destruction without impacting availability. Requests are routed to the nearest cross-region metropolitan area by using Border Gateway Protocol (BGP) routing. In an outage, requests are automatically rerouted to an active region. Advanced users who want to write their own failover logic can do so by sending requests to a tethered endpoint and bypassing the BGP routing.

For example:

• Data in US cross-region bucket is distributed only across regions (such as Dallas, WDC, and SJC) in the US geographical location.
• Data in EU cross-region bucket is distributed only across regions (such as, Amsterdam, FRA, and Milan) in the EU geographical location.
• Data in AP cross-region bucket is distributed only across regions (such as, TOK, SYD, and OSA) in the AP geographical location.

Single Data Center Endpoints

Single data centers are not co-located with IBM Cloud services, such as IAM or Key Protect, and offer no resiliency in a site outage or destruction.

If a networking failure results in a partition where the data center is unable to access IAM, authentication and authorization information is read from a cache that might become stale. This cached data might result in a lack of enforcement of new or altered IAM policies for up to 24 hours.

EU-Managed Endpoints

The IBM Cloud Activity Tracker can archive to a bucket at specific IBM Cloud Object Storage instances. This table shows the EU-Managed locations of Object Storage instances for archiving events.

Resource Configuration Endpoints

Requests made using the Resource Configuration API are sent to a global endpoint, regardless of the bucket's location.

Decommissioned locations

Over time, it may be necessary for locations to transform from a Single Data Center to a Regional configuration, or for a location to be decommissioned entirely. These situations will require users to migrate data from one bucket to another. Please consult this guide for migrating a bucket using rclone.