mirror of
				https://github.com/nickpoida/og-aws.git
				synced 2025-03-09 15:40:06 +00:00 
			
		
		
		
	Minor typo fixes
This commit is contained in:
		
							parent
							
								
									93c937db7c
								
							
						
					
					
						commit
						9c7f886654
					
				
					 1 changed files with 4 additions and 4 deletions
				
			
		| 
						 | 
				
			
			@ -1167,11 +1167,11 @@ CloudFront
 | 
			
		|||
 | 
			
		||||
-	📒 [Homepage](https://aws.amazon.com/cloudfront/) ∙ [Developer guide](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) ∙ [FAQ](https://aws.amazon.com/cloudfront/faqs/) ∙ [Pricing](https://aws.amazon.com/cloudfront/pricing/)
 | 
			
		||||
-	**CloudFront** is AWS’ [content delivery network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network).
 | 
			
		||||
-	Its primary use is improving latency for end users in to accessing cacheable content by hosting it at [over 60 global edge locations](http://aws.amazon.com/cloudfront/details/).
 | 
			
		||||
-	Its primary use is improving latency for end users through accessing cacheable content by hosting it at [over 60 global edge locations](http://aws.amazon.com/cloudfront/details/).
 | 
			
		||||
 | 
			
		||||
### CloudFront Alternatives and Lock-in
 | 
			
		||||
 | 
			
		||||
-	🚪CDNs are [a highly fragmented market](https://www.datanyze.com/market-share/cdn/). CloudFront has grown to be a leader, but many alternatives that might better suit specific needs.
 | 
			
		||||
-	🚪CDNs are [a highly fragmented market](https://www.datanyze.com/market-share/cdn/). CloudFront has grown to be a leader, but there are many alternatives that might better suit specific needs.
 | 
			
		||||
 | 
			
		||||
### CloudFront Tips
 | 
			
		||||
-	🐥**IPv6** is [now supported](https://aws.amazon.com/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration/)! 
 | 
			
		||||
| 
						 | 
				
			
			@ -1253,7 +1253,7 @@ EMR
 | 
			
		|||
 | 
			
		||||
### EMR Alternatives and Lock-in
 | 
			
		||||
 | 
			
		||||
-	⛓Most of EMR is based open source technology that you can in principle deploy yourself. However, the job workflows and much other tooling is AWS-specific. Migrating from EMR to your own clusters is possible but not always trivial.
 | 
			
		||||
-	⛓Most of EMR is based on open source technology that you can in principle deploy yourself. However, the job workflows and much other tooling is AWS-specific. Migrating from EMR to your own clusters is possible but not always trivial.
 | 
			
		||||
 | 
			
		||||
### EMR Tips
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -1277,7 +1277,7 @@ This section covers tips and information on achieving [high availability](https:
 | 
			
		|||
 | 
			
		||||
-	AWS offers two levels of redundancy, [regions and availability zones (AZs)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones).
 | 
			
		||||
-	When used correctly, regions and zones do allow for high availability. You may want to use non-AWS providers for larger business risk mitigation (i.e. not tying your company to one vendor), but reliability of AWS across regions is very high.
 | 
			
		||||
-	**Multiple regions:** Using multiple regions is complex, since it’s essentially like completely separate infrastructure. It is necessary for business-critical services which highest levels of redundancy. However, for many applications (like your average consumer startup), deploying extensive redundancy across regions may be overkill.
 | 
			
		||||
-	**Multiple regions:** Using multiple regions is complex, since it’s essentially like completely separate infrastructure. It is necessary for business-critical services with the highest levels of redundancy. However, for many applications (like your average consumer startup), deploying extensive redundancy across regions may be overkill.
 | 
			
		||||
-	The [High Scalability Blog](http://highscalability.com/blog/2016/1/11/a-beginners-guide-to-scaling-to-11-million-users-on-amazons.html) has a good guide to help you understand when you need to scale an application to multiple regions.
 | 
			
		||||
-	🔹**Multiple AZs:** Using AZs wisely is the primary tool for high availability!
 | 
			
		||||
	-	A typical single-region high availability architecture would be to deploy in two or more availability zones, with load balancing in front, as in [this AWS diagram](http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf).
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue