Welcome to the 16th issue of Last Week in AWS.
This newsletter is now four months old; if it were a puppy, it would be well on its way to no longer messing inside the house when you’re not home. Thank you all for continuing to read it.
My thanks to Security Newsletter for sponsoring this issue:
When building Last Week in AWS, I find myself going through a lot of sources. Security Newsletter is consistently one of the best I’ve found on all things InfoSec related. If security matters to you, check it out. If security doesn’t matter to you at all, Verizon and the WWE are both probably hiring.
Amazon’s CTO gives an interview about what happens behind the scenes when there’s an AWS outage. While he presents a very good picture, those of us with operational backgrounds can feel the rising sense of panic the technical teams must be feeling at the time. This stuff is hard, and the AWS teams do a terrific job. It’s to their credit that outages are rare enough that they make world headlines when they happen.
S3 permissions are hard– see today’s sponsor message for two embarrassing examples of this. This article takes us spelunking into S3 permissions and how to avoid being next week’s poster child for poor security practices.
Everyone has holes in their knowledge of AWS services– there’s more than a few! One of mine is DynamoDB– I’ve never used it, and thus know next to nothing about it. This article talks about eight keys to success for understanding DynamoDB’s model. I feel less ignorant about it now.
Application developers tend to see the world differently than infrastructure people do, as a general rule. I stumbled across a worthy read on how an application developer sees AWS Codestar.
And on the lighter side, someone on Reddit wants to throw their best friend an AWS themed party. The crowd’s suggestions are hilarious, and well worth the read.
Choice Cuts From the AWS Blog
Introducing Amazon EC2 G3 Instances, the next-generation of GPU-powered instances for graphics-intensive applications – Amazon has announced G3 instances to replace G2 instances. This likely means we’re roughly ten years away from my being able to make a “Like a G6” headline.
Elastic Load Balancing: Support for LCU metrics on Classic Load Balancer – Amazon is introducing new metrics for ELBs– it allows you to do an apples-to-apples comparison to see if it’s cost effective for you to migrate your existing elastic load balancers to the newer application load balancers. See the Tip of the Week below for more on this.
AWS Adds 12 More Services to Its PCI DSS Compliance Program – Many services were added to the PCI approved list. You can safely now trust cardholder data to Lambda and its “best effort” SLA. While your customers may be enraged, your PCI auditors won’t be.
AWS Database Migration Service Adds Support for AWS CloudFormation – You can now provision Database Migration Service resources via CloudFormation. For every great use case here, I can think of six terrible ones that will destroy your company if misused. Have fun!
New – Target Tracking Policies for EC2 Auto Scaling – Toss another item in the list of “things that can trigger autoscaling.” This should deprecate a huge number of internal scripts that people have thrown together over the years to implement versions of this.
Guest post: How EmailOctopus built an email marketing platform using Amazon SES – This one’s near and dear to my heart. SES offers great primitives, but for even marginally complex email efforts (including, say, a weekly AWS news roundup) it doesn’t go far enough. There’s a reason I pay Drip rather than trying to wrangle this monster myself!
Amazon CloudWatch Events now supports AWS CodePipeline as a target – This is a big deal– you can trigger deploys based upon CloudWatch events. I still haven’t managed to wrap my head around all of the possibilities, but “rollback when error rates exceed certain thresholds,” “needlessly complex autoscaling models,” and “deploy a ‘closed for cleaning’ static page instead of your site when the monthly bill exceeds a certain point” are all possibilities.
Automated Device Testing with AWS Device Farm and Jenkins – A perennial favorite in the “does this service exist, or is AWS just messing with us,” Device Farm gets tied to Jenkins in a guide to how to integrate one of AWS’s most ridiculous services.
An opinionated CloudFormation stack builder comes from Remind. This is handy to wrap CloudFormation with if you want a scalable management solution past the ones AWS gives you.
AWS Community Hero Eric Hammond wrote and maintains ec2-consistent-snapshot, which is surprisingly handy if you’re snapshotting filesystems that contain things you want to make very sure are consistent– such as databases.
Tip of the Week
Assuming us-east–2, classic load balancers cost $0.025 per hour per load balancer, plus $0.008 per GB of data it passes. This is relatively straightforward.
The newer “Application Load Balancers” cost $0.0225 per hour per load balancer (hey, a slight discount!), plus $0.008 per LCU hour. What the heck is an LCU?
One LCU is the first one of these to be hit:
- 5 new connections per second
- 3,000 active connections per minute
- 2.22 Mbps (which translates to 1GB per hour)
- 1,000 rule evaluations per second
As a result, the answer to “what will my load balancer cost me if I convert it to an ALB” has been “absolutely nobody knows.”
That changed last week. If you pull up your legacy Elastic Load Balancers, there are new metrics in CloudWatch for them, including “Estimated ALB Consumed LCUs.” This is important– multiply that number by $0.008, and you’ve solved for the LCU portion of the projected charge. Add in the number of hours you’re running it for, and you can now finally do an apples to apples comparison to figure out whether an ALB conversion makes economic sense.
…and that’s what happened Last Week in AWS.