The Wombelix Post - AI

params2env: AWS SSM Parameter Store to Environment variables

2025-08-07T00:00:00+02:00

I recently released params2env, a CLI tool written in Go that manages AWS SSM Parameter Store parameters and converts them to environment variables. The project is available under the MIT license with mirrors on Codeberg, GitLab and GitHub. Pre-built binaries for Linux, macOS, and Windows are available on the GitHub Releases page.

My motivation was using AWS SSM Parameter Store as a low-cost password manager for applications and pipelines. I don't need advanced features like rotation that AWS Secrets Manager offers, so Parameter Store is much cheaper, basically free, compared to Secrets Manager with costs per managed secret. I did some research and there wasn't a tool that did exactly what and how I wanted it, so I built it myself.

This tool is for you if you store configuration or secrets in AWS SSM Parameter Store and need to get them into environment variables for your applications. It doesn't matter if your workload runs on AWS, on-premises, or anywhere else. As long as your application reads environment variables, params2env can provide them from Parameter Store.

Parameter Store standard parameters with AWS-managed encryption are free, so using params2env with standard parameters has no additional AWS costs beyond your existing setup. Advanced parameters cost $0.05 per parameter per month. If you use customer-managed KMS keys for SecureString parameters, each key costs $1 per month. See the AWS Systems Manager pricing and AWS KMS pricing pages for current details.

params2env provides four main subcommands for complete parameter management. The read command retrieves parameters and outputs them as environment variables, either to stdout or files. You can customize variable names, add prefixes, control case conversion, and read multiple parameters from a YAML configuration file. The create command creates new parameters with support for both String and SecureString types. The modify command updates existing parameter values and descriptions while preserving the original parameter type. The delete command removes parameters from Parameter Store.

The tool uses the AWS Go SDK for authentication and supports all standard AWS credential methods including IAM roles, profiles, and environment variables. Role assumption is built-in for working across different AWS accounts and regions. For SecureString parameters, it handles KMS encryption and supports both AWS-managed and customer-managed KMS keys. When working with replicas, it automatically handles KMS key ARN conversion between regions.

Configuration can be managed through YAML files with a clear precedence order: command line arguments override local config files (.params2env.yaml), which override global config files (~/.params2env.yaml). This makes it flexible for both one-off commands and repeatable workflows. The usage instructions include detailed examples and configuration options.

You can install directly with Go:

go install git.sr.ht/~wombelix/params2env@latest

or pre-build binaries from the Releases page.

Basic usage to read a parameter and set it as an environment variable:

# Output to stdout
params2env read --path "/my/secret"

# Set in current shell
eval $(params2env read --path "/my/secret")

# Write to file
params2env read --path "/my/secret" --file ~/.env

Note: Only use eval with trusted sources. Since params2env outputs shell commands, ensure you trust the parameter values and the tool itself before executing the output in your shell.

Creating parameters:

# String parameter
params2env create --path "/my/param" --value "hello"

# SecureString with KMS
params2env create --path "/my/secret" --value "s3cret" \
  --type SecureString --kms "alias/myapp-key"

For managing multiple parameters, you can use a YAML configuration file:

region: eu-central-1
role: arn:aws:iam::123456789012:role/my-role
env_prefix: APP_
params:
  - name: /app/db/url
    env: DB_URL
  - name: /app/db/password
    env: DB_PASSWORD

Then run params2env read to process all configured parameters.

The replica feature is not an AWS native feature, it is something I've built into the tool. It performs create, edit, or delete operations in two regions instead of just one. AWS KMS supports custom keys to have identical backup keys in another region. This way you have your key material and secrets region redundant if you want that with minimal overhead and costs. This is useful for disaster recovery scenarios or when you need the same secrets available in multiple regions for your applications.

The code is organized into packages: cmd handles CLI interactions, internal/aws manages AWS SDK operations, internal/config handles YAML parsing, internal/validation provides input validation, and internal/logger manages logging. Input validation happens before AWS API calls to check parameter paths, regions, KMS key formats, and IAM role ARNs.

