This must be one of the greatest presentations on the Amazon AWS that I’ve ever seen. It uses a gradual approach – from small and simple to huge and complex. It covers a whole lot of different Amazon AWS services, how they compliment each other, at which stage and scale they become useful, and more.
Even quickly jumping through the slides gave me a lot to think (and Google) about.
This Hacker News thread is full of tips, tricks, and references to reducing Amazon AWS costs. There is plenty of good advice from cleaning up the data and releasing unused resources, to monitoring the reserved instances usage, to moving data from elastic volumes to the Amazon S3 for cheaper storage and smaller traffic bills.
“Persisting state between AWS EC2 spot instances” is a handy guide into using Amazon EC2 spot instances instead of on-demand or reserved instances and preserving the state of the instance between terminations. This is not something that I’ve personally tried yet, but with the ever-growing number of instances I managed on the AWS, this definitely looks like an interesting approach.
I found this visual primer to the Application Load Balancing on the Amazon AWS quite interesting. Application Load Balancing is not something I am using just yet, but it’s getting there. With more and more services and pricing schemas available from Amazon, explaining things simply is not as easy as it may seem.
“How we designed our Kubernetes infrastructure on AWS” is a case study of how Atlassian (the kind people behind BitBucket, HipChat, Jira, and a few other popular tools) setup their infrastructure on Amazon AWS.
With all the popularity of the cloud in general and AWS in particular, there is still not enough articles like this one.
AWS Blog lets us know that Amazon has finally implemented one of the most useful features ever – descriptions on Security Groups rules. Previously, one could provide a description to the Security Group only, for example: “Proxy Server Access”. Which wasn’t very useful, as it was almost obvious. But now one can add a description to every rule inside the Security Group. So when you have a Security Group with a bunch of IP address ranges, you can now describe each one of them. For example: “HQ Office”, “UK Office”, “Boss At Home”, etc.
As someone who went through a whole pile of trying and error with Amazon AWS, I strongly recommend reading anything you can on the subject before you start moving your business to the cloud (not even necessarily Amazon, but any vendor), and while you have it running there. “The AWS spend of a SaaS side-business” is a good one in that category.
5 Fancy Reasons and 7 Funky Uses for the AWS CLI has a few good examples of AWS CLI usage:
- AWS CLI Multiple Profiles
- AWS CLI Autocomplete
- Formatting AWS CLI Output
- Filtering AWS CLI Output
- Using Waiters in the AWS CLI
- Using Input Files to Commands
- Using Roles to Access Resources
There also a few useful links in the article, so make sure you at least scroll through it.
I think I’m giving up on even knowing the list and purpose of all the Amazon AWS services, let alone how to use them. Here’s one I haven’t heard about until this very morning: AWS X-Ray.
AWS X-Ray helps developers analyze and debug production, distributed applications, such as those built using a microservices architecture. With X-Ray, you can understand how your application and its underlying services are performing to identify and troubleshoot the root cause of performance issues and errors. X-Ray provides an end-to-end view of requests as they travel through your application, and shows a map of your application’s underlying components. You can use X-Ray to analyze both applications in development and in production, from simple three-tier applications to complex microservices applications consisting of thousands of services.
J Cole Morrison wrote an excellent guide into AWS IAM policies. It’s super useful for anyone who have tried implementing IAM policies and failed (or even barely succeeded).
What is an AWS IAM Policy?
A set of rules that, under the correct
conditions, define what
actions the policy
principal or holder can take to specified AWS
That still sounds a bit stiff. How about:
Who can do what to which resources. When do we care?
There we go. Let’s break down the simple statement even more…
Compared to all the AWS documentation one has to dive through, this one is a giant time saver!