Hacker News new | past | comments | ask | show | jobs | submit login
Amazon Web Services in Plain English (expeditedssl.com)
1479 points by ins0 on Sept 11, 2015 | hide | past | favorite | 223 comments

Hey HN, I wrote this, thanks for all the feedback. In particular if I've mischaracterized the functionality of a service or you see something that's really off please email me at mike@expeditedssl.com or just tell me here and I'll fix it.

I would have preferred if some of the full comedic ones were toned down because this has some use. The amount of AWS services is hard to keep track of, especially considering when they have a bunch of slightly different solutions to a similar problem, is quite staggering. E.g. I want to deploy my code - should I use Ops Works, Pipelines, CodeDeploy, Ec2 Container Service, Elastic Beanstalk, Elastic Breadstick, CodePizza, blah blah blah?

> SWF -> Amazon EC2 Queue Use this to Build a service of "deciders" and "workers" on top of EC2 to accomplish a set task. Unlike SQS - logic is setup inside the service to determine how and what should happen.

I do not find this one to be that helpful, as "deciders" and "workers" doesn't make sense in this context. Logic isn't encapsulated inside of SWF, and the workers do not need to be hosted on EC2. SWF basically tracks workflow and activity versions, and is essentially a state management and work distribution system. It distributes out tasks to polling workers based on what the workers are polling, and what state is currently in SWF.

I think a (possibly) better name/use this to would be Amazon Task Orchestrator/Schedule and run jobs that do a bunch of things in order that can be distributed, where you want to run the workers on either EC2 or your own machines.

Ok, maybe not too much better, but I think it shows the use case a little bit better.

I'm going to start saying Elastic Breadstick and see if my PM starts using the phrase to solve everything. He likes buzzwords.

It comes with Marinara Memory Management -- MMM


I'd considered calling it "Amazon State Machine" - better?

I'd say that is better than what I came up with.

I really like this concept of a product TLDR. It reminds me of https://tldrlegal.com/. I wish these sorts of summaries were available for other software products and services. It would help when trying to get a simple understanding of all the buzzwords that I can't keep up with without having to read pages of documentation or look at examples.

Hi Michael! Great guide. SNS is not just for mobile app developers and should probably belong in the "Web Developer Services" section.

It is a general messaging service and can deliver messages to SQS, AWS Lambda, email and arbitrary HTTP(S) endpoints.

For example, we have some S3 buckets set up to send an SNS message to an SNS topic on new object creation, the topic then in turn notifies our subscribed HTTPS endpoints by sending the SNS message which we can then parse. You can also connect S3 directly to AWS Lambda so that a new event in the bucket sends an SNS message to a lambda function - which is very handy for doing things such as "server-less" thumbnailing, transcoding, etc etc.

All good points, I think this is where the "plain english" starts to break down and you _have_ to really come to grips with exactly what the services are doing.

I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.

I totally agree with the grandparent comment. We use SNS for a few apps, none of which are mobile apps.

If you want a high level explanation for someone, I'd describe it as Amazon Callbacks. It lets you create callbacks for any action in and across any Amazon web service, where that callback can be in the form of an HTTP post (e.g. back to your web application), email, push notification, etc.

Well you did a fantastic job and I learnt a load. Many thanks.

This is great... well done. Any chance you could side-by-side it with Azure & Google Cloud's offerings? That would be MASSIVELY useful!

Holy Rosetta Stone Grail of Infrastructure as a Service: combine this document, include other provider offerings in the grid matching features, then also include the compatibility list from libcloud (https://libcloud.readthedocs.org/en/latest/supported_provide...) so we can understand how everything can easily be used together.

Sounds like a good fit as an open source documentation project for a dedicated group of platform researchers to knock out collaboratively in a month.

To really "go for the gold" you can add in other abstraction libraries for talking to clouds like http://www.dasein.org/ and https://jclouds.apache.org/

I surprised myself after reading your article by signing up for your newsletter and I can probably count on my fingers without using binary encoding the number of times I've done that based on an HN submission. The article's format is a hard one to sustain across a list that long and stay readable and pulling it off is an achievement. Here's to your newsletter being similar goodness.

Nice list. Disagree with many of them, though.

EC2/"Amazon Virtual Servers" - true today, perhaps. But when EC2 first launched, they were trying hard to sell the "elasticity" and "pay for what you use" aspects, which were unique at the time. There were no EBS volumes, the storage was all ephemeral. While it was possible to use EC2 instances as virtual servers, that was really not what they were designed for.

IAM/Users Keys and Certs - I agree that IAM is a bad name, but it's still useful to distinguish between aws API authentication and other kinds of authentication. Say "IAM" in a conversation and people will immediately know what you're talking about. Say "Users, Keys and Certs" and you'll have to keep distinguishing between certs for your websites, OS host keys, and that kind of thing.

S3/"Amazon Unlimited FTP Server" - Sorry but this one would just be very misleading. S3 is not an FTP service it is a distributed object store.

VPC/Virtual Colocated Rack" - Again I think using words like colocation and rack would just be misleading. VPC gives you software-defined networking. I think the real issue here is that amazon missed the mark just a little in the original design. VPC should have been the default mode of operation, where the initial VPC was transparent and got a default name. Not a big mistake in the long run but it did mean they had to deploy and name a new service.

RDS/Amazon SQL - I think "Relational Database Service" should be easily understood by any developer using a relational database. If you don't know that MySQL, Postgres, and Oracle are relational databases, consider this the right time to learn.

SQS/Amazon Queue: "Simple Queue Service" is basically the same as "Amazon Queue" except that it uses the same naming convention as S3 so that it's easily recognized as an AWS service rather than some generic amazon store feature.

Elastic Map Reduce/Hadooper: I think "Map Reduce" is much plainer English than "Hadooper."

CodeCommit/Amazon Github: This would be a blatant trademark violation. Also implies that it's less "plain English" given that Github is a proper noun and not a straightforward description of a service. I don't love "CodeCommit" but can't immediately think of anything better.

> S3 is not an FTP service it is a distributed object store.

Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized.

And it's hard to see how it's "distributed" when your bucket price varies "based on the location of your bucket" as Amazon puts it.

It's probably more redundant than FTP, but saying S3 is like FTP is a reasonable shorthand and cuts through a lot of the marketing BS.

The only real resemblance at all to FTP is that you use GET and PUT instead of filesystem commands. I mean, I guess if you really don't understand what FTP is and have no desire to understand how S3 is different from posix, then saying you have to use S3 like you use FTP kind of works. But it would be misleading to everyone else.

> It's probably more redundant than FTP

FTP is a transfer protocol, it says nothing about redundancy of the data on the back end. You could put an FTP server in front of an ext4 filesystem, and NTFS filesystem, an NFS mount, or maybe even S3.

Using FTP as shorthand is better than "Object Store", which sounds like the marketing BS this is designed to avoid.

FTP implies a specific protocol.

"File Server" or something like that would be better. You're quite right that "Object" is worthless terminology in this case - "Object" is basically nerdspeak for "thing".

It's not worthless terminology. It's a term that was chosen along time ago to distinguish this kind of storage architecture from filesystems and block devices: https://en.wikipedia.org/wiki/Object_storage.

This is a common issue in computer science and software development. Whenever new concepts are discovered or developed, they often need new names. You need to pick something that will distinguish this new concept from existing technologies. For laughs (kind of), look at configuration management software (Chef, Puppet, Cfengine, Ansible). They all quickly discovered that there were a whole bunch of new concepts that needed names, and while in some cases this hints that maybe these tools a bit over-engineered, it's hard to deny they've been popular and useful. Regardless, they all encountered these new concepts around the same time and they all made up their own names for them. So in chef you have cookbooks, where ansible has roles. Chef has roles where ansible has playbooks. Ansible has modules where puppet has providers and resource types. Ansible has tasks which are basically components of what chef would call a recipe and puppet would call a manifest.

All in all, I think "object storage" is a pretty fair term for the concept of a data store that neither heirarchical or sequential.

FTP is a terrible shorthand because it's confusing and archaic. S3 doesn't even natively support FTP.

Calling it a "file server" is way more reasonable.

How is "Object Store" marketing bs? What is the proper term for an S3 object? It's not file, because file is a term that comes from the context of a filesystem, which is what S3 is not.

Read the S3 docs: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects....

That is the technical term they've chosen to describe the key, its value, and all its associated metadata. As far as terms go, it's rather straightforward, in my opinion. They probably didn't use "file" because that usually implies a filesystem, which is specifically what S3 is not.

Also, go ahead and check out the history of the term "Object Store": https://en.wikipedia.org/wiki/Object_storage

So when I download a file from a website, I'm not actually downloading the file? Since it doesn't become a file until it gets flushed to disk by my browser? So what is the name for the sequence of bytes that are actually downloaded?

So what is the name for the sequence of bytes that are actually downloaded?

If you explicitly requested your browser to create a file, then it could be any kind of data. If the web server triggered the download, your browser probably saw an HTTP header like "Content-type: application/octet-stream"

I will admit that there is an abstract concept of a "file" that exists outside the restricted realm of a "filesystem," but that's not amazon's target audience. Their target audience are programmers using APIs.

To a normal person, MySpreadsheet.xls is considered a file, no matter where it is stored. But S3 is not limited to this definition of file. An S3 object does not have to be a file in the sense of an excel spreadsheet or digital photos from your friend's wedding. An S3 object can just be a sequence of random data, which would be called a file if stored as ".dat" in a filesystem, but is not considered a file in the same abstract sense as a Word Document.

From a programming perspective files tend to come with a number of traits, like options for sequential access, random access, or appending. A file can often be modified without re-writing the entire thing. When you are programming with S3 objects, the only way to "append" something is to GET the object, retrieve the value from the object, append the data to that value, and then use PUT to upload entire object back into S3.

In this way, it is similar to FTP, except that FTP is most definitely about files and filesystems. S3 is not just for downloading files, but for retrieving any kind of data, usually directly into an application.

Given that S3's target audience is software developers, the programming version of the term "file" is more appropriate.

Your distinction well-noted, a file server still makes a great name for the service, considering its end purpose is serving files, and the fact that it's a "service" implies an interface of sorts apart from a standard file system.

It would except for the fact that "File Server" has been a commonly used term for a long time that hadn't ever been previously used to describe the technology that S3 actually is: an eventually-consistent distributed object store with a simple network API.

It's not like "Simple Storage Service" is weirdly obscure or anything.

I'd say you don't really download the file, you render it in a browser via the http protocol. Downloading implies you have a local copy of the html file or js or whatever.

Object store is what it is...FTP would be marketing BS implying something that the service isn't at all.

File store? I agree that "object" makes no sense when applied to S3. It's not like you can store an "account" object and call a method to get back the current balance, with accrued interest for the time since last deposit added in. Or even store an image and call a method to get back a black-and-white version. Etc.

IMNHO "File server" implies it exports an actual file-system, and would also be wrong. In that light, I think S3 is more like FTP than a "file server". Sure, it might technically be more like WebDAV than FTP, perhaps "FTP-like service using HTTP for transport" is more accurate -- but I'm not sure it's better than just calling it FTP...

> I agree that "object" makes no sense when applied to S3. It's not like you can store an "account" object and call a method to get back the current balance, with accrued interest for the time since last deposit added in. Or even store an image and call a method to get back a black-and-white version. Etc.

Well, yes, they aren't OOP objects. But as you say, "files" isn't great either. But it was a theoretical alternative. For example, you could do a search/replace on the S3 docs here: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects...., and they would still make sense.

But FTP isn't even close. You could not find/replace "Object" with "FTP" without making those docs completely incoherent.

> But FTP isn't even close. You could not find/replace "Object" with "FTP" without making those docs completely incoherent.

That's the wrong comparison though. You could replace all instances of "S3" with "an FTP server" and it would make a ton of sense, minus the reliability claims.

No, it wouldn't make any sense at all.

Amazon Unlimited FTP Server is a simple key, value store designed to store as many FTP Servers as you want. You store these FTP Servers in one or more buckets. An FTP Server consists of the following:

You could use a mix of "FTP Server" and File:

Amazon Unlimited FTP Server is a simple key, value store designed to store as many files as you want. You store these files in one or more buckets. A file consists of the following:

Note that this is essentially redefining the word file to include S3-specific metadata.

Hah...I mean I think it's a bit arrogant for OP to try and rename all of a company's services. Sure some of them are confusing and could be named better but Amazon is a trailblazer here with lots of these services becoming available on a cloud.

"S3 - Simple Storage Service" describes pretty well what the point of the service is without making strong claims around what it may or may not be. It's a service for storing things; it's not a database or a filesystem. The devil is in the details of course but even when I was really new to cloud services I got the gist of what S3 was supposed to do.

> Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized.

It's not "Amazon's language"...your thinking is too programming-language-centric. Object has a much more general meaning. Amazon didn't invent the term blob (binary large object) and S3 is basically a blob store.

FTP is File Transfer Protocol. S3 is not for transferring files and it's not a protocol. It's a file bucket or object store is appropriate. I use S3 to store static content and then use Cloudfront as my CDN. I think comparing it to FTP is rather confusing to say the least. Static content includes things like html, css, javascript not just jpgs or what have you.

How about "Web File Server"? I think mentioning "FTP" in the "It's like" column is reasonable, but I thought it was confusing in the name.

Yeah I have no problem with drawing some comparisons to FTP. It's definitely like FTP in the sense that there's this step where you have to get the data you want to deal with then put it back; but that's really where the similarities end.

Maybe Simply... "Amazon File Server" ?

The main problem with that is that virtually all of Amazon's original target audience would have seen "Amazon File Server" and assumed it was a "File Server" like every other "file server" they'd ever heard of, which either exported a file system such as NFS or Samba or used ftp or http to serve files-- and in the latter case, calling it a "file server" rather than an ftp server or web server would be rare.

Since S3 was none of those things, they needed a different name.

Well done, as a front end developer I find this tremendously useful. Could you go even deeper and describe various components of some of the services? What is a bucket and what is an instance? etc. Thanks

The plan is to go back through and start doing a similar "plain english" post about each of the services. If you're interested in getting those, please drop your email into the little newsletter form on the page.

A great addition to this would be simple, real-world examples of how you may use each service. Build up to a more complex stack by evolving the use of each in iterative layers....

I'd like to help contribute to this if possible.

I did :)

