In my mind I actually separate it into three (from Google):
- The specs/docs for building AMP pages, which can be found on www.ampproject.org - note that, a lot of these are non-free, like standardized components for specific media/social sites, and requires you to include script tags for cdn.ampproject.org component implementations. This all tells you how to add an AMP version of your page to your site, and how to link it to the original content.
- The "Google AMP Cache" CDN that hosts cached versions of AMP pages under .cdn.ampproject.org - it seems that anyone can use this...? Note these are in a separate context than the google search result page (that people think of as "AMP pages") which means a generic XSS on AMP isn't an XSS on google.com.
- The integration into Google Search. On the frontend this looks like some javascript that preloads iframes to the .cdn.ampproject.org page for results, and also uses History.pushState() to give you the google.com/amp/foo.com/ urls. If you go to those URLs directly you'll get redirected (that's the server-side implementation of them and why you don't ). There's also some crawler (and ranking?) implementation too, presumably.
A lot of discussion about AMP seems to muddy all three of these things together, which is a bit unsurprising considering Google's messaging muddles them together, but I think it's important to distinguish between them. In the "Twitter AMP redirect" case of the article, only the first portion is coming into play.
As an aside - if you're interested in seeing how AMP works under the hood I highly recommend the Chrome Android USB debugging - I hadn't played with this before trying to figure out how AMP worked and it was really a godsend to be able to "Inspect Element" on my phone, especially because anything AMP-related is very aggressive about only AMPing to phones on cell networks.