This guide will briefly explain how .NET's resource management works and its limitations when it comes to dealing with unmanaged resources. You'll then see how the IDisposable interface can be implemented in different scenarios to ensure resources are cleaned up properly.

Resource Management in .NET

The .NET runtime manages a memory heap for your application's reference types. While the runtime handles the allocation, the Garbage Collector (GC) is responsible for automatically reclaiming memory from objects that are no longer in use. It is also responsible for optimizing memory by compacting the heap. This entire process frees you from manually deallocating memory.

Since the runtime manages the memory for reference types, it's called managed memory. However, applications can often use unmanaged resources. The memory for these resources sits outside the runtime's control and visibility. Such resources can include file handles, database connections, and network sockets. Because it has no visibility of these resources, the GC has no way of compacting or reclaiming this memory automatically. Instead, the class itself needs to release these unmanaged resources to prevent memory leaks.

To solve this problem, .NET provides the IDisposable interface to deterministically cleanup resources. The following section demonstrates a simple IDisposable implementation that is most commonly used.

The Basic Dispose Pattern: A Simple Implementation

In most cases, your classes will work with unmanaged resources that are already wrapped in their own IDisposable classes.

For instance, your class might use the NpgsqlConnection class to establish a connection to a PostgreSQL database. Even though the database connection is an unmanaged resource, the NpgsqlConnection class already implements a Dispose() method to manage those resources. Your class's Dispose() method simply needs to call the database's Dispose() method.

This is demonstrated in the code snippet below:

public class CustomerRepository : IDisposable
{
    private bool _disposed = false;

    private readonly NpgsqlConnection _connection;

    public CustomerRepository(string connectionString)
    {
        _connection = new NpgsqlConnection(connectionString);
        _connection.Open();
    }

    // Methods that use the database connection...

    public void Dispose()
    {
        if (_disposed)
            return;

        _disposed = true;

        // Call the database Dispose() method to handle cleanup
        _connection.Dispose();
    }
}

Notice how the CustomerRepository.Dispose() method makes a call to the underlying database connection to dispose it. Now the unmanaged resource is taken care of. Nothing too complicated!

The _disposed field also keeps track of whether the dispose method has been called already. This is important, since your Dispose() method should always be idempotent, otherwise exceptions might be thrown.

Consuming the IDisposable Class

When consuming the class above, you should use the using block as it automatically calls Dispose() for you when you're finished with the object:

using (var repository = new CustomerRepository(_connectionString))
{
    // Use repository here...
} // Calls repository.Dispose() automatically

Notice how the Dispose() method is called as soon as you reach the end of the using block.

You can also remove the block, in which case the Dispose() method will be called when the surrounding code block ends:

private Customer? FindCustomer(int id)
{
    // Create repository with `using var`
    using var repository = new CustomerRepository(_connectionString);

    return repository.Get(id);
} // Calls repository.Dispose() automatically

In the snippet above, the Dispose() method will be called automatically after the function returns.

The Full Dispose Pattern: Handling Unmanaged Resources

The implementation above will suffice for most of your IDisposable implementations. However, there might be times when you're dealing with unmanaged resources directly (i.e., they aren't wrapped in their own IDisposable). In those cases, there are a couple more things to consider in your implementation.

Take a look at the implementation below:

using Microsoft.Win32.SafeHandles;
using System.ComponentModel;
using System.Runtime.InteropServices;

public class UnmanagedFileHandler : IDisposable
{
    // Raw, unmanaged resource pointer
    private IntPtr _handle;

    // Managed resource
    private readonly MemoryStream _buffer;

    private bool _disposed = false;

    // Using a constant for the invalid handle value for clarity.
    private static readonly IntPtr INVALID_HANDLE_VALUE = new(-1);

