I’m happy to report that just shy of two years after I posted that I’m an AWS Certified Solutions Architect! (Associates level), that I’ve now leveled up to the AWS Certified Solutions Architect — Professional level! As my AWS experience has hit the roughly 5 year mark (and my associates was expiring) it turned out to be an opportune time for an upgrade. There isn’t much I can say that I didn’t say in my previous post — other than the professional level test is much more challenging.

If you work in the cloud, you’ve probably got an AWS account. It’s not just any account though, it’s the magical “AWS Root Account”. With this root user account, you are imbued with the god-like power to create worlds and smite instances. Your power is only limited by the thickness of your wallet (and the built in service limits). Of course such power should be reserved for only the most special occasions which is why the very first recommendation of AWS root accounts is to create an IAM user, then don’t use your root account.

We’re continuing our hat-trick streak of weekly OpsCrash episodes. Episode #3 was recorded on Sunday May 22nd, but the posting got a little delay due to… slackers. We managed to finally limit ourselves to just 23 minutes of witty banter covering the latest in: nano wins at SSH, GitLab love fest, custom ASIC for fun and profit, governments always make the best IT choices, dipping your servers in Ranch, and a special bonus.

There are a lot of container management services poping up these days and right now Rancher is my choice in solutions (for the moment). One of the coolest accessories to go with this container ranch is RancherOS. The OS is purpose built to do nothing but Docker and, in fact, runs the few required system services in Docker as well. Comming in at a massive 27MB (For v0.4), it’s a perfect choice to run in AWS under something like spot instances and autoscaling. However, if you’re properly autoscaling — you need a way for your new hosts to join the RancherOS cluster… which is where user data (aka cloud-init) comes in.

I’m pleased to report that as of Wednesday afternoon I’m an AWS Certified Solutions Architect — Associate. While I’ve been working in/on/around AWS for years now, it’s nice to have the certification that proves I know what I’m doing. Amazon’s testing, unlike a lot of the certifications in tech (I’m looking at you CompTIA A+), is 100% about the real world. While that makes it harder, it makes the testing all the more invaluable.

AWS re:Play. Yes, the outside is a wall of FEU shipping containers. (From @Werner)As expected, AWS re:Invent had more goodies in store for us after the Day 1 keynotes session. Most of the excitement centered around the new product announcements from the Day 2 keynote. The major difference between the two days is that the second day contained a lot more products that were already accessible to the general public (albeit some in Beta). This meant a lot more hands-on time at re:Invent along with more details emerging on a daily basis. Thursday night was also the re:Play party featuring Zedd and possibly the world’s biggest pun about containers.

Today was the first day (sans instructional courses) of the 4th annual AWS re:Invent conference. While I was unable to attend this year, I’ve been eagerly watching the streams and keeping an eye on the news feeds. There have been many product announcements leading up to re:Invent, but the “really good stuff” was kept for today’s keynote. It is my suspicion that tomorrow’s keynote will be even better, so keep an ear to the ground. In the mean time, let’s take a quick look at what was announced today:

During my last few visits to the AWS Popup loft, I really dug into my Amazon Web Services account, especially the billing. My bill had skyrocketed to over $5 a month! What had happened? How did I miss this huge spike in billing? Well, it turns out that a majority of that bill was from AWS Glacier, I must have stuck something in there for safekeeping and forgotten about it.

After last week’s Internet Of Things hack session, I became fascinated with all the fun IoT projects and technologies there are to play with. Everything you do, requires data to go into the cloud, so I figured I’d start there. In the hack series I learned how to push data into AWS Kinesis which is amazing, however it has its disadvantages. On the flip side there is the new AWS API Gateway which I also haven’t spent much time on, so that’s a perfect thing to learn. After some tinkering, I found that while AWS API Gateway -> Lambda -> DynamoDB might sound complicated, it’s actually quite easy.

Over a year ago, Amazon Web Services built their nifty Popup Loft in San Francisco. Since then they’ve hosted a ton of cool events, including a very regular series of all day, hands on labs. The labs are free, everything is provided, even lunch. There’s one critical issue (for most people): getting time off work to go to the lab is hard! Fortunately for me (and several others in the class) I’m between jobs, so I have time to attend and get all educated.