Would love to hear by what % your revenue increased today (or in the next month or so from lag time)

We don't actually have an AWS product released yet. This article was part of our becoming more familiar with all the different aspects of AWS (like a lot of other developers we're long time users of S3 and EC2 and PAAS services built on top of parts of AWS).

Thanks for the document, it's fantastic. One thing that would help for me would be spelling out what the actual amazon acronyms mean. For example: EC2 - Elastic Compute Cloud. Also a link from the amazon acronym to the official page at amazon would be helpful.

I'm kind of in love with you after writing this. Thank you for doing what so few product and service companies do: naming a product in a manner that makes it almost instantly-understandable as to what problem it solves.

This should be "product management 101" type of doc that all product managers should need to make for anything they are managing the evolution of.

Your list was discussed extensively in the office today and everybody loved it.

Having just come off a stint with Azure, my experience with generic names (like many you suggested and like most Azure service name) is that they're huge negatives. It makes searching impossible even when you're using the service's documentation. Got a problem with Azure Web Apps? Good luck searching for it. What about Azure SQL Database? Or Azure Virtual Network? Azure Storage?

This is great! One nitpick: I wouldn't say that SQS is like Sidekiq. Because sure, part of Sidekiq is a queue (in Redis), but the more important aspect of Sidekiq is the workers that operate on the queue. If you needed a second example I'd have gone with ZeroMQ.

Cognito is probably more like "oauth and backends for your apps"

My primary understanding of Cognito was that it was a great way to turn social or developer login into temporary AWS credentials with a specified role, allowing AWS apis to be safely used client side.

Personally I find that Cognito is a great name, which represent well the big picture and challenge ls of identity issues.on the web.

Disclosure : I am Founder of oauth.io to what Cognito is compare.

About Cognito, now I can understand what they are trying to mean.

A good read and helpful list.

Could you add the pricing model and notes? It seems to me that the pricing infos are always hidden somewhere and very hard to find out until you actually used them.

Thanks dude - finally one place where I can quickly understand everything Amazonian!

I think you misspelled "ingest" ;)

What's amazing is the amount of services Amazon offers.

Whenever I look at my AWS console I see these reems of badly named services and I think to myself

   "after I've dealt with the current problem for which I've logged in AWS,
   I might get to figure out what all that other stuff actually is". 
However, I never do because there is more stuff to take care of, and since AWS doesn't make this easy to understand, you just don't bother. Now I know that AWS actually has some really useful stuff, and for things I would never have considered using Amazon for, like video processing (Elastic Transcoder), source control (CodeCommit) and OAuth as a service (Cognito).

They just seem to be bad at marketing their stuff. Here's an example: https://www.google.de/search?q=source+code+repository+online...

Why isn't CodeCommit here on the first page of the search results?

I understand where you are coming from.

I'm just 'starting out' with a lot of this, despite a few years building/hosting websites, and these sort of services are the things I'm starting to look at.

I'm completely disinterested in Amazon's offerings chiefly because they're so obtuse. Why should I expend so much cognitive load just figuring out what each service is and what it could do for me?

It's undoubtedly possible to do, AWS has a hell of a lot of users, but I simply am not going to perform the mental gymnastics to work out what they could do for me, let alone work out the price (which seems cleverly designed to keep the final figure a total mystery).

Maybe I'm too early in my progression to really need this stuff yet ( I probably am TBH) and so I'm not motivated enough to really dig into it, but the point stands - why should I need to be?

Because when you figure out how to use them, you can save a tremendous amount of time and energy, and build sophisticated systems with simple code and little effort. When you have the need in a certain area, a lot of them will feel like "Wow, I didn't know that someone could automate this for me with so little effort compared to doing it myself". Most of it becomes increasingly valuable as you operate larger systems with many moving parts.

These AWS services are each solving a separate problem that people encounter, and usually embody a sort of "design pattern" like a distributed queue, or a load balancer, or a cache. Microsoft Azure and to a lesser extent Google Cloud Platform have similar lists of services (many services, each doing a different thing): https://azure.microsoft.com/en-us/services/

It's really just like figuring out any other software ecosystem, though. If you stacked up a list of open source libraries or commercial libraries in a certain area, I'm sure it will feel the same. For example, so you want to get one application to speak to another over RPC. Well, you could use Apache Thrift, or Google Protocol Buffers, or Cap'n Proto, or Swagger.io, or SOAP or ASN.1 or I'm sure countless other things, and that's simply to perform the same task. What if you wanted a message queue? RabbitMQ, ZMQ, IBM MQ, ... I don't know if anyone has tried to put all of these on the same page and product matrix, or even keep track of them.

There's just a lot of stuff out there to learn and take advantage of. Being an effective software engineer in business is just as much about reusing existing stuff as it is about building new stuff from first principles. I'd say it's actually more about reusing stuff, since all other things equal it saves a lot of time. Don't build yourself or manage yourself what you can use for free or buy unless it's your core competency.

"When you have the need in a certain area..."

I find this is the key to understanding a service, library or technology. It is very difficult for me to wrap me head around something if I haven't yet encountered the problem it solves.

For example, I'm sure Docker is awesome, but I don't really understand it yet because I haven't yet felt the pain Docker takes away. So I enjoy following new technologies, but when I don't really see the point I just assume I haven't experienced the pain the new technology takes away.

Did upvote your sincerity.

I've work with complex and critical linux firewalls, and I love some AWS networking aspects...

Your comment was like a fresh air of sincerity. We all need to deal with domain specific issues. You need to be practical to keep going on.

I know you are right (of course), I just wish is wasn't so much of an upfront cost (cognitively).

I do think the page shared here is fantastic though and has changed my attitude somewhat towards AWS.

Anecdote: after deploying and maintaining applications in Opsworks for a while I feel it's comparatively incredibly hard to do that anywhere else.

The services they offer are great. Remember that you don't have to learn them all at once though. I've worked with amazon services for a couple of years and I still don't know/haven't used most of them. Just use what you need, really.

You shouldn't. I've spent months trying to figure out a few services to launch some apps and it's been a complete and utter waste of time. Yes, there are a lot of services, but the platform is incredibly buggy, the docs beyond unusable and unsearchable, and the customer support extremely slow. Not only that, but you'll get stuck in a proprietary system that's going to charge you many times what more traditional hosting options would. Here's a different experience that's probably very similar to what you'll go through: http://lucianux.com/blog/2015/08/26/aws:-i'd-rather-cut-my-o...

In comparison to... (?) can traditional hosting scale vertically AND horizontally (worldwide)? can it downscale when there is no load?

Love this! Loved it so much I made it into a tampermonkey script: https://gist.github.com/ideasasylum/2d7518611ffaacbc5061

So now my Amazon dashboard looks like: https://dl.dropboxusercontent.com/s/iko1p8jdwdvjpaq/2015-09-...

Nice! You could save a good amount of space in the names by dropping the "Amazon". It's cleaner.

I could but that would involve some editing — I stripped the content directly from the parent post!

Dont forget to also edit your dashboard to exclude anything not in your stack.

"It's like: Stacking cash on the sidewalk and lighting it on fire"

Is an accurate description of a large number of products that I have been forced to use after various CTOs have played golf with a vendors sales team.

I've found that nearly any use-case of AWS is like "stacking cash on the sidewalk and lighting it on fire". It's very overpriced and there's a lot of smoke and mirrors involved in figuring out how much you're paying.

Disclaimer: I work at Linode, but have felt this way since before I started.

Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.

> Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.

To make the analogy accurate:

Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car, hire a driver, find a good mechanic, lease a parking spot, purchase automobile insurance, remember to buy gas, deal with speeding tickets, schedule regular maintenance ....

At some point it makes sense, but it is way, way down the road for most startups.

Empirically I've found that point to be at approximately the $30k/month spend rate (somewhere around 4-5 years in--arguably no longer strictly a "startup"). Of course it's pretty context-dependent, YMMV, etc.

For what type of service though?

Netflix spends millions on AWS -- but it would never make sense for them to do it themselves.

My average was ~$140K per month -- and it would NOT have made sense to do self DC.

Right now, im deploying from DC to AWS and dropping my cost and increasing my performance...

> At some point it makes sense, but it is way, way down the road for most startups.

Thing is, unlike the "get driven to work" analogy, programmers/etc are in the same problem domain as the required services.

It would be like a mechanic taking an Uber to his garage every day because he couldn't be bothered personally owning a car. What?!

"Car leases" (rented dedicated servers [possibly even managed]) are a happy medium everyone should consider.

> Thing is, unlike the "get driven to work" analogy, programmers/etc are in the same problem domain as the required services.

But programmers should be focusing on delivering their startup's unique technology or service, not building and maintaining commodity infrastructure.

Yeah, I agree that initially, startups should focus on building value over lowering infrastructure costs.

But I'm continually embarrassed when companies who raised $100Mns in Series B funding continue to rely on AWS when they could have build out much sooner, and reduced their burn rate measurably.

It is not an accurate description, however, of the economics or value proposition of Direct Connect. When we're moving TB to an off-cloud location it's almost a no-brainer. Similar when latency sensitive.

The highest barrier, quelle surprise, is dealing with interconnect telcos.

Yeah, and at certain data centers it is as simple as ordering a cross connect. There are many AWS services and each have many use cases where the customer is getting an excellent value. Unfortunately, just like deciphering all of the names is very difficult as OP demonstrated so well, understanding the use cases where you can get a good value as a customer is also esoteric and poorly documented. While AWS has pretty good docs in general for each service. Most of the naive implementations presented in tutorials and docs would not be a valuable reason for a customer to use the service. I wonder if documenting this type of stuff better would help them grow the business or if they just don't care and they want to just rip off as many faces as possible. I guess in traditional enterprise software, this is always the role of the consultants / partners rather than the role of the vendor. The vendor sales guy always just wants you to take the license that puts the most money in his pocket and it is up to those partners and consultants to explain to you how to optimize your usage and licensing.

Except that lighting cash on fire would be more fun and take less time ;)

and it gives off heat so has some use.

I know farms of unused servers that provide plenty of heat !

Is that another plain-English name for EC2, as well?

It took me forever to understand what each services aim to do. Like I could have literally been a better programmer by spending all the time learning algorithms instead of figuring out what each of the aws services do. I wish I've had access to this post before.

I like the services they offer, I just really hate the names they gave it. Funny enough, Jeff Bezos said in an interview that names of a product is important #irony

You've got a nasty shock coming then, you'll spend far more time scouring badly written documentation about something that is supposedly simple but just doesn't work and once you've got working you'll never, ever use again until you've forgotten everything and then you need to set it up again and you'll have to go through the whole soul destroying process again but the documentation you find is now out of date, why-god-why, than you ever will implementing algorithms.

