Enabling AWS tags for billing

Martina Della Corte — Tue, 09 Apr 2024 00:00:00 +0000

Recently I began tagging resources in my primary AWS account.

I use this account as a playground where I can experiment with services and occasionally host side projects.

As I've recently hosted new projects, I figured it was time to have a better understanding of costs, hence the decision to implement tagging.

AWS offers a suite of services and tools called Cloud Financial Management, among which is AWS Cost Explorer.

AWS Cost Explorer is a tool that allows you to analyze the costs and usage of your AWS resources.
It provides a user-friendly interface to visualize your data, allowing you to manipulate several parameters to customize your reports. You can adjust the time period, group data by various dimensions, and filter data based on different criteria.

One such criterion for grouping and filtering data is Tags.

So I tagged my resources, but I was surprised to realize that the tags were not included among the filters.

Turns out, you have to activate tags to make them show up.

In many projects I've worked on, there's usually a team that handles costs behind the scenes. So even though I've spent a lot of time with AWS Cost Explorer, I didn't realize I needed to activate tags myself.

Let's see how to enable tags for cost allocation.

Enabling tags for billing

Log in into your console and navigate to Billing and Cost Management.
In the side menu, go to the Cost Organization section and click on Cost Allocation Tags.

You will see a view with two tabs:

User-defined cost allocation tags: where tags defined by you are listed.
AWS generated cost allocation tags: where tags automatically generated by AWS, depending on the services you've used, are listed.

Example:

As mentioned before, this is my experimental account, so the tags I've created are somewhat random. I recommend utilizing tag categories suggested by AWS You can find them
here.

Select the tags you would like to activate and click on Activate button.

The activation was not retroactive until the 27th of March 2024, when it was announced the support for it up to twelve months.

The retroactive application is not automatic. You can read more about how to request a backfill of cost allocation tags here.

Here the retroactive application announcement.

Conclusions

This quick article reminded you to activate tags explicitly if you want to use them for cost allocation and showed you how to do it.

I hope you find this post helpful. See you next time folks! 🚀

References

AWS Cost Explorer

Activating user-defined cost allocation tags

Retroactive application announcement

Backfill cost allocation tags

Use AWS Credentials in a Dev Container

Martina Della Corte — Sun, 14 Jan 2024 00:00:00 +0000

If you work with AWS, you must have used AWS credentials at least once to run commands through the AWS CLI, CDK CLI, or SAM CLI.

When developing in a Dev Container, you don't have access to your local file system. So, if you try to run an AWS command in the Dev Container, you will encounter some sort of "missing credentials" error.

How can you fix this?

It is quite easy to overcome this issue. Remember that a Dev Container is a Docker Container. Therefore, you can use a bind mount to link the directory and the files that contain AWS credentials configurations (a.k.a. the .aws directory).

If you want to read more about Bind Mount, here's the link.

Adding a bind mount to a Docker Container

In Docker, you can add bind mounts using the --mount flag when running docker run:

docker run --mount type=bind,source=/.aws,target=/home/vscode/.aws,readonly

Let's dive into the command and try to understand each part.

First of all, as explained in the docs, --mount consists of multiple key-value pairs, separated by commas and each consisting of a
key=value pair.

OBS:
The order of the key-value pairs is not significant.

Let's see which keys are set in our command:

type: the type of the mount, which is bind.
source(or src): represents the local path to find the directory we want to mount. In this case the path of our .aws directory.
target(or dst or destination): represents the path where our local directory will be mounted in the container.
readonly option, which is used when the container does not need write access. In our case, the Dev container only need to read credentials, not to write them.

OBS:
In case you are using SSO to login, you will need to remove readonly option because new temporary credentials will be added.

More details about the --mount flag can be found here.

Now that we have understood how to add a bind mount to a Docker container, let's see how to do this using the devcontainer specification.

Adding a bind mount in a Dev container defined with devontainer.json.

When using devontainer.json, you can set the command under mounts property:

{
    "mounts": [
        "source=${localEnv:HOME}/.aws,target=/home/vscode/.aws,type=bind,readonly"
    ]
}

it looks pretty much the same, the only difference is the value of source:

localEnv:HOME, is a pre-defined variable.
You can find the list of available variables you can use in devcontainer.json here.

The semantic here is:

print the value of HOME variable that is on the local machine.

In this case I want the value of the variable HOME, since I am wokring on mac. For Windows users, the mounts the variable to select is USERPROFILE. Therefore, the specification property would look like:

{
    "mounts": [
        "source=${localEnv:USERPROFILE}/.aws,target=/home/vscode/.aws,type=bind,readonly"
    ]
}

A note.

If you want define a devcontainer.json that is not dependent on any specific IDE, you can use the following:

{
    "mounts": [
        "source=${localEnv:HOME}/.aws,target=/.aws,type=bind,readonly"
    ],
    "containerEnv": {
        "AWS_CONFIG_FILE": "/.aws/config",
        "AWS_SHARED_CREDENTIALS_FILE": "/.aws/credentials"
    },
}

In this way, you can set any path as your target, but you have to specify the custom config and credentials paths using respectevely,
AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE env variables.

You can read more about it on the following pages:

Checking the result

How can you check if we actually managed to mount the .aws on your Dev Container?

The easiest way is to check in Docker Desktop.
If go to Containers section and then click on the one of your interest, there you should see something like this:

bindmount.png)

Also, we can look at the Inspect tab and if you scroll to Mounts property, you should see something like the following:

Here, you can also see that readonly option was applied as well.

Conclusion

In this article we have seen how to use AWS credentials in a Dev Container.
I have created a repository on gitHub which contains an example that applies what we have seen today, to run AWS CLI commands.
Enjoy it!

That's all folks! 🚀
Stay tuned!

DEV Community: Martina Della Corte

Enabling AWS tags for billing

Enabling tags for billing

Conclusions

References

Use AWS Credentials in a Dev Container

Adding a bind mount to a Docker Container

Adding a bind mount in a Dev container defined with devontainer.json.

Checking the result

Conclusion

References