The project includes both unit tests and integration tests. Unit tests focus on business logic validation. Integration tests in tests/integration-tests.sh validate real AWS service interactions, including parameter creation, modification, deletion, and role assumption. The build system uses a Makefile with targets for build, tests, and clean.

Parts of the tool were built with AI assistance. I started with Cursor about half a year ago, curious how well it would work to describe the program features and implementation details, let AI create a design document, then use the AI agent to build out structure and functionality based on that guide. It went surprisingly well but required many iterations and improvements.

When I recently continued work on params2env, I used Amazon Q Developer to get up to speed on what I had implemented in an unfinished feature branch. I compared it with existing features and the original planning doc to identify what was missing.

I still wrote the majority of the code myself and worked on improvements through multiple iterations. But AI saved time and suggested ideas and solutions I might not have thought of or would have taken longer to develop.

Overall I think such AI tools are a positive thing and can make some tasks easier and faster. But they are not a magic solution that builds applications automatically end to end. Similar to my experience with DNS management with OpenTofu and some AI assistance, it was a useful experiment in understanding what these tools can contribute.

Building params2env was another great opportunity to improve my skills in Go development, AWS SDK usage, and CLI tool design.

Serverless RAG without monthly costs using AWS Bedrock and S3 Vectors

2025-07-30T00:00:00+02:00

I was curious if it's possible to build a Retrieval-Augmented Generation (RAG) system for an AI chatbot in a pure serverless way without monthly fixed costs. The main goal was to test some ideas without investing much in infrastructure upfront. When AWS launched S3 Vectors on July 15th, it immediately caught my attention because it promised exactly what I was looking for.

Part of the S3 Vectors announcement was that it can be used as a vector store in AWS Bedrock Knowledge Base too, which made it even more interesting. This combination could potentially solve the cost challenge I was facing with traditional vector databases that come with monthly fees regardless of usage.

S3 Vectors is currently in preview and available in five regions: US East (N. Virginia), US East (Ohio), US West (Oregon), EU Central 1 (Frankfurt), and Asia Pacific (Sydney). I picked eu-central-1, which is closest to me, for my tests and pricing calculations. I use around 500 markdown files from the Rancher Manager Documentation as my test dataset. Unlike regular S3 buckets, S3 Vectors doesn't require a globally unique name since you reference it by ARN, which means it only needs to be unique within the same account and region.

Setting up the Bedrock Knowledge Base was overall pretty straightforward. The wizard guides you through all the steps, though I created the S3 bucket and S3 Vectors bucket upfront. I had the Bedrock Knowledge Base documentation and S3 Vectors documentation open in parallel to learn more and make decisions about parsing strategy, chunking, vector dimensions and configuration options. The knowledge base, data source, and vector store all need to be in the same region, which makes sense from performance and traffic costs perspective.

I chose the Amazon Bedrock default parser as my parsing strategy. This parser claims to work well with various file formats including markdown, HTML, PDF, and Office documents. The main advantage is that it doesn't incur additional charges, making it perfect for projects where you want to keep costs low. Since my content was primarily text-based markdown files, the default parser seems more than sufficient for this use case.

For the vector configuration, I used a 1024-dimension index aligned with the Amazon Titan Text Embeddings V2 model. I also went with the default chunking strategy, which splits content into approximately 300-token chunks while preserving sentence boundaries. I want to play around with this another time and see if it would make sense and bring an improvement raising the chunk size. The embedding model can handle up to 8192 tokens.

The data flow is now: From the S3 source bucket through the AWS Bedrock parser, processed by the embedding model, stored in the vector storage. Testing the result and interacting with the synced data is easy using the Chat with your document feature in the Amazon Bedrock console. So, to see first results, you don't have to build out your Chatbot interface yet.

Several things became clear during my test setup. The overall process is simpler as expected, with the wizard handling resource creation and permissions. Since S3 Vectors is in preview, it's not yet available in infrastructure-as-code tools like the AWS Terraform provider. I didn't check if it's available in CloudFormation though. I would love to manage the knowledge base and related resources through IaC next time instead of the click-ops through the console.

