To reduce the number of calls to the endpoints and improve response times, caching can be configured to locally store frequent requests on the gateway. API Gateway will cache response for the TTL period. API Gateway will then first check the cache for the response before making an endpoint request if there is a cache miss.
For global connection requirements, the AWS CloudFront edge locations are used as API endpoints, as shown in Figures 1.16 and 1.17. Using edge locations improves latency by reducing the number of hops that may be required over the public Internet from distant locations. For instance, a user in Germany that is accessing your API endpoint in the us-east-1 Northern Virginia region will be connected to the nearest edge location and traverse the AWS dedicated backbone network to the us-east-1 region. AWS Gateway will still reside in the region you created it in, but the edge network can improve performance across the global network to connect to the gateway.
FIGURE 1.17 Regional API gateways
Regional endpoints are used by users connecting to API interfaces at the regional level, as shown Figure 1.17.
Another deployment option is to create a VPC gateway that is reachable only from inside your VPC, as shown in Figure 1.18, using a VPC endpoint network interface (ENI). Access will be controlled with a resource policy being applied.
FIGURE 1.18 API Gateway deployed in a VPC
Private APIs are accessed inside the VPC or systems that have remote network connectivity to the VPC, as shown in Figure 1.19.
FIGURE 1.19 Private API gateways
Web security models enforce what is known as a same-origin policy. This was implemented to prevent cross-site scripting (XSS) attacks. Same origin allows any scripts running from a web page to call or access data in a second web page only if they have the same origin. If they are of different domains, the calls will be dropped by the browsers unless they are configured to allow XSS operations by enabling cross origin resource sharing, or CORS. With CORS enabled, your AWS deployments can call the S3, cloudfront.net, and amazonaws.com domains that are different but are now allowed at the browser level. When a browser asks the API for HTTP OPTIONS, it will reply with the approved names of domains to interact with. If you see “Error – Origin policy cannot be read at the remote resource,” CORS is disabled and needs to be set to allow in the API Gateway console.
When accessing the API gateway from inside AWS, IAM is used to provide authentication support for API Gateway, and, as is always the case, there are a large number of policies preconfigured and also the ability to create custom polices as required. IAM requests are sent from the requester to API Gateway using Sigv4 security headers that contain the IAM credentials, which are then passed to IAM from API Gateway.
Another option is to use resource policies, which are JSON documents that define the rights to access API gateway and its backend services. Resource policies combined with IAM security are often used with cross-account access.
For external clients, such as those on the Internet that access your web resources using the API gateway, Cognito user pools are created and allowed access to your APIs. Users authenticate using Cognito user pools, and authorization is granted to access the APIs at the methods level you specify. The client receives a token from Cognito user pools, and the client passes the token to API Gateway to be granted access to the backend services. The token is single use with an expiration timer for onetime access.
For maximum flexibility, Lambda authorizers can be integrated with API Gateway. This token-based authorization service evaluates the request and returns an IAM policy to the requester to grant access. This method uses external, or third-party, authentication and Lambda authorization. This approach is more complex than the other methods but gives us the flexibility to meet all use case requirements.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