In fact, if you spend more than a couple of weeks implementing algorithms in your entire career you're probably doing it wrong or part of the 0.1% of programmers working on low level libraries.

Now re-read your first paragraph in light of the second one.

Sometimes, it really is easier to just implement something your self than go through the "soul destroying process" of figuring out how to correctly set up and configure a library, framework, or piece of open source infrastructure.

Not an algorithm, but it can be a lot easier to write your own SQL, for example, than setting up and configuring Spring and Hibernate. (Talk about soul destroying. Yes, I am a Java developer, why do you ask?)

> Sometimes, it really is easier to just implement something your self than go through the "soul destroying process" of figuring out how to correctly set up and configure a library, framework, or piece of open source infrastructure

But then the next person to look at your code has completely 0 support, rather than the very little support they'd have from the crappy documentation and stack overflow if you used an open source library.

Yes, if you do what jimbokun suggests you're definitely doing it wrong.

Edge cases will consume months of development instead of spending a day or two wrestling with poorly written error messages or badly documented APIs.

The one I always hit in .Net development is logging, log4net and elmah are both abysmally poor at documentation, but incredibly easy once they're actually set up.

I remember making project using spring. I still have night sweats thinking about it. I'm really happy with node and scala play framework

Your first paragraph is a perfect description of working with AWS.

Let me preface this by saying I use AWS only when clients insist on it. I think there are much better options that don't lock their customers in anywhere near to the same level.

I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actual AWS name:

* Amazon Unlimited FTP Server - why? ftp is a transfer protocol. S3 is about storage. It should be called Amazon Storage Server. Which it basically is (Simple Storage Service - S3)

* Amazon Memcached - I don't used the service so I don't know if it's only binary compatible with memcached but if its a generic cache that has multiple interfaces (the page references redis too) then more generic term like cache (and elastic implies it can grow/expand) seems more logical.

* Amazon Beginning Cut Pro - wtf. Transcoding is literally the process of converting a file from one type of encoding to another. That seems to be what this does. Final Cut Pro is not a mere format converter, it's a non-linear editor.

* Device Farm - I'll only concede that maybe this should reference mobile devices, but the name seems pretty clear and concise.

* CodeCommit - how is "code commit" less clear than "github". By this logic, Apple's email client should be called "Apple Outlook" because Outlook was a well known email client on the market.

* EC2 Container Service - the reference to EC2 means its slightly non-obvious, but Amazon Container Service would be much better than something referencing Docker. Docker !== Containers.

* WorkDocs, WorkMail - seriously, you're just replacing "Work" with "Company" here.

* Storage Gateway - what are you trying to be obtuse? From your very description, this sounds like exactly what the name describes - a local gateway to a storage service.

* Elastic Map Reduce - the compute/processing part of Hadoop is Map/Reduce. How is "Hadooper" more clear than the current one?

* Machine Learning - you're just being facetious now, right?

* OpsWorks - again, why does their name have to reflect a single specific implementation of a fairly well understood term(s) - Operations, DevOps, etc??

edit: typos

Yep, a lot of it is "plain English" for the values of "plain English" that include "entirely inaccurate" and "explained in terms of other, just as obtusely named services you may or may not be familiar with".

The idea, though, is great - provide some overview of Amazon's zillions of services that doesn't read like it's been generated by a markovbot. Perhaps the authors will improve the implementation.

What would you suggest as an alternative to AWS?

That's like me asking you "what car do you suggest?" without telling you what I want to use it for, how big my family is, or where I live.

I have no idea what your business does or what services you need, but there are plenty of other vendors from simple rented virtual machines up to full co-lo of customer owned hardware. The good ones will rely on good customer satisfaction rather than artificial vendor lock-in to remain profitable and competitive.

AWS is quite okay, I think, and useful. They even named their free training day as AWSome Day.

> * Amazon Memcached - I don't used the service so I don't know if it's only binary compatible with memcached but if its a generic cache that has multiple interfaces (the page references redis too) then more generic term like cache (and elastic implies it can grow/expand) seems more logical.

Considering all AWS ElastiCache is is "hosted Redis", that one confused me the most. Out of all the AWS services, this is the least 'magic' and custom and easiest to come up with a name.

From memory, when you create an ElastiCache cluster, you have to choose whether it's memcache or redis. It's really just a very thin wrapper around them running EC2 instances in your VPC which are running either memcache or redis.

to add: * Amazon Unlimited FTP Server: you can't really interact with S3 using a ftp client

Both of the most popular FTP clients for Mac and Windows that Ive seen developers using have fantastic support for S3!

http://cyberduck.io https://panic.com/transmit/

That is completely irrelevant.

They also support SFTP, and WebDAV too. Are these protocols all the same thing now, just because some apps support multiple protocols?

How is it irrelevant?

FTP is a protocol, but people use FTP in a variety of wrong but commonly understood meanings:

FTP Server = Hard drive accessible via FTP, not the server on that machine running the protocol

FTP Program = a file-management interface that uses FTP protocol to send commands

HTTP is also a protocol, though 'web browsers' can browse other protocols, as well as offline files.

Saying that an FTP Client that contains support for S3 is a misnomer is like arguing that accessing a file from your desktop using a 'web browser' isnt correct since you arent browsing any web.

The list is aimed at demystifying the confusing terms for the layman, its not aimed at providing the most technically correct taxonomy (since that would also not communicate much to the layman)

When I use my FTP client for SFTP am I using FTP or SSH?

What layman who can't understand ftp is a protocol and doesn't mean any kind of storage, needs to understand the meanings of aws services?

If you're using sftp you're using ssh. It doesn't matter if your client also talks to ftp servers.

Pretty sure CrossFTP supports talking to S3 stores (I use it at work to connect to our internal Ceph Object Store, basically S3)

So, if I understand this right, you're getting really really worked up at a slightly tongue-in-cheek post that tries to explain AWS in a way that's relateable to a lot of programmers. And you're upset because the words used in this post, which is about explaining Amazon's services to people who are familiar with similar services, wouldn't be a wise choice for Amazon to actually use, since it's too familiar with their competition?

That seems silly, and kind of missing the entire point of this submission. I haven't used any of Amazon's services, so having something to translate back to things I can understand was really helpful, and I feel like I have a much better idea of what Amazon offers.

