AWS Route 53 – Resolving DNS Queries Between VPCs and On-premises Network
Route 53 Resolver provides automatic DNS resolution within the VPC.
By default, Resolver answers DNS queries for VPC domain names such as domain names for EC2 instances or ELB load balancers.
Resolver performs recursive lookups against public name servers for all other domain names.
However, on-premises instances cannot resolve Route 53 DNS entries and Route 53 cannot resolve on-premises DNS entries
DNS resolution between AWS VPC and on-premises network can be configured over a Direct Connect or VPN connection
Route 53 Resolver is regional.
To use inbound or outbound forwarding, create a Resolver endpoint in the VPC.
As part of the definition of an endpoint, specify the IP addresses to forward inbound DNS queries to or the IP addresses that outbound queries to originate from. For each IP address specified, Resolver automatically creates a VPC elastic network interface.
Forward DNS queries from resolvers on your network to Route 53 Resolver
DNS resolvers on on-premises network can forward DNS queries to Resolver in a specified VPC.
This enables DNS resolvers to easily resolve domain names for AWS resources such as EC2 instances or records in a Route 53 private hosted zone.
Conditionally forward queries from a VPC to resolvers on your network
Route 53 Resolver can be configured to forward queries that it receives from EC2 instances in the VPCs to DNS resolvers on on-premises network.
To forward selected queries, Resolver rules can be created that specify the domain names for the DNS queries that you want to forward (such as example.com), and the IP addresses of the DNS resolvers on on-premises network that you want to forward the queries to.
If a query matches multiple rules (example.com, acme.example.com), Resolver chooses the rule with the most specific match (acme.example.com) and forwards the query to the IP addresses that you specified in that rule.
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
helps define a logically isolated dedicated virtual network within the AWS
provides control of IP addressing using CIDR block from a minimum of /28 to maximum of /16 block size
supports IPv4 and IPv6 addressing
cannot be extended once created
can be extended by associating secondary IPv4 CIDR blocks to VPC
Components
Internet gateway (IGW) provides access to the Internet
Virtual gateway (VGW) provides access to on-premises data center through VPN and Direct Connect connections
VPC can have only one IGW and VGW
Route tables determine where network traffic from subnet is directed
Ability to create subnet with VPC CIDR block
A Network Address Translation (NAT) server provides outbound Internet access for EC2 instances in private subnets
Elastic IP addresses are static, persistent public IP addresses
Instances launched in the VPC will have a Private IP address and can have a Public or a Elastic IP address associated with it
Security Groups and NACLs help define security
Flow logs – Capture information about the IP traffic going to and from network interfaces in your VPC
Tenancy option for instances
shared, by default, allows instances to be launched on shared tenancy
dedicated allows instances to be launched on a dedicated hardware
Route Tables
defines rules, termed as routes, which determine where network traffic from the subnet would be routed
Each VPC has a Main Route table, and can have multiple custom route tables created
Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
Route priority is decided by matching the most specific route in the route table that matches the traffic
Subnets
map to AZs and do not span across AZs
have a CIDR range that is a portion of the whole VPC.
CIDR ranges cannot overlap between subnets within the VPC.
AWS reserves 5 IP addresses in each subnet – first 4 and last one
Each subnet is associated with a route table which define its behavior
Public subnets – inbound/outbound Internet connectivity via IGW
Private subnets – outbound Internet connectivity via an NAT or VGW
Protected subnets – no outbound connectivity and used for regulated workloads
Elastic Network Interface (ENI)
a default ENI, eth0, is attached to an instance which cannot be detached with one or more secondary detachable ENIs (eth1-ethn)
has primary private, one or more secondary private, public, Elastic IP address, security groups, MAC address and source/destination check flag attributes associated
AN ENI in one subnet can be attached to an instance in the same or another subnet, in the same AZ and the same VPC
Security group membership of an ENI can be changed
with pre allocated Mac Address can be used for applications with special licensing requirements
Security Groups vs Network Access Control Lists
Stateful vs Stateless
At instance level vs At subnet level
Only allows Allow rule vs Allows both Allow and Deny rules
Evaluated as a Whole vs Evaluated in defined Order
Elastic IP
is a static IP address designed for dynamic cloud computing.
is associated with AWS account, and not a particular instance
can be remapped from one instance to an other instance
is charged for non usage, if not linked for any instance or instance associated is in stopped state
NAT
allows internet access to instances in private subnet
performs the function of both address translation and port address translation (PAT)
needs source/destination check flag to be disabled as it is not actual destination of the traffic
NAT gateway is a AWS managed NAT service that provides better availability, higher bandwidth, and requires less administrative effort
are not supported for IPv6 traffic
Egress-Only Internet Gateways
outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances
supports IPv6 traffic only
Shared VPCs
allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs
VPC Peering
allows routing of traffic between the peer VPCs using private IP addresses and no IGW or VGW required
No single point of failure and bandwidth bottlenecks
cannot span across regions
supports inter-region VPC peering
IP space or CIDR blocks cannot overlap
cannot be transitive, one-to-one relationship between two VPC
Only one between any two VPCs and have to be explicitly peered
Private DNS values cannot be resolved
Security groups from peered VPC cannot be referred for ingress and egress rules in security group, use CIDR block instead
Security groups from peered VPC can now be referred, however the VPC should be in the same region.
VPC Endpoints
enables you to privately connect VPC to supported AWS services and VPC endpoint services powered by PrivateLink
does not require a public IP address, access over the Internet, NAT device, a VPN connection or Direct Connect
traffic between VPC & AWS service does not leave the Amazon network
are virtual devices.
are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.
Gateway Endpoints
is a gateway that is a target for a specified route in the route table, used for traffic destined to a supported AWS service.
only S3 and DynamoDB are currently supported
Interface Endpoints
is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service
services supported API Gateway AWS CloudFormation, CloudWatch, CloudWatch Events, CloudWatch Logs AWS CodeBuild AWS CodeCommit AWS Config, EC2 API Elastic Load Balancing API, Elastic Container Registry, Elastic Container Service AWS Key Management Service, Kinesis Data Streams, SageMaker and, SageMaker Runtime, SageMaker Notebook Instance AWS Secrets Manager AWS Security Token Service AWS Service Catalog, SNS, SQS AWS Systems Manager
provides low latency and high data transfer speeds for distribution of static, dynamic web, or streaming content to web users.
delivers the content through a worldwide network of data centers called Edge Locations or Point of Presence (PoPs)
keeps persistent connections with the origin servers so that the files can be fetched from the origin servers as quickly as possible.
dramatically reduces the number of network hops that users’ requests must pass through
supports multiple origin server options, like AWS hosted service for e.g. S3, EC2, ELB, or an on-premise server, which stores the original, definitive version of the objects
single distribution can have multiple origins and Path pattern in a cache behavior determines which requests are routed to the origin
Web distribution supports static, dynamic web content, on-demand using progressive download & HLS, and live streaming video content
supports HTTPS using either
dedicated IP address, which is expensive as a dedicated IP address is assigned to each CloudFront edge location
Server Name Indication (SNI), which is free but supported by modern browsers only with the domain name available in the request header
For E2E HTTPS connection,
Viewers -> CloudFront needs either a self-signed certificate or a certificate issued by CA or ACM
CloudFront -> Origin needs certificate issued by ACM for ELB and by CA for other origins
Security
Origin Access Identity (OAI) can be used to restrict the content from S3 origin to be accessible from CloudFront only
supports Geo restriction (Geo-Blocking) to whitelist or blacklist countries that can access the content
Signed URLs
to restrict access to individual files, for e.g., an installation download for your application.
users using a client, for e.g. a custom HTTP client, that doesn’t support cookies
Signed Cookies
provide access to multiple restricted files, for e.g., video part files in HLS format or all of the files in the subscribers’ area of a website.
don’t want to change the current URLs
integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configured based on IP addresses, HTTP headers, and custom URI strings
supports GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE to get object & object headers, add, update, and delete objects
only caches responses to GET and HEAD requests and, optionally, OPTIONS requests
does not cache responses to PUT, POST, PATCH, DELETE request methods and these requests are proxied back to the origin
object removal from the cache
would be removed upon expiry (TTL) from the cache, by default 24 hrs
can be invalidated explicitly, but has a cost associated, however, might continue to see the old version until it expires from those caches
objects can be invalidated only for Web distribution
use versioning or change object name, to serve a different version
supports adding or modifying custom headers before the request is sent to origin which can be used to
validate if a user is accessing the content from CDN
identifying CDN from which the request was forwarded, in case of multiple CloudFront distributions
for viewers not supporting CORS to return the Access-Control-Allow-Origin header for every request
supports Partial GET requests using range header to download objects in smaller units improving the efficiency of partial downloads and recovery from partially failed transfers
supports compression to compress and serve compressed files when viewer requests include Accept-Encoding: gzip in the request header
supports different price classes to include all regions, or only the least expensive regions and other regions without the most expensive regions
supports access logs which contain detailed information about every user request for both web and RTMP distribution
Direct Connect & VPN
VPN
provide secure IPSec connections from on-premise computers or services to AWS over the Internet
is quick to setup, is cheap however it depends on the Internet speed
Direct Connect
is a network service that provides an alternative to using Internet to utilize AWS services by using private dedicated network connection
provides Virtual Interfaces
Private VIF to access instances within an VPC via VGW
Public VIF to access non VPC services
requires time to setup probably months, and should not be considered as an option if turnaround time is less
does not provide redundancy, use either second direct connection or IPSec VPN connection
Virtual Private Gateway is on the AWS side and Customer Gateway is on the Customer side
route propagation is enabled on VGW and not on CGW
Direct Connect vs VPN IPSec
Expensive to Setup and Takes time vs Cheap & Immediate
Dedicated private connections vs Internet
Reduced data transfer rate vs Internet data transfer cost
Consistent performance vs Internet inherent variability
Do not provide Redundancy vs Provides Redundancy
Route 53
Highly available and scalable DNS & Domain Registration Service
Reliable and cost-effective way to route end users to Internet applications
Supports multi-region and backup architectures for High availability. ELB , limited to region, does not support multi region HA architecture
supports private Intranet facing DNS service
internal resource record sets only work for requests originating from within the VPC and currently cannot extend to on-premise
Global propagation of any changes made to the DN records within ~ 1min
Route 53 to create an alias resource record set that points to ELB, S3, CloudFront. An alias resource record set is a Route 53 extension to DNS. It’s similar to a CNAME resource record set, but supports both for root domain – zone apex e.g. example.com, and for subdomains for e.g. www.example.com.
CNAME resource record sets can be created only for subdomains and cannot be mapped to the zone apex record
Route 53 Split-view (Split-horizon) DNS enables you to access an internal version of your website using the same domain name that is used publicly
Routing policy
Simple routing – simple round robin policy
Weighted round robin – assign weights to resource records sets to specify the proportion for e.g. 80%:20%
Latency based routing – helps improve global applications as request are sent to server from the location with minimal latency, is based on the latency and cannot guarantee users from the same geographic will be served from the same location for any compliance reasons
Geolocation routing – Specify geographic locations by continent, country, state limited to US, is based on IP accuracy
Failover routing – failover to a backup site if the primary site fails and becomes unreachable
Weighted, Latency and Geolocation can be used for Active-Active while Failover routing can be used for Active-Passive multi region architecture
Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service.
Amazon Route 53 provides three main functions:
Domain registration
allows you to register domain names
Domain Name System (DNS) service
translates friendly domains names like www.example.com into IP addresses like 192.0.2.1
responds to DNS queries using a global network of authoritative DNS servers, which reduces latency
can route Internet traffic to CloudFront, Elastic Beanstalk, ELB, or S3. There’s no charge for DNS queries to these resources
Health checking
can monitor the health of resources such as web and email servers.
sends automated requests over the Internet to the application to verify that it’s reachable, available, and functional
CloudWatch alarms can be configured for the health checks to send notification when a resource becomes unavailable.
can be configured to route Internet traffic away from resources that are unavailable
Supported DNS Resource Record Types
A (Address) Format
is an IPv4 address in dotted decimal notation for e.g. 192.0.2.1
AAAA Format
is an IPv6 address in colon-separated hexadecimal format
CNAME Format
is the same format as a domain name
DNS protocol does not allow creation of a CNAME record for the top node of a DNS namespace, also known as the zone apexfor e.g. the DNS name example.com registration, the zone apex is example.com, a CNAME record for example.com cannot be created, but CNAME records can be created for www.example.com, newproduct.example.com etc.
If a CNAME record is created for a subdomain, any other resource record sets for that subdomain cannot be created for e.g. if a CNAME created for www.example.com, not other resource record sets for which the value of the Name field is www.example.com can be created
MX (Mail Xchange) Format
contains a decimal number that represents the priority of the MX record, and the domain name of an email server
NS (Name Server) Format
An NS record identifies the name servers for the hosted zone. The value for an NS record is the domain name of a name server.
PTR Format
A PTR record Value element is the same format as a domain name.
SOA (Start of Authority) Format
SOA record provides information about a domain and the corresponding Amazon Route 53 hosted zone
SPF (Sender Policy Framework) Format
SPF records were formerly used to verify the identity of the sender of email messages, however is not recommended
Instead of an SPF record, a TXT record that contains the applicable value is recommended
SRV Format
An SRV record Value element consists of four space-separated values.The first three values are decimal numbers representing priority, weight, and port. The fourth value is a domain name for e.g. 10 5 80 hostname.example.com
TXT (Text) Format
A TXT record contains a space-separated list of double-quoted strings. A single string include a maximum of 255 characters. In addition to the characters that are permitted unescaped in domain names, space is allowed in TXT strings
Alias resource record sets
Route 53 supports alias resource record sets, which enables routing of queries to a CloudFront distribution, Elastic Beanstalk, ELB, an S3 bucket configured as a static website, or another Route 53 resource record set
Alias records are not standard for DNS RFC and are a Route 53 extension to DNS functionality
Alias record is similar to a CNAME record, but can create an alias record both for the root domain or apex zone, such as example.com, and for subdomains, such as www.example.com. CNAME records can be used only for subdomains.
Route 53 automatically recognizes changes in the resource record sets that the alias resource record set refers to for e.g. for a site pointing to an load balancer, if the ip of the load balancer changes, Route 53 will reflect those changes automatically in the DNS answers without any changes to the hosted zone that contains resource record sets
If an alias resource record set points to a CloudFront distribution, a load balancer, or an S3 bucket, the time to live (TTL) can’t be set; Route 53 uses the CloudFront, load balancer, or Amazon S3 TTLs.
Route 53 Hosted Zone
Hosted Zone is A container for records, which include information about how to route traffic for a domain (such as example.com) and all of its subdomains (such as www.example.com, retail.example.com, and seattle.accounting.example.com).
A hosted zone has the same name as the corresponding domain.
Routing Traffic to the Resources
Create a hosted zone with either a public hosted zone or a private hosted zone:
Public Hosted Zone – for routing internet traffic to your resources for a specific domain and its subdomains
Private hosted zone – for routing traffic within an VPC
Create records in the hosted zone
Records define where to route traffic for each domain name or subdomain name.
name of each record in a hosted zone must end with the name of the hosted zone.
Route 53 Split-view (Split-horizon) DNS
Route 53 Split-view (Split-horizon) DNS enables you to access an internal version of your website using the same domain name that is used publicly
You can maintain both a private and public hosted zone with the same domain name for split-view DNS with Route 53
Ensure that DNS resolution and DNS hostnames are enabled on the source VPC.
DNS queries will respond with answers based on the source of the request. From within the VPC, answers will come from the private hosted zone, while public queries will return answers from the public hosted zone.
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
What does Amazon Route53 provide?
A global Content Delivery Network.
None of these.
A scalable Domain Name System
An SSH endpoint for Amazon EC2.
Does Amazon Route 53 support NS Records?
Yes, it supports Name Service records.
No
It supports only MX records.
Yes, it supports Name Server records.
Does Route 53 support MX Records?
Yes
It supports CNAME records, but not MX records.
No
Only Primary MX records. Secondary MX records are not supported.
Which of the following statements are true about Amazon Route 53 resource records? Choose 2 answers
An Alias record can map one DNS name to another Amazon Route 53 DNS name.
A CNAME record can be created for your zone apex.
An Amazon Route 53 CNAME record can point to any DNS record hosted anywhere.
TTL can be set for an Alias record in Amazon Route 53.
An Amazon Route 53 Alias record can point to any DNS record hosted anywhere.
Which statements are true about Amazon Route 53? (Choose 2 answers)
Amazon Route 53 is a region-level service
You can register your domain name
Amazon Route 53 can perform health checks and failovers to a backup site in the even of the primary site failure
Amazon Route 53 only supports Latency-based routing
A customer is hosting their company website on a cluster of web servers that are behind a public-facing load balancer. The customer also uses Amazon Route 53 to manage their public DNS. How should the customer configure the DNS zone apex record to point to the load balancer?
Create an A record pointing to the IP address of the load balancer
Create a CNAME record pointing to the load balancer DNS name.
Create a CNAME record aliased to the load balancer DNS name.
Create an A record aliased to the load balancer DNS name
A user has configured ELB with three instances. The user wants to achieve High Availability as well as redundancy with ELB. Which of the below mentioned AWS services helps the user achieve this for ELB?
Route 53
AWS Mechanical Turk
Auto Scaling
AWS EMR
How can the domain’s zone apex for example “myzoneapexdomain com” be pointed towards an Elastic Load Balancer?
By using an AAAA record
By using an A record
By using an Amazon Route 53 CNAME record
By using an Amazon Route 53 Alias record
You need to create a simple, holistic check for your system’s general availability and uptime. Your system presents itself as an HTTP-speaking API. What is the simplest tool on AWS to achieve this with?
Your organization’s corporate website must be available on www.acme.com and acme.com. How should you configure Amazon Route 53 to meet this requirement?
Configure acme.com with an ALIAS record targeting the ELB. www.acme.com with an ALIAS record targeting the ELB.
Configure acme.com with an A record targeting the ELB. www.acme.com with a CNAME record targeting the acme.com record.
Configure acme.com with a CNAME record targeting the ELB. www.acme.com with a CNAME record targeting the acme.com record.
Configure acme.com using a second ALIAS record with the ELB target. www.acme.com using a PTR record with the acme.com record target.
AWS Route 53 routing policy determines how AWS would respond to the DNS queries and provides multiple Routing policy options
Simple Routing Policy
Simple routing policy is a simple round robin policy and can be applied when there is a single resource doing the function for the domain for e.g. web server that serves content for the website
AWS Route 53 responds to the DNS queries based on the values in the resource record set for e.g. ip address in an A record
Weighted Routing Policy
Weighted routing policy enables Route 53 to route traffic to different resources in specified proportions (weights) for e.g., 75% one server and 25% to theother during a pilot release
Weights can be assigned any number from 0 to 255
Weighted routing policy can be applied when there are multiple resources that perform the same function for e.g., webservers serving the same site
Weighted resource record sets let you associate multiple resources with a single DNS name
Common use cases include
load balancing
A/B testing and piloting new versions of software
To create a group of weighted resource record sets, two or more resource record sets can be created that have the same combination of DNS name and type, and each resource record set is assigned a unique identifier and a relative weight.
When processing a DNS query, Route 53 searches for a resource record set or a group of resource record sets that have the specified name and type.
Route 53 selects one from the group. Probability of any one resource record set being selected depends on its weight as a proportion of the total weight for all resource record sets in the group for e.g., suppose for www.example.com has three resource record sets with weights of 1 (20%), 1 (20%), and 3 (60%)(sum = 5). On average, Route 53 selects each of the first two resource record sets one-fifth of the time, and returns the third resource record set three-fifths of the time.
Latency-based Routing (LBR) Policy
Latency-based Routing Policy enables Route 53 to respond to the DNS query based on which data center gives the user the lowest network latency
Latency-based routing policy can be used when there are multiple resources performing the same function and Route 53 needs to be configured to respond to the DNS queries with the resources that provide the fastest response with lowest latency
Latency resource record set can be created for the EC2 resource in each region that hosts the application. When Route 53 receives a query for the corresponding domain, it selects the latency resource record set for the EC2 region that gives the user the lowest latency. Route 53 then responds with the value associated with that resource record set for e.g., you might have web servers for example.com in the EC2 data centers in Ireland and in Tokyo. When a user browses to example.com from Singapore, Route 53 will pick up the data center (Tokyo) which has the lowest latency from the users location
Latency between hosts on the Internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements performed over a period of time, and the measurements reflect these changes for e.g. if the latency from the user in Singapore to Ireland improves, the user can be routed to Ireland
Latency based routing cannot guarantee users from the same geographic will be served from the same location for any compliance reason
Latency resource record sets can be created using any record type that Route 53 supports except NS or SOA
Failover Routing Policy
Failover routing policy allows active-passive failover configuration, in which one resource takes all traffic when it’s available and the other resource takes all traffic when the first resource isn’t available.
Route 53 health checking agents will monitor each location/endpoint of the application to determine the availability.
Failover routing policy is applicable for Public hosted zones only
Geolocation Routing Policy
Geolocation routing policy enables Route 53 to respond to DNS queries based on the geographic location of the users i.e. location from which the DNS queries originate
Common use cases include
localization of content and presenting some or all of the website in the users language
restrict distribution of content to only the locations in which you have distribution rights.
balancing load across endpoints in a predictable, easy-to-manage way, so that each user location is consistently routed to the same endpoint.
Geolocation routing policy allows geographic locations to be specified by continent, country, or by state (only in US)
Geolocation record sets, if created, for overlapping geographic regions for e.g. continent and then for the country within the same continent, priority goes to the smallest geographic region, which allows some queries for a continent to be routed to one resource and queries for selected countries on that continent to a different resource
Geolocation works by mapping IP addresses to locations, which might not mapped to a exact geographic location
A default resource record set can be created to handle these queries and also the ones which do not have an explicit record set created
Route 53 returns a “no answer”response for queries from those locations, if a default resource record set if not created
Two geolocation resource record sets that specify the same geographic location cannot be created
Route 53 supports the edns-client-subnet extension of EDNS0 (EDNS0 adds several optional extensions to the DNS protocol.) to improve the accuracy of geolocation routing
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You have deployed a web application targeting a global audience across multiple AWS Regions under the domain name example.com. You decide to use Route 53 Latency-Based Routing to serve web requests to users from the region closest to the user. To provide business continuity in the event of server downtime you configure weighted record sets associated with two web servers in separate Availability Zones per region. During a DR test you notice that when you disable all web servers in one of the regions Route 53 does not automatically direct all users to the other region. What could be happening? (Choose 2 answers)
Latency resource record sets cannot be used in combination with weighted resource record sets.
You did not setup an http health check for one or more of the weighted resource record sets associated with the disabled web servers
The value of the weight associated with the latency alias resource record set in the region with the disabled servers is higher than the weight for the other region.
One of the two working web servers in the other region did not pass its HTTP health check
You did not set “Evaluate Target Health” to “Yes” on the latency alias resource record set associated with example.com in the region where you disabled the servers.
The compliance department within your multi-national organization requires that all data for your customers that reside in the European Union (EU) must not leave the EU and also data for customers that reside in the US must not leave the US without explicit authorization. What must you do to comply with this requirement for a web based profile management application running on EC2?
Run EC2 instances in multiple AWS Availability Zones in single Region and leverage an Elastic Load Balancer with session stickiness to route traffic to the appropriate zone to create their profile (should be in 2 different regions – US and Europe)
Run EC2 instances in multiple Regions and leverage Route 53’s Latency Based Routing capabilities to route traffic to the appropriate region to create their profile (Latency based routing policy would not guarantee the compliance requirement)
Run EC2 instances in multiple Regions and leverage a third party data provider to determine if a user needs to be redirect to the appropriate region to create their profile
Run EC2 instances in multiple AWS Availability Zones in a single Region and leverage a third party data provider to determine if a user needs to be redirect to the appropriate zone to create their profile(should be in 2 different regions – US and Europe)
A US-based company is expanding their web presence into Europe. The company wants to extend their AWS infrastructure from Northern Virginia (us-east-1) into the Dublin (eu-west-1) region. Which of the following options would enable an equivalent experience for users on both continents?
Use a public-facing load balancer per region to load-balance web traffic, and enable HTTP health checks.
Use a public-facing load balancer per region to load-balance web traffic, and enable sticky sessions.
Use Amazon Route 53, and apply a geolocation routing policy to distribute traffic across both regions
Use Amazon Route 53, and apply a weighted routing policy to distribute traffic across both regions.
You have been asked to propose a multi-region deployment of a web-facing application where a controlled portion of your traffic is being processed by an alternate region. Which configuration would achieve that goal?
Route 53 record sets with weighted routing policy
Route 53 record sets with latency based routing policy
Auto Scaling with scheduled scaling actions set
Elastic Load Balancing with health checks enabled
Your company is moving towards tracking web page users with a small tracking image loaded on each page. Currently you are serving this image out of us-east, but are starting to get concerned about the time it takes to load the image for users on the west coast. What are the two best ways to speed up serving this image? Choose 2 answers
Use Route 53’s Latency Based Routing and serve the image out of us-west-2 as well as us-east-1
Serve the image out through CloudFront
Serve the image out of S3 so that it isn’t being served of your web application tier
Use EBS PIOPs to serve the image faster out of your EC2 instances
Your API requires the ability to stay online during AWS regional failures. Your API does not store any state, it only aggregates data from other sources – you do not have a database. What is a simple but effective way to achieve this uptime goal?
Use a CloudFront distribution to serve up your API. Even if the region your API is in goes down, the edge locations CloudFront uses will be fine.
Use an ELB and a cross-zone ELB deployment to create redundancy across datacenters. Even if a region fails, the other AZ will stay online.
Create a Route53 Weighted Round Robin record, and if one region goes down, have that region redirect to the other region.
Create a Route53 Latency Based Routing Record with Failover and point it to two identical deployments of your stateless API in two different regions. Make sure both regions use Auto Scaling Groups behind ELBs. (Refer link)