    // Import the CreateFile function from the Windows API.
    [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    private static extern IntPtr CreateFile(
        string lpFileName,
        uint dwDesiredAccess,
        uint dwShareMode,
        IntPtr lpSecurityAttributes,
        uint dwCreationDisposition,
        uint dwFlagsAndAttributes,
        IntPtr hTemplateFile);

    // Import the CloseHandle function.
    [DllImport("kernel32.dll", SetLastError = true)]
    [return: MarshalAs(UnmanagedType.Bool)]
    private static extern bool CloseHandle(IntPtr hObject);

    // Constants for file access from the Windows API.
    private const uint GENERIC_WRITE = 0x40000000;
    private const uint CREATE_ALWAYS = 2;
    private const uint NO_SHARING = 0;
    private const uint DEFAULT_ATTRIBUTES = 0;

    public UnmanagedFileHandler(string filePath)
    {
        // Call the unmanaged Windows API to get a file handle.
        _handle = CreateFile(
            filePath,
            GENERIC_WRITE,
            NO_SHARING,
            IntPtr.Zero,
            CREATE_ALWAYS,
            DEFAULT_ATTRIBUTES,
            IntPtr.Zero);

        _buffer = new MemoryStream();

        // Check if the handle is valid. If not, throw an exception.
        if (_handle == INVALID_HANDLE_VALUE)
            throw new Win32Exception(Marshal.GetLastWin32Error(), "Failed to create the file handle.");
    }

    // File methods here...

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    ~UnmanagedFileHandler()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            // Dispose managed resources if called from Dispose()
            _buffer.Dispose();
        }

        // Always dispose unmanaged resources
        if (_handle != IntPtr.Zero && _handle != INVALID_HANDLE_VALUE)
        {
            CloseHandle(_handle);
            _handle = IntPtr.Zero;
        }

        _disposed = true;
    }
}

That's a bit more code!

First, notice how the class has an IntPtr pointing to a file, which is created using Window's low-level CreateFile method. This pointer is an unmanaged resource that has to be cleaned up manually.

A MemoryStream is also created to act as a buffer. This is another unmanaged resource. However, because the MemoryStream class implements IDisposable, you only need to call the Dispose() method on that field.

There's also a new Dispose(bool disposing) method. It cleans up managed and unmanaged resources. This method can be called from two places in the class: the IDisposable.Dispose() method, or the class finalizer.

The GC calls the finalizer before reclaiming the object's memory.

When calling the new Dispose(bool disposing) method, the disposing parameter is determined by the origin of the method call:

• When called from IDisposable.Dispose(), then disposing is true, meaning both managed and unmanaged resources should be cleaned up.

• When called from the finalizer (i.e., ~UnmanagedFileHandler()), then disposing is false, so only unmanaged resources are cleaned up. This is because the GC will finalize the owned managed resources, so no need to Dispose() them ourselves.

GC.SuppressFinalize() is also called on the current object in the Dispose() method. This tells the GC that it does not need to call the finalizer method on this class.

This is necessary for performance reasons, since finalizers are not exactly efficient. When the GC encounters a class with a finalizer that needs to be reclaimed, it first places that finalizer on a queue to execute later. This is to prevent the current GC run from being potentially delayed by calling the finalizer immediately. Once the current GC run is finished, the finalizer is executed. Only after the finalizer is executed does the class become eligible to be reclaimed.

So by suppressing the finalizer on the class, the memory for that class can be immediately reclaimed without waiting for the finalizer to execute first.

Finally, you'll see the Dispose(bool disposing) method is virtual. In the next section, you'll find out why this is necessary when it comes to class inheritance with IDisposable.

Disposing of Inherited Classes

What happens if a class inherits from your IDisposable class and uses its own unmanaged resources? The child class's resources also need to be cleaned up, along with the parent class's resources.

Fortunately, since the Dispose(bool disposing) method is virtual, a child class can execute its own cleanup logic when the class is disposed.

The code snippet below is for a LogFileHandler class, which inherits from the UnmanagedFileHandler class referenced above.

public class LogFileHandler : UnmanagedFileHandler
{
    private bool _disposed = false;

    private readonly MemoryStream _logBuffer;

    public LogFileHandler(string filePath) : base(filePath)
    {
        _logBuffer = new MemoryStream();
    }

    // Log methods here...

    // Override the parent class Dispose method to clean up the additional resource.
    protected override void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        _disposed = true;

