feat(bedrock): add s3Location support for document, image, and video sources

[strands-agent]

Description

Adds support for using S3 URIs as sources for documents, images, and videos in Bedrock model requests. This enables users to reference large files stored in S3 instead of embedding them as bytes.

Changes

1. Document source: Now supports s3Location in addition to bytes
2. Image source: Now supports s3Location in addition to bytes
3. Video source: Now supports s3Location in addition to bytes

Usage Example

from strands import Agent

agent = Agent()

messages = [
    {
        "role": "user",
        "content": [
            {"text": "Summarize the following PDF."},
            {
                "document": {
                    "format": "pdf",
                    "name": "document-pdf",
                    "source": {
                        "s3Location": {
                            "uri": "s3://my-bucket/documents/report.pdf",
                            "bucketOwner": "123456789012"  # optional
                        }
                    }
                }
            },
        ],
    },
]

result = agent(messages)

Backward Compatibility

When both bytes and s3Location are provided in a source, bytes takes priority to maintain backward compatibility (as tested by test_format_request_filters_nested_image_s3_fields).

Related Issues

Closes #1482

Type of Change

New feature

Testing

• Added tests for s3Location source in documents
• Added tests for s3Location source in images
• Added tests for s3Location source in videos
• Verified existing test test_format_request_filters_nested_image_s3_fields still passes (bytes takes priority)

Checklist

• I have read the CONTRIBUTING document
• I have added tests that prove my fix is effective or that my feature works
• My changes generate no new warnings

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/strands/models/bedrock.py	80.00%	0 Missing and 3 partials ⚠️

📢 Thoughts on this report? Let us know!

[dbschmigelski]

These are all breaking changes moving from required to optional fields. We'll need to discuss this as a team if this is an acceptable breakage. As of now, I am not inclined to merge this.

[strands-agent]

Thank you for the feedback @dbschmigelski! You raise a valid concern about breaking changes.

Changing bytes from required to optional is indeed a breaking change for type checkers, even if runtime behavior remains compatible.

Options to consider:

1. Keep bytes required, add s3Location optional - No breaking change, but users must provide bytes even when using S3

2. Create separate types - e.g., BytesDocumentSource and S3DocumentSource with a union type

3. Versioned type migration - Add new types with deprecation path

I'd lean toward Option 2 (separate types) as it provides better type safety and clearer intent. Option 1 would work but feels awkward for S3-only users.

Happy to revise the PR based on team discussion. Should I wait for async feedback here or is there a preferred way to engage on design decisions?

🧬

---

🤖 This is an experimental AI agent response from the Strands team, powered by Strands Agents. We're exploring how AI agents can help with community support and development. Your feedback helps us improve! If you'd prefer human assistance, please let us know.