- Hello and welcome to this lecture which will highlight some of the key points mentioned throughout the previous lectures within this course. I started by talking about the Simple Queue Service, SQS. And within this lecture, I explained that SQS is a fully managed service offered by AWS. It's ideally suited for serverless systems, market services, and distributed architectures. It's capable of sending, storing, and receiving messages at scale and the service is based around producers, consumers, and an SQS queue. Producers are responsible for sending messages to your queue and consumers are responsible for processing messages in the queue. The SQS queue is distributed across multiple services for resiliency. 

And when a message is retrieved, the visibility timeout is started. When the message is processed, the consumer then deletes the message from the queue. The default time for the visibility timeout is 30 seconds, but it can be set up to 12 hours. If the visibility timeout expires before receiving a delete message request, the message becomes available again. Standard queues, which is the default queue type, and it supports at least once delivery of messages and they offer a best effort on message ordering and they also offer an almost unlimited number of transactions per second. First in first out queues, the order of messages is maintained. There are no duplication of messages and the default TPS is 300 for all send/receive and delete operations. 

TPS for batching can be up to 3,000. Encryption can be enabled using server-side encryption via KMS. And dead letter queues are used to hold messages that fail to be processed and they allow engineers to assess why the message failed and these also must be configured as the same queue type as the source it is used against. Following this lecture, I then focused on Simple Notification Service. Within this lecture, I covered the following points. SNS is used as a publish subscribe messaging service. Users or endpoints can subscribe to SNS topics. Messages or events are published to topics which are then pushed to all subscribers to that topic. They're very useful in an event-driven architecture within a decoupled environment. They are highly scalable and it can be configured within the AWS Management Console, the CLI or using the AWS SDKs. Different methods of notification can be used when subscribing such as HTTP, email, AWS Lambda, and SQS. Subscribers don't just have to be users and SNS offers methods of controlling specific access to your topics through topic policies. These policies follow the same format as IAM policies. SNS integrates well with SQS in a highly distributed and decoupled environment. SNS can act as a producer for an SQS queue and SNS also integrates with Lambda to invoke functions. The Lambda function has to be subscribed to the topic for this to work. When a message is sent to the topic, the message is pushed to the Lambda function to invoke it and the message is used as the input parameter for the Lambda function. 

The last lecture within this course focused on the Simple Email Service, SES, and here I explained the following points. SES uses AWS infrastructure and email service to handle an automated email system to communicate with your customers. It's an ideal service for marketers and developers and applications can be developed to respond automatically to incoming emails such as request to unsubscribe to your newsletter. It's very reliable and cost-effective and it's easily integrated into your existing systems such as your SMTP interfaces. When sending email, the first time you configure SES to send email, your environment is placed in a sandbox for single email address testing. To move out of this sandbox environment, you must open a ticket within the AWS Support Center to increase the limits for SES sending. This allows you to then monitor sending activity along with bounced and complaint emails and verify entire domains. 

When receiving email, SES automatically scans for spam and viruses and receipt of emails and rejects messages from untrusted sources. Recipient-based control and IP address-based control work together to direct emails. Recipient-based control, recipient lists are created called conditions. Receipt rules are used to control what action is taken when a condition is met. And when a condition match is found, the recipient rule will carry out the associated action for that email such as an S3 action, SNS action, or a Lambda action, et cetera. If no match is found, the email is deleted. IP address-based control defines what happens to an email based on its source IP address. The email is accepted or rejected based on different IP lists. And SES operates and updates its own list of known spamming sources to delete unwanted email. And by default, all email that originates from EC2 instances is blocked. That now brings me to the end of this lecture and to the end of this course. You should now have a greater understanding of the three different AWS services discussed, SQS, SNS, and SES, and be able to distinguish when you would need to use each service within your decoupled and distributed architecture. If you have any feedback on this course, positive or negative, please do contact us at support@cloudacademy.com. Your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing, thank you.