awsthro00945

>It also speaks to inner AWS turmoil at least at DynamoDB.

How? Rick wasn't part of the DynamoDB service team. He wasn't an engineer, nor a manager on the team, nor even a product manager. He was a salesperson that specialized in DDB. He most likely had very little interactions, if any, with the engineering team. I don't see how him leaving speaks at all to anything about the inner workings of the engineering teams.

Rick seems cool, and after skimming some of his chats he seems really knowledgeable about the customer-facing side of DDB, and I mean absolutely no disrespect to him. But I think you're making way too many assumptions about his "rank" and "influence" within the company.

No, I haven't. There are thousands of reinvent sessions every year. I don't watch them all (I don't watch hardly any of them, and most people I know in Amazon watch a couple breakout sessions if that. Some don't even watch the keynotes). Their targeted audience is AWS customers, not internal engineers. Reinvent itself is a sales conference. If internal Amazonians want to learn about something like DDB, there are internal talks and documents given by the engineering leaders that we watch.

>At the same time you are able to this internal lookups?

I looked him up on LinkedIn. Nothing internal about it.

There are over a thousand breakout sessions at every reinvent every year. Some of the speakers are sales people, some are engineers, some are managers. There are L5 or junior engineers who give reinvent session talks. It's a fun gig, but it doesn't mean that the speaker is some top executive or anything like that.

Rich was in the sales org. His primary job was sales. Reinvent is a sales conference. Speaking at reinvent is a sales pitch. He was a salesperson. I'm not sure why you're so offended by that. Being a salesperson isn't bad, it's just an explanation for why engineers wouldn't have heard of him.

I think I've seen you post something similar on r/aws about how Rick was "top DynamoDb person at AWS" (apologies if that wasn't you). I think you are overestimating Rick's "rank".

I just looked him up (I had not heard of him before seeing his name mentioned on r/aws a few days ago) and he was an L7 TPM/Practice Manager in AWS's sales organization. That's not really a notably high position, and in the grand scheme of Amazon pay scales, isn't that high up. An L7 TPM gets paid about the same as, or sometimes less than, an L6 software dev (L6 is "senior", which is ~5-10 years of experience).

Also, him being in the sales org means he had practically nothing to do with the engineering of the service. AWS Sales is a revolving door of people. I mean no offense towards Rick (again, I didn't know him or even know of him before I read his name in a comment a few days ago), but I would not read anything at all into the fact that an L7 Sales TPM left for another company.

>No one uses DynamoDB alone

Almost every single team at Amazon that I can think of off the top of my head uses DynamoDB (or DDB + S3) as its sole data store. I know that there are teams out there using relational DBs as well (especially in analytics), but in my day-to-day working with a constantly changing variety of teams that run customer-facing apps, I haven't seen RDS/Redis/etc being used in months.

In any serious security design, "the attacker probably won't do that" would and should be shot down immediately. If your security strategy is hoping that an attacker will be kind enough to not exploit your open vulnerability, you've already failed at threat modeling and at security.

If an attacker can do it, you must assume they will do it. Because they will. That should be the starting point for any threat model.

"the attacker probably won't do that" is not a security control.

Why are you assuming that a determined attacker doesn't control your L4 stack? MITMs are a threat, your network could be compromised, routers (especially consumer routers) are rife with vulnerabilities. This is the entire reason "zero trust" is pushed.

"My logs and firewall are less cluttered" is not at all the correct metric to measure the security of your box.

IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker.

You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.

That's not the point. There was a selloff in December. How crypto fared compared to anything else at any time period is irrelevant.

Humanity "continuing" or "moving on" naturally due to the passage of time (which will be quite a long time) is a completely different thing than humanity "choosing" to move on. Your original comments imply/ask that humanity collectively "chooses" to move on and stop letting covid affect us, but again, that is simply not possible. It's not something we choose.

Individuals can individually choose to pretend covid isn't a thing, but society as a whole cannot simply choose to suddenly restore our medical infrastructure, fix supply chains, grow the labor market, etc. Covid's effect on those things won't magically go away just because someone says "you know what, I'm tired of waiting on covid! I'm going to be normal now!"

Adjustments to these will happen over time and humanity may "continue", but when that happens is not a choice we make.

You're still not understanding. We are not "waiting". Waiting implies that we are making some type of conscious choice to put things on hold. But there is no choice. We cannot simply choose to stop waiting. We cannot move on until people are vaccinated. We are blocked, not waiting.

I'll say it again: we cannot move on with it until people are vaccinated. It's not a choice. It's not something where we just say "eh well it looks like it won't get better so let's move on". It physically cannot happen.

Financial markets are more than just the SP500. The sentence before that is talking about both stock markets and crypto markets. Crypto (BTC specifically, but also others) dropped ~30% in December.

This is a false equivalency. Being vaccinated or not is the difference between requiring days/weeks in the hospital or only spending 1-2 days with a mild headache. It's "mildly inconvenienced if you do, damned if you don't".

I was at the hospital yesterday (for something unrelated to covid) and there are 0 rooms available. The hallways are still packed with unvaccinated people with covid laying in every open space they can find. Nurses and doctors are still worked past their breaking point.

We cannot move on until the thick-skulled members of society realize that their unwillingness to get vaccinated is the number one thing stopping us from moving on.

It's not that. Like most niche AWS services, this was likely the "pet project" of a major AWS customer that wanted something like this as part of a major business agreement [0]. And then after building it for that customer, AWS also expanded offering it to anyone else who wants to use it.

0: https://blog.maxar.com/earth-intelligence/2018/sending-data-... (posted the same day Ground Station was launched in 2018)

>This a) is not new

