image
SQS versus SNS - When to Use?
Start course
Difficulty
Intermediate
Duration
3h 8m
Students
4933
Ratings
4.7/5
starstarstarstarstar-half
Description

Course Description

The AWS exam guide outlines that 60% of the Solutions Architect–Associate exam questions could be on the topic of designing highly-available, fault-tolerant, cost-efficient, scalable systems. This course teaches you to recognize and explain the core architecture principles of high availability, fault tolerance, and cost optimization. We then step through the core AWS components that can enable highly available solutions when used together so you can recognize and explain how to design and monitor highly available, cost efficient, fault tolerant, scalable systems.

Course Objectives

  • Identify and recognize cloud architecture considerations such as functional components and effective designs
  • Define best practices for planning, designing, and monitoring in the cloud
  • Develop to client specifications, including pricing and cost
  • Evaluate architectural trade-off decisions when building for the cloud
  • Apply best practices for elasticity and scalability concepts to your builds
  • Integrate with existing development environments

Intended Audience

This course is for anyone preparing for the Solutions Architect–Associate for AWS certification exam. We assume you have some existing knowledge and familiarity with AWS, and are specifically looking to get ready to take the certification exam.

Pre-Requisites

Basic knowledge of core AWS functionality. If you haven't already completed it, we recommend our Fundamentals of AWS Learning Path. We also recommend completing the other courses, quizzes, and labs in the Solutions Architect–Associate for AWS certification learning path.

This Course Includes:

  • 11 video lectures
  • Detailed overview of the AWS services that enable high availability, cost efficiency, fault tolerance, and scalability
  • A focus on designing systems in preparation for the certification exam

What You'll Learn

Lecture Group What you'll learn

Designing for High availability, fault tolerance and cost efficiency 

Designing for business continuity 

How to combine AWS services together to create highly available, cost efficient, fault tolerant systems.

How to recognize and explain Recovery Time Objective and Recovery Point Objectives,  and how to recognize and implement AWS solution designs to meet common RTO/RPO objectives

 Ten AWS Services That Enable High Availability Regions and Availability Zones, VPCs, ELB, SQS, EC2, Route53, EIP, CloudWatch, and Auto Scaling 
   

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

Transcript

- Hi Cloud Academy ninjas. Let's do a quick chalk talk on the difference between the Amazon Simple Queue Service and Amazon Simple Notification Service. First thing to note is the Simple Queue Service is a pull service. It's a queue, so we pull messages from the queue and consume them. Simple Notification Service is a push service, so it pushes messages out to consumers. Okay, so with Simple Queue Service we've got a standard queue, in which there can be multiple versions of a message and the ordering is not guaranteed. It's a highly available web application, so it means that when messages are distributed across availability zones in regions. There's also what we call a FIFO queue, which stands for first in or first out. And with first in, first out queues, it's a guaranteed one-time delivery, and the order of messages is preserved. Okay, so those two are one simple way of actually doing a distributed queuing service. With our Simple Notification Service, we've got a number of different ways we can send notifications. So we can use SMS, which is basically text, we can use HTTP, we can use SMTP, which is email, and there's a few other things we can consider as well. Mobile push, okay, so mobile push can be used to-- Mobile push service can be used to send a Simple Notification Service message. Alright, so this is really good for time-sensitive updates, for example. So if there's something that is time-sensitive then the Simple Notification Service will do a very good job of that for us. Now it doesn't currently integrate with Simple Queue Service FIFO queues, but it does integrate with Simple Queue Service standard queues. Now it doesn't also support two-way SMS messages, so while we can use mobile messaging, a simple message service, it doesn't support two-way SMS, which is something which some people might want to use. And it doesn't currently support MMS messaging, which is multimedia messaging, alright. Okay, but it does support CloudTrail, okay, and this is a very common use case for Simple Notification, is for CloudTrail. Okay, so where we have any kind of activity, an alarm or a CloudWatch or CloudTrail event, then we can use Simple Notification Service to notify different services. So a common use case is Auto Scaling, so our Auto Scaling group can use Simple Notification Service to send a message to another application layer or it can send it to a consumer and that consumer can be an application or a person. And if we want to send a message to a number of people then Simple Notification Service is a really good way of doing a one-to-many notification. So, just remembering the two differences, Simple Queue Service is a queue, it's a pull service. We take messages from that queue, consume them and delete them and then move on. With our Simple Notification Service, we can push messages out to any number of consumers or applications or whatever is the consumer layer using, any one of these common transmission protocols. Simple Messaging Service, the text-based one. HTTP, HTTPS, SMTP, which is email, or mobile push. So, Simple Notification is perfect for monitoring applications, for monitoring notifications, workflow systems. What else could we use it for? Time-sensitive information updates, alright. Alright, okay, just one other key difference is that messages are pushed out to consumers when they are sent by publishers, okay. So a publisher publishes a message to SNS and then those messages are pushed out to our consumers, and they can be multiple consumers. Whereas with our SQS queue, we literally push a message to a queue and then that queue-- A consumer requests that message from a queue. So a slightly different workflow but they're both very very useful services. Okay Cloud Academy ninjas, see you next time.

Previous lessons

Next lessons:

1

About the Author
Students
175749
Courses
72
Learning Paths
179

Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built  70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+  years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.