1
00:00:00,860 --> 00:00:01,740
Hello looking back.

2
00:00:01,770 --> 00:00:07,770
So now with reliability security and encryption features let's start.

3
00:00:08,400 --> 00:00:10,790
So let's start with reliability.

4
00:00:10,820 --> 00:00:18,160
Amazon asking us stores all the queued messages and messages within a single.

5
00:00:18,370 --> 00:00:26,770
So all the cues and the messages within in a single highly available region with multiple redundant

6
00:00:26,920 --> 00:00:27,870
it is on.

7
00:00:28,060 --> 00:00:33,840
So your messages and cues are in in multiple availability zones but in the same region.

8
00:00:33,910 --> 00:00:39,120
So there's no single computer network or easy failure that can make messages inaccessible.

9
00:00:40,480 --> 00:00:46,300
So by doing that by taking your cues and the messages within and replicating them in multiple availability

10
00:00:46,300 --> 00:00:49,000
zones but it has to be in the same region.

11
00:00:49,210 --> 00:00:54,820
The only thing which is highly unlikely except if it is a natural disaster that we are going to lose

12
00:00:54,820 --> 00:00:57,170
a complete region at once.

13
00:00:57,670 --> 00:01:00,450
And even if that happens that will be very rare to happen.

14
00:01:00,490 --> 00:01:07,690
And I'm sure it will have its place in place or somehow to compensate its customers for such a mistake.

15
00:01:07,720 --> 00:01:13,810
So there is no single computer is it for instance hardware server network or easy failure that can make

16
00:01:13,810 --> 00:01:21,430
your message inaccessible unless if you are extremely unlucky and you lose a complete region for extended

17
00:01:21,430 --> 00:01:21,660
time

18
00:01:24,310 --> 00:01:32,410
security you can use I am policies to control who can read or write messages from two years.

19
00:01:32,410 --> 00:01:39,210
Q Can I provide access to cues to anonymous anonymous access.

20
00:01:39,210 --> 00:01:46,170
Yes you can but you are talking about control and security features not the security features authentication

21
00:01:46,170 --> 00:01:53,790
mechanism mechanism ensure that message is stored in an obscure message queues are secured against unauthorized

22
00:01:53,790 --> 00:01:55,560
access.

23
00:01:55,560 --> 00:02:00,650
You can't control who send messages to a message queue and who can receive messages from a message queue

24
00:02:00,720 --> 00:02:07,890
using in policies and for additional security you can build your application to encrypt messages before

25
00:02:07,890 --> 00:02:09,710
they are placed in a message queue.

26
00:02:09,710 --> 00:02:14,970
It's up to you if you want to encrypt your message below before they are placed in a queue.

27
00:02:15,210 --> 00:02:19,740
Of course you can but remember that your upgrade your other application components must have access

28
00:02:19,740 --> 00:02:21,890
to the encryption keys in order to be kept.

29
00:02:22,080 --> 00:02:32,170
So it's up to you but you manage the complex it's your support HDTV it's GDP over SSL and supports allows

30
00:02:32,440 --> 00:02:36,650
virgins when 1.1 1.2 in all supported regions.

31
00:02:36,670 --> 00:02:46,000
So this is supported us is PCI d s s payment card industry data security standard live and one complaint

32
00:02:46,290 --> 00:02:52,750
and also it is eligible for hiper which is the Health Insurance Portability and Accountability Act.

33
00:02:52,750 --> 00:02:58,600
So these are certification of compliance for the obscure service that can be used for PCI ideas as basically

34
00:02:58,960 --> 00:03:04,630
great card payment industry or applications and also for the health care industry that you can use it

35
00:03:04,630 --> 00:03:10,670
for that to decouple applications that will help will serve in the PC industry or in the healthcare

36
00:03:10,750 --> 00:03:11,430
industry.

37
00:03:11,530 --> 00:03:13,450
Encryption very important.

38
00:03:13,450 --> 00:03:15,840
Now lets talk about server side encryption.

39
00:03:15,850 --> 00:03:23,620
If the components were log message to the queue is there ability in the queue as queue to encrypt the

40
00:03:23,630 --> 00:03:24,940
messages as they are received.

41
00:03:24,970 --> 00:03:25,700
Yes.

42
00:03:25,810 --> 00:03:31,120
So it will let you transmit sensitive data and encrypted queues service something corruption protects

43
00:03:31,120 --> 00:03:37,840
the contents of messages in Amazon as Skewes using Calamus managed keys but of course using keys will

44
00:03:37,840 --> 00:03:39,220
be an extra charge.

45
00:03:39,240 --> 00:03:43,950
You can if you don't want to encrypt it on your side before sending it to ask you as.

46
00:03:44,230 --> 00:03:48,640
Then you can send it unencrypted and it will be encrypted on the queue itself.

47
00:03:48,850 --> 00:03:52,450
And what will be encrypted there are parts that will be encrypted and parts will not and we talk about

48
00:03:52,450 --> 00:03:53,840
that now.

49
00:03:54,760 --> 00:03:58,380
So it was I think optional encrypt messages as soon as Amazon.

50
00:03:58,410 --> 00:04:05,440
Q S receives them so as soon as they are get into the queue they are going to be encrypted the messages

51
00:04:05,440 --> 00:04:07,620
are stored in encrypted form.

52
00:04:07,700 --> 00:04:08,590
Amazing.

53
00:04:08,700 --> 00:04:15,280
Decrypts message is only when they are sent to an authorized consumer who determined the authorized.

54
00:04:15,290 --> 00:04:22,800
We talked about high end policies right and it uses a 256 bit encryption and not worry about a mess.

55
00:04:22,810 --> 00:04:27,690
It is a skillful and secure highly available service in the club and when we talk about encryption.

56
00:04:27,700 --> 00:04:30,430
Is it available for standard or for FIFO queues.

57
00:04:30,430 --> 00:04:32,060
It's available for both of them.

58
00:04:32,170 --> 00:04:35,530
As we mentioned before that FIFO queues are not available in all regions.

59
00:04:35,530 --> 00:04:37,720
Also several have been corruption for years.

60
00:04:37,730 --> 00:04:42,910
Is not available in all regions so you need to check the entire region for availability.

61
00:04:42,910 --> 00:04:46,420
What if I need to use it in a region and the region doesn't have the service.

62
00:04:46,420 --> 00:04:53,810
We said that you can always encrypt the data before encrypt the messages before sending them to the

63
00:04:53,820 --> 00:04:55,060
rescue rescue.

64
00:04:55,060 --> 00:05:01,330
However that will be client side encryption not server side encryption so you'll need to manage how

65
00:05:01,330 --> 00:05:07,180
we are going to do that what is encrypted what's not encrypted so he will encrypt the body of the message

66
00:05:07,330 --> 00:05:12,730
in a queue and it will not encrypt the following components of the message.

67
00:05:12,730 --> 00:05:14,330
The meta data of the queue.

68
00:05:14,380 --> 00:05:18,610
So basically the queue name and the attributes of the queue are not.

69
00:05:18,780 --> 00:05:19,830
Message me today.

70
00:05:19,950 --> 00:05:23,730
So which message timestamp and attributes for the message itself.

71
00:05:23,760 --> 00:05:30,990
It's not encrypted and Bercu Matrix The Matrix specific to that Q And if you look at that this is not

72
00:05:30,990 --> 00:05:33,240
something critical for you to be encrypted.

73
00:05:33,240 --> 00:05:36,120
Right you are worried about the message itself.

74
00:05:36,120 --> 00:05:37,290
Which part.

75
00:05:37,290 --> 00:05:40,450
What to do what transcoding is required.

76
00:05:40,470 --> 00:05:46,770
Your actual data that your actual date but these are human to date that message today to pick your metrics.

77
00:05:46,770 --> 00:05:50,130
These are AWOS attributes for your Qs.

78
00:05:50,190 --> 00:05:51,470
Not the message itself.

79
00:05:51,570 --> 00:05:56,940
Encrypting a message makes it makes its context unavailable to unauthorized or anonymous user so even

80
00:05:56,940 --> 00:06:03,610
if someone has access to the message they will not be able to read the contents of the message.

81
00:06:03,610 --> 00:06:10,050
Getting messages does not affect the normal function functioning of an excuse so that encryption will

82
00:06:10,050 --> 00:06:12,450
it affect the performance would affect the number of queues.

83
00:06:12,450 --> 00:06:20,020
This or that it does not and message is encrypted only if it is sent after the encryption of a queue

84
00:06:20,020 --> 00:06:20,870
is enabled.

85
00:06:20,890 --> 00:06:25,480
So are you telling me that if I had queues the queue had messages.

86
00:06:25,480 --> 00:06:28,830
Remember when you said that some messages can be there for 14 days.

87
00:06:28,990 --> 00:06:33,640
What if I don't own encryption service side encryption on the queue and there are some messages on encrypted

88
00:06:34,170 --> 00:06:35,650
so young cryptic messages.

89
00:06:35,710 --> 00:06:40,120
It will not be encrypted when you turn it on on the ice.

90
00:06:40,270 --> 00:06:43,930
So the new message is loaded or it will be encrypted.

91
00:06:43,930 --> 00:06:49,060
The older ones will not be encrypted and also any encrypted message that say that it was an encrypted

92
00:06:49,110 --> 00:06:51,250
queue and I had encrypted messages.

93
00:06:51,400 --> 00:06:56,650
And now I turned off the encryption so the encrypted messages will remain encrypted.

94
00:06:56,650 --> 00:06:58,840
But the new ones will not be encrypted.

95
00:06:59,930 --> 00:07:06,480
Karaite one more lecture with us limits and names and monitoring monitoring this should be an easier

96
00:07:06,480 --> 00:07:07,040
one.

97
00:07:07,170 --> 00:07:12,110
In order to complete the theory part of the US I will see you after the break.

98
00:07:12,120 --> 00:07:12,500
Thank you.