In this section of the AWS Certified: SAP on AWS Specialty learning path, we introduce you to the various Networking services currently available in AWS that are relevant to the PAS-C01 exam.
- Identify and describe the various Networking services available in AWS
- Describe how to configure an Amazon Virtual Private Cloud (VPC)
- Understand how to control network traffic via Security Groups and Network Access Control Lists (NACLs)
- Describe AWS-managed services for Domain Name System (DNS) and Content Delivery Network (CDN)
- Understand how the AWS global infrastructure is used in conjunction with services like Route 53, CloudFront, and the AWS Global Accelerator to reduce latency and improve application performance for end-users
- Identify networking and VPC configuration options for SAP environments running on AWS
The AWS Certified: SAP on AWS Specialty certification has been designed for anyone who has experience managing and operating SAP workloads. Ideally you’ll also have some exposure to the design and implementation of SAP workloads on AWS, including migrating these workloads from on-premises environments. Many exam questions will require a solutions architect level of knowledge for many AWS services, including AWS Networking services. All of the AWS Cloud concepts introduced in this course will be explained and reinforced from the ground up.
DNS, or Domain Name System, is a hierarchical distributed naming system for computers, services or any resource connected to the internet or a private network. It associates various information with domain names, such as CloudAcademy.com or Amazon.com, and is responsible for the translation of domain names to IP addresses. A common analogy used to explain DNS, is that it is the phone book of the internet, as you can look up a human-friendly name. For example, www.CloudAcademy.com, and it will provide the respective IP address.
Now going back to Route 53, Route 53 is Amazon's highly available and scalable domain name system that provides secure and reliable routing of requests, both for services within AWS and infrastructure that is outside of AWS. Route 53 is able to provide this service through its global network of authoritative DNS servers that reduce latency and can be managed via the management console or API.
To understand Route 53, let me explain some of the components and elements used within the service, starting with Hosted Zones.
A hosted zone is a container that holds information about how you want to route traffic for a domain such as CloudAcademy.com. Route 53 supports the following type of zones: A public hosted zone. This zone determines how traffic is routed on the internet and can be created when you register your domain with Route 53. A private hosted zone. This zone determines how traffic is routed within the Amazon VPC. If your resources are not accessible outside of the VPC you can use any domain name you wish.
Next, there are different domains that are supported by Route 53, and these include: generic top-level domains, known as TLDs. For example .watch which may be used for websites relating to streaming, video, or watches. Or perhaps .clothing, used by those in the fashion industry, such as retailers and department stores, as well as designers. So essentially TLDs are used to help determine what information you might expect to find on the website Then we have: Geographic domains For example .com.au (Australia), or .uk for the United Kingdom. So these are used to represent the geographical location of the site itself.
Next, we have resource record types, and Route 53 supports the most common types, which will meet the needs for the majority of customer DNS requirements as shown in this table. In addition to these record types, Route 53 also uses Alias records, which are a Route 53-specific extension to DNS. These Alias records which act like a CNAME record allow you to route your traffic to other AWS resources, such as Elastic load balancers, Elastic Beanstalk environments, CloudFront distributions, VPC Interface Endpoints, or S3 buckets configured as static websites.
Routing Policies. When you create a resource record set, you must choose a routing policy that will be applied to it, and this then determines how Route 53 will respond to these queries. The routing policies available within Route 53 include:
Simple routing policy: This is the default policy, and it is for single resources that perform a given function. For example, a single web server, in this case, all responses to the DNS query are based solely on the values you entered into the resource record when you created it.
Failover routing policy: This allows you to route traffic to different resources based upon the health of those resources. If the primary resource is healthy then traffic will be directed to that resource, if it becomes unhealthy then the routing policy will route the traffic to an alternate healthy resource. This is considered as an active-passive failover mechanism.
Geo-location routing policy: This lets you route traffic based on the geographic location of your users. You can define geographic routing policies based on continent, country or state in the U.S. If you have overlapping geographic regions, for example continent and country, it will direct to the smallest denominator, and in this case, that would be country. Geo-location can also be used to restrict access to your site based on location the geographic origin of the traffic. Or perhaps you want to direct all DNS queries from Europe to an elastic load balancer in the London region.
Geoproximity routing policy: This policy is based upon the location of both the users and your resources, whereas geo-location is based purely on the location of the users. Geoproximity allows you to set a bias against resources that can either route more or less traffic to your resource. This bias can either expand or reduce the geographic regional scope of traffic that can be routed to your resource.
Latency routing policy: This is suitable when you have resources in multiple regions, and you want Route 53 to respond to DNS queries with resources that provide the lowest latency for the request.
Multivalue answer routing policy: This allows you to get a response from a DNS request from up to 8 records at once that are picked at random, all of which will be healthy resources. This helps to factor in a level of load balancing and enhance availability.
Weighted routing policy: This is suitable when you have multiple resource records that perform the same function, such as a website, and you want to route traffic between them based on proportions that you specify. To determine the probability, the formula is the weight of the individual resource record divided by the sum of the total value in resource record set. For example, if you have three servers, weights are assigned two, two and six, a sum of 10. The first two are selected 20% of the time, and the last one 60% of the time.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.