‫So one let's talk about,
‫DynamoDB security and some other features.
‫So for security, we have VPC endpoints
‫that are going to be available to
‫access DynamoDB without using the public internet,
‫and only keeping all the traffic within your VPC.
‫Access to DynamoDB is fully controlled by IAM,
‫which makes it a great database choice in AWS.
‫And you have encryption at rest
‫using AWS KMS or in-transit using SSL and TLS.
‫There are backup and restore features available.
‫You have two of them.
‫So you have point-in-time recovery,
‫so PITR, just like RDS
‫and there's no performance impacts,
‫or we can just do a normal backup and restore it.
‫Now there's the concept of global tables and DynamoDB.
‫So the idea is that you have a multi-region, multi-active
‫fully replicated high-performance table in DynamoDB.
‫And how to enable it?
‫Well, you need to first enable DynamoDB streams.
‫So, while DynamoDB is a cloud service,
‫It's possible for you to get a simulation
‫of DynamoDB on your local computer,
‫called DynamoDB local,
‫and the idea is that you have,
‫a local DynamoDB database that you can use
‫to develop and test your applications locally
‫without using the DynamoDB web service,
‫which is really, really handy.
‫And if you wanted to migrate data to and from DynamoDB,
‫the AWS Database Migration Service
‫is a great choice.
‫So for example,
‫from MongoDB to DynamoDB,
‫or Dynamic V2 Oracle, mySQL, S3 and so on.
‫Now another feature you need to understand around DynamoDB
‫is going to be around fine grain access.
‫So for example, if you have clients
‫and applications, web, or mobile,
‫and they need to access directly our DynamoDB table,
‫then we don't want to give them IAM permissions
‫and IAM roles, users directly from AWS,
‫that will be truly inefficient and a security hole.
‫Instead, we're going to use an identity provider.
‫It could be Amazon Cognito User Pools,
‫Google login, Facebook login, open ID connect,
‫or SAML or whatever.
‫And the users will, in the simplified flow,
‫login with these identity providers
‫and they will have the feature to
‫exchange the credentials they just got
‫for temporary AWS credentials.
‫And the idea is that because they're temporary,
‫they're more secure.
‫And with them, they can be associated with an IAM role,
‫but this IAM role must be restricted
‫because now that our clients and applications
‫can access our DynamoDB table,
‫you want them to be able to do operations
‫only on the data that they own.
‫And so how do we do this,
‫this fine grain access control?
‫Well, we have a federated login
‫to get temporary credentials,
‫and then we can create IAM role,
‫and this IAM role will have a condition.
‫And this condition will lead on to what the user can do.
‫So here is a sample policy.
‫So in this policy, the user can do get item,
‫batch get item, query, put item, update item,
‫delete item and batch right item on a specific table.
‫But there's a condition here.
‫And the condition is saying,
‫Hey, only if the leading keys is corresponding to DynamoDB
‫and then the connector identity pseudo variables,
‫which will be replaced at run time by the specific user.
‫And so effectively what we're saying is that
‫with LeadingKey, we only limit row level access for users
‫based on what the primary key value is.
‫And so therefore we make sure that the users can only modify
‫and access their own data.
‫And you can also specify conditions on attributes
‫and this would be to limit the specific attributes
‫a user can see in your DynamoDB table, okay?
‫So to summarize, you have fine-grain access control
‫by using a federated login
‫and by specifying a condition on LeadingKeys,
‫if you want it to limit at the role level
‫or attributes, if you want your limits at the column level,
‫the attribute level.
‫Okay, that's it for this lecture.
‫I hope you liked it.
‫And I will see you in the next lecture.