        if (disposing)
        {
            // Dispose the additional managed resource
            _logBuffer.Dispose();
        }

        // No unmanaged resources to clean up in this child class

        // Call the base class Dispose method
        base.Dispose(disposing);
    }
}

The LogFileHandler class has its own MemoryStream field, which is used to buffer log messages. This resource implements the IDisposable interface, so the LogFileHandler must override the Dispose(bool disposing) method from the parent class to dispose of the buffer. When overriding the method, the base class Dispose(bool disposing) method must still be called.

Since the Dispose(bool disposing) method is already called from the IDisposable.Dispose() and finalizer in the base class, there's no need to implement them in the LogFileHandler class.

Best Practices

When implementing any of the patterns above, keep these things in mind to ensure your disposal logic is robust.

Ensure Idempotency

Calls to Dispose() should always be idempotent to avoid exceptions from being thrown. This can happen if part of disposing of a property sets it to an invalid value (like null):

public void Dispose()
{
    _connection.Dispose();
    _connection = null;
}

If, for any reason, the Dispose() method above is called again, a NullReferenceException will be thrown because _connection was set to null previously.

So it's best to always use a _disposed private field to track if the dispose has already been run:

public void Dispose()
{
    if (_disposed)
        return;

    _disposed = true;

    _connection.Dispose();
    _connection = null;
}

Now the method will return early if it's ever called multiple times.

Don't Throw Exceptions in Finalizers

When implementing a finalizers that dispose resources, it's crucial to avoid throwing any exceptions as they can have unintended side effects, like causing the entire application to crash.

Always write your finalizers as defensively as possible to prevent unhandled exceptions from surfacing.

Cascade Dispose Calls to Owned Resources

Any class that owns resources that implement IDisposable must implement the IDisposable interface and call the Dispose() method on those resources in its own Dispose() method. If not done, owned resources won't be released, which could cause memory leaks.

Always Call Base Class Dispose

If a class inherits from another class implementing IDisposable, make sure you override the Dispose(bool disposing) method to release any unmanaged resources in the inherited class.

Also, always call the base class's Dispose(bool disposing) method from the overridden method.

Use SafeHandle to Managed Those Unmanaged Resources

The full Dispose pattern is necessary if your class deals with unmanaged resources directly (i.e., the resources don't have an existing IDisposable wrapper, such as IntPtr). However, the .NET runtime comes with SafeHandle classes that can wrap any raw unmanaged IntPtr in an IDisposable. These wrapper classes manage the pointer for you, meaning your class only needs to implement the Basic Dispose pattern.

The official documentation goes into great detail on SafeHandles and how they simplify disposing of a class.

Disposing Asynchronously with IAsyncDisposable

When your class holds resources that involve asynchronous operations during cleanup (like closing a database connection or releasing a lock), you should implement the IAsyncDisposable instead of (or in addition to) IDisposable. This allows for non-blocking cleanup, keeping your application responsive.

The IAsyncDisposable interface expects a ValueTask DisposeAsync() method to be implemented.

Below is an example of implementing the IAsyncDisposable interface:

public class CustomerRepository : IAsyncDisposable
{
    // ... 

    public async ValueTask DisposeAsync()
    {
        // Implement asychronous cleanup logic
        await _connection.DisposeAsync();

        // Also implement any synchronous cleanup here as well
        _buffer.Dispose();
    }
}

Consuming an IAsyncDisposable class is similar to the IDisposable class. You just need to add await to your using statement:

await using (var repository = new CustomerRepository(_connectionString))
{
    // Use repository here
} // Calls repository.DisposeAsync() automatically

Conclusion

While the .NET GC does a great job of managing memory, it cannot clean unmanaged resources, like low-level file handles or database connections. The IDisposable interface helps ensure all managed and unmanaged resources are cleaned up deterministically.

Hopefully, this guide has shed some light on the Dispose pattern in C#. In most cases, you'll stick to the first, simple implementation. However, if you ever have to clean up unmanaged resources manually, a bit more code is needed to make it work.

By implementing the IDisposable interface properly, you'll reduce the number of potential memory leaks, resulting in a robust and stable end product.

This caught me off-guard since my particular use case required a case-sensitive comparison. I managed to get case-sensitive comparisons to work and thought I'd share it.

Using the Equals operator (-eq/-ceq)

When you would like to see if two strings are exactly the same, you can make use of the equals operator.

Case-Insensitive Equals (-eq)

You can use -eq to perform a case-insensitive string comparison.

❯ "Ivan Kahl's Blog" -eq "ivan kahl's BLOG"
True

Case-Sensitive Equals (-ceq)

If you would like to do a case-sensitive string comparison, you can use -ceq:

❯ "Ivan Kahl's Blog" -ceq "ivan kahl's BLOG"
False

Using the Like operator (-like/-clike)

You can also use patterns for string comparisons using the Like operator in Powershell.

Case-Insensitive Like (-like)

If you want to use a pattern for string comparison and not worry about the case, use -like:

❯ "Ivan Kahl's Blog" -like "ivan kahl's*"
True

Case-Sensitive Like (-clike)

If you do want to check case while using string patterns, you can make use of -clike:

❯ "Ivan Kahl's Blog" -clike "ivan kahl's*"
False

Closing

I hope you found this quick tip useful. If you have any questions or thoughts, please leave a comment below.

Many services in the AWS ecosystem feed their logs directly into CloudWatch by default without any configuration needed. This is convenient when debugging AWS services, but you might find yourself figuring out how to send your own application's logs to AWS (when AWS doesn't automatically forward them to AWS CloudWatch like it does with some services). This could happen if you are running your application on an EC2 instance or in a container.

