Adrian Cantrill’s SAA-C02 study course, learn.cantrill.io, 60 minutes:
CSA CCSK exam study guide, 15 minutes:
‘Global DNS’ section: ‘Multivalue Routing’, ‘Weighted Routing’, ‘Latency-based routing’, ‘Geolocation Routing’, ‘Geoproximity Routing’, ‘Interoprability’
Multivalue Routing: This routing policy can be thought of as a mixture between simple and failover routing. It starts with a hosted zone, can create many records with the same name, and ach record can have an associated health check. Up to eight healthy records are returned to the client; if there more than eight, eight are returned randomly, and any records which fail the health check will not be returned to the client. This improves availability, though it is not a replacement for load balancing.
Weighted Routing: This routing policy can be used as a simple form of load balancing, or to test new versions of software. It starts with a hosted zone and records, and you can specify a weight for each record known as the ‘record weight’: each record is given a number, the numbers are summed, and then each record is returned based on it’s weight vs. the total weight. A zero record means that the record is never returned. This can be combined with health checks. It is useful for controlling the distrbution of a group of records with the same name.
Latency-based Routing: This routing policy is best for optimizing for performance and user-experience. It starts with a hosted zone in R53 and records with the same name. You can specify a record region for each record; this routing policy supports one record with the same name in each region. You specify the region where the infrastructure for that region is located, and in the background AWS maintains a database of latency between the user’s general region and the location tagged in the records, using an ip lookup service to verify user’s region. This helps to understand that the user will have a specific latency relative to a specific region. This can be combined with health checks, used to improve global performance. Note that the database not in real time and runs in the background. The database cannot account for local networking issues,
Geolocation Routing: This routing policy is similar to the latency routing policy: the location of resources and customers is used to influence decisions. When creating records, they are tagged with their location, generally a country using ISO standard country codes, continenets using ISO standard continent codes, or the records are tagged as default. There are also ‘subdivision’ tags (US state for instance). When a user is making a resolution request an ip check verifies the location of the user (user directly or resolver server); Important: geolocation doesn’t return the closest record, only relevant ones; when resolution request happens, r53 takes the location of the user, and starts checking for any matching records. If user’s are in the US, the state is checked and any records with the state attached are attempted to be matched, then country, then continent, then default. If nothing matches, ‘no answer’ is returned. This type of routing policy doesn’t return the closest record, only those which are applicable or no records. This can be used to restrict content, load balance across regions; geolocation is not about proximity, it is about location.
Geoproximity Routing: This routing policy aims to provide records which are as close to customers as possible. When using geoproximity you define rules, providing region, latitude and longitude, and if it’s an external resource. You can also use a ‘bias’, which adjusts how R53 handles the calculation: the bias is plus or minus, which can be used to increase a region size and decrease neighboring regions
Interoperability: This routing policy uses R53 to register domains or host zone files when the other part is not part of R53. Generally both are done by R53, but it is possible for R53 to do one or the other. R53 is a domain registrar AND provides domain hosting, but it can do one or the other. Hosting: registering domain, allocating 4 name servers, creating a zone file on ns; next R53 communicates with the registry of the TLD, creates ns records which point at ns. Reminder, there are two parts: registry and domain (registrar and DNS). It is more common for a registered domain to utilize R53 dns hosting than for a R53 registered domain to utilize another DNS provider
Started studying for the CSA CCSK exam. Notes below:
CCSK Study guide: Domain 2: Governance and Enterprise risk management
Cloud Computing impacts 4 areas of governance and risk management:
Governance: policy, process, internal controls: comprise how an organization is run
Enterprise Risk Management: managing overall risk for the organizations, aligned to governance and risk tolerance; includes all areas of risk
Information Risk Management: managing risk to information, including i.t.
Information Security: tools and practices to manage risk to information
This list is tailored to be a hierarchy, with governance at top and I.S. tools as the foundation