A: no, it lives side-by-side with the existing Aurora Serverless, which will still be available to you as "v1".
I've gotten a few questions about Aurora Serverless v2 preview, so here's what I've learnt so far. Please feel free to chime in if I've missed anything important or got any of the facts wrong.
Alright, here goes the 🧵...
A: no, it lives side-by-side with the existing Aurora Serverless, which will still be available to you as "v1".
A: no, v2 scales up in milliseconds, during preview the max ACU is only 32 though
A: yes, unfortunately...
Q: so if you want to avoid cold starts, what's the minimum ACU you have to run?
A: minimum ACU with v2 is 0.5
A: no, it scales up in increments of 0.5 ACUs, so it's a much tighter fit for your workload, so you'll waste less money on over-provisioned ACUs
A: yes, v2 supports all the Aurora features, including those that v1 is missing, such as global database, IAM auth and Lambda triggers
A: yes, but v1 requires a lot of over-provisioning because it doubles ACU each time and takes 15 mins to scale down. v2 scales in 0.5 ACU increments and scales down in < 1 min. AND you get all the Aurora features!
A: yes you can! cool, right!?
A: yes, you probably should, until data API is enabled on v2, otherwise, more connections = more ACUs, it can run you into trouble
@jeremy_daly has written a nice summary post on this too, with a nice experiment on the scaling behaviour of v2, so check it out if you haven't already https://t.co/DIGylN0HFX
More from Software
As the year wrap's up, let's run through some of the worst public security mistakes and delays in fixes by AWS in 2020. A thread.
First, that time when an AWS employee posted confidential AWS customer information including including AWS access keys for those customer accounts to
Discovery by @SpenGietz that you can disable CloudTrail without triggering GuardDuty by using cloudtrail:PutEventSelectors to filter all events.
Amazon launched their bug bounty, but specifically excluded AWS, which has no bug bounty.
Repeated, over and over again examples of AWS having no change control over their Managed IAM policies, including the mistaken release of CheesepuffsServiceRolePolicy, AWSServiceRoleForThorInternalDevPolicy, AWSCodeArtifactReadOnlyAccess.json, AmazonCirrusGammaRoleForInstaller.
First, that time when an AWS employee posted confidential AWS customer information including including AWS access keys for those customer accounts to
Fresh data breach news-
— Chris Vickery (@VickerySec) January 23, 2020
Amazon AWS engineer exposes work-related keys, passwords, and documents marked "Amazon Confidential" via public Github repository: https://t.co/7gkIegnslx
Discovered within 30 minutes of exposure by my team at @UpGuard.
Discovery by @SpenGietz that you can disable CloudTrail without triggering GuardDuty by using cloudtrail:PutEventSelectors to filter all events.
"Disable" most #AWS #CloudTrail logging without triggering #GuardDuty:https://t.co/zVe4uSHog9
— Rhino Security Labs (@RhinoSecurity) April 23, 2020
Reported to AWS Security and it is not a bug.
Amazon launched their bug bounty, but specifically excluded AWS, which has no bug bounty.
Amazon Vulnerability Research Program - Doesn't include AWS D:https://t.co/stJHDG68pj#BugBounty #AWS
— Spencer Gietzen (@SpenGietz) April 22, 2020
Repeated, over and over again examples of AWS having no change control over their Managed IAM policies, including the mistaken release of CheesepuffsServiceRolePolicy, AWSServiceRoleForThorInternalDevPolicy, AWSCodeArtifactReadOnlyAccess.json, AmazonCirrusGammaRoleForInstaller.
Developer productivity, y'all. It is a three TRILLION dollar opportunity, per the stripe report.
Eng managers and directors, we have got to stop asking for "more headcount" and start treating this like the systems problem that it is. https://t.co/XJ0CkFdgiO
If you are getting barely more than 50% productivity out of your very expensive engineers, I can pretty much guarantee you cannot hire your way out of this resourcing issue. 😐
(the stripe report is here:
Say you've got a strategic initiative that 3 engineers to build and support it. Well, they're going to be swimming in the same muddy pipeline as everyone else at ~50%, so you're actually gotta source, hire and train 6, er make that 7 (gonna need another manager too now)...
...which actually understates the problem, because each person you add also adds friction and overhead to the system. Communication, coordination all get harder and processes get more complex and elaborate, etc.
So we could hire 7 people, or we could patch up our sociotechnical system to lose say only 25% productivity to tech debt, instead of 42%? 🤔
By my calculations, that would reclaim 3 engineers worth of capacity given a team of just 17-18 people.
Eng managers and directors, we have got to stop asking for "more headcount" and start treating this like the systems problem that it is. https://t.co/XJ0CkFdgiO
When people often have to spend weeks just to get a local development environment up, there is a lot to improve. \U0001f641
— Daniel Schildt (@autiomaa) December 20, 2020
If you are getting barely more than 50% productivity out of your very expensive engineers, I can pretty much guarantee you cannot hire your way out of this resourcing issue. 😐
(the stripe report is here:
Say you've got a strategic initiative that 3 engineers to build and support it. Well, they're going to be swimming in the same muddy pipeline as everyone else at ~50%, so you're actually gotta source, hire and train 6, er make that 7 (gonna need another manager too now)...
...which actually understates the problem, because each person you add also adds friction and overhead to the system. Communication, coordination all get harder and processes get more complex and elaborate, etc.
So we could hire 7 people, or we could patch up our sociotechnical system to lose say only 25% productivity to tech debt, instead of 42%? 🤔
By my calculations, that would reclaim 3 engineers worth of capacity given a team of just 17-18 people.
