Are you manually detecting Curl specifically? If I use anything other than Curl, e.g. HTTPie or wget, I get the HTML page, even if I provide an `Accept: text/plain` request header. If I use one of those tools and spoof the Curl user agent string, I get the text/plain response. You should probably just look at the Accept request header, it’s there specifically so clients can tell you what kind of response they want.
This is "ANSI" as in ANSI X3.64 escape sequences, not "ANSI" as in a character encoding. You can output color to curl on an ANSI-compatible terminal but not to something expecting actual plain text like a browser.
I've moaned about this with other CLI tools as well. I wish trend of using RGB values in ANSI escape codes would die because as ugly as the 16*3 colour fields¹ are, they are at least customisable so people can use palettes that suite their terminal and eyesight.
You don't get any such opportunity if the developers hard code the colour values in (and it's worse with a tool like this because you can't even set an environmental variable to change the tools behaviour)
I personally try looking into implementing a curl "interface" to one of my projects, realised that it actually need to check the user-agent (of curl and a plethora of curl alternatives) which I find kind of weird...
Neat! The prices are without currency symbols - I guess it's always USD? Or maybe dependent on the region…? Would be nice if the $ symbol is printed, and even better if I could see the prices of my european servers in european currency - maybe add a param to select the currency?
It would be very helpful if you would support the `Accept: application/json` header. This way, we could use it in combination with jq to do arbitrary filtering:
Anyone who likes to prevent that can submit their site to the HSTS preload list. Chrome, Firefox and Edge use a shared one, the only two relevant other agents (Safari and curl) unfortunately don't though.
Yes, it isn't that hard to support Spot prices but the price change too often so I have to scrape it for every 5 minutes. Right now, I haven't had the automation to run this yet but it's doable and my pain point too =)
Can I be sure that the prices from this endpoint are accurate (i.e. if Amzn changes the prices, this endpoint will reflect that change)?
Off-topic: if I request a spot instance, is there any way (API/cli) to know how much Amzn charges me every hour for that instance?
I've built something like this in the past (I was running a beefy server for my friends, and wanted them to know how much it was costing us at an hourly rate, before they ran it for 3 weeks straight).
It's definitely possible and not very challenging, but the API Documentation for prices was pretty weak when I built it (a year or two ago, written in Go if it makes a difference). The google cloud prices API was similarly gross. It was kinda fun, but I wouldn't enjoy maintaining that code. In reality, it turns out that $/hour isn't a super straightforward metric (there are many dimensions that go into it), so it's not super straightforward to query.
Neat, didn't realize how much the options for ec2 have grown over time. Can those instances with 100Gbps networking actually push that to upstream transit (ie. the Internet)? Or is that mostly for internal network communication between instances and other AWS services?
Nice list. Recently, I loaded all the prices into an Excel document to make things easier for projecting costs and determining prices. I always use the following formula for estimating monthly costs on Amezmo.