Skip to content

AWSLambda: Use shogo82148 as the default image provider#9777

Draft
bblommers wants to merge 1 commit intogetmoto:masterfrom
bblommers:awslambda-make-shogo82148-default-provider
Draft

AWSLambda: Use shogo82148 as the default image provider#9777
bblommers wants to merge 1 commit intogetmoto:masterfrom
bblommers:awslambda-make-shogo82148-default-provider

Conversation

@bblommers
Copy link
Collaborator

Until now we've been using mlupin as the default provider for Lambda images. However, these images haven't received an update in a long time. If users want to use a recent runtime (anything released in the last 3 years), they need to manually configure a different provider.

Most people are probably using shogo82148 as the 'custom' provider, as they have been creating up-to-date images for every recent runtime.

This issue has come up fairly often, and my response has always been: yes, we should change the default, but it's technically a breaking change, so this should happen in a major version bump.

However: the more I think about it, the more I think that the functionality doesn't actually break. It changes, yes - more images are available, and they are more recent. But nothing should actually break, which means that this should be an acceptable change in an non-major release.

The benefit of supporting recent runtimes is also that we can start using the AWS_ENDPOINT_URL to redirect AWS requests from inside the Lambda back to the MotoServer. This wasn't possible with mlupin images, as they contained older versions of the AWS SDK that did not yet support this environment variable.

Our current solution (and recommendation) is for users to have an if-else clause in their AWSLambda. If under test: set the endpoint url to motoserver:5000, else keep it as is. Using the AWS_ENDPOINT_URL means that users can do away with these workarounds. We're using this workaround in our tests as well a few times, which I've removed as part of our PR to verify that everything works as it should.

@bpandola I'm thinking of making this part of an upcoming 5.2 release. Do you foresee any problems with that, things that may break that I'm not seeing?

@bblommers bblommers added this to the 5.2 milestone Feb 22, 2026
@codecov
Copy link

codecov bot commented Feb 22, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.11%. Comparing base (a6b7b4f) to head (bec00ff).
⚠️ Report is 8 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #9777   +/-   ##
=======================================
  Coverage   93.11%   93.11%           
=======================================
  Files        1308     1308           
  Lines      118800   118802    +2     
=======================================
+ Hits       110615   110618    +3     
+ Misses       8185     8184    -1     
Flag Coverage Δ
servertests 28.88% <14.28%> (+<0.01%) ⬆️
unittests 93.08% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@bpandola
Copy link
Collaborator

@bblommers Seems fine to me (although I'm not an expert in this area of the codebase). If I'm understanding the proposed change correctly, I agree that this does not warrant a major version bump.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants