What would make AWS even better

Network Load Balancers supporting security groups.

I've gone through a bunch of audits, and automated scans, and I constantly have to explain this shit, even to AWS Employees.

How it works with ALBs, which do support security groups:

You want to receive traffic on port :443, and allow it to be accessible to the world. You have EC2 instances, and they are listening on the VPC at port :1234

So, you create:

- ALB my_alb which listens on :443, and forwards traffic to tg_traffic

- Target group tg_traffic, which contains the EC2 instances and targets the EC2 instance with port 1234

- Security Group sg_alb, attached to my_alb with two rules:

  - rule 1, inbound, from 0.0.0.0/0:443

  - rule 2, outbound, to sg_servers:1234

- Security Group sg_servers, attached to the EC2 instances with one rule:

  - rule 1, inbound from sg_alb:1234

This makes everyone happy. The rules require that traffic from the internet has to go through the ALB.

Now how it works on a NLB, with the same scenario:

You want to receive traffic on port :443, and allow it to be accessible to the world. You have EC2 instances, and they are listening on the VPC at port :1234

However, NLBs, as mentioned, don't support security groups.

So, you create:

- NLB my_nlb which listens on :443, and forwards traffic to tg_traffic

- Target group tg_traffic, which contains the EC2 instances and targets the EC2 instance with port 1234

- Security Group sg_servers, attached to the EC2 instances with one rule:

  - rule 1, inbound from 0.0.0.0:1234  (not :443, because the NLB translates the port for you, but not the source ip)

...that's it.

However, now every audit/automated scan of the EC2 instance & it's security group is going to see that you're listening on some random port, and allowing traffic from anywhere. This throws errors/alerts all the time. Even AWS's automated scans are throwing these alerts.

When it's an auditor you have to take the time to explain that, no, that's how NLBs work. For automated scans, you have to just ignore the warnings/errors constantly.

If your instance has no public IP associated, then at least only that port is exposed, and traffic does have to go through the NLB.

If for some reason the instance does have a public IP associated, then anyone who can reach the public IP can bypass your NLB.

If you could have a SG attached, then you could force the traffic to go via the NLB and not come direct to the instance.

A lot of Stripe's success comes from their UX and dev documentation. Something AWS struggles with

Amazon is a terrible place to work for your well-being generally (personal experience and data-based). But, 2 weeks vacation only applies to 1st year employees outside of CA.

Seattle dev: 1st year -> 2 weeks, 2-4th year -> 3 weeks, 5th+ year -> 4 weeks.

California dev: 1st year -> 3 weeks, 2-4th year -> 4 weeks, 5th+ year -> 5 weeks.

The audit logging story sucks unless you give them more money to understand the data they are throwing at you. I had a problem recently that was entirely Amazons fault and resulted in a massive increase in billing. I'm still trying to scrape the data together that they want to issue a credit but it's a pain in the ass scouring through all the event logs because of all the internal stuff (do I really need a log entry every time an AWS internal process hits another AWS internal process for data?) polluting the output.

I would feel better about using AWS if Amazon they treated all of their employees properly, including those in the warehouses doing hard physical labour.