Cloud SDKs Highlights Summary

Every highlight bullet from the 11 pages in this section, gathered on one page and grouped by the page it came from.

The boto3 Architecture Mental Model

• boto3 is a thin, data-driven layer generated from AWS service models
• A session is a configuration context, not a network connection
• Clients are low-level and complete; resources are a smaller, friendlier subset
• Every call passes through the same credential and retry machinery, regardless of API
• New AWS APIs appear in clients first because they come from generated service data
• Retry and pagination are solved once in botocore, not per service

boto3 Basics

• Session centralizes region, profile, and credentials
• Clients are low-level; resources are higher-level ORM-style
• Never hardcode keys - use profiles, env vars, or IAM roles
• Reuse sessions/clients in long-running workers

S3

• Block public access at account level and use presigned URLs instead of ACL
• Presigned URLs need short TTL 15-60 minutes to limit damage from leaked URLs
• Multi-GB objects with read() cause OOM, use iter_chunks or download_file instead
• Pagination required for list_objects, truncated responses without it lose data
• Scope IAM keys tightly when generating presigned URLs since they use caller credentials
• Specify correct bucket region in client to avoid permanent redirect errors

Lambda

• RequestResponse waits for return, Event is fire-and-forget
• Payload must be JSON bytes for structured event handling
• Reuse boto3 clients outside handlers to optimize cold starts
• Use layers, containers, or slim deps to reduce cold start times
• Offload blocking work from async handlers to prevent timeouts
• Implement idempotent handlers to prevent duplicate side effects

DynamoDB

• Composite pk/sk holds multiple entity types; add GSIs for alternate patterns
• Query one partition efficiently; avoid full-table Scans in production
• Hot partitions occur when one pk gets all traffic; shuffle writes
• Use Decimal for money; floats cause precision loss
• Items larger than 400KB rejected; offload to S3, store pointer
• batch_writer automatically handles retries for unprocessed items

SQS & SNS

• Use SNS for fan-out pub-sub, SQS for point-to-point queues
• Long polling with 10-20 second wait cuts API calls and costs
• Delete messages only after processing succeeds, never before
• Tune visibility timeout above your p99 handler time to prevent duplicates
• Store messages larger than 256KB in S3, send S3 pointer in the queue
• Use DLQ with redrive policy to catch poison messages and prevent infinite loops

Secrets Manager & SSM

• Use TTL-based in-memory caching to avoid latency and API throttling on every secret fetch
• Log secret ARNs only, not values, to prevent credential leaks in log aggregators
• Parse SecretString JSON once at startup and cache it in memory for the process lifetime
• Prefix secret names with environment variables like /app/${ENV}/db to avoid prod-dev mix-ups
• Choose Secrets Manager for rotatable DB passwords and API keys, SSM for cheaper configuration
• Apply IAM policies at the ARN level per secret, never use wildcard secretsmanager actions

google-cloud & azure-sdk

• Connection strings in git grant full storage access; use managed identity instead
• GCP uses ADC or service account JSON; Azure uses DefaultAzureCredential or managed identity
• Sync SDKs block async event loops in FastAPI; use threadpool or async-compatible clients
• Install only needed SDK packages to keep Lambda layers slim
• Use shared wrapper helpers for different pagination APIs across providers
• GCP and Azure RBAC roles differ from boto3 IAM patterns; verify role mappings

Credential & Session Patterns

• Pass all three fields (access key, secret, token) to Session for temporary creds
• Use assume_role to get temporary creds with session token for scoped access
• Never embed long-lived IAM keys in repos - use SSO and roles instead
• Credential sources in order: explicit args, env vars, config file, IAM metadata
• Refresh assumed role before expiry to avoid ExpiredToken errors on API calls
• Use separate profiles for prod and dev to prevent changes to wrong account

Retry, Pagination & Throttling

• Set botocore Config retries mode to standard with max_attempts cap for production
• Adaptive retry mode enables client-side rate limiting under sustained throttling
• Pagination completes when IsTruncated is false; use paginators for complete results
• Cap max_attempts to prevent infinite retries that hang application workers forever
• Add random jitter to backoff to prevent synchronized retries from amplifying throttles
• Raise max_pool_connections to avoid thread starvation in parallel upload workflows

Cloud SDK Best Practices

• Reuse sessions and clients in hot paths
• Least-privilege IAM per workload
• Paginate every list operation
• Never log secrets or presigned URLs at info level