Since you already decided to implement amp for all your pages, how can you not know? When you have read the amp spec and look at the tweets and instagram posts, you will see that both contain elements that are not allowed in amp.
I have the feeling you don't know what you are getting into. Why do you want to implement amp in the first place?
Here's a great place to start AMP Tutorials https://www.ampproject.org/docs/tutorials/create
The whole point of AMP is to cut down on content that will be slow to reach a users mobile. It was originally developed for news publishers, and AMP pages are not meant to have lots of graphics or downloads, which will be inherently slower than just plain text. The more your put on the page the slower it'll be. If you really need to include the content, don't bother with AMP, just focus on minimising the page overhead. This is a great intro video
There are such pages for FB, Instagram etc... Just spend some time on the AMPByExample.com page.
Then if you still can't find what you need, say for some other kind of interactive content then you can always embed the content in iframe.
graeme_p's comments are based on ignorance. While there may be some truth to the statements in regards to strictly static content, but when it comes to dynamics content it is categorically false. AMP allows you to do some pretty amazing things such as create PWAs that will make pages load fast and seamlessly whether on-line or off, from the users first click in search. There is lot more to it than most realize and it is constantly evolving.
what exactly can you do with AMP that you cannot do without AMP?
Pre-load a service-worker directly from the search-cache such that once the user interacts with the page the service worker already has control of the page. This may seem like a trivial difference but it makes a big difference on how a user interacts with the page and perceives the speed of the page. Typically, the service worker will only take control after the first click.
AMP also allows you, to redirect user that use a browser that do not support service-workers (eg: on IOS devices) to a different url. This is done directly from the search-cache. Again, a subtle difference. You could easily redirect user on your server but the user first needs to request the page, then the server redirects to the correct page. AMP skips the steps and redirects the user directly from the cache to the page.
so that aspect is just a subset of HTML
Watch the video that is on this page: [ampproject.org...] It explains a lot about PWA and AMP integration. And note at 1min15sec it is stated "AMP is both subset and a superset of HMTL". In otherwords there are things that cannot be achieved without AMP.
Also the video you linked to outlines other aspect. For example "static layouting".
Each of this things alone may only provide marginal improvements in speed but the combination of this factors can make a measurable difference.
Both your examples are features of the Google AMP CDN not of AMP itself. I wonder
1. Whether other AMP CDNs offer the same features 2. Whether other non-AMP CDNs offer the same features.
I would have though the answer is yes to both for the first (loading services works from cache).
As far as AMP being a superset of HTML goes. Sort of. It adds stuff that is not HTML, but it uses HTML and JS to do it - its rather like a front end framework in that respect - in fact it IS a front end framework.
None of that makes AMP a bad thing, but because it runs in a browser it is ultimately limited to things you can do with HTML and JS.