Recently I registered the domain “derp.army” and wanted to host a couple static pages on it, on the quick and cheap. Of course I have a server that works perfectly well, but the less complicated the infrastructure (or the less I have to run), the less headaches for me. The best solution for static websites I know of is AWS S3. Since this is obviously going to be an extremely popular website, we can’t forget to add a CDN in front of it, for that I chose Cloudflare. Here’s how I did it in a few easy steps.

For those of you who might stop by semi-regularly, you’ve not seen me post in about 4 months. In fact, I’ve not regularly posted since January of this year and John has been carrying the weight. Work has “kept me out of trouble” as they say, or more correctly just been insanely busy. When I’m crazy busy at work I don’t have said time/energy to blog… which is quite unfortunate because that is the time when I have the best things to write about.

For the last year or so I’ve been using SendGrid to relay all emails coming from my server. I don’t send a lot of emails through the system; it’s mostly notifications from the blog and a few related automated messages. While I like paid version of SendGrid (which I’ve used at work), the free version is lacking a few features and includes an unsubscribe link on emails which is really annoying. I decided to mix things up a bit and give Amazon Simple Email Service (AWS SES) a shot. Along with SES I wanted to configure all my mail to be signed with DKIM, on my server. I hope the internet continues to allow the anonymity it currently does, but that comes with a price (because people are abusive bastards), and that price is trust. DKIM is like trust, for email!

As everyone knows, today is IPv6 Launch Day, where we (the internet) are supposed to turn on (and leave on) IPv6. It saddens me that I am unable to participate in this launch day by turning on IPv6… because We’ve been natively v6 accessible since June 2011. Even before that, Snowulf & company were accessible via an IPv6 tunnel provided by HE.net.

This morning I received an email from Amazon Web Services announcing the release of Amazon ElastiCache. In Amazon’s own words “ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory cache in the cloud.” At first glance, that sounds very handy to have. After all, Amazon already has DB backends, instances for application front ends, load balancers and remote file storage, really the only part left for a large application is cache. The best part about Amazon ElastiCache, and a very smart thing to do overall, is that it is running Memcache (or at least is Memcached compatible). So I start out very enthused by this prospect, but by the time I get to the pricing section… I’m very underwhelmed.

So last week, I didn’t know a whole lot about IPv6 (backwater hick — slow and behind the times). After spending a long weekend delving into the world of it, I find out that I’m basically on the bleeding edge already… and that makes me sad. How can I go from not even having used IPv6 to the bleeding edge in a few days? As it turns out, there isn’t much of a distance to go.

WordPress being as popular as it is, is a very common target for all sorts of evil and dastardly hacks. As such, you should make sure to back it up on a very regular basis. Sometimes we don’t backup because we’re lazy, cheap, or it simply takes too much work. Well, let me tell you about a way to backup your WordPress easily, cheaply, and completely automated: BackWPup. This is a plugin I found that does one thing, and does it well, it runs backups. You can very easily setup BackWPup to backup your all your WordPress files and database to a file on your server. This is a great start, but not the best idea. Now, for those who aren’t in the “know” the best place to have your backups is “offsite” (or not on the same server or in the same physical location as your original data). This means that after the backup files are created, they need to be pushed somewhere else. BackWPup offers you the ability to FTP said files, but if you don’t have another server…this doesn’t help you much. What BackWPup offers, that is a fantastic feature, is the ability to push to Amazon Simple Storage Service (S3). The basic idea is: “Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web.” Most importantly, it is cheap! It is only 15 cents per Gigabyte/Month.

I’ve recently begun tinkering with Amazon Web Services (specifically their EC2 service) and RightScale. The major difference between these “Cloud” computing platforms and others is that the “instance” (i.e A running virtual machine) is temporary. Once it is shut down, all the data is gone. Additionally, the RightScale (and fairly common) way about going things is to use a “clean” machine image and script the install of the specific packages you need on Launch.