In this article, we are going to look at how we can log messages to AWS CloudWatch in .NET. We will be using the AWS SDK to get a low-level, first principles understanding of how it's done before having a look at logging to AWS CloudWatch using popular logging libraries such as Serilog and NLog in future posts.

Video

Prerequisites

AWS Account

You will need an active AWS account that we can use to push logs from our .NET application to AWS CloudWatch. Our volumes will be minimal so we shouldn't exceed the free tier for AWS CloudWatch.

If you don't have an AWS account yet, you can sign up for one here.

AWS Profile

Since this article is just focusing on AWS CloudWatch, we won't be configuring any AWS credentials in our .NET application. Rather, we will let the AWS SDK automatically use our AWS profile that is set up when running the AWS CLI. This simplifies the demonstrations as we don't have to fumble around with permissions and credentials.

However, please note that you should always make sure to give applications their own IAM roles/users in production with minimal permissions according to AWS best practices.

Let's Go!

With that out the way, let's get started!

1. Create a new Console application

We will be using a .NET 6 Console application in this demonstration. You can create this project using either Visual Studio 2022 or the .NET 6 CLI.

2. Add the AWS SDK Nuget package

Before we can do anything with AWS CloudWatch from .NET, we need to install the AWSSDK.CloudWatchLogs Nuget package. This will allow us to make calls to the AWS CloudWatch service from .NET programmatically using an SDK developed by AWS.

3. Create a Logging class

We will be encapsulating our logging logic in a single Logging class (called CloudWatchLogger). This will neaten up our logging logic and keep it out of our application code.

While we are creating our own CloudWatchLogger, it will be a heavily simplified logger that aims to simply demonstrate how most logging libraries log to AWS CloudWatch. In production, it is advisable to use an existing logging library to log to AWS CloudWatch rather than try roll your own.

4. Asynchronously construct our CloudWatchLogger class

When interacting with AWS services using the AWS SDK, all of our operations occur asynchronously. This is important to remember because we are going to do some initialization in AWS CloudWatch when creating our logger. In order to do this initialization, we need to be able to construct our CloudWatchLogger asynchronously.

You can see how we are able to do this using a private constructor and asynchronous static method:

CloudWatchLogger.cs

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    private CloudWatchLogger()
    {
    }

    public static async Task<CloudWatchLogger> GetLoggerAsync()
    {
        var logger = new CloudWatchLogger();

        // Do more initialization work here

        return logger;
    }
}

The pattern you're seeing is similar to the factory method of constructing objects where we have a method create instances of an object.

5. Create the AmazonCloudWatchLogsClient

