DynamoDB Use Case: Managing Media Content at Let’s Go! Media Inc.

I’m still on my cloud computing journey. This time my project will be using Dynamo DB, EC2 and learning more about IAM in AWS.

— — — — — — — — — — — — — —

Since things are going well at the bank, I decided to take some time to learn about some other technical aspects of AWS. In the midst of learning about Lambda and DynamoDB, I get a call from my friend, Ralph, who just started at Let’s Go Media.

Let’s Go! Media Inc. is a prominent media production and distribution company with a global reach, specializing in the creation and distribution of movies, TV shows, and a wide array of entertainment content. Ralph tells me about their desire to move from on-premise to cloud and thought about my journeys at Level Up Bank. He stated that their desire is to streamline their business operations and efficiently manage their extensive media library, encompassing metadata, ratings, and other crucial details. After further discussion with him, the company has embraced Amazon Web Services’ DynamoDB as their preferred database solution. To bolster the security of their DynamoDB table and ensure that only authorized personnel can access the data, the company wants to deploy a t2.micro Amazon Elastic Compute Cloud (EC2) instance, specifically tailored to their requirements. This EC2 instance is configured with an Identity and Access Management (IAM) role, meticulously fine-tuned to grant the bare minimum permissions necessary for reading the DynamoDB. This should help ensure that only authenticated users with the appropriate permissions can access the table’s contents, mitigating any risks associated with unauthorized modifications to the data.

So we decided to give a test run of how this could work in the cloud. we connected on Zoom and jumped into AWS. From his understanding, the goal is to create a database (they prefer the name “MediaCatalog” so we’ll go with it) containing the their 10 latest movie releases, including movie titles, genres, release dates, and audience ratings. So, we navigated to the DynamoDB section of AWS, created a table called “MediaCatalog”, using a movieid as a partition key. Since he’d just started he didn’t have all the access necessary, we went to IMDB and pulled the 10 Top Movies in the box office as of today (9/13/2023) and entered the information requested for each:

The table created

The contents that we entered into the table

Simple enough (though kinda tedious), that’s done. Next, we needed to create a role to be read-only for the DynamoDB database. After doing a little research, we found this article on AWS’s website that gave the policy we’d need to make this happen — https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/read-only-permissions-on-table-items.html.

The example policy for what we needed to create is:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ReadOnlyAPIActionsOnBooks",
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:BatchGetItem",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:ConditionCheckItem"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
        }
    ]
}

So we went to IAM / Roles / Create Role and started creating the policy (MediaCatalogDBReadOnly) and the role that we could attach it to for use. He noted that we needed to edit the policy to use their region, account ID and table name. So after the editing the block above, it looked like this:

Policy for DynamoDB read-only

Once that was completed, we created a role (MediaDB-ROforEC2) to attach the policy to so we could eventually apply it to the EC2 instance we were spinning up.

So, now we have the table and the role with proper permissions in place. We need to deploy an instance to test this out with. We spun up a quick t2.micro instance (named MediaCataloger) using Amazon Linux 2023 and assigned the role we created to it.

We tested remote access via SSH to this instance and verified we could access the data in the MediaCatalog table:

As a final step to validate the robustness of their security measures, we tested a write operation to the “MediaCatalog” table using the AWS CLI on the EC2 instance.

First, we created a json file called newMovies.json with a couple of additional movies to add to the current table:

Then we tried to update an item and perform a batch write to the table to see if we are able to write to it:

As anticipated, the system promptly denied the write request, effectively showcasing the IAM role’s permissions in action. This layer of security guarantees the integrity of the “MediaCatalog” data, safeguarding it against any unauthorized modifications or access. Ralph is up doing his happy dance…

Actual pic of Ralph dancing on the Zoom call…

We were able to get the project completed in a pretty quick time and have given Let’s Go Media a solid foundation in a secure media provider’s cloud presence.