Skip to main content
This page shows how to configure the AWS CLI and boto3 to interact with CoreWeave AI Object Storage, so you can use AWS tooling against CoreWeave endpoints. We recommend using a separate AWS profile for Object Storage to avoid conflicts with other AWS profiles and S3-compatible services. Both static credentials and Workload Identity Federation are supported, but we recommend Workload Identity Federation.

​
Static credentials

Static credentials are the simplest way to get started when you have an access key and secret key on hand. To set up your AWS configuration for Object Storage, create a new credentials file and profile.
  1. Create a new profile called cw: 
    AWS_SHARED_CREDENTIALS_FILE=~/.coreweave/cw.credentials aws configure --profile cw
  2. When prompted for information, provide the following values:
    FieldValue
    AWS Access Key IDThe Object Storage Access Key.
    AWS Secret KeyThe Object Storage Secret Key.
    Default region nameOptional. To set a default region, use a CoreWeave Availability Zone.
    Default output formatUse json for JSON output.
  3. Set the endpoint URL to the appropriate endpoint for your use case:
    Endpoint URLDescription
    https://cwobject.comThe primary endpoint for Object Storage. Use this when running outside of a CoreWeave cluster.
    http://cwlota.comThe LOTA endpoint, which routes to the LOTA cache for best performance. Always use the LOTA endpoint when running inside a CoreWeave cluster.
    AWS_CONFIG_FILE=~/.coreweave/cw.config aws configure set endpoint_url http://cwlota.com --profile cw
  4. Set the default addressing style to virtual. This is required for Object Storage. 
    AWS_CONFIG_FILE=~/.coreweave/cw.config aws configure set default.s3.addressing_style virtual --profile cw
With your profile in place, the AWS CLI is ready to issue commands against Object Storage using static credentials.

​
Workload Identity Federation in Kubernetes

This approach is best for workloads running inside CKS, where short-lived tokens are preferred over long-lived static credentials. When an OIDC token is available in a file and automatically rotated (as in Kubernetes and CKS), use the Container Credentials API. Start with a basic config file for the endpoints: 
aws configure set region US-EAST-04A --profile cw
aws configure set endpoint_url https://cwobject.com --profile cw
aws configure set default.s3.addressing_style virtual --profile cw
This produces a configuration like: 
[profile cw]
region = US-EAST-04A
endpoint_url = https://cwobject.com
s3 =
    addressing_style = virtual
Then set the Container Credentials environment variables. These are often injected automatically by the Pod Identity Webhook. Replace [ORG-ID] with your CoreWeave organization ID. Your Org ID is a short hexadecimal string (for example, ab1cd2). Find it on the Settings page of your Cloud Console account. 
export AWS_PROFILE=cw
export AWS_CONTAINER_CREDENTIALS_FULL_URI=https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]
export AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/path/to/token

aws s3 ls
The SDK reads the token from the file path and exchanges it for temporary credentials at the specified endpoint, then refreshes them automatically before expiry.

​
Workload Identity Federation with a credential process

Use this approach when you want federated credentials outside of CKS, such as on developer workstations or in CI environments. Without an auto-rotated token file, AWS SDKs support a Process Credential Provider that invokes a custom command to fetch credentials. This works for both human and machine workloads. 
aws configure set region US-EAST-04A --profile cw
aws configure set endpoint_url https://cwobject.com --profile cw
aws configure set s3.addressing_style virtual --profile cw
aws configure set credential_process "/bin/cw-auth.sh" --profile cw
This produces: 
[profile cw]
region = US-EAST-04A
endpoint_url = https://cwobject.com
credential_process = /bin/cw-auth.sh
s3 =
    addressing_style = virtual
When an S3 client invokes a command using this profile, it runs the specified script and expects output in this format: 
{
    "Version": 1,
    "AccessKeyId": "[ACCESS-KEY-ID]",
    "SecretAccessKey": "[SECRET-ACCESS-KEY]",
    "SessionToken": "[SESSION-TOKEN]",
    "Expiration": "[RFC3339-TIMESTAMP]"
}
The script implementation depends on your platform. It might perform an interactive browser sign-in, fetch a GitHub Actions ID token, or use another identity provider. The general pattern is:
  1. Check for cached credentials.
  2. Obtain a new OIDC token from your identity provider if the cached credentials are missing or expired.
  3. Exchange the token with the CoreWeave API for temporary credentials.
  4. Cache and return the response.

​
Boto3

This section covers how the same configuration applies when you use boto3 in Python.
If you use Workload Identity Federation, use boto3 >= 1.42.5, which incorporates a required fix for CoreWeave APIs.
Boto3 uses the same configuration files as the AWS CLI. If you have already configured the AWS CLI, no additional setup is needed. Boto3 can also use a Config object or the environment to override the AWS CLI configuration. See the full configuration examples.
Last modified on May 29, 2026