We first need to create an instance of AmazonCloudWatchLogsClient that we will then use to call AWS CloudWatch methods. We will create a new instance in the constructor and assign it to a private field for later use:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    private IAmazonCloudWatchLogs _client;

    private CloudWatchLogger()
    {
        // If don't have an AWS Profile on your machine and application is hosted outside
        // of AWS infrastructure (where IAM roles cannot be assigned to infrastructure),
        // rather use:
        // _client = new AmazonCloudWatchLogsClient(awsAccessKeyId, awsSecretAccessKey, RegionEndpoint.AFSouth1);
        _client = new AmazonCloudWatchLogsClient();
    }

    public static async Task<CloudWatchLogger> GetLoggerAsync()
    {
        var logger = new CloudWatchLogger();

        return logger;
    }
}

6. Create a Log Group

In AWS CloudWatch, logs are grouped at a top-level into Log Groups. Each Log Group can belong to a different application or service in AWS. For example, a Log Group for an AWS Lambda function called first_python_function might look like this:

/aws/lambda/first_python_function

When we construct our new logger, we will need to create a new Log Group that we can log to:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;
using Amazon.CloudWatchLogs.Model;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    private IAmazonCloudWatchLogs _client;
    private string _logGroup;

    private CloudWatchLogger(string logGroup)
    {
        // If don't have an AWS Profile on your machine and application is hosted outside
        // of AWS infrastructure (where IAM roles cannot be assigned to infrastructure),
        // rather use:
        // _client = new AmazonCloudWatchLogsClient(awsAccessKeyId, awsSecretAccessKey, RegionEndpoint.AFSouth1);
        _client = new AmazonCloudWatchLogsClient();
        _logGroup = logGroup;
    }

    public static async Task<CloudWatchLogger> GetLoggerAsync(string logGroup)
    {
        var logger = new CloudWatchLogger(logGroup);

        // Create a log group for our logger
        await logger.CreateLogGroupAsync();

        return logger;
    }

    private async Task CreateLogGroupAsync()
    {
        _ = await _client.CreateLogGroupAsync(new CreateLogGroupRequest()
        {
            LogGroupName = _logGroup
        });
    }
}

While this might look like it should work, after calling our constructor a second time, you will get the following exception:

As you've probably already guessed, this exception is being thrown because we're trying to create a Log Group that already exists! We need some way of making sure we don't crash the application because the log group already exists. There are a few techniques for doing this. We will take a rather simple and naive approach and update our CreateLogGroupAsync method as follows:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;
using Amazon.CloudWatchLogs.Model;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    // ...

    private async Task CreateLogGroupAsync()
    {
        var existingLogGroups = await _client.DescribeLogGroupsAsync();
        if (existingLogGroups.LogGroups.Any(x => x.LogGroupName == _logGroup))
            return;

        _ = await _client.CreateLogGroupAsync(new CreateLogGroupRequest()
        {
            LogGroupName = _logGroup
        });
    }
}

This will now fetch a list of all the Log Groups in AWS and check if our Log Group already exists. If it does, we return before creating a new Log Group.

Let's do a quick test to see what happens when we create a new instance of our logger:

Program.cs

using AWSCloudWatchLoggingWithAWSSDK;

var logger = await CloudWatchLogger.GetLoggerAsync("/dotnet/logging-demo/awssdk");

AWS CloudWatch Console

You can see that we have a new Log Group created in the AWS CloudWatch Console now!

7. Create a Log Stream

Previously we created a Log Group to contain logs for our application. In AWS CloudWatch, our logs are group again into Log Streams. Ideally, these Log Streams group log events from a single invocation or request in an application. For example, if you had a web application, you would group a single request sent to your web application in a Log Stream.

