If you missed the first 2 tips, go back and read 5 Tips to Avoid Deadlocks in Amazon RDS (Part 1), and then come back for the last 3 tips on deadlock avoidance. Once again, I want to re-emphasize that RDS is not actually capable of creating deadlocks — it merely reports them from the underlying database engine.

Last week, I wrote A Beginner’s Guide to Deadlocks in Amazon RDS. This week, I’d like to lay out my 10 years of experience about how to avoid deadlocks altogether. Often times, this will be out of the hands of operations people, but you can still move for dev changes based on issues in production. The more knowledgeable you are about deadlocks in general, the more they will lean on you as a resource with wisdom, not a totalitarian barking rules.

Although AWS sometimes feels like magic, it’s just software that controls capacity and allocation on their previously provisioned hardware. RDS is one of the services that can feel especially magic, because of the general difficulty and drudgery required to set up and manage a production database. In a matter of minutes, anyone can have a production database, complete with replication, automatic failover, backup schedules, and point-in-time recovery.

With the recent panic over the zero-day Kubernetes vulnerability CVE-2018-1002105, Kubernetes administrators are scrambling to ensure their Kubernetes clusters are upgraded to a version that is patched for the vulnerability. As of this writing, the minimum versions that have the patch are 1.10.11, 1.11.5, 1.12.3, and 1.13.0-rc.1.

AWS Lambda can use stream based services as invocation sources, essentially making your Lambda function a consumer of those streams. Stream sources include Kinesis Streams and DynamoDB streams. When you allow streams to invoke your Lambda function, Lambda will emit a CloudWatch metric called IteratorAge. In this post, we discuss what this metric is and how to fix it if it’s too high.