Agree WRT network performance, the basic instances are unreasonably slow (only 70 Mbps for a micro), and requiring users to pay for a big 8 core server for wirespeed Gbe, and a huge 40 core beast for 10Gbe (and rather poor 10gbe at that) is totally unreasonable, and borders on price gouging (if such a term can be used for this market sector). The cross-AZ network performance is terrible much of the time, the jitter and loss are unpredictable and often far higher than you'd expect and generally trying to run high performance network services on AWS is deeply unpleasant in multiple directions at once.

WRT to VPC and security groups, I wonder if the OP might be talking about some of the surprising and frustrating limitations with them. E.g. VPCs are limited to fairly small subnet blocks, within which you have virtually no control. You can specify simple static routes - but only for subnets outside your VPC block. If you want to run a routing protocol in your VPC (e.g. you want your docker containers to be reachable via BGP), you get stuck pretty quickly - if the BGP subnet is within the VPC block, you can't route to them within the VPC, as the router won't permit more specific routes within the BGP block. If it's not within the VPC block, you won't be able to get to it via VPNs, peering connections, etc. So you're stuck either way.

Security groups are also limited - the number of rules you can have is pretty small, and they are a weird mix of stateless and stateful - they are stateful if the src/dest is an individual IP or group, but stateless for 0.0.0.0/0. And As you can't match TCP states like related or established, properly securing services when you have rules including 0.0.0.0/0 can be surprisingly difficult to achieve.

These are but a few examples of the limitations of the ways in which networking and security are implemented on AWS - there are plenty plenty more.