AWS Developer Associate Certification Summary Notes (Part 2)

Route 53, VPC

Hi reader, I have cleared the exam with 868/1000 on June 26, 2022. These are my personal notes, do check out other parts as well. A shout out to Stephane Maarek’s ellaborate and thorough udemy course and its hands on excercises and Jon Bonso’s tough Practice tests.

Amazon Route 53

All computers on the internet, from your smart phone or laptop to the servers that serve content for massive retail websites, communicate with one another by using numbers. These numbers, known as IP addresses, are in one of the following formats:

  • Internet Protocol version 4 (IPv4) format, such as
  • Internet Protocol version 6 (IPv6) format, such as 2001:0db8:85a3:0000:0000:abcd:0001:2345

When you open a browser and go to a website, you don’t have to remember and enter a long string of characters like that. Instead, you can enter a domain name like and still end up in the right place. A DNS service such as Amazon Route 53 helps to make that connection between domain names and IP addresses.

DNS Terminologies

The following is a list of terms common to DNS. They can help you understand the procedures for adding custom domains.

CNAME: A Canonical Record Name (CNAME) is a type of DNS record that masks the domain for a set of webpages and makes them appear as though they are located elsewhere. A CNAME points a subdomain to a fully qualified domain name (FQDN). For example, you can create a new CNAME record to map the subdomain, where www is the subdomain, to the FQDN domain assigned to your app in the Amplify console.

ANAME: An ANAME record is like a CNAME record, but at the root level. An ANAME points the root of your domain to an FQDN. That FQDN points to an IP address.

Name server : A name server is a server on the internet that’s specialized in handling queries regarding the location of a domain name’s various services. If you set up your domain in Amazon Route 53, a list of name servers are already assigned to your domain.

NS record : An NS record points to name servers that look up your domain details.

A : Maps host name to IPv4.

AAAA : Maps hostname to IPv6.

Advanced record types are CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, SRV

For hosted zones and records, the domain name can include any of the following printable ASCII characters (excluding spaces):

  • a-z
  • 0–9
  • - (hyphen)
  • ! “ # $ % & ‘ ( ) * + , — / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ .

Amazon Route 53 stores alphabetic characters as lowercase letters (a-z), regardless of how you specify them: as uppercase letters, lowercase letters, or the corresponding letters in escape codes.

If the domain name includes any characters other than a to z, 0 to 9, — (hyphen), or _ (underscore), Route 53 API actions return the characters as escape codes. This is true whether you specify the characters as characters or as escape codes when you create the entity. The Route 53 console displays the characters as characters, not as escape codes.

Hosted zones — >You can’t include an * in the leftmost label in a domain name. For example, * is not allowed. If you include * in other positions, DNS treats it as an * character (ASCII 42), not as a wildcard.

Records — >DNS treats the * character either as a wildcard or as the * character (ASCII 42), depending on where it appears in the name.

Amazon Route 53: Its a highly available, Authoritative(Meaning you can update the DNS records) DNS. It is also a domain registar.

When you register a domain with Route 53, the service automatically makes itself the DNS service for the domain by doing the following:

  • Creates a hosted zone that has the same name as your domain.
  • Assigns a set of four name servers to the hosted zone. When someone uses a browser to access your website, such as, these name servers tell the browser where to find your resources, such as a web server or an Amazon S3 bucket. (Amazon S3 is object storage for storing and retrieving any amount of data from anywhere on the web. A bucket is a container for objects that you store in S3.)
  • Gets the name servers from the hosted zone and adds them to the domain.

