aluskuiuc

I may have had that one; there was southeast asian writing on a sign and it was Malaysia.

I have a usb-c monitor connection, and of course the usb-c charger - so any third device requires unplugging one of those. In my case that's a usb-c yubikey. That dongle gives me an hdmi port I can't use (HDMI on the 13" pro can't drive a 34" monitor) and a usb-a port I can't use (I was good and got usb-c perpherals!).

It's decidedly inferior in its lack of hubs. If you don't have enough USB-C ports, you're SOL (and given I have a 2-port macbook pro, I feel this acutely).

As a backup for engine failure that could be a substantially safer and cheaper alternative to a second engine.

Also, if the stock doesn't perform well, Amazon will grant you more to keep you in the expected band; but it won't take any away if you are making "more than you should".

Amazon has a target compensation for you for your first 4 years, with a cash signing bonus making up for the lack of stock in the first two years, so it evens out.

Of course the 5/15/40/40 model only applies to your signing; all further yearly stock grants are over the next 2 years from grant time.

Is Amazon Lightsail in Sydney what you're looking for?

I'm surprised the author didn't consider using DynamoDB Streams to replicate to a PGSQL database for the relational queries while keeping the primary key-value lookups on DDB.

I think if your app is a cluster that requires a quorum, 2 AZs just isn't enough - you need to be running in 3 to be tolerant to one going down.

A notable difference is that Azure file shares have a 5 TB limit for the whole share, and a 1 TB limit on the size of any given file [1], while EFS has no limit on the size of the file system, and a 52 TB limit on the size of any given file. [2]

Disclosure, work for AWS.

[1] https://azure.microsoft.com/en-us/documentation/articles/sto...

[2] http://docs.aws.amazon.com/efs/latest/ug/limits.html

At least when I started there the first two years had cash bonuses to make up the target-comp difference before the larger stock vests came in, so it was fairly even.

This is a little disingenuous - that schedule only applies to the RSUs granted at offer sign time. Yearly stock compensation vests over a 2-year period 50/50.

There used to be - unsure if now - some very specific teams (like 2-3 in the whole company) that had to drive in for very specific issues. Basically if you need to get inside the cage in the datacenter where there are credit card numbers.

Amazon generally has a pretty strong remote work culture - I can even get my ipad onto the VPN and SSH around to get my work done.

a Systems Engineer will always be paid 15 to 30% less than a Software Development Engineer at the same level, despite the fact that the skills and duties are not that much different, why?

In the past couple of months this was fixed by the creation of a new role called 'Systems Development Engineer'.

Speaking as someone who just finished a 2-year rotation through Cape Town as an SDE - massive, core parts of EC2 are still there and aren't going anywhere. "not as much EC2 work" is definitely not accurate.

I was an intern in the WinFS team in 2004 - seriously nobody knew what it actually was even inside the team.

The best I could say was that it was a way for lots of applications writing their own complex datastores (like outlook) to share an OS-level platform so that it could be exposed to other applications with a unified API. It was way more a developer tool than a user-facing feature, but that's not how it was marketed.

One of the easiest mitigations to this is to not even create credentials that have access to do anything that could run up a bill in any short amount of time. Between the Console (access protected with an MFA token) and IAM roles, neither you or your application ought to ever have to handle raw AWS secrets.

This post was written a couple months before the c3s were released, I think.

That said; the AWS APIs offer a lot of tools to hand keys to clients with extremely limited scope, both in API access and time boundaries. For example; a game could be given access keys that allow it to write a high score only to a particular row of a DynamoDB table, the one corresponding to that user.

Direct device->AWS use can make a lot of scaling issues very simple without needing a middleman service on every request. However this does not obviate the need for a federation brokering-type service that auths the device, calls AWS to get a time-limited token with permissions scoped just so, and hands that back to the client.

AWS provides Amazon/Google/FB web identity federation for just this use case: http://aws.amazon.com/iam/details/manage-federation/.

If you get a notification that your instance is going to get terminated - then yes, you can stop/start, but then you will lose ephemeral disks (but not EBS volumes). If you get a notification that your instance is just going to get rebooted, then nothing's going to get lost.

As I said above - the terminology can get hairy pretty fast. It's valuable to take stock of what you really need persisted, and what use can be made of 'scratch disks'. Local ephemerals are fast and cheap (included in the price of any instance). They come with the operational overhead of needing to rsync data off of them yourself if you want to retire that instance however.

Eh, don't feel dumb. I can't really claim it's totally unambiguous and not confusing. Rebooting the physical server should only reboot your instance.

I'll pick this comment out of the many to reply to rather than spamming - you do not lose your data when you reboot an EC2 instance. Local ephemeral stores are retained unless you terminate or 'stop' your instance - but a reboot is just fine.

If you look up the public DNS from inside EC2, it resolves to the private address.

It's not exactly the first time, but close - the Simple Workflow Service has client helper libraries for both Java and Ruby.

At Amazon the individual contributor path goes up to level 10 (VP level).