Expedited Security, a small security and SSL certificate company, writes about AWS, API security, TLS, and log4j mitigations.
Commenters repeatedly link its "AWS in Plain English" page to joke about AWS's confusing service names.
Hmmm. There are a few different levels of "proficiency" for a product as sprawling as AWS, and I think there are different ways of approaching each level. You didn't tell us what you are looking for :) .
* Broad knowledge of services. This is important because you can often short circuit or accelerate entire projects just by being aware of AWS services. Ways to learn this: certs (esp the Architecture cert), subscribe to rss feeds, sign up for https://www.lastweekinaws.com/newsletter/ , read: https://expeditedsecurity.com/aws-in-plain-english/
* How to use a service at a basic level. This means that you know what a service is/does and can do basic tasks with it (start up an EC2 instance or know which EC2 type makes sense for a certain use case, for example). Here the AWS tutorials and other docs are good (reference architectures, well architected framework), as are the certs.
* Understanding the ins and outs of a service. This is where you start to dive in deeper. You might learn what the limits of EBS are for certain EC2 instance types, how to use local volumes, how to maximize network throughput, when you might use dedicated hardware, etc. Here good sources are books, re:invent videos, the builders library: https://aws.amazon.com/builders-library/ , hard knocks/testing ( when in doubt, test it out: http://www.mooreds.com/wordpress/archives/3335 ). You can also short circuit some of the learning by hiring consultants.
* Being an expert at a service. I'm not there, but…
>TLS verifies that the URL matches cert through the chain of trust,
I think you need to point out that TLS utilizes the browsers cert store for that chain of trust. If a bad actor acquires an entity that has a trusted cert, or your cert store is compromised, that embedded cert store is almost entirely useless which has happened on more than one occassion (Chinese government and Symantec most recently).
https://expeditedsecurity.com/blog/control-the-ssl-cas-your-browser-trusts/
This is typically caught pretty quickly but there's almost nothing a user can do to defend against a chain of trust attack. With SSH, while nobody does it, at least you have the ability to protect yourself.
For Heroku - Expedited WAF does filter (inbound) for log4j - but I'm not sure there's a good way to outbound, even with Private Spaces. You can start a dyno that only has access to the other apps in the space, but if log4j was on one of the connected web app servers you'd still be in trouble.
https://expeditedsecurity.com/heroku/how-to-block-log4j-vulnerability-on-heroku/
(2015)
rip of other article (https://expeditedsecurity.com/aws-in-plain-english/) and ancient
Plenty of discussion over the years:
Original 2015 https://news.ycombinator.com/item?id=10202286
2017 where the author repeats that this is old https://news.ycombinator.com/item?id=13442022
2018 https://news.ycombinator.com/item?id=18475518
This can be a good cheat-sheet and no wonder there have been so many attempts at this(1).
Maybe we're better off making this as github page where users can send pull requests and add/rewrite to these.
(1) https://netrixllc.com/blog/aws-services-in-simple-terms/
(2) https://expeditedsecurity.com/aws-in-plain-english/
Reminded me of these similar threads I read a while earlier:
Azure:
https://web.archive.org/web/20190321175020/https://www.expeditedssl.com/azure-in-plain-english
https://news.ycombinator.com/item?id=13442597
AWS:
https://expeditedsecurity.com/aws-in-plain-english/
https://news.ycombinator.com/item?id=10202286