Certification Prep: https://aws.amazon.com/certification/certification-prep/
Solutions Architect: https://aws.amazon.com/training/course-descriptions/architect/ https://aws.amazon.com/certification/certified-solutions-architect-associate/
Reading Materials:
Exam Tips
- https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KKr5HCv2bzH3EOBSUAt/my_path_to_solutions_architect
- http://cantrill.io/certification/aws/2016/03/27/how-to-pass-AWS-certifications.html
- https://www.cozero.com.au/news/2017/424-things-you-should-know-about-aws.html
- https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KSDNs4nfg5ikp6yBN9l/exam_feedback
- read CloudGuru forums
- https://www.linkedin.com/pulse/how-get-all-aws-certifications-asia-wong-chun-yin-cyrus-%E9%BB%83%E4%BF%8A%E5%BD%A5-/
Interesting links: Breaking the monolith: https://aws.amazon.com/getting-started/container-microservices-tutorial/ Make diagrams: https://draw.io
h3. S3 https://aws.amazon.com/s3/faqs/
- Manage Access to Your S3 Resources: http://docs.aws.amazon.com/AmazonS3/latest/dev/intro-managing-access-s3-resources.html
- Log Requests to Your Bucket: http://docs.aws.amazon.com/AmazonS3/latest/UG/ManagingBucketLogging.html To manage the lifecycle of an object, we provide the ability to automatically delete or transition objects to Glacier: http://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html To get started with event driven workflows, you can configure Amazon S3 Event Notifications: http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html S3 also supports many use cases like running a web service/application or running enterprise applications. We have several narratives that can help you on this journey like:
- Host a Static Website: http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html
- Monitor Storage Metrics with Amazon CloudWatch: http://docs.aws.amazon.com/AmazonS3/latest/dev/cloudwatch-monitoring.html
- Programmatically Access S3 with the AWS Command Line Interface: http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html
- Optimize Performance for High Request Rates (More Than 100 Requests per Second): http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html https://aws.amazon.com/answers/infrastructure-management/crr-monitor/
08/12
Route 53: Weighted Routing Lab
I was a bit confused between ELB and Routing w/ Route 53. With Route53, you can have more granular control, e.g having different routing strategies. In the example, you might even put Routing logic that direct traffic to more than one ELB.
Some useful comments from: https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KTWtu_Y5HscAAS8NCyc/elb-vs-route-53-routing
ELB duty is to distribute traffic to instances while making sure that the instances are healthy to make sure your application is always available. Route 53 has many functionality which are called polices and they are; simple, weighted, latency, failover and geolocation. Unlike ELB, with Route 53 weighted policy you can manually set the traffic distribution for your applications like 20% traffic should be routed to instance A while 80% should be routed to instance B. In the case of failover, both Route 53 and ELB do have similar functionality by routing traffic to only health application or instances. But for Route 53, you use fail-over for active passive fail-over.
In summary, I believe ELBs are intended to load balance across EC2 instances in a 'single' region. Whereas DNS load-balancing (Route 53) is intended to help balance traffic 'across' regions. Route53 policies like geolocation may help direct traffic to preferred regions, then ELBs route between instances within one region.
Functionally, another difference is that DNS-based routing (e.g. Route 53) only changes the address that your clients' requests resolve to. On the other hand, an ELB actually reroutes traffic.
One analogy is: if you ask for the closest WalMart, you may get an address based on your location, but you could choose to go to another Walmart if you know one. That's Route 53; it just switches the address resolved based on some context. On the other hand, a policeman redirecting traffic because of construction, is more like an ELB, he/she is actually changing the traffic flow, not just suggesting.
A/B testing is a good use case of using weighted routing with Route53.
Route 53: Latency Based Routing
Latency with Route 53 respond to DNS queries with the resources that provide the best latency. This means that Route 53 chooses to respond to the DNS query based on which data centre gives your user the lowest latency.
Route 53: Failover Routing Policy
So i think this is similar to ELB. In this you specify passive / active route - just like Hagrid has production and DR instances.
In the case of failure - the passive will become active.
So just like ELB - you need to setup health check too. Setting this up feels a little bit complicated. So first of all you need to create health checks - which is a separate section on the route 53. And then you go to Hosted Zone - setup an A record with the failover routing policy - in here you are to associate the routing with a health check.
Ok - so say I have a domain felixt.org - in here I can then create multiple A records (hm interesting?) and each will have their own routing policy - ah okay, kinda get it - set these records as aliases and set target alias - which can be EC2, S3, ELB - what else?
There is only primary and secondary option for failover - production and DR I guess. So you create a health check attached to the primary A record, the secondary record has no need for health check I guess? But what if you want a cascading failover? e.g more than primary and secondary? Can you do that?
Geolocation is when you want Amazon Route 53 to respond to DNS queries based on the location of your users. But Geo-location do have a functionality of presenting the user the ability to change the content like languages to suit the users.