AWS
Boto3
Python
Resource
Client

Difference in Boto3 between resource, client, and session?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Boto3 exposes three concepts that are related but not interchangeable: Session, client, and resource. A Session controls configuration such as credentials and region, a client exposes low-level AWS API operations, and a resource gives a higher-level object-oriented wrapper for some services. If you keep those roles separate, the SDK becomes much easier to reason about.

Session Is the Configuration Context

A session is the object that decides which AWS identity and region your code will use. It is the starting point for creating clients and resources.

python
1import boto3
2
3session = boto3.Session(
4    profile_name='default',
5    region_name='us-east-1',
6)
7
8s3_client = session.client('s3')
9s3_resource = session.resource('s3')

If you do not create a session explicitly, boto3 uses a default session behind the scenes. That is fine for short scripts, but explicit sessions are clearer when you work with multiple accounts, profiles, or regions.

client Is the Low-Level AWS Interface

A client maps closely to the underlying AWS service API. Its methods usually match service operations, and the responses are plain Python dictionaries.

python
1import boto3
2
3s3 = boto3.client('s3')
4response = s3.list_buckets()
5
6for bucket in response['Buckets']:
7    print(bucket['Name'])

Use a client when you want:

  • direct access to AWS operations
  • predictable request and response shapes
  • support for services that do not have a resource layer

In day-to-day practice, clients are the most universal boto3 interface.

resource Is the Higher-Level Object API

A resource wraps some AWS services in Python objects. Instead of parsing dictionaries everywhere, you work with higher-level objects such as buckets, instances, or tables.

python
1import boto3
2
3s3 = boto3.resource('s3')
4
5for bucket in s3.buckets.all():
6    print(bucket.name)

You can also target a specific object:

python
1import boto3
2
3s3 = boto3.resource('s3')
4obj = s3.Object('my-bucket', 'reports/data.csv')
5print(obj.content_length)

This style is often pleasant for S3 or EC2 because the code reads more like working with domain objects than raw API payloads.

The Practical Relationship Between Them

The easiest way to remember the difference is:

  • 'Session picks credentials and region'
  • 'client performs low-level API calls'
  • 'resource provides convenience objects on top of some client behavior'

A resource is not a separate AWS subsystem. It is a higher-level abstraction in boto3, and under the hood it still depends on service metadata and client-style operations.

When to Prefer a client

Prefer clients when:

  • you need complete service coverage
  • you want exact control over request parameters
  • the AWS documentation you are following is written in terms of API operations
  • the service has no resource abstraction

That is why many teams standardize on clients even when resources are available.

When to Prefer a resource

Prefer resources when:

  • the service offers a mature resource interface
  • object-style code is easier for the task at hand
  • you are doing common operations rather than edge-case API work

For example, iterating S3 buckets or reading EC2 instance attributes often feels cleaner with resources than with raw dictionaries.

Explicit Sessions Become Important Fast

Sessions are especially useful when one program must talk to different AWS accounts.

python
1import boto3
2
3prod = boto3.Session(profile_name='prod', region_name='us-east-1')
4dev = boto3.Session(profile_name='dev', region_name='us-east-1')
5
6print(prod.client('sts').get_caller_identity()['Account'])
7print(dev.client('sts').get_caller_identity()['Account'])

Without explicit sessions, multi-account code becomes harder to audit because the active credentials may depend on ambient shell state.

Common Pitfalls

  • Treating resource and client as competitors when they are simply different abstraction levels.
  • Assuming every AWS service has a rich resource interface even though many workflows require clients.
  • Relying on the implicit default session in larger codebases where region and credentials should be explicit.
  • Expecting resource objects to return raw response dictionaries instead of higher-level attributes and methods.
  • Mixing sessions, clients, and resources without being clear which account and region are actually active.

Summary

  • 'Session controls credentials, profile selection, and region.'
  • 'client is the low-level boto3 interface that maps closely to AWS APIs.'
  • 'resource is a higher-level object-oriented wrapper for some services.'
  • Use clients for broad coverage and precise control.
  • Use explicit sessions whenever you need clear account and region boundaries.

Course illustration
Course illustration

All Rights Reserved.