Named profiles are a great way to simplify working with multiple AWS accounts and profiles, but it can be a little tedious when it comes to using SDKs and third-party applications that don't provide support for them. awsprof aims to alleviate some of that pain.

Since I personally dislike having unnecessary extras in my URLs, I always avoid file extensions like .html on my sites. This poses a problem with S3, because the built-in request rewrite tools are cumbersome and not overly flexible.

Whenever I push CSS or layout changes to the blog, I like to invalidate my CloudFront cache to ensure the changes propagate near-synchronously. For instance during a new UI update, if a CSS file were to take 12 hours to propagate into the caches, but the layout changes only take 4 hours, there would be 8 hours where the new layout isn't properly styled.

With AWS Auto Scaling Groups, you have a lot of options regarding how you scale, determining instance health, and where and how you launch your EC2 instances. One piece of the auto scaling configuration that I find myself frequently modifying from the default is the Health Check Type.

While deploying Docker containers on Amazon's Elastic Beanstalk is about as easy as it gets, it can be a little tricky to debug the container. For example, you may want to tail the logs, or open a shell inside the container to see what's going on.

A pretty standard setup these days is to have an application deployed on any number of EC2 instances in an Auto Scaling Group, behind an Elastic Load Balancer (ELB). The trouble is, how do you redeploy the application, with zero downtime, across the entire fleet of instances? In addition, how can we do this while maintaining the current number of healthy instances? Depending on your setup, the answer is actually pretty simple.

lambda-uploader is a Node.js module for uploading a source directory to AWS Lambda as a function.

When you're talking about auto scaling your applications, automating everything is key. That includes updating your source code, installing dependencies, starting your web server, etc. In this post, I'm going to walk you through setting up a Launch Configuration for your Auto Scaling Group that does just that.

Often times when starting a project, I want a simple, cost-effective, and custom tailored system for tracking user events. In order to solve that problem, I created Metroid.

Amazon recommends using a properties file to supply AWS credentials to your Java application, and while this is generally the most appropriate way to do it, what happens if you want to dynamically connect to different AWS accounts, or for whatever reason you need to provide the credentials in code?