And you are here why?

Many years ago, when I was wood-working, one of my projects was an oak side-table. I spent months on it — hour after hour, night after night, bringing it to the correct finish. There was a kind of zen-like quality to the work, an introspective meditative state that I would be in, that would help ease away the daily burdens and leave me curiously refreshed. Oh, I’m glad I built that table — I still have it — but  the entirety of that experience was about building the table . The journey truly was the reward. And then I think about AWS. The entirety of my DevOps-y life with AWS has consisted of mastering an increasing number of bells and whistles associated with VPCs, ELBs, ECR, ECS, and whatnot. And that’s before you even get to the  Things That Are Not Three Letter Acronyms  like Aurora, Fargate, Snowflake, Aurora, and such-like. And, somewhere along the way, I realized that I had successfully confused the mastering of a complex process with the joy of delivering th...

I’ve written about  Data Transfer Costs  in the past , and how they’re probably the premier source of unpleasant surprises when the AWS bill shows up. There are many many sources for these, but, in my experience, the vast majority of them come down to • Traffic to public IPs, and forgetting that  any  traffic to them, even from your own instances, counts • Static assets on EC2 which you haven’t moved to Cloudflare. Especially when you’ve got videos (ouch!) • Multi-AZ deployments, and in particular, multi-AZ RDS, where every damn write involves data-transfer costs. So fine, you know the above, what’re you going to do about it? You  could  stay on top of it with  Cloudability  or  CloudCheckr  or some such, but this really requires you to  seriously  stay on top of it. And the issue with this i s that relying on always doing the right thing to keep your costs down  will  end up ‘sploding in your face , and pr...

It’s the usual story — you develop stuff on your laptop, deploy on AWS, the costs are  de minimus , until, well, they aren’t. And when they aren’t, boy howdy, do they every shock you! The baseline ways to reduce costs are pretty well known  — make sure you’re using the right instance type, don’t use  io1  by default, serve objects out of S3 instead of EC2, and keep track of your data transfer costs. Ah,   Data Transfer Costs . I really can’t emphasize this one enough y’know? There are  so many ways  that this can nail you • Running multi-AZ RDS? You realize that you’re paying data transfer costs across AZs, right? • Heck,  any  multi-AZ deployment will result in data transfer costs. And yes, that means your fault-tolerant setup • Serving any static assets out of EC2? Like, oh, videos that you forgot to move over to S3 or a CDN? Oh Noes! • Using a public IP, or Elastic IP? Whoops, now you’re paying for the incoming traffic too! • Heck...

From the   AWS S3 documentation , about adding randomness to key-names to avoid “hot-partition” / sharding issues. If you anticipate that your workload will consistently exceed 100 requests per second, you should avoid sequential key names. If you must use sequential numbers or date and time patterns in key names, add a random prefix to the key name. The randomness of the prefix more evenly distributes key names across multiple index partitions. An oldie but goodie, this one is. I’ve been bit by it, on average, about once a year or so.   Shopify got nailed recently too , and a quick Google search reveals that there is a fairly constant stream of people running into this. It’s not just an S3 thing, it’s there in   the docs for Google Cloud Storage   too… The issue at hand is, that is the the type of thing that • you experience rarely,   but • when you   do   experience it,   it hurts ,   but • it’s not the kind of thing that you walk a...

Shiv Manne ran a whole bunch of tests against GPU instances from platform providers like AWS, GCE, Paperspace, Softlayer, etc., and   the results were…interesting . Not surprising mind you, just   interesting . The lede — high end GPUs get very expensive very fast. Yes, they train wicked fast, but the ROI, frankly, sux. In fact, the best deal seems to be to run lower-end single-GPU instances (more info on this   here ). Why single-GPU? Largely because,   right now , support for multi-GPU either doesn’t work, or when it does, seems to be surprisingly inefficient. Go figure! Paperspace   seems to be on the game here, both for costs, and for performance. In fact, if you’re just testing stuff, they’re pretty much your best bet, as seems to be   validated elsewhere   too. And, of course, the obvious remains — AWS is expensive, and GCE is not   . The results are below, but go take a look at   the whole post . Note : There is also  ...

/via https://www.networkcomputing.com/cloud-infrastructure/when-aws-goes-awry/1164227596 Herewith some fairly obvious pointers on what to look at when it comes to reducing your AWS / RDS spend. Instance Size  : Obvious, but is your instance small enough? Or, heave-forfend, big enough? Storage Type  : Obvious, but are you using the right type of storage? Do you really   need   io1 ? Data  : Why for you storing   everything   in RDS? Slap it in S3/CloudFront, and use a pointer! Usage  : aka “Tune your DB”. The correct index might obviate the need for a   db.m4.16xlarge   Archival  : Do you really need   all   that data in RDS? Clobber your old data, once you’re done with it! Data Transfer  : Yeah, here’s where you’ll definitely get nailed. Moving data out of each instance dips into your wallet. That includes backups, multi-AZ, remote transfers, and whatnot. Of the above,   Data Transfer   is on...

A nice overview of   #orchestration , focusing on   #Kubernetes   and   #ECS   at —  https://www.datadoghq.com/container-orchestration/ To summarize • If you are using Kubernetes, you’re probably running short-lived / lightweight containers • If you’re on ECS, you’re probably running long-lived ones — think “standalone app in a container” • Either way, you churn your host VMs once every 10 days (17 for Docker only, 23 for Non-Docker) On a side note, Kubernetes has gone from 30% of Docker environments in Jan to 41% in October It’s, definitely, on a roll…