If your traffic is from EC2 within the region, this avoids the necessity of jumping onto the Edge Network and back off again, which will optimize performance of API requests from inside the same EC2 region. Regional API Endpoints are advantageous in cases like these: but your API is still only in one region (but keep reading). The new configuration offering, called a Regional API Endpoint, does not use CloudFront or the Edge Network. Overall, this was good, but in some cases, it can be better. Accessing your API from anywhere meant you were accessing it through the CloudFront, which meant optimized connections and transport from the API client - anywhere on the globe - back to your API's home region via the AWS Edge Network, which is the network that powers CloudFront, Route 53, and S3 Transfer Acceleration. With the previous setup - which has now been renamed "Edge-Optimized Endpoints" - every API Gateway API had a regional endpoint hostname but was automatically provisioned behind CloudFront. What you couldn't do, before, was configure API Gateway API endpoints in different regions to expect the same hostname - and this is a critical capability that was previously unavailable, if you wanted to have a geo-routing or failover scenario using API Gateway. You can already deploy the same API code in multiple regions and create different HTTPS endpoints using API Gateway. Does it mean I can deploy my same API code in two regions which sends request to Lambda micro-services? (It will be two different Https endpoints)
0 kommentar(er)
