12.11 Whizlabs - Section Tests - Part 2
Last updated
Was this helpful?
Last updated
Was this helpful?
Cross-origin resource sharing (CORS) defines a way for client web applications that are loaded in one domain to interact with resources in a different domain. With CORS support in Amazon S3, you can build rich client-side web applications with Amazon S3 and selectively allow cross-origin access to your Amazon S3 resources.
The following are example scenarios for using CORS:
Scenario 1: Suppose you are hosting a website in an Amazon S3 bucket named website as described in Hosting a Static Website on Amazon S3. Your users load the website endpoint "". Now you want to use JavaScript on the web pages that are stored in this bucket to be able to make authenticated GET and PUT requests against the same bucket by using the Amazon S3's API endpoint for the bucket, "website.s3.amazonaws.com". A browser would normally block JavaScript from allowing those requests, but with CORS, you can configure your bucket to explicitly enable cross-origin requests from website.s3-website-us-east-1.amazonaws.com.
Scenario 2: Suppose you want to host a web font from your S3 bucket. Again, browsers require a CORS check (also referred as a preflight check) for loading web fonts, so you would configure the bucket that is hosting the web font to allow any origin to make these requests.
Troubleshooting CORS Issues. When you are accessing buckets set with the CORS configuration, if you encounter unexpected behavior the following are some troubleshooting actions you can take:
Verify that the CORS configuration is set on the bucket.
Capture the complete request and response using a (third party) tool of your choice. For each request Amazon S3 receives, there must exist one CORS rule matching the data in your request, as follows:
Verify the request has the Origin header.
Verify that the Origin header in your request matches at least one of the AllowedOrigin elements in the specific CORSRule.
Verify that the Method in your request is one of the AllowedMethod elements in the same CORSRule.
For a preflight request, if the request includes an Access-Control-Request-Headers header, verify that the CORSRule includes the AllowedHeader entries for each value in the Access-Control-Request-Headers header.
Application ELB vs. Classic ELB. See 12.6: 30, 31.
When you create a load balancer in a VPC, you must choose whether to make it an internal load balancer or an Internet-facing load balancer. If your application has multiple tiers. Create an Internet-facing load balancer and register the web servers with it. Create an internal load balancer and register the database servers with it.
Application ELB doesn't support TCP protocol.
Application ELB can be used to build applications based on the micro-services architecture, not the applications based on RESTful API.
Request Tracing for Your Application Load Balancer. You can use request tracing to track HTTP requests from clients to targets or other services.
Amazon CloudWatch dashboards are customizable home pages in the CloudWatch console that you can use to monitor your resources in a single/consolidate view, even those resources that are spread across different regions. You can use CloudWatch dashboards to create customized views of the metrics and alarms for your AWS resources.
You can create a CloudWatch alarm that watches a single metric. The alarm performs one or more actions based on the value of the metric relative to a threshold over a number of time periods. The action can be an Amazon EC2 action, an Auto Scaling action, or a notification sent to an Amazon SNS topic.
CloudWatch alarm can also be used to monitor your estimated charges. When you enable the monitoring of estimated charges for your AWS account, the estimated charges are calculated and sent several times daily to CloudWatch as metric data.
AWS Billing and Cost Management is the service that you use to pay your AWS bill, monitor your usage, and budget your costs. The Billing and Cost Management service provides features that you can use to estimate and plan your AWS costs, receive alerts if your costs exceed a threshold that you set, assess your biggest investments in AWS resources, and, if you work with multiple AWS accounts, simplify your accounting. The AWS Billing and Cost Management console includes the no-cost Cost Explorer tool for viewing your AWS cost data as a graph. You can use budgets to track your AWS usage and costs. Budgets use the cost visualization provided by Cost Explorer to show you the status of your budgets, to provide forecasts of your estimated costs, and to track your AWS usage, including your free tier usage.
You have been requested to advise the IT monitoring team on they can monitoring a specific functionality of an application hosted on the EC2 instance. The best possible way is to publish custom metrics about the application onto CloudWatch, and then publish a widget on a CloudWatch dashboard.
CloudTrail Concepts.
CloudTrail Events. An event in CloudTrail is the record of an activity in an AWS account. This activity can be an action taken by a user, role, or service that is monitorable by CloudTrail. CloudTrail events provide a history of both API and non-API account activity made through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. There are two types of loggable events in CloudTrail: management events and data events. By default, trails log management events, but do not log data events. Both management events and data events use the same CloudTrail JSON log format.
CloudTrail Event History. CloudTrail event history provides a viewable, searchable, and downloadable record of the past 90 days of CloudTrail events.
Trails. A trail is a configuration that enables delivery of CloudTrail events to an Amazon S3 bucket, CloudWatch Logs, and CloudWatch Events. You can use a trail to filter the CloudTrail events you want delivered, encrypt your CloudTrail event log files with an AWS KMS key, and set up Amazon SNS notifications for log file delivery. A trail can be applied to all regions or a single region. As a best practice, create a trail that applies to all regions in the AWS partition in which you are working. This is the default setting when you create a trail in the CloudTrail console. A trail that applies to all regions has the following advantages:
The configuration settings for the trail apply consistently across all regions.
You receive CloudTrail events from all regions in a single S3 bucket and optionally in a CloudWatch Logs log group.
You manage trail configuration for all regions from one location.
You immediately receive events from a new region. When a new region launches, CloudTrail automatically creates a trail for you in the new region with the same settings as your original trail.
You can create trails in regions that you don't use often to monitor for unusual activity.
Encrypting CloudTrail Log Files with AWS KMS–Managed Keys (SSE-KMS). By default, the log files delivered by CloudTrail to your bucket are encrypted by Amazon server-side encryption with Amazon S3-managed encryption keys (SSE-S3). To provide a security layer that is directly manageable, you can instead use server-side encryption with AWS KMS–managed keys (SSE-KMS) for your CloudTrail log files.
When you are configuring CloudTrail to send trails to an S3 bucket, you must ensure CloudTrail has access to the S3 bucket. By default, S3 buckets and objects are private. Only the resource owner (the AWS account that created the bucket) can access the bucket and objects. The resource owner can grant access permissions to other resources and users by writing an access policy. To deliver log files to an S3 bucket, CloudTrail must have the required permissions.
CloudTrail can provide risk auditing of your AWS account.
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. The VPCs can be in different regions (also known as an inter-region VPC peering connection).
For VPC peering, when you configure the route table of the source VPC, you can specify the entire IPv4 CIDR block of the peer VPC as the destination, or a specific range, or an individual IPv4 address.
If either VPC in a peering relationship has one of the following connections, you cannot extend the peering relationship to that connection:
An internet connection through an internet gateway.
An internet connection in a private subnet through a NAT device.
A VPC endpoint to an AWS service; for example, an endpoint to Amazon S3.
(IPv6) An Amazon ClassicLink connection. You can enable IPv4 communication between a linked EC2-Classic instance and instances in a VPC on the other side of a VPC peering connection. However, IPv6 is not supported in EC2-Classic, so you cannot extend this connection for IPv6 communication.
When creating a NAT Gateway, you need to ensure that:
Assign an Elastic IP to the NAT Gateway.
Modify the route table of the private subnet (routing Internet-bound traffic to the NAT Gateway).
You cannot route traffic to a NAT Gateway through a VPC peering connection, a VPN connection, or AWS Direct Connect. A NAT Gateway cannot be used by the resources on the other side of these connections.
Facts about NAT Gateway:
A NAT gateway supports the following protocols: TCP, UDP, and ICMP.
When a NAT gateway is created, it receives a network interface that's automatically assigned a private IP address from the IP address range of your subnet.
You can associate exactly one Elastic IP address with a NAT gateway. You cannot disassociate an Elastic IP address from a NAT gateway after it's created.
You cannot associate a security group with a NAT gateway.
You can use a network ACL to control the traffic to and from the subnet in which the NAT gateway is located. A NAT gateway uses ports 1024–65535.
You created a NAT Gateway, but after an hour it is no longer visible in the VPC. The reason could be that the NAT Gateway got created with the failed status. There may be an error when your NAT Gateway was being created, and it failed. A NAT Gateway with a status of failed is visible in the VPC console for a short while (an hour), after which it is automatically deleted.
Your IAM user can get permission to create, describe, delete a NAT Gateway, but you cannot grant a user permission to perform specific API operations on the NAT Gateway.
You cannot change the CMK that is associated with an existing snapshot or encrypted volume. However, you can associate a different CMK during a snapshot copy operation so that the resulting copied snapshot uses the new CMK.
AMIs that are backed by Amazon EBS snapshots can take advantage of Amazon EBS encryption. Snapshots of both data and root volumes can be encrypted and attached to an AMI.
A VPN connection or an AWS Direct Connect connection to a corporate network. For example: