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.
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.
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.
You can also target a specific object:
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:
- '
Sessionpicks credentials and region' - '
clientperforms low-level API calls' - '
resourceprovides 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.
Without explicit sessions, multi-account code becomes harder to audit because the active credentials may depend on ambient shell state.
Common Pitfalls
- Treating
resourceandclientas 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
- '
Sessioncontrols credentials, profile selection, and region.' - '
clientis the low-level boto3 interface that maps closely to AWS APIs.' - '
resourceis 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.

