That's kind of a funny way of thinking about it, buy yes? Loading an AMP page is (hopefully) an action which isn't mutating any state, so I would say it's more similar to how a CDN works. You decide you are interested in having a cache respond to a given request in a specific way, and it responds to requests which look a certain way with that response.

In this case it's significantly more secure though, as the exact request and response are signed and a third-party you trust (your browser) is deciding if that signature matches.

Analogy: Squid caching with a signature from your SSL certificate that proves it was valid as of when you signed it, so that the browser can trust the Squid cache and display the URL that’s in the signed plaintext with a domain matching that of the certificate that signed the cache blob.

Today’s browsers trust all user-configured proxies implicitly and no other proxies at all, so providing a signed copy of the GET-only AMP content, it can be safely cached (the “replay attack”) without needing to trust the cache, because it’s signed plaintext.

> okaying a replay attack

When you permit a proxy to replay your content, it's just caching. It's not an "attack." (If the proxy can replay your content without your permission, that would be an attack.)