Using MySql.Data in .NET AWS Lambda with D.I

I'm refactoring a .NET AWS Lambda project with MySql.Data in it for connecting to AWS Aurora. I implemented the DI process and registered MySqlConnection into DI container as Transient and injected it into the DataAccess service.

The registration of MySqlConnection and the DataAccess go something like this:

Startup:

services.AddTransient<MySqlConnection>(provider => 
{
    //Get the necessary parameters and build a connection string.

    return new MySqlConnection(connectionString);
});

services.AddSingleton<IDataAccess, DataAccess>();

DataAccess:

private readonly MySqlConnection _connection;

// inject the MySqlConnection.

async function() 
{
  await _connection.OpenAsync();
  await _connection.DoStuff();
  await _connection.CloseAsync();
}

My boss concerned that all of the DB interaction will be going through a single connection that is injected into the DataAccess class and she doesn't want the db to crash because I'm not cleaning up the connections properly.

I have a few questions:

1. I see the old code base has the using statement when it create a new MySqlConnection but I don't see one on the MySql documentation. Do I need the "using" statement when I create a new MySqlConnection?
2. Should I register MySqlConnection as Transient and use DI or simply create a new MySqlConnection instance inside the class that use it?
3. Is the DI of the DB connection going to leave a lot of open connections? Or, on the other extreme, that a single connection is going to slow down the lambda because it used to make numerous connections?

Thank you!

IMO, instead of using DI, you can go with using statements. SQL connections will be picked from pool that .NET maintain at application level, and will be returned once connection is closed. Refer this answer for more detail.

However, connection pooling won't help much in case of AWS Lambda, as entire Lambda compute is destroyed after idle timeout. So it is recommended to use RDS proxy to avoid connection related issues.

> Using RDS Proxy, you can handle unpredictable surges in database traffic. Otherwise, these surges might cause issues due to oversubscribing connections or creating new connections at a fast rate. RDS Proxy establishes a database connection pool and reuses connections in this pool. This approach avoids the memory and CPU overhead of opening a new database connection each time. To protect the database against oversubscription, you can control the number of database connections that are created.

Also, you can checkout RDS Proxy for SQL Server with AWS Lambda and .NET 6