Hosted Zone: A container for records, which include information about how you want to route traffic for a domain (such as and all of its subdomains (such as,, and A hosted zone has the same name as the corresponding domain.

There are two types, Public Hosted Zones and Private Hosted Zones. Like what their names suggests, Public HZ has records to define how to route traffic in the internet and Private HZ does it for VPCs.

Private Hosted Zone

A private hosted zone only responds to queries coming from within the associated VPC and it is not used for hosting a website that need to be publicly accessed.

The main use case of a private hosted zone is split-view DNS. We can use Amazon Route 53 to configure split-view DNS, also known as split-horizon DNS. If we want to maintain internal and external versions of the same website or application (for example, for testing changes before we make them public), we can configure public and private hosted zones to return different internal and external IP addresses for the same domain name. We just create a public hosted zone and a private hosted zone that have the same domain name, and create the same subdomains in both hosted zones.

We can easily manage authoritative DNS within our Virtual Private Clouds. This allows us to use custom DNS names for our internal resources without exposing the names or IP addresses to the public Internet. In other words, we use Route 53 to manage the internal DNS names for our application resources (web servers, application servers, databases, and so forth) without exposing this information to the public Internet.

This adds an additional layer of security, and also allows you to fail over from a primary resource to a secondary one

Public and Private hosted zones can have the same domain name and can contain same subdomains inside them. For example, one internal version of our website can be maintained for testing code changes before making them public.

When you create a private hosted zone, you must associate a VPC with the hosted zone, and the VPC that you specify must have been created by using the same account that you’re using to create the hosted zone. After you create the hosted zone, you can associate additional VPCs with it, including VPCs that you created by using a different Amazon account.

To associate VPCs that you created by using one account with a private hosted zone that you created by using a different account, you must authorize the association and then make the association programmatically.

CNAME vs Alias Record

  • For example, lets say we have some AWS resource (e.g., Load Balancer, CloudFront, etc..) that exposes an AWS hostname: and we want the hostname to point to it
  • In this case we can use a CNAME record. CNAME can point any non-root (also called non apex) hostname to any other hostname (e.g., =>

To create records for complex routing configurations, you can also use the traffic flow visual editor and save the configuration as a traffic policy. You can then associate the traffic policy with one or more domain names (such as or subdomain names (such as, in the same hosted zone or in multiple hosted zones. In addition, you can roll back the updates if the new configuration isn’t performing as you expected it to.

  • Again, CNAME records only work for non root domains (e.g., but Alias can be used to point to top node of DNS namespace (Zone Apex). The benefit of an Alias record is that it works for root domains and also non-root domains.
  • We can also use an Alias but note, an Alias record can only point a hostname to an AWS resource (e.g., => You cannot set Alias Record for EC2 DNS name.
  • Alias records are always of the type A/AAAA for AWS resources (IPv4/IPv6). Alias records are also free.

White label Servers/ Vanity name Servers: Each Amazon Route 53 hosted zone is associated with four name servers, known collectively as a delegation set. By default, the name servers have names like If you want the domain name of your name servers to be the same as the domain name of your hosted zone, for example,, you can configure white-label name servers, also known as vanity name servers or private name servers.

TTL: Each DNS record has a TTL (Time To Live) which orders clients for how long to cache these values and not overload the DNS Resolver with DNS requests. The TTL value should be set to strike a balance between how long the value should be cached vs. how many requests should go to the DNS Resolver.

Health Checks

A default of 3 health checks needs to be passed to consider a resource healthy, but this number can be configured. Health check is performed by around 15 health checker every 30 seconds. Health checks can be configured to pass or fail based on the first 5120 bytes of data in the response.

Calculated Health Checks: Use AND, OR or NOT to calculate health checks of a cluster. A combination of 256 resources can be used for the calculation.

Amazon Route 53 health checks monitor the health of your resources such as web servers and email servers. You can optionally configure Amazon CloudWatch alarms for your health checks, so that you receive notification when a resource becomes unavailable.

Failover: Two types of failover configurations

  • Active-Active Failover — all the records that have the same name, the same type, and the same routing policy are active unless Route 53 considers them unhealthy. Use this failover configuration when you want all of your resources to be available the majority of the time.
  • Active-Passive Failover — use this failover configuration when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable. When responding to queries, Route 53 includes only the healthy primary resources.
  • To create an active-passive failover configuration with one primary record and one secondary record, you just create the records and specify Failover for the routing policy.
  • To configure active-passive failover with multiple resources for the primary or secondary record, create records with the same name, type, and routing policy for your primary resources. If you’re using AWS resources that you can create alias records for, specify Yes for Evaluate Target Health.

CIDR Block: A CIDR block is an IP range used with IP-based routing. In Route 53 You can specify CIDR block from /0 to /24 for IPv4 and/0 to /48 for IPv6. For example, a /24 IPv4 CIDR block includes 256 contiguous IP addresses. You can group sets of CIDR blocks (or IP ranges) into CIDR locations, which are in turn grouped into reusable CIDR collections.

Route 53 — Routing policies : Defines how the routing / response to the DNS queries are done. There are different types of routing policies, like, Simple, Weighted, Failover, Latency based, Geolocation, Multi-value Answer and Geoproximity.

Simple Routing: Single value response. If multiple values are returned, a default is choosen at random on the client side. Cannot attach health checks.

Weighted Routing: Self explanatory. Can associate with healths checks. A weight of zero will stop sending that resourse as a response. If all records have same weight even if its zero, all of them will be returned equally.

Latency Routing: Returning a response which will result in least latency and can be associated with health checks.

FailOver Routing: When there is a primary resource, it needs to pass the health check to be returned as a response else a secondary resourse set for disaster recovery will be returned.

Geolocation Routing: Response based on the geolocation of the request origin. A default record is required in case of no location match.


GeoProximity : Similar to Geoloaction but based on distance.

You can also optionally choose to route more traffic or less to a given resource by specifying a value, known as a bias.

Here’s the formula that Amazon Route 53 uses to determine how to route traffic:

Positive bias

Biased distance = actual distance * [1 - (bias/100)]

Negative bias

Biased distance = actual distance / [1 + (bias/100)]

Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers

Multi Value Routing: When you need to return a max of 8 healthy records as a response. Its optional to perform health checks or not. Usually it will return only healthy records but if all the resources are unhealthy, it will return all the unhealthy records. Its not suitable for having Elastic Load balancer.

Note the following:

  • If you associate a health check with a multivalue answer record, Route 53 responds to DNS queries with the corresponding IP address only when the health check is healthy.
  • If you don’t associate a health check with a multivalue answer record, Route 53 always considers the record to be healthy.
  • If you have eight or fewer healthy records, Route 53 responds to all DNS queries with all the healthy records.
  • When all records are unhealthy, Route 53 responds to DNS queries with up to eight unhealthy records.

IP based Routing: With IP-based routing in Amazon Route 53, you can fine-tune your DNS routing by using your understanding of your network, applications, and clients to make the best DNS routing decisions for your end users. IP-based routing gives you granular control to optimize performance or reduce network costs by uploading your data to Route 53 in the form of user-IP-to-endpoint mappings.

Geolocation and latency-based routing is based on data that Route 53 collects and keeps up to date. This approach works well for the majority of customers, but IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider may want to route end users from a particular Internet Service.

Some common use cases for IP-based routing are as follows:

  • You want to route end users from certain ISPs to specific endpoints in order to optimize network transit costs or performance.
  • You want to add overrides to existing Route 53 routing types such as geolocation routing based on your knowledge of your clients’ physical locations.

Making Route 53 the DNS service for a domain that’s in use

If you want to migrate DNS service to Amazon Route 53 for a domain that is currently getting traffic — for example, if your users are using the domain name to browse to a website or access a web application — perform the procedures in this section.

Step 1: Get your current DNS configuration from the current DNS service provider (optional but recommended)
Step 2: Create a hosted zone
Step 3: Create records
Step 4: Lower TTL settings
Step 5: (If you have DNSSEC configured) Remove the DS record from the parent zone
Step 6: Wait for the old TTL to expire
Step 7: Update the NS records to use Route 53 name servers
Step 8: Monitor traffic for the domain
Step 9: Change the TTL for the NS record back to a higher value
Step 10: Transfer domain registration to Amazon Route 53
Step 11: Re-enable DNSSEC signing (if required)


Attackers sometimes hijack traffic to Internet endpoints such as web servers by intercepting DNS queries and returning their own IP addresses to DNS resolvers in place of the actual IP addresses for those endpoints. Users are then routed to the IP addresses provided by the attackers in the spoofed response, for example, to fake websites.

You can protect your domain from this type of attack, known as DNS spoofing or a man-in-the-middle attack, by configuring Domain Name System Security Extensions (DNSSEC), a protocol for securing DNS traffic.

When you configure DNSSEC for your domain, a DNS resolver establishes a chain of trust for responses from intermediate resolvers. The chain of trust begins with the TLD registry for the domain (your domain’s parent zone) and ends with the authoritative name servers at your DNS service provider. Not all DNS resolvers support DNSSEC. Resolvers that don’t support DNSSEC don’t perform any signature or authenticity validation.

Cloud Watch Metrics

Route 53 automatically sends the number of DNS queries to CloudWatch for all public hosted zones, so you don’t need to configure anything before you can view query metrics. There’s no charge for DNS query metrics.

Getting more detailed data about DNS queries

To get more detailed information about each DNS query that Route 53 responds to, including the following values, you can configure query logging:

  • Domain or subdomain that was requested
  • Date and time of the request
  • DNS record type (such as A or AAAA)
  • Route 53 edge location that responded to the DNS query
  • DNS response code, such as NoError or ServFail

Public DNS Query Logging: Each log file contains one log entry for each DNS query that Amazon Route 53 received from DNS resolvers in the corresponding edge location. Each log entry includes the following values:

Log format version: The version number of this query log. If we add fields to the log or change the format of existing fields, we’ll increment this value.

Query timestamp: The date and time that Route 53 responded to the request, in ISO 8601 format and Coordinated Universal Time (UTC), for example, 2017-03-16T19:20:25.177Z.

Hosted zone ID: The ID of the hosted zone that is associated with all the DNS queries in this log.

Query name: The domain or subdomain that was specified in the request.

Query type: Either the DNS record type that was specified in the request, or ANY.

Response code: The DNS response code that Route 53 returned in response to the DNS query.

Layer 4 protocol: The protocol that was used to submit the query, either TCP or UDP.

Route 53 edge location: The Route 53 edge location that responded to the query. Each edge location is identified by a three-letter code and an arbitrary number, for example, DFW3. The three-letter code typically corresponds with the International Air Transport Association airport code for an airport near the edge location. (These abbreviations might change in the future.)

Resolver IP address: The IP address of the DNS resolver that submitted the request to Route 53.

EDNS client subnet: A partial IP address for the client that the request originated from, if available from the DNS resolver.

Here’s an example query log (Region is a placeholder):

1.0 2017-12-13T08:16:02.130Z Z123412341234 A NOERROR UDP Region -
1.0 2017-12-13T08:15:50.235Z Z123412341234 AAAA NOERROR TCP Region
1.0 2017-12-13T08:16:03.983Z Z123412341234 ANY NOERROR UDP Region 2001:db8::1234 2001:db8:abcd::/48
1.0 2017-12-13T08:15:50.342Z Z123412341234 A NXDOMAIN UDP Region
1.0 2017-12-13T08:16:05.744Z Z123412341234 TXT NOERROR UDP Region -

Resolver query logs include values such as the following:

  • The Amazon Region where the VPC was created
  • The ID of the VPC that the query originated from
  • The IP address of the instance that the query originated from
  • The instance ID of the resource that the query originated from
  • The date and time that the query was first made
  • The DNS name requested (such as
  • The DNS record type (such as A or AAAA)
  • The DNS response code, such as NoError or ServFail
  • The DNS response data, such as the IP address that is returned in response to the DNS query
  • A response to a DNS Firewall rule action

Protection from dangling delegation records in Route 53

In Route 53, when you use nameserver (NS) records to delegate the management of a subdomain to another public hosted zone, a problem could arise if the subdomain hosted zone is deleted without also deleting the delegation. Another user could potentially re-create the subdomain hosted zone and gain control via the still-active delegation belonging to the first customer. However, Route 53 protects against such “dangling” delegations by not allowing any new hosted zones with overlapping domain names to be created by using those nameservers before verifying that the delegation has first been removed.


I can’t route traffic to an Amazon S3 bucket that’s configured for website hosting

When you configure an Amazon S3 bucket for website hosting, you must give the bucket the same name as the record that you want to use to route traffic to the bucket. For example, if you want to route traffic for to an S3 bucket that is configured for website hosting, the name of the bucket must be

If you want to route traffic to an S3 bucket that is configured for website hosting but the name of the bucket doesn’t appear in the Alias Target list in the Amazon Route 53 console, or if you’re trying to create an alias record programmatically and you’re getting an InvalidInput error from the Route 53 API, one of the Amazon SDKs, the Amazon CLI, or Amazon Tools for Windows PowerShell, check the following:

  • The name of the bucket exactly matches the name of the record, such as or
  • The S3 bucket is correctly configured for website hosting.


  • Domains : 20 per Amazon account
  • Hosted zones : 500 per Amazon account
  • Hosted zones that can use the same reusable delegation set : 100
  • Amazon VPCs that you can associate with a private hosted zone per hosted zone : 300
  • The number of key signing keys (KSK) that you can create per hosted zone : 2
  • Resolver Endpoints per Amazon Region : 4
  • Queries per second per IP address in an endpoint: 10,000


VPC Fundamentals

  • VPC, Subnets, Internet Gateways, NAT Gateways
  • Security Groups, Network ACL (NACL), VPC Flow Logs
  • VPC Peering, VPC Endpoints
  • Site to Site VPN & Direct Connect

PC & Subnets

  • VPC: private network to deploy your resources (regional resources)
  • Subnets: allow you to partition your network inside your VPC (subnets are defined at the Availability Zone level)
  • A public subnet is a subnet that is accessible from the internet
  • A private subnet is a subnet that is not accessible from the internet
  • To define access to the internet and between subnets we use Route Tables

Route Tables

A route table contains a set of rules, called routes, that are used to determine where network traffic from your VPC is directed. You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table.

Each route in a route table specifies the range of IP addresses where you want the traffic to go (the destination) and the gateway, network interface, or connection through which to send the traffic (the target).

Example of route table

Internet Gateway and NAT Gateways

  • Internet Gateways help our VPC instances connect to the internet
  • Public subnet has a route to the internet gateway
  • NAT Gateways (AWS managed) and NAT Instances (self managed) allow your instances in your Private Subnets to access the internet while remaining private

NACL (Network ACL)

  • A firewall which controls the traffic from and to the subnet (i.e., the first mechanism of defense of our public subnet)
  • Can have ALLOW and DENY rules
  • Are attached at the Subnet level
  • Rules only include IP addresses

To establish internet connectivity inside a subnet:

The network ACLs associated with the subnet must have rules to allow inbound and outbound traffic — The network access control lists (ACLs) that are associated with the subnet must have rules to allow inbound and outbound traffic on port 80 (for HTTP traffic) and port 443 (for HTTPs traffic). This is a necessary condition for Internet Gateway connectivity

Security Groups

  • A firewall that controls the traffic to and from an ENI or an EC2 Instance (i.e., second mechanism of defense)
  • Can have only ALLOW rules
  • Rules can include IP addresses as well as other security groups

Egress-Only Internet Gateways

  • VPC component that allows outbound communication over IPv6 from instances in your VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances.
  • An egress-only Internet gateway is stateful.
  • You cannot associate a security group with an egress-only Internet gateway.
  • You can use a network ACL to control the traffic to and from the subnet for which the egress-only Internet gateway routes traffic.

VPC Flow Logs

  • Capture information about network traffic: VPC Flow Logs, Subnet Flow Logs & Elastic Network Interface Flow Logs
  • Captures network information from AWS managed interfaces too: Elastic Load Balancers, ElastiCache, RDS, Aurora, etc..
  • VPC Flow logs data can be published to S3 / CloudWatch Logs

DHCP Options Sets

  • Dynamic Host Configuration Protocol (DHCP) provides a standard for passing configuration information to hosts on a TCP/IP network.
  • You can assign your own domain name to your instances, and use up to four of your own DNS servers by specifying a special set of DHCP options to use with the VPC.
  • Creating a VPC automatically creates a set of DHCP options, which are domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region, and associates them with the VPC.
  • After you create a set of DHCP options, you can’t modify them. Create a new set and associate a different set of DHCP options with your VPC, or use no DHCP options at all.


  • AWS provides instances launched in a default VPC with public and private DNS hostnames that correspond to the public IPv4 and private IPv4 addresses for the instance.
  • AWS provides instances launched in a non-default VPC with private DNS hostname and possibly a public DNS hostname, depending on the DNS attributes you specify for the VPC and if your instance has a public IPv4 address.
  • Set VPC attributes enableDnsHostnames and enableDnsSupport to true so that your instances receive a public DNS hostname and Amazon-provided DNS server can resolve Amazon-provided private DNS hostnames.
  • If you use custom DNS domain names defined in a private hosted zone in Route 53, the enableDnsHostnames and enableDnsSupport attributes must be set to true.

VPC Peering

  • Connect two VPC privately using AWS network
  • Make them behave as if the two VPCs are in the same network
  • We do this by setting up a VPC peering connection between them
  • The two VPCs must not have overlapping CIDR (IP address range)
  • VPC Peering is not transitive. If we have a peering connection between (VPC A and VPC B) and (VPC A and VPC C) this does not mean that VPC C can communicate with VPC B (this means there is no transitivity)

VPC Endpoints

  • Use when you need private access from within your VPC to an AWS services
  • Endpoints allow you to connect to AWS services using a private network instead of the public network
  • This gives you increased security and lower latency to access AWS services
  • Use VPC Endpoint Gateway for S3 and DynamoDB. Only these two services have a VPC Gateway Endpoint (remember it), all the other ones have an Interface endpoint (powered by Private Link — means a private IP).
  • Use VPC Endpoint Interface for the rest of the services

Site to Site VPN & Direct Connect

Site to Site VPN: On premise VPN to AWS over the public internet. The connection is automatically encrypted

Direct Connect (DX) : Establish a private secure and fast physical connection between on-premise and AWS

Note: Site to site VPN and Direct Connect cannot access VPC endpoints

Three Tier Solution Architecture

  • Public Subnet (e.g., Public to ELB)
  • Private Subnet (e.g., ELB to EC2. That is EC2 instaces with ASG(Auto Scaling Group) sitting behind the ELB — they do not need to be accessible to anyone beside the ELB, so we use route tables to define network access between public ELB subnet and the EC2 private subnet)
  • Data Subnet (e.g., EC2 to AWS RDS + ElastiCache also sitting in private subnet)

Autonomous System Number (ASN) : Specify a private Autonomous System Number (ASN) for the virtual private gateway. If you don’t specify an ASN, the virtual private gateway is created with the default ASN (64512). You cannot change the ASN after you’ve created the virtual private gateway.

AWS prefix list ID: The AWS prefix list ID logically represents the range of public IP addresses used by the service. All instances in subnets associated with the specified route tables automatically use the endpoint to access the service. Subnets that are not associated with the specified route tables do not use the endpoint. This enables you to keep resources in other subnets separate from your endpoint.

To view the current public IP address range for a service, you can use the describe-prefix-lists command:

A prefix list is a set of one or more CIDR blocks. There are two types of prefix lists:

  • AWS-managed prefix-list — Represents the IP address ranges for an AWS service. You can reference an AWS-managed prefix-list in your VPC security group rules and in subnet route table entries. For example, you can reference an AWS-managed prefix-list in an outbound VPC security group rule when connecting to an AWS service through a gateway VPC endpoint. You cannot create, modify, share, or delete an AWS-managed prefix list.
  • Customer-managed prefix-list — A set of IPv4 or IPv6 CIDR blocks that you define and manage. You can reference the prefix-list in your VPC security group rules and in subnet route table entries. This enables you to manage the IP addresses that you frequently use for these resources in a single group, instead of repeatedly referencing the same IP addresses in each resource. You can share your prefix list with other AWS accounts, enabling those accounts to reference the prefix-list in their own resources.

In this scenario, you can use the AWS-managed prefix-lists in your security group to allow access to the VPC Gateway Endpoint of the Amazon S3 bucket. AWS will automatically update the underlying public IP ranges that are associated with these prefix-lists.


Will continue in Part 3….



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Data Scientist @ BigTapp Pte — Decision making, my strongest suit. I aspire to excel in ML, DL & AI innovations and dream to push its boundaries.