Introduction

In AWS SDK for JavaScript v3, the best way to “set credentials” depends on where the code runs. On a server, you usually rely on the default credential provider chain or an IAM role. In local development, shared config profiles and environment variables are common. In browser code, you should not hard-code long-lived access keys at all.

The important shift in v3 is that credentials are provider-based and modular. You can still pass static credentials directly, but that should be the exception rather than the default.

The Simplest Server-Side Approach

For Node.js code, many applications do not need to pass credentials explicitly. The SDK can resolve them from the default provider chain.

import { S3Client } from '@aws-sdk/client-s3';

const client = new S3Client({ region: 'us-east-1' });

With that configuration, the SDK will try the usual credential sources such as environment variables, shared config files, and role-based providers depending on the environment.

This is often the cleanest setup for server applications, Lambda, ECS, and EC2.

Using Environment Variables

One common local-development setup is:

1export AWS_ACCESS_KEY_ID=YOUR_KEY
2export AWS_SECRET_ACCESS_KEY=YOUR_SECRET
3export AWS_SESSION_TOKEN=YOUR_SESSION_TOKEN
4export AWS_REGION=us-east-1

Then the same client code works without embedding secrets in source code.

This is better than hard-coding keys because the code stays portable across machines and environments.

Using a Named AWS Profile

If you already use the AWS CLI or shared config files, a named profile is usually more convenient.

1import { S3Client } from '@aws-sdk/client-s3';
2import { fromIni } from '@aws-sdk/credential-providers';
3
4const client = new S3Client({
5  region: 'us-east-1',
6  credentials: fromIni({ profile: 'dev-profile' }),
7});

This is useful when switching between multiple accounts or roles in development.

Passing Static Credentials Directly

You can pass credentials explicitly, but this should be reserved for controlled cases such as temporary test code or credentials obtained securely from another process.

1import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
2
3const client = new DynamoDBClient({
4  region: 'us-east-1',
5  credentials: {
6    accessKeyId: 'AKIA...EXAMPLE',
7    secretAccessKey: 'SECRET...EXAMPLE',
8    sessionToken: 'OPTIONAL_SESSION_TOKEN',
9  },
10});

This works, but it is not the preferred long-term pattern because secrets can leak into source control or logs if handled carelessly.

IAM Roles Are Better in AWS Environments

When code runs on Lambda, ECS, or EC2, the recommended pattern is usually to attach an IAM role and let the SDK resolve temporary credentials automatically.

That gives you:

• no hard-coded secrets
• automatic rotation of temporary credentials
• cleaner separation between code and identity

In those environments, explicit credential objects are often a smell rather than a best practice.

Browser Code Is Different

Do not ship long-lived AWS access keys in frontend JavaScript. If the code runs in the browser, use a browser-appropriate identity solution such as Cognito or a backend service that signs or proxies the required AWS requests.

The AWS SDK supports browser use, but credential strategy must change because the browser is not a trusted secret store.

Region and Credentials Are Separate

A frequent point of confusion is that region configuration does not equal credential configuration.

This:

const client = new S3Client({ region: 'us-east-1' });

only sets the region. Whether it works depends on whether credentials can be resolved elsewhere.

If region is correct but credentials are missing, requests will still fail.

Common Pitfalls

A common mistake is hard-coding access keys directly in repository code. That creates both security risk and maintenance pain.

Another mistake is trying to use server-side credential patterns in the browser. Frontend apps need a different trust model.

Developers also forget that the SDK can already load credentials from the default provider chain, so they add unnecessary custom logic.

Finally, do not confuse AWS profile names with credentials themselves. A profile is a way to resolve credentials, not the credential values.

Summary

• In AWS SDK v3, the default provider chain is often the best server-side credential strategy.
• Use environment variables or shared profiles for local development.
• Use IAM roles for Lambda, ECS, and EC2 whenever possible.
• Pass static credentials explicitly only when you have a strong reason.
• Never embed long-lived AWS secrets in browser code.