aws-sdk-python-usage
AWS SDK for Python (boto3/botocore) development patterns. You MUST use this skill when writing Python code that uses AWS services via boto3 or botocore. This includes creating service clients or resources, configuring sessions and credentials, handling errors with ClientError, using paginators and waiters, S3 file transfers and presigned URLs, DynamoDB table operations, and any boto3/botocore client configuration. Use this skill whenever Python code imports boto3 or botocore, or when the user as
Security Assessment
Detected risks:
About aws-sdk-python-usage
A reference for AWS SDK for Python (boto3/botocore) development patterns, to be used whenever writing Python code that uses AWS services via boto3 or botocore. It covers creating service clients or resources, configuring sessions and credentials, error handling with ClientError, paginators and waiters, S3 file transfers and presigned URLs, DynamoDB table operations, and client configuration, and applies whenever Python code imports boto3 or botocore or when the user asks about AWS operations in Python. It also instructs that no emojis be used in code, comments, or output while active.
The guidance starts from the client-versus-resource distinction: clients map 1:1 to service APIs and return plain dicts and exist for every service, while resources provide an object-oriented interface and exist only for select services such as S3, DynamoDB, EC2, IAM, SQS, SNS, CloudFormation, CloudWatch, and Glacier, auto-marshaling types in a way that is especially useful for DynamoDB. It advises reusing a single client instance rather than creating clients inside loops, noting clients are thread-safe once instantiated, and that parameter names match the AWS API casing, typically PascalCase.
For error handling it recommends catching only when there is an actionable response, preferring typed exceptions on the client (via client.exceptions) over generic ClientError string matching, and reserving ClientError as a top-level catch-all that lives in botocore rather than boto3. It promotes a script structure where the __main__ guard is a single call to main(), keeping argument parsing, error presentation, and exit codes in main() and never calling sys.exit from business logic. It directs the use of paginators with JMESPath .search() instead of manual NextToken loops, waiters for resource states, and botocore.config.Config for retries, timeouts, and connection pools, and shows logging via set_stream_logger. A common-issue note clarifies that ClientError must be imported from botocore.exceptions, not boto3.exceptions. Service-specific reference files for S3 and DynamoDB, plus references for configuration, credentials, error handling, pagination, and waiters, must be loaded when relevant.
FAQ
When should I use a client versus a resource?
Use clients for full API coverage or services without a resource interface; use resources where they exist (such as S3 and DynamoDB) to simplify code, since they are object-oriented and auto-marshal types.
Where is ClientError imported from?
From botocore.exceptions, not boto3.exceptions. The skill flags from boto3.exceptions import ClientError as wrong.
How should pagination be handled?
Never manually loop with NextToken. Use paginators, and when you only need specific fields use .search() with a JMESPath expression to extract and flatten across pages.
What is the recommended script structure?
Keep if __name__ == "__main__" to a single main() call, put argument parsing, error presentation, and exit codes in main(), and never call sys.exit() from business logic functions.
How are retries and timeouts configured?
Through botocore.config.Config, which sets retries, connect and read timeouts, and max_pool_connections, passed when creating the client.
Install aws-sdk-python-usage
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
aws/agent-toolkit-for-aws