In our example, we are going to create a Log Stream in the constructor and reuse that Log Stream throughout the lifetime of that instance of the CloudWatchLogger class:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;
using Amazon.CloudWatchLogs.Model;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    // ...

    private string _logStream;

    // ...

    public static async Task<CloudWatchLogger> GetLoggerAsync(string logGroup)
    {
        var logger = new CloudWatchLogger(logGroup);

        // Create a log group for our logger
        await logger.CreateLogGroupAsync();

        // Create a log stream
        await logger.CreateLogStreamAsync();

        return logger;
    }

    // ...

    private async Task CreateLogStreamAsync()
    {
        _logStream = DateTime.UtcNow.ToString("yyyyMMddHHmmssfff");

        _ = await _client.CreateLogStreamAsync(new CreateLogStreamRequest()
        {
            LogGroupName = _logGroup,
            LogStreamName = _logStream
        });
    }
}

If we now run our program again and look in AWS CloudWatch, we should see a newly created Log Stream in our Log Group:

Awesome!

8. "Put" log messages into AWS CloudWatch

Now that we've set up a Log Group and Log Stream, we're finally ready to start sending log messages to AWS CloudWatch! The AWS SDK provides a method called PutLogEventsAsync which allows us to upload a batch of log events to AWS CloudWatch.

For simplicity's sake we are going to call this method every time we log a message, however, we can exceed our maximum requests per second very quickly this way. Hence, it is best practice to batch these log events when sending them through to AWS CloudWatch.

Let's create a LogMessageAsync method which will write our log message to AWS CloudWatch when called:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;
using Amazon.CloudWatchLogs.Model;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    // ...

    public async Task LogMessageAsync(string message)
    {
        _ = await _client.PutLogEventsAsync(new PutLogEventsRequest()
        {
            LogGroupName = _logGroup,
            LogStreamName = _logStream,
            LogEvents = new List<InputLogEvent>()
            {
                new InputLogEvent()
                {
                    Message = message,
                    Timestamp = DateTime.UtcNow
                }
            }
        });
    }

    // ...
}

Let's run the following program and see what happens:

Program.cs

using AWSCloudWatchLoggingWithAWSSDK;

var logger = await CloudWatchLogger.GetLoggerAsync("/dotnet/logging-demo/awssdk");

await logger.LogMessageAsync("This is my first message!");
await logger.LogMessageAsync("this is another message much like the first!");

You will see that we get the following exception when trying to call LogMessageAsync a second time:

This is caused by not providing a Sequence Token when putting log events into the Log Stream. The first time we call PutLogEventsAsync on an empty Log Stream, the Sequence Token is not required because the Log Stream is empty. But, once we've written messages to the Log Stream, subsequent calls need to provide a Sequence Token so that they can be written in the correct order.

Fortunately, this isn't too hard to fix in our simple demonstration:

CloudWatchLogger.cs

using Amazon.CloudWatchLogs;
using Amazon.CloudWatchLogs.Model;

namespace AWSCloudWatchLoggingWithAWSSDK;

public class CloudWatchLogger
{
    //...

    private string _nextSequenceToken = null;

    // ...

    public async Task LogMessageAsync(string message)
    {
        var response = await _client.PutLogEventsAsync(new PutLogEventsRequest()
        {
            LogGroupName = _logGroup,
            LogStreamName = _logStream,
            SequenceToken = _nextSequenceToken,
            LogEvents = new List<InputLogEvent>()
            {
                new InputLogEvent()
                {
                    Message = message,
                    Timestamp = DateTime.UtcNow
                }
            }
        });

        _nextSequenceToken = response.NextSequenceToken;
    }

    // ...
}

We've now created a private field to store the next Sequence Token that should be used the next time we insert log events into the Log Stream. Initially, the private field is set to null, but that's not a problem for our implementation because we know that our first request to log a message to the Log Stream will always be to an empty Log Stream. Thereafter, we get the NextSequenceToken value from the response object and store it in the private field for next time.

And that solves the issue! You should now see our two, beautiful logged messages in AWS CloudWatch:

Closing

That's all for this first post in the Logging .NET to AWS CloudWatch series. The goal of this post was to give you a first principles, hands-on demonstration of how we use the AWS SDK to log to AWS CloudWatch.

It is a very simplified demonstration, but it paves the way for understanding how existing logging libraries implement this functionality such as Serilog or NLog. We will focus on implementing logging to AWS CloudWatch using these libraries in the next few posts in this series.