How often should a small SaaS team patch its AWS production?
By the Keel team · Last checked · 4 min read
Short answer
A small SaaS team should patch AWS production on a fixed monthly rhythm, with security fixes done sooner. Let AWS apply the managed parts inside a maintenance window you chose, rebuild and scan your container images every month and on every release, and keep a short log of what changed. The monthly cadence is a sensible default, not an AWS rule, so adjust it to the risk you carry.
30 minutes
Length of an RDS weekly maintenance window
Source: AWS docs, Oct 2026
5
Kinds of scan Trivy covers: vulnerabilities, misconfigurations, secrets, licences and cryptographic assets
Source: Trivy docs, Oct 2026
What do you actually have to patch on AWS?
You have to patch whatever you control: the base images and libraries inside your containers, your application dependencies, and any servers you run yourself.
AWS looks after the layers it manages, but under the shared responsibility model you stay responsible for security in the cloud, which includes your own software.
That split is why a team that has moved to managed services still has patching to do. A managed database patches itself within limits, but a vulnerable library in your own app image is yours to find and fix.
What does Amazon RDS patch for you?
Amazon RDS applies required maintenance to your database during a weekly maintenance window, but only some of it is automatic.
AWS says required patching is automatically scheduled only for patches related to security and instance reliability, while optional updates are not applied unless you apply them.
- The maintenance window is a weekly interval; if an event is scheduled it starts in the 30-minute window you pick.
- If you do not choose one, RDS assigns a 30-minute window on a randomly selected day.
- The window decides when operations start, not when they finish, so they can run past the end.
- Mandatory updates can still be applied outside your window after their apply date.
- The maintenance window and the backup window cannot overlap.
How often should you rebuild and scan container images?
Rebuild and scan your container images on every release and at least once a month, so a vulnerability published after your last deploy does not sit in production for a quarter.
An image that has not been rebuilt still contains whatever was in it the day you built it.
Trivy is a free scanner that can check container images, filesystems and code repositories for vulnerabilities, misconfigurations, secrets and licence issues. It also reads infrastructure files such as Terraform and CloudFormation, so one tool covers a good part of a small team's estate. Run it in your pipeline and fail the build on findings above a severity you have agreed.
Which fixes should not wait for the monthly cycle?
Actively exploited vulnerabilities and anything that exposes customer data should be fixed as soon as you can test and ship the change, not on the next monthly date.
A monthly rhythm is for the steady stream of ordinary fixes.
| What | When | Who |
|---|---|---|
| Critical or actively exploited issue | As soon as tested, same week | Named owner |
| Container base images and dependencies | Every release and at least monthly | Pipeline plus owner |
| RDS maintenance | Inside your chosen window | AWS, with you checking afterwards |
| Optional database and OS updates | Reviewed monthly, applied when tested | Owner |
| Everything else | Next monthly cycle | Owner |
How do you patch production without causing downtime?
Patch without downtime by putting every change through the same pipeline as any other release, with health checks and automatic rollback behind it.
A patched image that fails its health check should never take traffic.
Deployment health checks and automatic ECS rollback from GitHub Actions describe the safety net. Keep database maintenance away from your busiest hours, and take a fresh backup you know restores before any major engine upgrade, as in how to prove your AWS backups restore.
What should a patch log record?
A patch log should record the date, what was updated, who did it, the scan result before and after, and how you verified the service afterwards.
It can be a simple table in your wiki or a ticket per month.
The log is useful twice: it shows a customer's security review that patching is a routine, not a hope, and it lets you work out quickly whether a new vulnerability affected you. How to answer an enterprise security questionnaire lists the questions it helps with.
Can a very small team get monthly patching done without hiring?
Yes, if someone owns it and the steps are automated.
Keel's Startup programme includes monthly patching as part of its foundation-level service for teams of fewer than 5 who are live on AWS with at least one paying customer, alongside a deploy pipeline with rollback, tested backups and monitoring, all in your own account.
Places are limited and awarded on merit, and pricing is agreed on application. If that sounds like your team, apply for a place in the pricing section. If you would rather do it yourselves, the cadence above is a good starting point.
Is your patching routine or accidental?
Tick each item that is true today.
- Someone is named as owner of patching.
- Your RDS maintenance window is set on purpose.
- Container images are rebuilt and scanned on every release.
- Critical fixes have a faster path than the monthly cycle.
- Patches go through the same pipeline, with health checks and rollback.
- A log records what was patched and when.
Decision point: Five or six ticks: patching is a routine. Three or fewer: a published vulnerability could sit in production unnoticed.
Sources
- AWS docs, Maintaining a DB instance (Amazon RDS) (checked October 2026)
- Trivy docs, Scanner coverage (checked October 2026)
- AWS, Shared Responsibility Model (checked October 2026)
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.