Exactly what i was thinking about as i submited this. Don't read this article as a "They should rename the Services to..." and more like "This name would explain the Service in a simpler form". Thanks for reading my mind btw :)

Simpler or easier to recognise by some, but wrong is hardly better.

I wouldn't call this worked up or upset.

The post claims to have "better hames" for the AWS services. Many of those names are much worse.

Take the suggested "Amazon Beginning Cut Pro" which was their suggestion for "Elastic Transcoder".

"Beginning Cut Pro" is clearly a reference to Apple's NLE, Final Cut Pro. I would suggest that there are literally zero people on the planet, who would use Amazon's video transcoding service (I imagine it's essentially a distributed ffmpeg queue.) to process video files before importing them into FCP.

This isn't "tongue in cheek", this is "stupid and confusing as an attempt at a laugh". I mean, what if I suggested that a hosted Memcached service be called AppStart because it uses memory and Apps use memory.

> having something to translate back to things I can understand was really helpful

My issue is that several of the services covered, already have a MORE MEANINGFUL name. So if I had no idea what "Elastic Transcoder" did, but it was instead called "Amazon Beginning Cut Pro", I would then assume it's somehow a tool meant to work with FCP, and disregard it (I don't need a NLE, at most maybe I need something akin to ffmpeg, so I can transcode/scale video files between formats automatically and efficiently.

If it's comedy, call it comedy, and make it actually funny.

If it's meant to be a useful guide, make it fucking accurate, or it's worse than what AWS is doing already.

I wouldn't want to be around you when you're actually worked up.

I found it both funny and useful. But I can see where you're coming from. If I wanted something fucking accurate that goes into greater fucking detail than 1-2 mostly tongue-in-cheek sentences I'd go to the fucking source.

The fucking source is confusing, remember? This is frankly just as confusing for different reasons. It isn't funny enough to be considered comedy so I honestly don't understand the point.

I have to say that I think "glacier" is an inspired name. It takes a negative -- slow data retrieval -- and turns it into a positive -- indestructible, huge, unstoppable.

I completely agree. It is a great name for the service.

"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." ~ Jeff Atwood

Jeff Atwood did not come up with that quote.

I count 4 hard things there.

When you're building a new app based around a handful of these services, how do you have any idea what it will cost to host your business on a startup? In the past I've avoided using these, and just used VPS servers doing my own thing, because it's really hard for me to, for example, guess how many database queries I'll do or messages I'll send between app components. I feel much safer saying that I can limit myself to N servers with so much memory. How do you make that jump to thinking the other way?

Well, there's a cost calculator that you can use to get an idea (though it requires understanding their services somewhat to put it together correctly): http://calculator.s3.amazonaws.com/index.html

You can also set up billing alerts, though as has been discussed, they aren't strict caps, so you can still exceed your cap.

Spitball some calculations?

You can start with just a few EC2 instances, so conceivably, you could everything on those you'd do with a VPS.

Maybe you decide that managing a database is taking too much of your time, so now you're looking at RDS. It's more expensive, but, it manages just about everything for you. Maybe you make the decision to switch to RDS Now you turn down that EC2 instance running your database.

Maybe now you're thinking that RabbitMQ is too much of a pain to manage, so you do the same thing with SQS. Analyze the time/cost savings of switching, and see if it makes sense.

I think for new applications, estimating is a lot harder, right? You have no traffic until someone is interested in your product, but you can sort of spitball. There's a bunch of free load testing services out there to let you roughly simulate N concurrent users, and open-source projects to simulate those users yourself.

Ultimately, and maybe someone has an idea how to do this: I don't think you can ever plan beforehand. You could be optimistic, and assume your app is going to explode, and that you'll need 8 web servers and redundant load balancers and DB with a read replica... but that's just what it seems like, optimistic. I think the closest you can get is spitballing -- assuming maybe you'll get 100 concurrent users or something -- and making sure you can handle that.

Separately, there's the whole issue of trying to make smart decisions ahead of time with your infrastructure, but similarly, this can be really hard to do.

We all just wing it.

The good thing is that services and charges that are hard to estimate (SQS, egress network bandwidth, S3 access charges) are mostly drops in a bucket compared to those that are easy to plan for (ec2, RDS, S3 / Dynamo storage).

Right. There's a lot of simple choices you can make -- SQS instead of RabbitMQ, ELBs instead of HAProxy -- that aren't going to cut your burn rate in half or anything.

The estimation part is definitely very hard to do for the things you mentioned at the end, especially things like DynamoDB which want you to specify throughput. Not only do you spend time on that, you then spend time on handling when you exceed your provisioned throughput, etc. There's a lot of time spent thinking about shit there.

Anywho, I agree overall. Some of their services just make sense to use because you'll be hard pressed to paint yourself into a corner with them.

I'd say run on Heroku, but IIRC they gave up on their free plan. You could run on Google App Engine though, IIRC they still offer a free service up until a certain number of requests or CPU usage or something in that direction. You could use those to determine how much your application actually uses the service.

IIRC, Amazon also offers services for a fixed monthly price, you could look into that too.

Heroku's free tier is alive and well: https://www.heroku.com/pricing

Sad that this is necessary, but glad someone did it. There are AWS services listed here which — when explained this way — I realize I might want to take advantage of.

I agree. There are some AWS consultants out there telling you what should order from AMZ. At least the billing is easier.

Thank you for this.

I can't wrap my head around why Amazon would make names for some very useful services so inscrutable.

It's like the developers were put in charge of naming everything.

It's like they started to create different products with their own identity and stopped here. Each product has the same doc, same yellow/white/black design, same marketing, but with a special name. So we have nothing to anchor our mind but that. They should continue to do what they were doing and do a whole sub-website for each one of their product with their own marketing identity. It will make more sense for newcomers to wrap their mind and will ease how they should think about them. They should do the same websites than Vault, Consul, Docker with Route 53, S3, Glacier...


I think this comes from considering all those services as separate products. After all, today every product needs a distinguishable name, a logo, etc. /s

To be fair AWS is much, much better than your average 'corporate crap'

Whoa errors!

* S3 is not FTP. It's more like static web hosting and storage.

* VPC is not a "colocated rack" as it doesn't offer physical placement of hardware. Amazon VLAN would be a better name. It's just private network address space.

S3 (or any object store) "is like FTP" has been the best explanation I've used. Way too many people I've talked to think that it's a POSIX-compliant filesystem and "like FTP" is familiar enough to them to know that treating it like a standard filesystem is a terrible idea.

Yeah but just because a flawed analogy happens to work for people who are completely clueless about S3, doesn't mean you should deliberately misname your service to accommodate this lowest common denominator.

I did not read the article as literally suggesting that Amazon change the name of its service, but rather, as a means of conveying the crux of the idea behind the services.

I also did not take this particular description to indicate a literal FTP service.

Analogies do not have to be perfect to be helpful. I've never used Amazon web services, perhaps partly because I found their terminology too obfuscated to bother trying to figure out what it did. Similar services provided by other companies were more recognizable to me for what they were.

I found the post here helpful.

I did not read the article as literally suggesting that Amazon change the name of its service

Neither did I. But it's flawed even as a rhetorical device. For that kind of thing to work for me, it would have to at least be plausible.

FTP is a good analogy. A lot of people are familiar with FTP, and given a good s3 client, it appears the same.

I guess for people who don't understand what FTP really is, and wouldn't find it valuable to understand what S3 really is.

Whoa pedantry.

It's fine the way it is.

No, calling it Amazon FTP would be both misleading and incorrect, and is a very bad idea.

I disagree. It gets the point across to me, and is presented in the right manner for me to not take it literally.

Not to me. The absurd lack of plausibility and simply erroneous analogy makes the whole rhetorical technique distracting and misleading rather than funny and insightful.

You must be fun at parties.

This was orders of magnitude more helpful than the thousands of words that describe AWS on the AWS website. Thank you.

I found this video quite helpful. I hope it will help you.


Excellent! You seem to have overlooked "Elastic Block Store" which should be called "Disk".

I'm not the author of this article, but i tweeted your suggestion to the guys. Thank you!

So many ways to make your software depend on Amazon.

If you make so much money that it really matters if your software depends on Amazon, that is a rather pleasant problem to have. Build it, and they will come.

Seems to work for Reddit, Zynga, Dropbox and Netflix.

Except when they suffer huge outages because of some upstream issue and HN/twitter/etc go stupid with "omg half the internet is offline" because everyone thinks AWS is indestructible.

AWS makes even less sense at scale than it does for small companies. Once you can afford to hire competent Ops staff (and assuming you don't have developers who insist they know everything needed to run a complex system in a high traffic environment, so Ops will 'get in the way') you can get much better results with co-lo or even rented full-hardware, and largely the same Open Source software AWS is built on, but without the confusing naming and vendor lock-in.

"Once you can afford to hire competent Ops staff"

Here, that's the catch. Most companies simply can't. Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.

Plenty of medium sized companies would work out better off overall, with a skilled Ops person to setup cost effective services

> Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.

You don't have to compete. They are trying to make a profit. You just need to be better off, long term. That could be a mixture of lower service fees, more flexibility, improved productivity, less vendor lock in, etc.

Relying on any single company's services, particularly for key/essential systems your business relies on, doesn't sound like a smart strategy.

I don't see how a single "skilled ops person" can deliver "lower service fees, more flexibility, improved productivity". On the other hand, Cloud Computing will, by definition, let you turn on and off services based on business demands. It doesn't get much more flexible and cost effective than that.

"You just need to be better off, long term." - This is a good one. Do you really think your homegrown Docker environment, Hadoop cluster and/or state-of-the-art Cassandra ring maintained by your one and only skilled Unicorn is a better long term plan than 100% managed alternatives? Let's see how well (and how secure) your in-house stuff work 2-3 years down the road and how it will then compare with the always "up-to-date" alternative.

The "vendor lock-in" part is your only valid argument, in my opinion. Costs/benefits will have be weighted properly. How much do you value business agility and pace of innovation vs. increased vendor dependency?

The proper answer will be different for all businesses, but I would argue that as long as a specific IT component/technology is not part of your core business, you might be better off buying it off-the-shelves instead of building it and maintaining it yourself.

Set it up well, and train dev staff to understand what monitoring notifications mean. I mean, you are monitoring your services hosted on AWS right?

Netflix had to go through a massive engineering effort to make their system reliable enough to work on AWS. If they knew what it would take in human and capital investment, they may have chosen to build their own datacenter.

Netflix did have their own data centres. They moved to Amazon to get away from having them.


Really? I thought they shutdown their last home-made datacenter just recently.


Probably avoid using Reddit as a performance metric, they like their 500 errors.

Some of that could be Cloudflare

This is gold.

I wrote a quick and dirty chrome extension that adds these names to the dashboard: https://github.com/pierceg/Amazonese

The Direct Connect description is gold: "It's like Stacking cash on the sidewalk and lighting it on fire"

Pretty spot on...

I laught real hard at that! it's amazingly accurate :)

Awesome. I wish there was a column to tell you Google's version of the same service, where applicable.

The Google names seem to be much closer to the "should have been called" names from the article.

I have started researching both AWS and Google Cloud services over the past couple of months.

My clear favorite is Google. Things are generally simpler (in a good, well-designed way). I get the feeling smart hackers are designing things.

With AWS, the general feeling is that is designed by bureaucrats, the type of people who like big, slow and boring companies.

I can't agree. This is like all those people who wasted money buying shop.com, and tv.com, when all the recognition is in ebay.com and youtube.com. If you listen to people talk about cloud services they say 'competitor-X's S3 clone', AWS owns the terminology.

Also, S3 is NOT some ftp service, it is a new concept. And why should they call Cloudfront instead Amazon CDN? Anyone using it knows what a CDN is and what Cloudfront is? Its like insisting Toyota call the Camry the Toyota Mid Size Car.

Think you took this waaay took seriously ;)

I don't know who you hang around by Amazon does NOT own the terminology. There have been common names for all this stuff for the last 10-30 years.

Amazon invented their own terms out of hubris.

I believe the author was making the point that the names are overly descriptive ("Elastic Compute Cloud" -- not at all innaccurate, but not easy to grok; the less descriptive "Amazon Virtual Servers" is easier for a newbie to recognise and intuitively understand).

Like most entries on the list, Amazon S3 _is_ a new concept but try explaining it to somebody without mentioning FTP -- you'll see what I mean.

What was that quote about the only hard problems in Computer Science?

What differentiates S3 from FTP, WebDAV, or other file transfer technologies?

Wow really? https://aws.amazon.com/s3/details/

Replication, versioning, security, life-cycle management, events to name a few.

Has AWS deprecated any of the services they've launched? If not, isn't that almost unprecedented in the worlds of either enterprise software and SaaS?

They used to have SimpleDB which had been mostly deprecated in favor of DynamoDB.

This is awesome! I spent probably an hour or two yesterday wading through all of it to figure out exactly what each piece does. This make it really clear.

SES is great for newsletters. We use it for that all the time. Not sure why this article concludes it's only a good idea for transactional email.

I agree - I built support for Amazon SES into Dada Mail[0], and allows my users to take a quantum leap from running Dada Mail and using their (not so good) shared host mail servers, to sending via SES. Deliverability and speed goes through the roof and the service is incredibly cheap AND you're in complete control over your own data, as your hosting the app yourself.

[0] http://dadamailproject.com/

Also, original author - are you using confirmation in your email subscriptions? I signed up for your mailing list, and didn't get a confirmation email - it just says I'm subscribed. That's usually not a good idea, as I can put just anyone's email address in there. FYI.

This guide is surprisingly helpful. Oh, but Glacier (not a bad name, actually) should be "Amazon Storage for Backups".

What should Lambda be called?

Ha, I also browsed through the list, curious to find the name for AWS Lambda. Perhaps it's omitted because it is tougher to find a good name? Amazon NoServer Computing? Amazon NoEC2?

Amazon NoEC2 is a hilarious name for lambda

I think it is a pretty strong reference that many programmers understand, and speaks volumes about the execution-model-as-value-proposition: "Just give us a piece of code, we'll do the rest". I'd say it's up there with Glacier and CloudFormation as an evocative product name.

There is a category violation in the name since, arguably, AWS Lambda functions are not true anonymous functions, having ARNs to identify them. If only I could save environment state along with the code function (e.g. for injection of runtime secrets); it'd be AWS Closure.

Amazon Computational Processes.

Thanks for sharing. It's feeling like I've just weared some magic glasses for auto translating.

Thank you, such a great post, I'd like to try getting a certificate from expeditedssl on AWS next.

Some of these names make you wonder if Amazon are more in love with their own cuteness than in actually getting people to use their stuff - "Elastic Beanstalk" FFS? Either way, Bezos should hire the author of this piece and make him product-naming czar.

He really shouldn't. A number of the AWS names are much clearer than the ones he suggests.

Great post some of this stuff has been is a mystery to me. Probably one of the reason I use Digital Ocean. For my personal needs, a simple VM will do and they even let me attach my Keys before instance creation.

The SWF description is pure garbage; it's got nothing to do with EC2, or IronWorker at all. Oddly, I think it's named sanely - it lets you setup and manage a workflow using small bits of code.

Lovely and really helpful. I used some AWS but never fully understand the rest services, Amazon really should have some 101 page for this on its own. Those names are painfully opaque to say the least.

I have always had the slight suspicion that the names for their developer tools are "deliberately" bad. I mean, far easier to replace and supercede "Amazon SZJ" than something generic like "Amazon Messenger". (As an indirect comparison, finding out which generation of "Kindle" I have is quite a challenge)

Yes ! I need Plain-English-As-A-Service or maybe just Amazon-As-A-Service

Why didn't I read this earlier?! I was at an AWS hackathon all day and it was my first time ever using any of their offerings . This would have been super useful.

Nice one: Machine Learning Should have been called Skynet

The fact that their service portfolio has grown so large that you need a guide to navigate through it is very telling. Has AWS grown too vast?

Why do people like to describe services in a complex way? Maybe to seems a more complex product than it really is, or too look like "specialists" speaking about stuff.

This is very common for small companies without marketing experience, but this happening in companies like Amazon and Microsoft (Azure), I can't understand.

A lot of companies have code names for their products, the obvious reason being easy/fast day-to-day communication. IMO this loses its effectiveness when you have a large panel of products, and each one is provided by at least one other company.

TL;DR version: I use "Amazon's <service name>" instead of a code name.

AWS's internal code names are never used for the public services.

"SES: You could use it to send a newsletter if you wrote all the code, but that's not a great idea."

As the co-founder of a startup doing exactly that (https://emailoctopus.com), I respectfully disagree!


How would you describe in a few words (in keeping with the theme of the piece)?

Where's the main danger as you see it

One of the good things about this is that when somebody comes again comparing AWS to any regular ISP's VM we can point at this to show that EC2 alone may not look favourably in a comparison, it's the other services in the vast AWS ecosystem that brings the value.

Would be nice if the services' header linked to the official AWS product page.

DynamoDB is nothing like mongodb. Its more like a key/value database.

Actually we have a lot in common :).

In addition to KV pairs storage, DynamoDB supports querying, documents, indexing and streaming from a feature stand point and infinite provisioning/scaling from a infrastructure stand point. Give it a shot and ping me about any questions!

Now if someone would write a book translating Linux commands into plain English it would be a best seller. Or in other words explain it like you would to an experienced Windows user.

Frustrating for the beginning developer , I could not even clearly see if they had an in-house service ,for image hosting , or is images3 their brand or 3rd party ? . . . !!

This is great. One note: "injest" should be ingest.

I'd like to claim that this was me trying to hide one more joke in post about how the whole thing was just 'in jest' but I actually just messed that up. Will fix.

Love it. Keep it simple. It is too often the case that writes assume their readers have the same knowledge as they do. Always assume your reader knows nothing.

Amazon literally should pay you for this. I will be signing up for some additional services now that I know what they are. Thank you.

Also, love the light application of humor.

Such an awesome list. Really helpful! Thanks a ton!!

It makes me think that eventually technology will be so vast, there will be a need for a 'Google Translate' of such terms.

Possible alternative "should have been called" for Glacier: "Amazon Write Only S3"

Best One:

It's like: Stacking cash on the sidewalk and lighting it on fire

This should bed added as a new language in Google translate.

Lambdas are missing

Is there something like this for Heroku?

Thank you


should have been called: Amazon GitScanner

Use this to: search your online source code repos for injudiciously committed access keys

It's like: Slamming the door in bitcoin miners' faces

I'm surprised they don't offer this actually

They do, but it runs automatically so no need to name the service.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact