How to migrate from Microsoft SQL Server to Amazon DynamoDB

Introduction

In this lesson, you migrate a legacy Microsoft SQL Server database to a cloud-native NoSQL database with DynamoDB. First, you create a SQL Server database and load it with sample data. Then you create a DynamoDB database and prepare your data for the migration. Finally, you migrate your data to DynamoDB by using AWS Database Migration Service (AWS DMS). At the end of this lesson, you should feel confident in your ability to migrate from a legacy database to a cloud-native NoSQL database using DynamoDB.

Time to complete: 3045 minutes

Why use DynamoDB?

DynamoDB is a cloud-native NoSQL database that offers fast, consistent performance at any scale. DynamoDB is used for high-scale applications from companies such as Amazon.com, Lyft, and Samsung, as well as in serverless applications because of its flexible billing model and serverless-friendly connection model.

DynamoDB is a fully managed service, so all database operations are managed by AWS. You pay for read and write units directly, and AWS ensures that necessary capacity is available for your application. You don't need to think about instance failures, software updates, backups, or other database maintenance tasks. Your team can focus on innovating in ways that matter to your users.

Data modeling principles in a nonrelational database such as DynamoDB are different than those with a relational database. When replatforming from a legacy relational database to DynamoDB, you need to adjust your data model. In this lesson, you learn how to migrate an existing relational data model to a nonrelational data model in DynamoDB.

Lesson contents

In this lesson, you learn how to migrate a legacy SQL Server database to a cloud-native NoSQL database using DynamoDB. This lesson has seven steps.

  • 1. Create a SQL Server database

    In this module, you create a SQL Server database instance in Amazon Relational Database Service (RDS) and load the database with sample data. This database serves as an example that you can compare to when moving your own legacy database to DynamoDB.


    To get started, navigate to the Amazon RDS console. On the main page, choose Create database to create a new database.

    Choose "Create database"
    (click to zoom)

    This initiates the database creation wizard. In the Engine options section, choose Microsoft SQL Server as your Engine type. Then choose SQL Server Standard Edition and use the default version.

    Choose "Microsoft SQL Server" as your "Engine type" and the default version of "SQL Server Standard Edition"
    (click to zoom)

    The database creation wizard includes templates to make it easier to configure the settings for your Amazon RDS database. Because this database is being used as an example, you can choose the Dev/Test settings.

    Choose the "Dev/Test" template
    (click to zoom)

    In the Settings section, give your database a name and set the master username and password. Make sure you write these down because you need them to connect to your database and create additional users.

    Give your database a name and set the master username and password
    (click to zoom)

    Next, choose the database instance size. Choose the db.m5.large instance class for your instance.

    Choose the db.m5.large instance class for your instance
    (click to zoom)

    Next, configure the storage options for your Amazon RDS database. You can use the default options with 20 GiB of General Purpose (SSD) storage.

    Configure the storage options for your Amazon RDS database
    (click to zoom)

    The next section in the Amazon RDS database creation wizard is about connectivity. You must specify the Amazon Virtual Private Cloud (Amazon VPC) in which your database resides, as well as the network subnet and security groups for your database instance.

    You can use the default VPC in your AWS account. In the Additional connectivity configuration subsection, under Publicly accessible, choose Yes so that you can connect to your database from your own computer. Then choose to create a new VPC security group and give it a name.

    Specify the Amazon VPC, network subnet, and security groups
    (click to zoom)

    There are some additional configuration options you can configure, including settings for backups, monitoring, maintenance, and automated upgrades. The default settings work for the migration example in this lesson.

    Choose Create database to create your database.

    Note: After creating your database, you must be sure to clean up the Amazon RDS database instance as explained in the final module of this lesson. You incur charges of around one dollar for every hour the Amazon RDS database is left running.

    Choose "Create database" to create your database
    (click to zoom)

    As Amazon RDS is provisioning your infrastructure and initializing your database, the Status of your database is Creating.

    When your database is ready to use, its Status is Available.

    As Amazon RDS is provisioning your infrastructure and initializing your database, the "Status" of your database is "Creating"
    (click to zoom)
    When your database is ready to use, its "Status" is "Available"
    (click to zoom)

    Choose your database name in the DB identifier column to see details about your database. There is an Endpoint property in the details. Save this value for the next module when you connect to your database.

    Save the value of the "Endpoint" property
    (click to zoom)

    In this module, you created a SQL Server database to be used for example data to migrate to a cloud-native NoSQL database using DynamoDB. In the next module, you load your SQL Server database with sample data and prepare it for migration to DynamoDB.

  • 2. Load your SQL Server database with sample data and prepare it for migration

    In this module, you load your SQL Server database with sample data and prepare it for migration to DynamoDB.


    Modeling data in a NoSQL database such as DynamoDB is different from modeling data in a relational database such as SQL Server. With DynamoDB, you need to denormalize your data and design your table for your access patterns rather than write your queries for your access patterns as in a relational database.

    Data modeling in DynamoDB is too broad of a topic to cover in this lesson. For additional information, see the DynamoDB documentation, including the best practices section about the Differences Between Relational Data Design and NoSQL. Additionally, you can review hands-on tutorials for data modeling with DynamoDB.

    For this example, use one of the hands-on tutorials as a data model. The Modeling Game Player Data with DynamoDB tutorial shows how to model a multiplayer battle royale game. In this lesson, you adopt it for your relational database, and then show how to migrate it to the DynamoDB data model. We do not cover the multiplayer game schema in depth in this example. If you want to understand the DynamoDB data model more, review the hands-on tutorial first.

    To prepare for this lesson, download this .zip file that has SQL statements to prepare your SQL Server database. Inside the .zip file are three files that you use in this lesson.

    Next, download the Azure Data Studio client to interact with your SQL Server database instance. This client allows you to connect to your database and execute queries.

    Open Azure Data Studio and choose Create a connection. Enter the endpoint of your SQL Server database from the last module as well as the user name and password from when you created the database. Then choose Connect.

    Choose "Create a connection" and then connect
    (click to zoom)

    After you connect, choose New Query to execute a query in your database.

    Choose "New Query" to execute a query in your database
    (click to zoom)

    This opens a query window. Copy and paste the contents from the create_tables.sql file from the .zip file you downloaded. This contains SQL statements to create a database and tables for your multiplayer battle royale game.

    After you paste the contents of the file into the query window, choose Run to execute the query.

    Run the query
    (click to zoom)

    Next, replace the contents of the query window with the contents from the insert_data.sql file. This contains the sample data for the game, including maps, users, games, and user-game mappings.

    After you have pasted the contents in the window, choose Run to execute the query and insert the data.

    Replace the contents of the query window with the contents from the insert_data.sql file
    (click to zoom)

    Let's read some of the data to ensure everything was inserted correctly.

    Enter the following query in the query window.

    SELECT games.game_id,
           maps.map_name as map,
           games.create_time,
           creator.username as creator,
           users.username
    FROM games
    JOIN maps ON games.map_id = maps.map_id
    JOIN users creator ON games.creator_id = creator.user_id
    JOIN user_games ON games.game_id = user_games.game_id
    JOIN users ON user_games.user_id = users.user_id
    WHERE games.game_id = '0ab37cf1-fc60-4d93-b72b-89335f759581'

    This fetches all of the users that are signed up for a particular game. Execute the query, and you should see 34 rows in your results.

    Run the query to fetch all users signed up for a game
    (click to zoom)

    Finally, notice how many SQL joins you had to use in that query. In NoSQL databases such as DynamoDB, there are no join operations. As your SQL Server database scales, the performance of your join operation decreases.

    Instead of join operations, DynamoDB has different strategies for modeling your data. There are a number of differences when modeling your data in DynamoDB, but the three main differences are:

    • With DynamoDB, you need to design your table for your access patterns rather than write your queries for your access patterns as in a relational database. In this example, you store a count of the number of players who have signed up on the Game record.
    • Put multiple different entity types into a single table. This enables you to retrieve multiple, heterogeneous item types in a single request without using a join.
    • Use generic names (such as PK and SK) for your primary keys. This is because you have multiple different entity types in a single table and thus no common properties across them.

    For more details about DynamoDB data modeling, see the full tutorial about Modeling Game Player Data with DynamoDB.

    To make your migration easier, create some tables in your SQL Server database. These tables reshape the data into the format expected by DynamoDB. You will use these tables with AWS DMS to migrate the data to DynamoDB.

    Paste the contents of the create_migration_tables.sql file in the query window. This file creates four different tables to be used in the migration task. Choose Run to execute the query and create the tables.

    Create some migration tables in your SQL Server database to make the migration easier
    (click to zoom)

    To ensure your tables were created successfully, enter the following query in the query window and choose Run.

    SELECT * FROM dynamodb_open_games

    Your results should look as follows.

    Notice that there are PK and SK columns in your result set. These map to the primary key values of the DynamoDB data model for the multiplayer game. Additionally, notice that the results include the map name, rather than the map ID as in the original Games table in your database. This is some of the denormalization that is done as part of the move to a NoSQL database. This table represents one of the four tables you created for the migration.

    Run a query to ensure your tables were created successfully
    (click to zoom)

    In this module, you loaded your SQL Server database with sample data to be used for the migration. You used data from an existing DynamoDB tutorial to see how to replatform from a relational database to DynamoDB. Then you created some tables in your database to prepare your data for migration to DynamoDB.

    In the next module, you create a DynamoDB table to be used as the target for your migration.

  • 3. Create a DynamoDB table

    In this module, you create a DynamoDB table. This table serves as the target for your migration from a legacy relational database. You also create an IAM role that allows AWS DMS to access your DynamoDB table.


    To get started, navigate to the DynamoDB console. Choose Create table to create a new table.

    Choose "Create table" to create a new table
    (click to zoom)

    The first thing you need to do is give your table a name and specify the primary key for your table.

    The tutorial that you are using uses a table name of battle-royale. For the primary key, there is a composite primary key with a partition key named PK and a sort key named SK. Enter those values in the table creation wizard.

    Name your table and specify the primary key
    (click to zoom)

    The table-creation wizard allows you to use default settings for your table, and those settings work for this walkthrough. Choose Create to create your table.

    Use the default settings and create your table
    (click to zoom)

    As your table is being created, the Overview tab indicates that the table creation is in progress.

    The "Overview" tab indicates that the table creation is in progress
    (click to zoom)

    After your table is created, the DynamoDB console shows the details of your table with a Table status of Active.

    The DynamoDB console shows the details of your table with a "Table status" of "Active"
    (click to zoom)

    The console also includes the Amazon Resource Name (ARN) of your DynamoDB table. You need this ARN when creating your IAM role.

    To create your IAM role, navigate to the Roles section of the IAM console. Choose Create role to start the role-creation wizard.

    Choose "Create role" to start the IAM role-creation wizard
    (click to zoom)

    Next, choose a trusted entity. Create a service role that can be used by AWS DMS. Choose DMS and then choose Next: Permissions.

    Create a service role that can be used by AWS DMS
    (click to zoom)

    Next, attach permissions to your role. Choose Create policy to create a new policy.

    Choose "Create policy" to create a new policy
    (click to zoom)

    Choose the JSON tab and paste the following into the editor.

    {
        "Version": "2012-10-17",
        "Statement": [
        {
            "Effect": "Allow",
            "Action": [
              "dynamodb:PutItem",
              "dynamodb:CreateTable",
              "dynamodb:DescribeTable",
              "dynamodb:DeleteTable",
              "dynamodb:DeleteItem",
              "dynamodb:UpdateItem"
            ],
            "Resource": [
              "<yourDynamoDBTableArn>",
              "arn:aws:dynamodb:*:*:table/awsdms_apply_exceptions",
              "arn:aws:dynamodb:*:*:table/awsdms_full_load_exceptions"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
              "dynamodb:ListTables"
            ],
            "Resource": "*"
        }
        ]
    }

    Be sure to replace <yourDynamoDBTableArn> with the actual ARN of your DynamoDB table.

    Your screen should look as follows. Choose Review policy to review your policy.

    Choose the &quot;JSON&quot; tab and paste the code into the editor
    (click to zoom)

    Give your policy a name and description, and then choose Create policy to create your policy.

    Give your policy a name and description, and then create your policy
    (click to zoom)

    Return to the IAM role creation tab. Choose the Refresh icon to refresh the IAM policies in your account. Then find your policy name and choose the check box next to it.

    Choose Next: Tags to move to the next step in the wizard.

    Find your policy name and choose the check box next to it
    (click to zoom)

    You can skip adding tags to your IAM role. Choose Next: Review to go to the next step.

    Give your IAM role a name and description, and then choose Create role.

    Give your IAM role a name and description, and then choose &quot;Create role&quot;
    (click to zoom)

    After you create your IAM role, it appears in your list of IAM roles in the IAM console. Choose your IAM role to see more details about it.

    Choose your IAM role to see more details about it
    (click to zoom)

    The IAM role summary page shows the Role ARN. Save this value because you need it when configuring an endpoint in AWS DMS in a future module.

    Save the value of the &quot;Role ARN&quot;
    (click to zoom)

    In this module, you created a DynamoDB table that serves as the target for your migration from a legacy relational database. You also created an IAM role that AWS DMS uses to access your DynamoDB table.

    In the next module, you create a replication instance in AWS DMS.

  • 4. Create a replication instance in AWS DMS

    In this module, you create a replication instance in AWS DMS.

    AWS DMS is a service you can use to copy data from an existing database to a fully managed AWS database. A replication instance is an Amazon EC2 instance that can host replication tasks in AWS DMS. In a future module, you set up a replication task.


    To create a replication instance, go to the Replication instances section of the AWS DMS console. Choose Create replication instance to begin the replication instance-creation wizard.

    Choose &quot;Create replication instance&quot; to begin the replication instance-creation wizard
    (click to zoom)

    In the Replication instance configuration section, give your replication instance a name and description. Then choose your instance class. In this lesson, the amount of data is small, so choose the dms.t2.micro instance class.

    Then choose an engine version for AWS DMS. Finally, choose the amount of allocated storage for your replication instance.

    Give your replication instance a name and description, and choose your instance class
    (click to zoom)

    As you continue in the Replication instance configuration section, you need to choose a VPC for your replication instance. Choose the same VPC in which you provisioned your SQL Server database to ease network access for the replication instance.

    There are options for Multi AZ configuration and whether your replication instance should be publicly accessible. Keep the default options for both of these.

    Choose the same VPC in which you provisioned your SQL Server database
    (click to zoom)

    Next, open the Advanced security and network configuration section. For the VPC security group(s) configuration, choose the same security group that you attached to your SQL Server database. This allows your replication instance to access your SQL Server database instance.

    Advanced security and network configuration settings
    (click to zoom)

    When you're ready, choose Create to create your replication instance in AWS DMS.

    Choose &quot;Create&quot; to create your replication instance in AWS DMS
    (click to zoom)

    After you choose Create, AWS provisions your replication instance. The instance’s Status is Creating while AWS provisions and initializes your instance.

    When your replication instance is ready to go, its Status is Available.

    The instance&rsquo;s &quot;Status&quot; is &quot;Creating&quot; while AWS provisions and initializes your instance
    (click to zoom)
    When your replication instance is ready to go, its &quot;Status&quot; is &quot;Available&quot;
    (click to zoom)

    While you are waiting for your replication instance to be available, go to the Security Groups section in the Amazon EC2 console. You need to add a rule to your security group to allow your replication instance to access your database.

    In the Security Groups section, find the security group you attached to your SQL Server database instance and your replication instance, and choose it.

    Find the security group you attached to your SQL Server database instance and your replication instance, and choose it
    (click to zoom)

    Choose to Edit inbound rules for your security group.

    Choose to &quot;Edit inbound rules&quot; for your security group
    (click to zoom)

    Your security group has an existing rule that allows for access to your SQL Server instance from the IP address you used to create the database. Choose Add rule to add an additional rule. For Type, choose MSSQL. For Source, enter the security group that is attached to your SQL Server database and your replication instance.

    Your screen should look as follows.

    Choose Save rules to save the updated rules for your security group.

    When your replication instance is available and you have updated the rules for your security group, you may move on to the next module.

    Add an additional rule
    (click to zoom)

    In this module, you created a replication instance in AWS DMS. The replication instance is used to host the replication tasks that migrate data from your legacy database to a cloud-native database in DynamoDB. You also updated a security group to allow access from your replication instance to your SQL Server database instance.

    In the next module, you create endpoints for your source and target databases for AWS DMS.

  • 5. Create endpoints in AWS DMS

    In this module, you create source and target endpoints for a replication task in AWS DMS.

    A replication task is a job that migrates data from one database to another by using AWS DMS. Before creating a replication task, you must register endpoints for your source and target databases. An endpoint describes the connection address, credentials, and other information required to connect to a database.


    First, create the endpoint for your source database. This is the SQL Server database you created in Amazon RDS.

    Navigate to the Endpoints section of the AWS DMS console. Choose Create endpoint to create a new endpoint.

    Choose &quot;Create endpoint&quot; to create a new endpoint
    (click to zoom)

    In the endpoint creation wizard, choose to create a Source endpoint. Choose the box to Select RDS DB instance, and choose your newly created Amazon RDS database in the dropdown.

    Choose to create a &quot;Source endpoint&quot;
    (click to zoom)

    This completes most of the Endpoint configuration details for you. You need to enter your password and a database name near the bottom of the section.

    Enter your password and a database name near the bottom of the section
    (click to zoom)

    Before you save your endpoint, you should test the connection to ensure it was configured correctly. Open the Test endpoint connection section to test your connection.

    Choose the replication instance you want to use, and then choose Run test. After a few seconds, you should see a status of successful. This indicates you configured your security group and endpoint correctly. Choose Create endpoint to save your endpoint.

    Test the endpoint connection to ensure it was configured correctly
    (click to zoom)

    Next, you need to create a target endpoint for your DynamoDB table. In the Endpoints section, choose Create endpoint again.

    Create a target endpoint for your DynamoDB table
    (click to zoom)

    Choose Target endpoint in the Endpoint type section.

    Choose &quot;Target endpoint&quot; in the &quot;Endpoint type&quot; section
    (click to zoom)

    In the Endpoint configuration section, give your endpoint a name. Then choose dynamodb for the Target engine. Paste the ARN of the IAM role that you created in a previous module.

    Give your endpoint a name, and choose &quot;dynamodb&quot; for the &quot;Target engine&quot;
    (click to zoom)

    Be sure to test your endpoint connection as you did with your source endpoint. If you configured your IAM role correctly, you should see a successful connection.

    Choose Create endpoint to create your endpoint.

    Test your endpoint connection as you did with your source endpoint
    (click to zoom)

    Before moving on to the next module, you should have two endpoints configured: one for your source SQL Server database and one for your target DynamoDB table. Make sure that you have tested both endpoints and can successfully connect to both databases. Then move on to the next module.


    In this module, you created your endpoints to connect to your databases. In the next module, you use those endpoints to create a replication task that copies data from your source database to your target database.

  • 6. Create a replication task in AWS DMS

    In this module, you create a replication task in AWS DMS.

    A replication task is responsible for migrating data from a source database to a target database. In your case, you are moving data from a legacy relational database to a cloud-native NoSQL database in DynamoDB.


    To get started, navigate to the Database migration tasks section of the AWS DMS console. Choose Create task to create a new replication task.

    Choose &quot;Create task&quot; to create a new replication task
    (click to zoom)

    In the Task configuration section, set up the parameters of your replication task. Give your task a name and choose the replication instance you created in an earlier module. Then choose the source endpoint for your existing database and your target endpoint for your DynamoDB table.

    You need to choose a migration type. There are two migration types:

    1. Migrate existing data, which performs a one-time process to copy data from your source database to your target database.
    2. Replicate ongoing changes, which copies all ongoing operations from your source database to your target database.

    In this walkthrough, you migrate existing data to your new DynamoDB table. For the migration type, choose Migrate existing data.

    Set up the parameters of your replication task
    (click to zoom)

    Skip the Task settings section and leave all the settings at their defaults.

    In the Table mappings section, tell AWS DMS which tables you want to copy over and how to map them to your target database.

    You need to combine records from multiple SQL Server tables into a single DynamoDB table. To do so, use a JSON configuration file for the table mappings. Choose JSON editor for the editing mode, and then paste the contents of the table_mappings.json file in the .zip file you downloaded.

    After you paste the table mappings, choose Create task to start your migration task.

    Tell AWS DMS which tables you want to copy over and how to map them to your target database
    (click to zoom)

    After you create your task, your task is shown in the Database migration tasks section with a Status of Creating.

    After the task is created and the load finishes, its Status is Load complete.

    After you create your task, your task is shown in the &quot;Database migration tasks&quot; section with a &quot;Status&quot; of &quot;Creating&quot;
    (click to zoom)
    After the task is created and the load finishes, its &quot;Status&quot; is &quot;Load complete&quot;
    (click to zoom)

    Go back to your DynamoDB table and choose it in the console. Choose the Items tab to see the records in your DynamoDB table.

    Choose the &quot;Items&quot; tab to see the records in your DynamoDB table
    (click to zoom)

    Earlier, you ran a SQL query to look at the users in a game in your database. You can do the same in DynamoDB to verify that you get the same results.

    In the DynamoDB data model, a Game item and all UserGameMapping items have the same partition key of GAME#<GameId>. You can use the DynamoDB Query operation to fetch the Game item and the UserGameMapping items that represent users that have signed up for the game.

    Choose the dropdown to change from Scan to Query. Then for the partition key value, enter GAME#0ab37cf1-fc60-4d93-b72b-89335f759581 and choose Start search.

    This should return 35 records: the Game item and 34 UserGameMapping items for each user in the game.

    Run a SQL query to look at the users in a game in your database
    (click to zoom)

    This query is one way to validate that the data migration was successful. Before switching to your new database, perform additional data validation queries. This includes performing sample queries, as shown previously, as well as using record counts to ensure all records were transferred.

    To count records in a relational database, you could use the following query to get the total number of rows in a table.

    SELECT count(*) FROM <table_name>;

    Be sure to replace <table_name> with the name of your table.

    In a DynamoDB table, you need to use the Scan operation to read all the items in your table. The following AWS CLI command shows how to use a Scan and return the COUNT of items read.

    aws dynamodb scan \

    --table-name <table_name> \
    --select COUNT

    The Scan operation is a paginated operation and can only read 1 MB of data in a single request. If your migrated table contains more than 1 MB of data, you need to make multiple requests to get an accurate count. For more information about paginating in DynamoDB, see the documentation about Paginating the Results.

    You have successfully migrated your data into DynamoDB. The data in your table should now work with the application code in the hands-on tutorial for Modeling Game Player Data with DynamoDB.


    In this module, you created a replication task in AWS DMS to migrate your existing data from SQL Server to a NoSQL database in DynamoDB. You verified that the copied data matched the data in your source database.

    In the next module, you complete the migration and clean up the resources you created.

  • 7. Complete the migration and clean up resources

    If you have followed all of the steps in this lesson, you have created a cloud-native NoSQL database by using DynamoDB. You also created a SQL Server database with sample data and a migration task to copy data from your source database to your new database. In this final module, you learn the steps to complete your migration as well as the steps to clean up the resources you created during this lesson.

    When your initial migration is complete and all data is synced to your new database, you are ready to use your new database as your primary database. Change your application code to read and write from your new database.

    After you have switched to using your primary database and are confident in the results, you want to delete your AWS DMS infrastructure.


    First, stop and delete the database migration task to replicate your data. Navigate to the Database migration tasks section of the AWS DMS console. Choose the task you want to remove and choose Delete.

    Stop and delete the database migration task to replicate your data
    (click to zoom)

    Next, navigate to the Endpoints section of the AWS DMS console. Choose both your source endpoint and your target endpoint, and then choose Delete.

    Choose both your source endpoint and your target endpoint, and then choose &quot;Delete&quot;
    (click to zoom)

    Then go to the Replication instances section of the AWS DMS console. If your replication instance is not being used for any other replication tasks, choose it and then choose Delete.

    If your replication instance is not being used for any other replication tasks, choose it and then choose &quot;Delete&quot;
    (click to zoom)

    Next, delete the SQL Server database you used as a sample source database. Navigate to the Amazon RDS console, choose your SQL Server database, and then choose Delete.

    Delete the SQL Server database you used as a sample source database
    (click to zoom)

    Finally, you need to delete the DynamoDB table you created in this lesson. Navigate to the DynamoDB console, choose the table, and then choose Delete table.

    Delete the DynamoDB table you created in this lesson
    (click to zoom)

    AWS DMS created a table called awsdms_full_load_exceptions to help track exceptions. Delete this table as well.

    Finally, you need to delete the IAM role and policy that you created for AWS DMS to use in the migration.

    Navigate to the Roles section of the IAM console. Find the role you created for AWS DMS and choose it. Then choose Delete role.

    Delete the IAM role and policy that you created for AWS DMS to use in the migration
    (click to zoom)

    Then go to the Policies page of the IAM console. Choose the Filter policies filter and then choose Customer managed.

    On the &quot;Policies&quot; page of the IAM console, choose the &quot;Filter policies&quot; filter and then choose &quot;Customer managed&quot;
    (click to zoom)

    On the Policies page of the IAM console, delete the IAM policy. 

    On the Policies page of the IAM console, delete the IAM policy
    (click to zoom)

    In this module, you learned how to migrate your application to use your new database. You also saw how to clean up the resources you created during this lesson.

In this lesson, you migrated a legacy relational database to a cloud-native NoSQL database in DynamoDB. Moving from a relational database to a NoSQL database requires some changes to your data model. In this lesson, you saw how to make those changes and automate the migration by using AWS DMS.