Use CDN for Bridge

[kj4ezj]

Following issue 404 and engineering issue 38, this task is to retrofit the cloud infrastructure for the EVM bridge websites to use a content delivery network (CDN).

The testnet bridge currently uses a load balancer, and the mainnet bridge uses a load balancer behind a global accelerator. This is great, but a CDN would be substantially faster for clients outside of North America and Europe.

If there is some reason a CDN cannot be used, the testnet bridge should also be put behind a global accelerator.

Strategy

We will start with the testnet bridge, then implement a CDN for the mainnet bridge if and only if it is a sure thing - we got everything working on the testnet with the CDN, the process is well understood, and there is minimal risk to causing downtime for mainnet endpoints. The existing infrastructure shall not be torn down until the CDNs are complete and verified working in a number of cities across the globe using a virtual private network (VPN). This enables us to fall back to the existing infrastructure quickly in the face of downtime.

The good news is that we can test with the CDN distribution URI before we change the DNS records. The CDN changes will not impact the community until the DNS records are changed for the published endpoints. On the testnet, we also have certificates issued for a subdomain (beta.bridge.testnet.evm.eosnetwork.com.) so we can also test the HTTPS wiring with an ENF domain name using the CDN before deploying a change which could potentially cause downtime for customers.

Acceptance Criteria

1. A CDN was deployed for the testnet bridge.
2. If:
   1. the distribution URL worked, and;
   2. the "beta" subdomain worked using HTTPS with HTTP disallowed, then;
   3. the testnet CDN was deployed to the published testnet endpoint.
3. If the testnet CDN worked end-to-end, then a CDN is deployed for the mainnet bridge.
4. If the mainnet CDN worked using the distribution URI, then the CDN is deployed to the mainnet endpoint.
5. If the above steps failed, an AWS Global Accelerator is put in front of the testnet bridge.
6. HTTP is disabled (using a 301 redirect to HTTPS) for all bridge endpoints on both networks.
7. All unused bridge infrastructure is torn down.

[kj4ezj]

This was placed in the icebox sometime on or before April 13th. We decided to use load balancers instead because, even though it is less performant and possibly more work to implement, it was a "sure thing" to meet the release deadline.

I put the load balancers behind an AWS Global Accelerator to partly meet the needs of this ticket. Global accelerators use the same AWS edge nodes as CloudFront to provide DDoS protection, global fault tolerance, increase throughput by ~90%, and decrease latency by ~50%. My customers were very satisfied with the improvements in performance! However, global accelerators do not cache content at the edge locations. We should still switch the bridge to a CDN at some point in the future.

[Joshua2Mars]

Needs to confirm if it's complete or not.