Episode 10: Amazon Route 53 - DNS & Global Traffic Routing Deep Dive | SAA-C03 Exam Prep

Hey everyone, Balu here. Welcome back to Tech Talk with Balu. Your complete guide to asing the AWS Solutions Architect Associate Exam. We are on episode 10 and today we're diving into Amazon Route 53. That's AWS's DNS service. If you're building applications that need to be accessible over the internet, you need DNS and Route 53 is AWS's answer to DNS management. Here's why this matters. DNS is the backbone of the internet. When users type your website address into their browser, DNS translates that human friendly name into an IP address that computers can understand. Without DNS, users would need to remember IP addresses like, you know, the 54.239.28.85 instead of Amazon.com. Route 53 does way more than just basic DNS. It provides intelligent traffic routing based on latency, geography, health checks and more. You can route the users to the fastest server, implement automatic failover during outages and distribute traffic across multiple regions. So today we are covering what DNS is and how it works. Route 53 fundamentals and hosted zones. DNS record types, the AAA, the C name and the alias records, seven routing policies that simple weighted latency, failover, geolocation, joke proximity and multi-value. We are covering health checks for automatic failover. We are covering domain registration and of course, exam traps at the end. By the end of this episode, you'll understand how to use Route 53 to build globally distributed highly available applications with intelligent traffic routing. So let's dive straight in. Let's start with the basics. What is DNS? DNS stands for domain name system. It translates human friendly host names into machine IP addresses. So when you type www.google.com into your browser, DNS translates that into an IP address like 172.217.18.36. Your browser then connects to that IP address. DNS is the backbone of the internet without it. We'd all be memorizing IP addresses. Just imagine telling someone to visit your website at 54.239.28.85. Well, that's terrible. Much better to say visit Amazon.com or your website. DNS uses a hierarchical name in structure. So let me break down a URL for you. HTTP.4/4/API.ww.example.com. Now reading from right to left, the route is the dot at the very end. It's usually not shown. Com is the top level domain or TLD. Example.com is the second level domain or called SLD. www is a subdomain. API here is another subdomain. So the full name is api.ww.example.com is called a fully qualified domain name or FQDN. Now how does DNS actually work? Let me walk through what happens when you visit a website. So you type example.com into your browser. Your browser asks your local DNS server. What's the IP address for example.com? Your local DNS server is typically provided by your ISP or your company. It doesn't know the answer. So it asks the root DNS server. The root DNS server says I don't know example.com's IP but what I know is the name server for dot com domains. Go ask that. The local DNS server then asks the TLD DNS server for dot com. What is the IP address for example.com? The TLD server says I don't know the IP but I know the name server for example.com. Go ask that. Finally the local DNS server asks the authoritative name server for example.com. What's the IP address? The authoritative name server responds example.com is at IP address 9.10.11.12 for example. The local DNS server caches this answer and returns it to your browser. Your browser then happily connects to 9.10.11.12. This entire process by the way happens in milliseconds. The caching at each level means subsequent requests for the same domain are much faster. For the exam understand the basic DNS hierarchy and that DNS queries go through multiple levels before reaching the authoritative answer. Now let's talk about Amazon Route 53. So what is Route 53? Route 53 is AWS's highly available scalable fully managed and authoritative DNS service. Now let me explain what authoritative means. An authoritative DNS service means you the customer control the DNS records. You decide what example.com points to. Route 53 doesn't make that decision for you. You do that. Route 53 is also a domain registrar by the way. You can buy domain names directly through Route 53. So you can register your domain and manage DNS all in that single one place. Route 53 provides health checking. It can monitor your resources and automatically route traffic away from unhealthy endpoints. If your server in one region goes down, Route 53 can redirect traffic to a healthy server in another region. Now here's something unique. Route 53 is the only AWS service with 100% available DSLA. AWS guarantees it will be available. That's how critical DNS is. By the way, why is it called Route 53? Route 53 is the traditional DNS port. That's very clever naming. Now let's talk about hosted zones. What's a hosted zone? A hosted zone is a container for DNS records. It defines how to route traffic for a specific domain and its subdomains. Route 53 has two type of hosted zones. First, the public hosted zones. These contain records for routing traffic on the public internet. When someone on the internet queries your domain, Route 53 responds with these public records. Example, you create a public hosted zone for mypublicdomain.com. You are a record saying www.mypublicdomain.com points to your application load balancer. Anyone on the internet can now visit your website and can reach your load balancer. The second one we'll look at is private hosted zones. These contain records for routing traffic within your VPCs. These records are not accessible from the public internet. An example is you can create a private hosted zone for company.internl. You add a record saying database.company.internl points to your RDS's instances private ip. Easy to instances in your VPC can then query database.company.internl and get the private ip. The internet cannot access this. Private hosted zones are perfect for internal applications, databases and microservices that should only be accessible from within your AWS environment. Hosted zones cost about a dollar per month per hosted zone plus your paper query but it's very cheap. It's 40 cents per million queries for the first billion queries. For the exam, remember route 53 is AWS's managed DNS service. Authoritative means you control the records. It's got 100 person available yesterday. This is the only AWS service with this capability. There are two zone configuration. One is the public hosted zones that's for internet accessible resources and then there is the private hosted zones for resources within VPCs and it costs about half a dollar per month per hosted zone. Alright, now let's talk about DNS record types. Route 53 supports many record types but for the exam you need to know four main ones. That is A, A, A, A, A, C name and alias. Each DNS record contains several pieces of information. The domain or sub domain name like example.com or www.example.com. The record type which is either A or 4A's, C name etc. The value which is the IP address or host name it points to the routing policy. That's how route 53 responds to those queries. We'll cover this in detail a bit later. The TTL which is the time to live. That is how long DNS resolvers should cache the record. Now let's go through each record type. First, the A record is stands for address. An A record maps a host name to an IPv for address. Example www.example.com then points to 12.34.56.78. This is the most common record type. When you want your website to point to a specific IP address, you use an A record. Second, the A, A, A record 4A's. An A, A record maps a host name to an IPv6 address. IPv6 addresses are much longer than IPv4. So they look like, you know, 2001 call and 0db8 call and so on and so forth. As the world transitions to IPv6, you'll see more A, A, A records. For now, A records for IPv4 are still dominant. Third, we have the C name record. C name stands for canonical name. A C name maps a host name to another host name. Example www.example.com then maps to app.example.com. The target must be a domain name that has either an A or an A A A A record. You're essentially creating an alias from one name to another. Here is though a critical limitation you need to remember. You cannot create a scene name record for the zone Apex. That's the top node of your DNS name space. Okay, what does that mean? If your domain is, for example, example.com, you cannot create a scene name, for example.com itself. You can only create a scene name or see names for subdomains like www.example.com or api.example.com. This limitation is built into the DNS specification itself. It is not an AWS limitation, by the way. So how do you point example.com to another host name? Right, that's where alias records come into play. So we look at alias records. This is an AWS specific extension to DNS. An alias record maps a host name to an AWS resource. So for instance, example.com can then be mapped to my hyphen load, hyphen balancer hyphen 123456 dot us hyphen east hyphen one dot ELB dot Amazon AWS dot com. Unlike scene name, alias records work for the zone Apex. You can create an alias for example.com pointing to your load balancer. Alias records automatically recognize changes in the resources IP addresses. If your load balancers IP changes, the alias record updates automatically. You don't have to do anything. Remember alias records are always type A or AA AA for AWS resources. That's IP V4 or IP V6. Here's a huge benefit. Alias records to AWS resources are free. You don't pay for queries to alias records pointing to AWS resources like load balancers, cloud front distributions or S3 websites. You cannot set the TTL for alias records though. Route 53 manages that automatically. So what can you point alias records to? You can point alias records to elastic load balancers, cloud front distributions, API gateway, elastic bean stock environments, S3 website and points, VPC interface and points, global accelerator and other route 53 records in the same hosted zone. Remember an important limitation is that you cannot create an alias record pointing to an EC2 instances DNS name. If you need to point to EC2, you use the EC2 instance IP with an A record. So here is a simple decision tree for you to remember. If you need to point to an IP V4 address, then use a record. If you need to point to an IP V6 address, then you use AA AA record. If you need to point one host name to another host name for a subdomain, you use a C name record. If you need to point the zone apex or any host name to an AWS resource, you use the alias record. So for the exam, remember a IP V4 address AA AA is IP V6 address. C name is host name to host name, but will not work for zone apex. You can instead use alias to map host name to AWS resources. It works for zone apex and it's free for AWS resources. Next, let's look at this concept of time to live, which is called TTL. This is important for understanding DNS performance and cost. That's when a client queries route 53 for a DNS record route 53 returns the answer along with a TTL value. The TTL tells the client cash this answer for X seconds. For example, if the TTL is 300 seconds, that's five minutes, let's say, the client caches the result for five minutes during those five minutes. If the client needs the same DNS record again, it uses the cash value instead of querying route 53 again. So high TTL, let's say 24 hours, benefit is less traffic to route 53, which means lower costs. What's the downside? So if you change the DNS record, clients with the cashed values won't see the change for up to those 24 hours. Records will stay potentially outdated. For a low TTL's configuration, like let's say 60 seconds, the benefit is records are outdated for less time changes propagate quickly, but the downside is there is more traffic to route 53, which means higher costs. So you guessed it right. So there is a trade off. If your DNS records change frequently, use a low TTL so changes propagate quickly, whereas if your DNS records are stable, then you want to use a high TTL to save money and reduce query volume. One important note though is for alias records, you cannot set the TTL. Route 53 manages it automatically based on the target resource. For all the other record types, TTL is mandatory. For the exam, understand that TTL affects cashing duration, cost and how quickly changes propagate. Okay, now we get to the heart of Route 53, that's routing policies. This is where Route 53 becomes much more than basic DNS. Routing policies define how Route 53 responds to DNS queries. Don't confuse this with load balancer routing by the way. DNS doesn't route traffic, it just responds to queries with IP addresses. The client then connects to those IPs. Route 53 supports 7 routing policies. Simple, weighted, latency, failover, geolocation, geoproximity and multi-value. Let's go through each one of them. Routing policy number one, that's simple routing. Simple routing is the most basic. You route traffic to a single resource. You create a record, let's say www.example.com and point it to an IP address like 11.22.33.44. When someone queries www.example.com, they get that IP that's done. You can specify multiple values in the same record though. If you provide three IP addresses, Route 53 returns all three and the client randomly then chooses one. Simple routing cannot be associated with health checks. Remember that there is no intelligence here, just basic DNS lookup. So when would you use simple routing? When you have a single resource or multiple resources and you don't care which one the client connects to, you want to use simple routing. Onto routing policy two, weighted routing. Weighted routing lets you control the percentage of traffic going to each resource. You create multiple records with the same name but different weights. Route 53 routes traffic based on the weight proportions. As an example, if you have three servers, you assign weights for let's say 70, 20 and 10. The calculation is traffic percentage is equal to weight for this record divided by sum of all the weights. So 70 divided by 70 plus 20 plus 10, that's 70 divided by 100. That's equal to 70% of traffic goes to the first server. 20% goes to the second and 10% goes to the third. One note is that weights don't need to sum to 100. They are just relative proportions. Let's look at the use case. Load balancing between regions. You have servers in U.S. East 1 and U.S. 1. You want to send 80% of traffic to U.S. East 1 and 20% to U.S. to 1. This is a great example of where you can use weighted routing. Another use case. You want to test new application versions. You release a new version, but want to test it carefully. You want to send 5% of traffic to the new version and 95% to the old version. If the new version works well, then you gradually increase its weight. You can set a weight of 0 to stop traffic to a resource without deleting the record. Weighted routing can be associated with Hellchecks. If a resource becomes unhealthy, Route 53 stops routing traffic to it. Pretty sweet. Routing policy number 3. Latency-based routing. Latency-based routing directs users to the resource with the lowest network latency. You create multiple records for the same host name each in a different AWS region. When a user queries, Route 53 evaluates which region has the lowest latency for that user and returns that region's IP. This is based on actual network latency measurements between the users and AWS regions, not the geographic proximity. An example is, you have servers in US East 1, EU West 1, and AP Southeast 1. A user in India queries your domain. Route 53 then determines that AP South East 1 has the lowest latency for that user and returns the IP of your server in Singapore. A user in Germany queries the same domain. Route 53 determines that EU West 1 has the lowest latency and returns your Ireland server's IP. This gives users the best possible performance automatically. Latency-based routing can be associated with Hellchecks 2. If the lowest latency region is unhealthy, Route 53 routes to the next lowest latency health region. On to routing policy 4. Failure routing. Failure routing implements active passive failure. You designate a primary resource and the secondary resource. Route 53 routes all the traffic to the primary as long as it's healthy. If the primary fails its Hellchecks, Route 53 automatically routes traffic to the secondary. This is mainly used for disaster recovery. Your primary instance is in US East 1. Your secondary disaster recovery instance is in US 1. Under normal conditions all traffic goes to US East 1. If US East 1 fails then traffic automatically fails over to US 1. Hellchecks are mandatory for the primary resource in failover routing, without Hellchex Route 53 just doesn't know when to failover. Onto routing policy #5 - Geo Location Geo Location routing routes traffic based on the user's geographical location. You create records specifying locations that's either the continent, country, or a US state. Route 53 routes users to the record matching their location. An example is, users from Europe gets routed to your server in Ireland. Users from the US get routed to your server in Virginia. Users from Asia gets routed to your server in Singapore. If there is overlapping, say you have a record for Europe and a specific record for Germany, the most precise match wins. German users get the Germany record, other European users get the Europe record. You should create a default record for users whose location doesn't match any specific record, otherwise they get no response. Use cases are web site localization, that is to show European users the European version of your website with local pricing and language or restrict content distribution based on geography, comply with data residency requirements and so forth. Geo Location routing can be associated with Hellchex. On to routing policy 6, Geo proximity routing. Geo proximity routing routes traffic based on the geographical location of the users and the resources with the ability to shift traffic using a bias. This is different by the way from Geo location. Geo location, remember is strict if you're in Europe, you get the Europe record. Geo proximity lets you adjust the boundaries. You specify a bias value from -99 to +99, a positive bias expands the geographical region more traffic flows to this resource. On the other hand, a negative bias shrinks the region, that's less traffic flows to this resource. An example is you have servers in US East 1 and US West 1 with no bias. Users get routed to the geographically closer region. Now let's say you set a bias of positive 50 for US East 1. The geographical region for US East 1 now expands. More users, even some closer to US West 1 gets routed to US East 1. To use Geo proximity, you must use route 53 traffic flow, which is a visual editor for complex routing configurations. On to routing policy 7, multi-value answer routing. Multi-value answer routing returns multiple values that's up to 8 in response to DNS queries. It's similar to simple routing but with Hellchecks. Route 53 only returns value for healthy resources. An example is that you have 10 web servers. You create 10 multi-value records all with the same name each pointing to one server. Each record has a Hellcheck. When a client queries route 53 returns up to 8 healthy server IPs. The client chooses one and connects. If some servers are unhealthy, route 53 only returns the healthy ones. Multi-value is not a substitute for a load balancer remember that. It's client side load balancing. The client receives multiple IPs and then picks one. With a real load balancer, client connects to one IP and the load balancer distributes traffic. For the exam, you want to know all the seven routing policies. Simple, that's basic DNS, one or more resources, there's no Hellchecks. There is weighted which controlled traffic percentage, used for AB testing and regional distribution use cases. There is latency routing. That's the lowest latency for users and is best in performance. There is failover routing that's an active passive kind of mechanism and requires Hellchecks on the primary. There is geolocation routing that routes based on user location. It's got straight geographical boundaries. There is geoproximity routing that routes based on geography but with an adjustable bias. It's used for traffic flow and then there is finally multi-value routing that returns multiple healthy IPs up to 8 with Hellchecks enabled. Now let's talk about health checks. Health checks are critical for automated failover. Route 53 Hellchecks monitor the health of your resources. If a resource becomes unhealthy, route 53 then stops routing all traffic to it. Hellchecks are only for public resources. They cannot directly monitor private resources inside your VPC. There are three types of Hellchecks. The first one, Hellchecks that monitor an endpoint, an application, server or AWS resource. About 15 global Hellcheckers distributed around the world send requests to your endpoint. If more than 18% of the Hellcheckers report that the endpoint is healthy, then route 53 considers it healthy, otherwise it's unhealthy. The default threshold is 3 consecutive checks. You can configure the interval. The default is 30 seconds or you can set it to 10 seconds for faster detection but it costs higher. Hellchecks support HTTP, HTTPS and TCP protocols. For HTTP and HTTPS, the Hellcheck passes only if the endpoint receives with a 2XX or 3XX status code. You can also configure the Hellcheck to look for specific text in the first 520 bytes of the response. An important thing you must remember is that you must configure your firewall or security groups to allow incoming requests from your route 53 Hellcheckers. Route 53 publishes the IP ranges of Hellcheckers. So if you block them, Hellchecks fail even though your server is healthy. The second type of Hellcheck is calculated Hellchecks that monitor other Hellchecks. You can combine multiple Hellchecks using OR and NOT operational logic. You can monitor up to 256 child Hellchecks. An example is that you have 3 servers. You create a Hellcheck for each of them and then you create a parent calculated Hellcheck that passes if at least 2 out of 3 children pass. In use cases you're doing maintenance on one server. You don't want all the Hellchecks to fail. The calculated Hellchecks still passes because 2 out of 3 servers are still healthy. The third type of Hellchecks is Hellchecks that monitor cloud watch alarms. This is how you monitor private resources by the way. You cannot create a Hellcheck directly to a private resource because Hellcheckers are outside your VPC. Instead you create a cloud watch metric for your private resource. Maybe CPU utilization or custom application metrics let's say. Create a cloud watch alarm based on that metric and then create route 53 Hellchecks that monitors that alarm. Now if the alarm goes into an alarm state the Hellcheck fails. Route 53 stops routing traffic to that resource. This gives you full control. You can monitor anything that cloud watch can monitor. DynamoDB throttles, RDS metrics, custom application metrics, anything. For the exam remember Hellchecks are for public resources by default. They're up to 15 Hellcheckers worldwide that monitor each endpoint. We deem healthy threshold which is greater than 18% of the checkers that report healthy. It supports HTTP, HTTPS and TCP protocols. You must allow Route 53 Hellcheckers IPs through the firewalls. Calculated Hellchecks combine multiple checks with and/or not operation and for private resources you want to use cloud watch alarms with Hellchecks monitoring these alarms itself. Okay so the final topic we're covering today in this episode is domain registration. So let me quickly cover domain registration because it confuses people. A domain registrar is a company where you buy or register your domain name. You might have heard some of the common registrars like GoDaddy or Namecheap but by the way Amazon Route 53 is a domain registrar too. When you register a domain you typically pay an annual fee that's around 10-20 dollars per year for common domain names like.com. The domain registrar usually provides DNS service to manage your DNS records but here's a key. You can use a different DNS service as an example. You can register your domain with GoDaddy but you can use Route 53 to manage your DNS records. Okay so how does this all work? When you register a domain with any registrar you specify name service. Name service are the authoritative DNS service for your domain. If you want to use Route 53 for DNS you create a hosted zone in Route 53. Route 53 gives you four name service. You then update your domains registrar settings to use Route 53's name service. Now when someone queries your domain the query eventually reaches Route 53 which responds with your DNS records. This is common. Many people registered domains with one company but manages DNS with Route 53 because Route 53 provides advanced functionalities and features like health checks and sophisticated routing policies. So for the exam I want you to remember domain registrar is where you buy the domain. DNS service is where you manage DNS records. They don't have to be the same company but to use Route 53 for DNS you want to update your domain name service to Route 53's name service. All right now for the most interesting part of this episode exam trap and gotchas. Let's cover some of the common Route 53 exam traps. Trapped number one see name cannot be used for zone apex. Question point example.com to load balancer. Can you use a C name? No, you can't. C name cannot be used for zone apex. That's the naked domain. The right answer is to use an alias record. Alias records work for zone apex. Trap number two. Alias records are free for AWS resources. Question. I want to minimize DNS query costs. Do I use C name or alias to point to a load balancer? The answer is alias. Queries to alias records pointing to AWS resources are free. Trap number three. Weighted routing weights don't need to sum to 100. You have three records with weights 70, 20 and 10 respectively. What percentage goes to the third? People might think weights must sum to 100, so 10 percent. That's correct. It is 10 percent, but understand that weights are relative. You could use weights of seven, two, one and get the same 70 percent, 20 percent, 10 percent distribution. Trap number four. Latency routing is based on network latency, not geographic distance. Question is, your user is in New York and your servers are in Virginia and California. Latency routing sends them to Virginia because it's geographically closer. Is that right? The answer is usually yes, but not always. Latency routing is based on actual network latency measurements and not the distance. If there is network congestion in Virginia, the user might get routed to California. Trap number five. Geolocation routing needs a default record. The question is, you have set up a geolocation routing with the records for US and Europe. User from Australia queries what happens. The answer is, if there is no default record, the user gets no response. So you remember you always want to create a default record for unmatched locations. Trap number six. Failure routing requires hell checks on primary. You want to implement failure routing. Do you need hell checks? The answer is definitely yes. Hell checks are mandatory for primary resource. In this case, without them, route 53 will not know when to fail over. Trap number seven. Hell checks are for public resources. Question is, you want to create hell check for RDS database in a private subnet. How do you do it? The answer is you cannot directly create hell check for a private resource. We've covered that earlier. You want to instead use cloud watch alarms and then create alarm on RDS metrics, then create hell check that monitor this alarm. Trap number eight. Multi-value routing is not a load balancer. Can you use multi-value routing instead of an elastic load balancer? The answer is definitely no. Multi-value returns multiple IPs to the client which then takes one. It's client-side selection. A load balancer on the other hand actively distributes traffic on the server site. Multi-value doesn't replace a load balancer. Remember that. Trap number nine. Jaw proximity requires traffic flow. The question is, can you use jaw proximity routing with bias? Yes, you must use route 53 traffic flow which is a visual policy editor. You cannot configure jaw proximity without traffic flow. Trap number 10. Route 53 has 100% availability SLA. Question is, which AWS service has 100% availability SLA? Of course, the answer is route 53 and that's the only one. This makes it a very critical infrastructure. Trap number 11. TTIL doesn't apply to alias records. The question is, you want to set TTIL for alias record pointing to a load balancer? The answer is you cannot set TTIL for alias records. Route 53 manages it based on the target resource. And finally, Trap 12. Simple routing cannot have help checks. Can you have a simple routing with help checks? The answer is not possible. Simple routing doesn't support help checks. You want to use multi-value routing if you need multiple values with help checks. Okay, and finally, let's look at some exam quick tips. TIP number one. Route 53 is AWS's managed DNS service. TIP number two. You want to use public hosted zones for internet traffic while you want to use private hosted zones for VPC internal traffic. TIP number three. Use a record for IPv4 and AAAA for IPv6. C name for host name to host name but not for zone apex alias for AWS resources and it works for zone apex. TIP number four. There's no query charges. TIP number five. There are seven routing policies. Please know when to use each of them. There is simple for basic DNS. Weighted for traffic percentage control. Latency for best performance. Failure for DR. Geolocation for strict geographical routing. Geoproximity for geographical routing with bias. And finally, multi-value for multiple IPs with help checks. Remember them. TIP number six. Failure routing requires health checks on primaries mandatory. TIP number seven. Health checks are for public resources only. For private resources, you want to use cloud watch alarms and then monitor them. TIP number eight. TTI means less cost but slower propagation. TTI low means higher cost but faster propagation. TIP number nine. You cannot set TTI for alias records because Route 53 manages them. And finally, TIP 10. Route 53 is the only AWS service with 100 person availability SLA. All righty, everyone. That's episode 10 on Amazon Route 53. We covered a lot today as usual. We started with DNS fundamentals and how DNS resolution works through multiple levels. We explored Route 53 as AWS managed DNS service with 100 person availability SLA. Public and private hosted zones for different use cases. We went deep on DNS record types that's A, A, A, A, A, C name and the AWS specific alias record that works for the zone apex and is free for AWS resources. We then covered all the seven routing policies that symbol weighted latency, fail over geolocation, geoproximity and multi-value. Each serves different use cases from basic DNS to sophisticated global traffic management. We then learned about health checks for automatic fail over and monitoring how to monitor public resources directly and private resources through cloud watch alarms. We discussed domain registration and how you can use Route 53 for DNS even if you register your domain elsewhere and we finished with 12 exam traps that trip people up on the test day. The key takeaway is that Route 53 is much more than basic DNS. It's a powerful traffic management service that enables global applications with intelligent routing, automatic fail over and health monitoring. In our next episode, we are diving into VPC architecture that is virtual private clouds. We will cover subnets, route tables, internet gateways, NAT gateways and the critical distinction between security groups and network ACLs. This is the core AWS networking and is absolutely essential for the exam. If this episode helped you master Route 53, please do consider to leave a five star rating on Spotify and to share it with anyone studying for the AWS exam. So until next time, keep studying, keep practicing and I will see you in episode 11. This is by LoL signing off, bye.