12.10 Whizlabs - Section Tests - Part 1
Last updated
Was this helpful?
Last updated
Was this helpful?
The API Gateway is used along with CloudFront for better distribution of the response to API calls. So if API calls are made from different Regions, the responses would be provided by the closest Edge Location.
Clients -> Method Request -> API Gateway -> Integration Request -> Integration Type (e.g. Lambda function) -> Integration Response -> API Gateway -> Method Response -> Clients.
Deploying an API in Amazon API Gateway.
After creating your API, you must deploy it to make the API callable for your users. To deploy an API, you create an API deployment and associate it with a stage. Each stage is a snapshot of the API and is made available for the client to call.
To call a deployed API, the client submits a request against an API method URL (Invoke URL). The method URL is determined by an API's Host Name, a Stage Name, and a Resource Path. The host name and the stage name determine the API's base URL. Using the API's default domain name, the base URL of an API in a given stage {stageName} is of the following format: "". You need to associate your resource (e.g. your Lambda function. Under each resource, you can have different methods e.g. GET or POST to access to the resource) to a stage when you deploy this API. For example, "". Using different stage-deployment combinations, you can enable smooth and robust version control for the API. The "" is the domain of this API, so when your API's resources receive requests from a domain other than the API's own domain, you must enable CORS for selected methods on the resource. The CORS is used for cross-domain access of APIs. This amounts to having your API respond to the OPTIONS preflight request with at least the following CORS-required response headers:
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Origin
For example, if you are trying to enable CORS for a GET method within a /services resources you will have to:
Add the Access-Control-Allow-Origin header in your GET method
Create a new OPTIONS method under the /services resource
Create and populate the Access-Control-Allow-Origin or Method or Headers in the OPTIONS method
For each stage, you can optimize the API performance by adjusting the default account-level request throttling limits (over the limits API will return 429 which means too many requests) and enabling API caching. You can also enable logging API calls to CloudTrail or CloudWatch and select a client certificate (SSL certificate) for the backend to authenticate the API requests. In addition, you can override stage-level settings for individual methods and define Stage Variables to pass stage-specific environment contexts to the API integration (e.g. Lambda function) at run time.
You can use API Gateway to generate an SSL certificate and use its public key in the backend to verify that HTTP requests to your backend system are from API Gateway. This allows your HTTP backend to control and accept only requests originating from Amazon API Gateway, even if the backend is publicly accessible.
When integrating AWS Lambda or calling an AWS Lambda function from the API Gateway, granting access to the IAM user to have the required access level with Lambda is a must pre-requisite action that must be performed first. It means you can use roles in your account (what was called the invocation role). API Gateway will assume the role in your account and invoke the Lambda function.
You can enable API Caching in Amazon API Gateway to cache your endpoint’s response. With caching, you can reduce the number of calls made to your endpoint and also improve the latency of the requests to your API. When you enable caching for a stage, API Gateway caches responses from your endpoint for a specified time-to-live (TTL) period, in seconds. API Gateway then responds to the request by looking up the endpoint response from the cache instead of making a request to your endpoint. The default TTL value for API caching is 300 seconds. The maximum TTL value is 3600 seconds. TTL=0 means caching is disabled. Caching is charged by the hour and is not eligible for the AWS free tier.
The following lists the exceptions of the general pricing scheme and API Gateway limits:
API Caching in API Gateway is not eligible for the AWS Free Tier.
Calling methods with the authorization type of AWS-IAM, CUSTOM, and COGITO-USER-POOLS are not charged for authorization and authentication failures.
Calling methods requiring API keys are not charged when API keys are missing or invalid.
API Gateway-throttled requests are not charged when the request rate or burst exceed the pre-configured limits.
Usage plan-throttled requests are not charged when rate limits or quota exceed the pre-configured limits.
Some of the known issues when using the API Gateway is given below:
The plain text pipe character ( | ) is not supported for any request URL query string and must be URL-encoded.
Paths of /ping and /sping are reserved for the service health check. Use of these for API root-level resources with custom domains will fail to produce the expected result.
Cross-account authentication is not currently supported in API Gateway. An API caller must be an IAM user of the same AWS account of the API owner.
Stage variables are name-value pairs that you can define as configuration attributes associated with a deployment stage of an API. They act like environment variables and can be used in your API setup and mapping templates. You can also use stage variables to pass configuration parameters to a Lambda function through your mapping templates.
Remember the Integration types (proxy) includes: Lambda functions, HTTP endpoins, Mock, and AWS Service, so you can create an API as a proxy to an AWS Service, such as Amazon SNS, S3, Kinesis, enabling your client to access the backend AWS services through your APIs.
In addition to using IAM roles and policies or custom authorizers, you can also use a user pool in Amazon Cognito to control who can access your API in API Gateway. A user pool serves as your own identity provider to maintain a user directory. It supports user registration and sign-in, as well as provisioning identity tokens for signed-in users.
After you created your API, you must deploy it to make the API callable for your users. An API deployment represents an API snapshot and becomes callable by the API users when it is associated with a stage. Deploying an API involves creating a deployment and stage and associating the deployment with the stage.
Swagger extensions, or vendor extensions, are custom properties that start with x-, such as x-logo. They can be used to describe extra functionality that is not covered by the standard Swagger specification. Many API-related products that support Swagger make use of extensions to document their own attributes, such as Amazon API Gateway, ReDoc, APIMatic and others.
Amazon Cognito lets you easily add user sign-up and sign-in and manage permissions for your mobile and web apps. You can create your own user directory within Amazon Cognito. You can also choose to authenticate users through social identity providers such as Facebook, or Amazon (OpenID); with SAML 2.0 identity solutions; or by using your own identity system. In addition, Amazon Cognito enables you to save data locally on users' devices, allowing your applications to work even when the devices are offline. You can then synchronize data across users' devices so that their app experience remains consistent regardless of the device they use.Features of Amazon Cognito:
Amazon Cognito User Pools: You can create and maintain a user directory and add sign-up and sign-in to your mobile app or web application using Amazon Cognito User Pools.
Amazon Cognito Federated Identities: Amazon Cognito Federated Identities enable you to create unique identities for your users and authenticate them with federated identity providers.
Amazon Cognito Sync: Amazon Cognito Sync is an AWS service that supports offline access and cross-device syncing of application-related user data.
How auto-scaling process can be designed to testing new instances before sending traffic to them, while still keeping them in your auto-scaling group? (It means auto-scaling group should be able to launch new instances, but these new instances should not be able to receive traffic immediately because you need to test them firstly). Answer is "Suspend the process AddToLoadBalancer".
Suspending and Resuming Scaling Processes. You can suspend and then resume one or more of the scaling processes for your Auto Scaling group. This can be useful when you want to investigate a configuration problem or other issue with your web application and then make changes to your application, without triggering the scaling processes. Amazon EC2 Auto Scaling supports the following scaling processes:
Launch. Adds a new EC2 instance to the group, increasing its capacity. If you suspend Launch, this disrupts other processes.
Terminate. Removes an EC2 instance from the group, decreasing its capacity. If you suspend Terminate, this disrupts other processes.
HealthCheck. Checks the health of the instances. Amazon EC2 Auto Scaling marks an instance as unhealthy if Amazon EC2 or Elastic Load Balancing tells Amazon EC2 Auto Scaling that the instance is unhealthy. This process can override the health status of an instance that you set manually.
ReplaceUnhealthy. Terminates instances that are marked as unhealthy and later creates new instances to replace them. This process works with the HealthCheck process, and uses both the Terminate and Launch processes.
AZRebalance. Balances the number of EC2 instances in the group across the Availability Zones in the region. If you remove an Availability Zone from your Auto Scaling group or an Availability Zone becomes unhealthy or unavailable, the scaling process launches new instances in an unaffected Availability Zone before terminating the unhealthy or unavailable instances. When the unhealthy Availability Zone returns to a healthy state, the scaling process automatically redistributes the instances evenly across the Availability Zones for the group. If you suspend AZRebalance and a scale out or scale in event occurs, the scaling process still tries to balance the Availability Zones. For example, during scale out, it launches the instance in the Availability Zone with the fewest instances.
AlarmNotification. Accepts notifications from CloudWatch alarms that are associated with the group. If you suspend AlarmNotification, Amazon EC2 Auto Scaling does not automatically execute policies that would be triggered by an alarm.
ScheduledActions. Performs scheduled actions that you create.
AddToLoadBalancer. Adds instances to the attached load balancer or target group when they are launched. If you suspend AddToLoadBalancer, Amazon EC2 Auto Scaling launches the instances but does not add them to the load balancer or target group. If you resume the AddToLoadBalancer process, it resumes adding instances to the load balancer or target group when they are launched. However, it does not add the instances that were launched while this process was suspended. You must register those instances manually.
Both of Auto-scaling group and ELB can take health check the EC2 instances. You can configure auto-scaling group to determine the health status of an instance using:
EC2 status checks
ELB health checks (this is using HTTP to check healthcheck.html)
Custom health checks.
By default, auto-scaling health checks use the results of the EC2 status checks to determine the health status of an instance. Auto-scaling group marks an instance as unhealthy if its instances fails one or more of its status checks.
Different actions when the ELB or Auto-scaling group find an unhealthy instance:
When ELB find an instance is unhealthy, it will just stop to send traffic to it.
When Auto-scaling group find an instance is unhealthy, it will terminate it and launch a new one.
Auto Scaling group periodically checks the health status of each instance. It can use EC2 status checks only (selecting "EC2", this is the default option), or EC2 status checks plus Elastic Load Balancing health checks (selecting "ELB").
If you configure an Auto Scaling group to determine health status using EC2 status checks only, which is the default, It considers the instance unhealthy if it fails the EC2 status checks. However, if you have attached one or more load balancers (classical load balancer) or target groups (application load balancer) to the Auto Scaling group and a load balancer reports that an instance is unhealthy, it does not consider the instance unhealthy and therefore it does not replace it.
If you configure your Auto Scaling group to determine health status using both EC2 status checks and Elastic Load Balancing health checks, it considers the instance unhealthy if it fails either the status checks or the health check. Note that if you attach multiple load balancers to an Auto Scaling group, all of them must report that the instance is healthy in order for it to consider the instance healthy. If one load balancer reports an instance as unhealthy, the Auto Scaling group replaces the instance, even if other load balancers report it as healthy.
Auto-scaling group life-cycle. The EC2 instances in an Auto Scaling group have a path, or lifecycle, that differs from that of other EC2 instances. The lifecycle starts when the Auto Scaling group launches an instance and puts it into service. The lifecycle ends when you terminate the instance, or the Auto Scaling group takes the instance out of service and terminates it. The following illustration shows the transitions between instance states in the Auto Scaling lifecycle.
Lifecycle Hooks. You can add a lifecycle hook to your Auto Scaling group so that you can perform some custom actions when instances launch or terminate. For example, use lifecycle hook to launch the custom scripts whenever an instance is spun up in an auto-scaling group.
Because there is a lifecycle hook, the instance is put into the Pending:Wait state, which means that it is not available to handle traffic yet. When the instance enters the wait state, scaling actions due to simple scaling policies are suspended. When the instance enter the InService state, the cooldown period starts. When the cooldown period expires, any suspended scaling actions resume.
AssumeRoleWithSAML returns a set of temporary security credentials (four values) for users who have been authenticated via a SAML authentication response. This operation provides a mechanism for tying an enterprise identity store or directory to role-based AWS access without user-specific credentials or configuration.
The temporary security credentials returned by this operation consist of an access key ID, a secret access key, and a security token. Applications can use these temporary security credentials to sign calls to AWS services.
The temporary security credentials are valid for the duration that you specified when calling AssumeRole, or until the time specified in the SAML authentication response's SessionNotOnOrAfter value, whichever is shorter. The duration can be from 900 seconds (15 minutes) to a maximum of 3600 seconds (1 hour). The default is 1 hour.
With IAM policies, you can spcify which APIs a user is allowed to call. In some cases, you might want the additional security of requiring a user to be authenticated with AWS multi-factor authentication (MFA) before the user is allowed to perform particularly sensitive actions.
AssumeRoleWithWebIdentity returns a set of temporary security credentials for users who have been authenticated in a mobile or web application with a web identity provider, such as Amazon Cognito, Login with Amazon, Facebook or any OpenID connect-compatible identity provider.
Permissions for AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity. The permission policy of the role that is being assumed determines the permissions for the temporary security credentials returned by AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity of STS. You define these permissions when you create or update the role.
Optionally, you can pass a separate policy as a parameter of the AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity API call. You use the passed policy to scope down the permissions assigned to the temporary security credentials—that is, to allow only a subset of the permissions that are allowed by the permission policy of the role. You cannot use the passed policy to grant permissions that are in excess of those allowed by the permission policy of the role; it is a filter only. If you do not pass a policy as a parameter of the AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity API call, then the permissions attached to the temporary security credentials are the same as the permissions defined in the role permissions policy of the role that is being assumed.
So if the question is: You are the architect for an application which will be used to get temporary security credentials from the STS service. You want to ensure that the right permissions are set whenever a request for the credentials are made using STS. The design principles that you would adopt is: ensure a policy is passed with each request.
Requesting Temporary Security Credentials from AWS STS. To request temporary security credentials, you can use the AWS STS API actions. You can use AWS Security Token Service (AWS STS) to create and provide trusted users with temporary security credentials that can control access to your AWS resources. The AWS STS API actions return temporary security credentials that consist of an access key and a session token. The access key consists of an access key ID and a secret key. Users (or an application that the user runs) can use these credentials to access your resources. When the credentials are created, they are associated with an IAM access control policy that limits what the user can do when using the credentials. Note: Although temporary security credentials are short lived, users who have temporary access can make lasting changes to your AWS resources. Following are the APIs that you can use to acquire temporary credentials for use in your AWS environment and applications:
AssumeRole: Cross-Account Delegation and Federation Through a Custom Identity Broker. The duration, which specifies how long the temporary security credentials are valid. The minimum is 15 minutes and the maximum (and the default) is 1 hour. You need to pass this value only if you want the temporary credentials to expire before 1 hour.
AssumeRoleWithWebIdentity: Federation Through a Web-based Identity Provider such as Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC)-compatible identity provider. The duration, which specifies how long the temporary security credentials are valid. The minimum is 15 minutes and the maximum (and the default) is 1 hour. You need to pass this value only if you want the temporary credentials to expire before 1 hour.
AssumeRoleWithSAML: Federation Through an Enterprise Identity Provider Compatible with SAML 2.0. The duration, which specifies how long the temporary security credentials are valid. The minimum is 15 minutes and the maximum (and the default) is 1 hour.
GetFederationToken: Federation Through a Custom Identity Broker. Default expiration period is substantially longer (minimum 15 minutes, up to 36 hours instead of up to 1 hour).
GetSessionToken: Temporary Credentials for Users in Untrusted Environments. Default expiration period is substantially longer (minimum 15 minutes, up to 36 hours instead of up to 1 hour).
Private Registry Authentication. When you need the ECS service to connect with your registries hosted on Docker Hub (maybe you a container instance to connect to your cluster), you can use Private Registry Authentication. The Amazon ECS container agent can authenticate with private registries, including Docker Hub, using basic authentication. When you enable private registry authentication, you can use private Docker images in your task definitions.
You can monitoring your ECS resources using CloudWatch, which collects and processes raw data from ECS to readable, near real-time metrics.
Docker Diagnostics. Docker provides several diagnostic tools that help you troubleshoot problems with your containers and tasks.
Amazon EC2 Container Service (ECS) Now Integrated with Application Load Balancer to Support Dynamic Ports and Path-based Routing. Previously, you had to define a fixed host port for your container to use ELB to route traffic to your applications, preventing multiple copies of the same task from running on the same host. There was also a one-to-one mapping between ECS services and ELBs, increasing the complexity of running microservices applications. Now, you can specify a dynamic host port which gives your container an unused port when it is scheduled on an EC2 instance. The ECS scheduler will automatically add the task to the Application Load Balancer using this port. An ELB can also be shared amongst multiple services using path-based routing. Each service can define its own URI, and that URI routes traffic to that service. In addition, you can create an environment variable with the service’s ELB DNS name, supporting service discovery.
Port mappings allow containers to access ports on the host container instance to send or receive traffic. Port mappings are specified as part of the container definition.