The cost aspect, which was my primary motivation, exceeded expectations. With S3 Vectors, we're talking about the cost of a cup of coffee when testing or building a proof of concept. This opens up possibilities for builders who want to experiment with ideas without upfront investment.

One challenge I encountered was with permissions. The Knowledge Base wizard is strict and defaults to claiming ownership of the entire bucket, at least from an IAM role perspective. The managed roles don't cover individual subfolders / prefixes someone might create when uploading data. Manual IAM adjustments work but can cause issues when editing the knowledge base later. There's likely a better way to configure this properly from the start. I have to figure out if the answer is really one source S3 bucket per knowledge base or if there's a better way to leverage prefixes without the clunky IAM role and policy handling.

I'm also curious about further reducing costs for the S3 data source, which could grow over time. S3 Intelligent-Tiering might help reduce ongoing storage costs. The knowledge base index can be recreated from the source data in the S3 bucket, though that will cause costs for using the embedding model again.

Embedding tokens are another cost factor, though not a major one. My test with approximately 5MB of Rancher documentation in markdown format resulted in about 1 million tokens, translating to roughly $0.02 USD with Amazon Titan Text Embeddings V2, which doesn't seem like much. Using batch processing outside of Bedrock could potentially cut costs in half, but batch processing doesn't work in the context of Bedrock Knowledge Base. The knowledge base is convenient to use, but if you build your own stack instead, then batching can become a cost saver, especially at a higher scale beyond simple testing.

I ran into an issue with metadata handling. Using S3 Vectors as vector storage with Bedrock Knowledge Base requires adding the Bedrock-related metadata keys as non-filterable, otherwise the sync fails. By default, all metadata keys in S3 Vectors are considered filterable, but Bedrock's metadata exceeds the 2KB limit for filterable metadata. I found the solution in the S3 Vectors documentation and this AWS re:Post discussion: create the vector index with AMAZON_BEDROCK_TEXT and AMAZON_BEDROCK_METADATA as non-filterable metadata keys.

Additional (slight) costs occur when interacting with the knowledge base, for the input and output tokens of the leveraged LLM through AWS Bedrock. For example, something between $0.05 and $0.10 USD per 1 Million Tokens when using one of the Amazon Nova Models. Based on the S3 Vectors pricing for eu-central-1, storage costs $0.064 per GB per month, PUT requests cost $0.214 per GB, and query requests are $0.0027 per 1,000 requests. For small datasets like my 5MB test, these costs remain minimal.

With my tests I achieved what I wanted. Vector storage was previously the component with higher monthly costs in Bedrock Knowledge Base, but S3 Vectors makes this purely pay-per-use. Now we're talking about costs comparable to a cup of coffee for testing and building MVPs, just perfect for experimentation and idea validation. Even though I didn't run the numbers, I wouldn't be surprised if this is even up to a specific scale extremely interesting and cost efficient.

DNS management with OpenTofu and some AI assistance

2025-07-27T00:00:00+02:00

Today I migrated dozens of DNS records from manual to OpenTofu based management. My DNS provider allows downloading zone files in BIND format, but other information like record IDs needed for OpenTofu imports are buried in the HTML of their web interface.

Manual migration would have been time-consuming and error-prone. Perfect opportunity to test AI assistance. I'm not expecting magic, but to handle the repetitive parsing while I focus on validation and logic.

I used Google's Gemini Code Assistant for this experiment. Over the past months I've worked with Amazon Q Developer, GitHub Copilot, Cursor, and Roo Code with various models.

The key was, and in my experience always is, to provide specific context instead of vague requests. I had already built the OpenTofu modules and project structure to manage Domains and DNS records months ago. So, I knew exactly what I needed and how things should work. This allowed me to give precise guidance to the assistant without relying on it to figure out implementation details.

I provided the AI with full context: existing record files, OpenTofu module structure, and clear objectives. I essentially train the coding assistant on the patterns and conventions of my existing codebase. This doesn't mean hours of actual training, just a few well-crafted prompts.

For tasks like this (processing large amounts of data that humans can barely read, finding patterns, applying logic, and transforming data into different formats) LLMs are naturally a good fit.

For converting a BIND zone file, my instruction was:

Here is the BIND zone file for mycloudoffice.de. I need you to create
a records_mycloudoffice_de.tf file. Please follow the syntax and naming
conventions you see in my existing records_wombacher_cc.tf file, and be
sure to ignore irrelevant records like SOA and RRSIG or CAA that are handled
in a different place and are not in scope now.

Of course, I then pasted the complete BIND zone file content after this instruction as well. By providing both raw data and a clear example of desired output, the model understood the pattern, identified relevant records, and produced properly formatted OpenTofu code. The "Magic" here is that popular LLMs of course know what DNS records are and how BIND Zone files are structured. So, they don't need handholding to understand and parse them.

The next step was generating import commands. To get these resources into my OpenTofu state without destroying and recreating them, I needed tofu import commands for each record. The unique IDs are somewhere in the HTML code from my DNS provider's web interface.

My prompt was:

Now, I need you to generate the tofu import commands for the resources
you just created. Here is the raw HTML containing the record IDs. The
command format is "tofu import <resource_address> <domain>:<record_id>".

Again, I included the full HTML source after this instruction. A while later, I had a complete list of shell commands ready to execute. A task that would have involved manually matching dozens of records to their IDs was done in seconds without errors.

But this wasn't about blindly accepting AI responses. When we encountered a URL record type specific to my DNS provider, the AI's first attempt was based on its general knowledge of resource options. Since none of my shared examples contained details for this specific URL type, it made a reasonable but non-functional guess.

I researched the provider's documentation and fed that back to the model to get the right syntax. Even then, tofu plan revealed subtle drift that required my analysis and guidance to resolve. But two short iterations later, we had a working solution.

This collaboration - where AI handles repetitive tasks while I provide direction and validation - is practical and effective. It's not about replacing developers but freeing us from repetitive work so we can focus on architecture and problem-solving.

As models improve, we stay in the driver's seat, making decisions and reviewing results. Work quality depends on clear instructions and critical evaluation of results, not on expecting AI to solve everything automatically.

Personally, I never want to go back to do all this manually. It isn't fun to read through hundreds of lines of BIND zone files and HTML code to find the right IDs in a weirdly nested div tag.

If you are interested in the outcome, some of what Gemini came up with today made it into my OpenTofu based domain management.

AWS Certified AI Practitioner

2024-08-28T00:00:00+02:00

I took and passed the brand new Amazon Web Services (AWS) Certified AI Practitioner (Archive: [1], [2]) exam this morning! Pretty cool to be one of the first people certified. I even got this nice Early Adopter Badge :D

I'm already 6 times AWS Certified (1x Practitioner, 3x Associate, 2x Pro) but also wanted to gain a better understanding of AI and ML on AWS. Preparing and taking the AI Practitioner Exam was very valuable for me. I would do it again and recommend it to others to gain a solid understanding.

It's a very new Exam, at the time I took it even in Beta state. The amount of available training content is low. I used a combination of the official Learning Path available in AWS SkillBuilder and the Course from Stephane Mareek. That worked out well thanks to previous AWS Certifications and a lot of practical knowledge as part of my current Role.

Summary: Earners of this badge understand AI, ML, and generative AI concepts, methods, and strategies in general and on AWS. They can determine the correct types of AI/ML technologies to apply to specific use cases and know how to use AI, ML, and generative AI technologies responsibly. They are familiar with the AWS Global Infrastructure, core AWS services and use cases, AWS service pricing models, and the AWS shared responsibility model for security and compliance in the AWS Cloud.

Source & Copyright: https://www.credly.com

Skills

AI and ML on AWS - Foundational
Amazon Web Services
Artificial Intelligence (AI)
AWS
AWS Certification
AWS Cloud
Cloud Certification
Foundation Models
Generative AI
Machine Learning (ML)

Source & Copyright: https://www.credly.com

Certificate

Downloads
- Certificate (ID: 6c5005136e7c420aa9eebfdb2011db7b) (PDF, 32k)
- Badge (PNG, 88K)
- Badge (Early Adopter) (PNG, 83K)
Links
- Credly Badge (Archive: [1], [2])
- Credly Badge (Early Adopter) (Archive: [1], [2])