This specific announcement is new, because this specific announcement is about Outposts in a new, smaller form factor that just went GA today.

>One use case is wanting to run the same cloud stack globally, but having a market where there is no local region and local law requires that data stay in country.

The use case mentioned in the announcement is more about running EC2 instances in small branch offices or retail stores where you 1) still want to run AWS, 2) need the servers to be in very close proximity, and 3) don't have the room or infrastructure for a full rack.

Newer fabs like this recycle a huge portion of their water. I did some back of the napkin math a few weeks ago and the amount of water that the fab will be drawing (after accounting for the recycling) will be about the same as the water usage of an equivalently-sized suburban neighborhood. So while water usage is definitely a concern, I'm not sure that this fab is a bigger concern than your typical neighborhoods or farms.

I think the closest you can get is using a VPS like DigitalOcean where you pay $X for a server and there's no autoscaling to worry about. But even with those, if you go over the bandwidth limit (although with DO the bandwidth limit is a lot higher) you would be charged more.

The unfortunate reality is that hobby developers that just want to pay $20/month aren't the target audience for GCP etc. They don't really care if you're using them less for your personal hobby projects. They target large enterprises, and those large enterprises would have very little use for something like "cap my spend at $20".

Even as an AWS employee, I sometimes use non-AWS hosting providers for my own projects. Even outside of the billing situation, AWS is often too complicated for my use cases. It's just not targeted at me and my hobby development projects.

disclaimer: am AWS employee but the above is my own opinion and not official position of the company, etc etc.

I think AWS drastically needs to create some type of "sandbox account" flag that severely locks down the services you can use and the amount you can scale up, exactly for reasons like you said.

However, I also think a big problem is that many people on the internet and especially people who try to sell AWS tutorials or learning courses push AWS as some toy that every developer should sign up for on a whim without understanding what they are doing. An AWS account is an industrial-grade tool, it's not a toy, and it should be treated as such. It's like renting a backhoe when you don't even know how to use a shovel yet, and then being surprised when you completely screw up your yard.

Sites like acloudguru that offer ephemeral sandbox AWS accounts are becoming more popular, and people new to AWS should really be steered towards those.

It's stupidly confusing because the regional transfer of 1GB free per month isn't technically part of the "Free Tier" as advertised on this page [0], it's just part of the normal egress pricing model of the individual services [1] [2]. So I guess really this announcement post is misleading/confusing because the regional transfer increase is just a change in the normal pricing model, not the "Free Tier"... but really that's just semantics. AWS really needs to fix the "Free Tier" to make it less confusing.

0: https://aws.amazon.com/free/

1: https://aws.amazon.com/ec2/pricing/on-demand/

2: https://aws.amazon.com/s3/pricing/

You're misreading it. Only some parts of the free tier "age out". Other parts of the free tier are free forever (it's really stupidly confusing). The things announced in this announcement are free forever.

I really doubt proximity to the ERCOT center has anything to do with it. The new facility isn't close enough at all to the ERCOT center to be on the same grid segment. And with a new facility like this that is in the middle of a field outside of town, the new fab will be built on its own grid segment anyway, completely separate from the rest of Taylor and the ERCOT center.

Taylor was chosen because that area (northeast of Austin, just south of Taylor) is one of the last areas near Austin that has abundant amounts of wide open fields ready to be developed. They also got a good deal on the water usage, and of course the tax breaks from Williamson County.

The problem is that your calculations aren't just "grossly simplistic", they completely ignore the cash bonus, which again, is the entire problem. The cash bonus is a core part of the compensation strategy, which means you must include consideration of it in your calculations for them to be accurate, but you did not do so.

Even for the person who receives $150k in RSUs, they are still simply receiving a dollar amount. It doesn't matter if it's in AMZN stock or if it's in cash, because the cash amount and the AMZN stock can be exchanged equally, and B has just the same opportunity for stock growth as A has (because either of them can purchase whatever investments they want with the $150k they receive, regardless of it it's cash or a stock unit). If you aren't considering this, then all of your calculations about "which situation pays more" are wrong.

>The scenarios become endlessly complicated if we consider side investments in individual stocks.

And they become completely useless if we don't consider it. Attempting to simplify your calculations isn't a good reason to make them wholly inaccurate.

They also aren't "endlessly complicated". It's still very simple: any investment opportunity that A has, B also has, because they are receiving the same dollar amount of compensation that can be invested. So when comparing A vs B, there is no difference.

>So a large number of AWS employees may not be receiving 80% of their stocks.

Again, this doesn't matter, because they get cash instead of the stocks.

You are making the classic mistake that many make that imagines that RSUs are fundamentally any different than just receiving cash. But they aren't. Receiving an RSU for $3000 is the exact same thing as receiving $3000 cash and then using it to purchase $3000 worth of that stock. There is a reason that the IRS taxes RSUs vests just like normal cash income.

Your math seems right, but again you're neglecting the $120k cash bonus in your calculations.

>Price of A's RSU on Nov 3 2021 - $3384 * 150 = $507,600 Price of B's RSU on Nov 3 2021 - $3384 * 30 = $101,520

This is the correct price of the RSUs, but again, neglects the cash bonus. If you look at it (more correctly) through the lens of "the amount of compensation given", the price of A's RSU+bonus is $507k, and the price of B's RSU+bonus is $221k (your $101k + the $120k cash).

But! There's no reason that the $120k cash just has to stay cash forever. If you're considering the stock appreciation of the RSUs, you also have to consider the appreciation of what you can do with the cash. For example, if you're one of the Amazonians that just gets the cash bonus all paid up front, then you just take the $120k and buy 120 AMZN stocks to go along with the 30 you were granted as RSUs, and you end up with the exact same 150 stocks ($507k) at the end of 4 years. There's no difference. If you get paid the cash bonus monthly instead of up front, then you would come out a little behind since you can buy less AMZN shares as time goes on, but not as drastically as your numbers make it look.

The RSU vesting schedule at Amazon is nonstandard but it's not an issue. You may only vest 5% of your RSUs in your first year, but everyone is given a significant monthly cash bonus to make up for it. The compensation strategy at Amazon is that you always make the same "target compensation" each year, even your first. You aren't shortchanged just because you vest less RSUs in your first year.

An example with numbers: someone in their third year at Amazon makes $150k/yr salary + $150k/yr RSU vests, for $300k/yr total. In comparison, someone in the same position in their first year at Amazon makes $150k/yr salary, but only makes $30k/yr RSU vests, for $180k/yr total. That seems shitty, right? Except the person in their first year also gets a $120k/yr cash bonus, bringing them up to the same $300k/yr.

I doubt it, considering their point about Amazon (the RSU backloading, not the hire-to-fire thing) is a misconception that only someone who has never worked at Amazon would complain about.

(probably some of the others too, but I only personally know about Amazon)

> if you haven't worked at a place for longer than 3+ years, they want a detailed explanation why.

Interesting. At my FAANG (Amazon) we explicitly are told to not ask this. It would be kind of weird for us to ask that, really, considering the tenure of most people here is <2 years.

I used to agree but after working at Amazon... yes, it really is passed down.

There is still large variation per org/team, but there are definitely a lot of things that can permeate all the way down. The way hiring is done, the way performance is evaluated and promotions/raises are done, the way weekly org-wide metrics meetings are done, the way escalations are handled, even the way we hold meetings or write documents... At Amazon, all of these things are influenced (or directly guided) by processes that are put in place by the highest levels, and they really do have enormous impact on the overall culture of the company.

You shouldn't view the RSUs as different from any other compensation package, even just an all-cash package.

If Google says they'll give you $200k per year in cash + $400k split over 4 years as RSUs, that's the same as just getting $300k per year in cash.

Why would you leave $300k per year in cash on the table? Because another company is offering you $350k per year (or more likely in the case of FAANG, another company is offering you the same $300k/yr but with significantly less stress).