DEV Community: Jens Båvenmark

New pricing model for CloudFront

Jens Båvenmark — Tue, 18 Nov 2025 21:58:37 +0000

AWS just released a new pricing model for CloudFront. Now you can pay a fixed price.

As most of you know, calculating the cost in AWS can be hard, especially on resources where traffic is the cost driver (like CloudFront). So this change will make it a lot easier.

So how will this work then?

There will be different plans with varying costs that include CloudFront and other services in the pricing. You will select the plan you want when deploying your CloudFront Distribution.

For current distributions, you can “migrate” them to the plan of your choice by selecting to switch to a plan for your distribution in the console (right now, the console is the only place to set plans). If the current deployment configuration matches what the plan provides, you will be able to use that plan.

Included Services

The different plans include these services, but not all plans include all services. Some services are for the higher plans (see the image below for details about each plan).

CloudFront CDN
WAF and DDoS protection
DNS (Route 53)
TLS Certificate (ACM)
CloudWatch Log Ingestion (Storage costs for log still apply)
Serverless Edge Compute (CloudFront Functions, not Lambda@Edge)
Bot Management (Business plan and above)

You will also get S3 credits that can be used across all your accounts S3 costs.

And data transfer to CloudFront is automatically waived.

The Different Plans

There are four different plans, as well as the old pay-as-you-go pricing.

As you see in this image, you can easily see what each plan includes. All higher plans include the services of the lower plans.

Free Plan

This is, in my opinion, the best part of these pricing plans. The Free plan will make it possible for people learning AWS or running small workloads to use CloudFront without having to worry about getting a large bill at the end of the month.

And what you get in the free tier is not a bad setup for many small companies and PoC sites. The included WAF will make it easy to secure you distributions and you can add up to 5 different rules.

Additionally, 5 GB of S3 storage is available for free per CloudFront Distribution. But before you start planning on removing your S3 bill by deploying 100 Free distributions, you should know that every account will be limited to three Free Plan distributions.

Pro Plan

For $15/month, this plan will likely be the most popular choice for companies with medium traffic, as it supports 10 million requests / 50 TB per month, and includes WAF protection for your WordPress, PHP, and SQL databases, as well as logging support.

Business Plan

Jumping up in cost with $200/month, the Business Plan will not be for everyone, but will be a must for more heavily trafficked sites (125M requests / 50 TB per month). It also comes with Bot management, more advanced DDoS protection, and the first plan to support Private Origins in your VPC (a great security feature where you do not need to have your ALB in public subnets and have public IPs).

Premium Plan

For your sites with extremely high traffic (500M requests / 50 TB per month) or where you require even greater security (like regex-based WAF filtering), the Premium Plan can be yours for only $1000/month.

With it, you will have features such as automatic origin failover, mTLS for end-users, and high-speed private origin routing.

Pay-as-you-go Pricing

If you don't want to choose a plan, you can continue to use Pay-as-you-go pricing. Current distributions will continue on this “plan” if not “migrated” to one of the other plans.

So, when would you want to use this “plan”? If your distribution has a really heavy load so that the Premium Plan is not enough (over 500M requests or 50 TB per month), or when you need a special setting on the services that is not included in the other plans, like Lambda@Edge.

But if you don't need that, you should select a plan that matches your traffic.

But what about when?

So changes are scary, and for many technicians, there will be many questions, especially when deciding on migrating current distributions to a plan. So I will answer the questions I can here.

What happens if I exceed the usage allowance?

If your usage exceeds the limit of your plan, your distribution will continue to work and receive traffic just as before. But you may experience reduced performance. You will not be charged anything more than your set monthly cost.

Can I change plans whenever?

You can deploy a new distribution or “migrate” an existing distribution and select a plan at any time, and the cost of that plan will be applied to the current billing cycle.

If you want to change plan (downgrade or upgrade), the change will take effect in the next billing cycle.

If you cancel a plan, it will take effect at the beginning of the next billing cycle, where the distribution will revert to pay-as-you-go pricing.

Can I have as many plans as I want?

From the start, you will be able to have three free plans and 100 paid plans per account.

I believe the limit for paid plans can be increased after several customers have requested it, but for now, this is the limit.

Can I monitor if I am exceeding my plan's limit?

Yes, there will be CloudWatch metrics for this, and AWS will also send you an email if you are approaching your plan's limit.

Can I use this with Amplify?

No, not right now, Amplify has its own pricing model.

Can I move a Plan to another distribution?

No. A plan is connected to a distribution and can not be moved to another distribution.

Final Thoughts

This is a significant improvement from AWS, making CloudFront costs easier to predict.

Of course, there are some “features” I would have liked to have, like the possibility to manage this with IaC, a solution for handling Blue/Green deployments without having to have two different plans, and the possibility to switch to a pay-as-you-go model whenever you want from a set plan. But I believe these will be implemented when feedback comes back to AWS after the release, and they see what limitations the customers are facing.

All information in this blog post was the information available at the time of release on the 17th of November 2025. If something changes, I will try to update this blog post, but as always, check the AWS documentation for the latest information.

AWS Capabilities by Region

Jens Båvenmark — Thu, 06 Nov 2025 22:47:38 +0000

AWS just released a new service in Builder Center, AWS Capabilities by Region.

I believe this will be a service that many might miss, but for those who know it exists, it will be integral when deciding where to place workloads when planning for migrations, disaster recovery regions, and expansions.

So what does the service do? It lets you compare what services and features exist in different regions. And this will make planning much easier and help avoid unnecessary work in regions that won't support your workload.

For example, it is not uncommon when implementing a disaster recovery (DR) region that you, in the middle of setting it up, run into issues where a service/feature available in the main region doesn't exist in the DR region, and you need to pivot to another region.

And by using this service in the planning stage, we can avoid issues like that.

Service and features

The main feature of the service is the Service and features, where you can compare different regions and see what services and features they offer.

To use it, you select what regions you want to check and either select all services or specific ones.

You will see a comparison of the availability of the service and its features between the regions.

One other great feature is that you will also be able to see when a service/feature is planned to be deployed to the region.

When I have used it, I have added all the services I am using, then selected the region I am currently in, and then selected the regions I am planning to migrate to. I quickly get an overview of which services and features will and will not work.

API Operations

Another feature of the service is to see what API operations are available in each region and compare the regions.

CloudFormation resources

You can also view and compare available CloudFormation resources in the regions.

Final Thoughts

This is a great new service that I will use a lot when planning where to place workloads. It will make it easy to get an overview of where the resources you need are available.

Create AWS Diagrams with Kiro

Jens Båvenmark — Mon, 28 Jul 2025 06:33:55 +0000

A short while ago, I wrote a blog post about Creating AWS Diagrams with Python and Amazon Q Developer in the CLI. After posting that blog, I got a question about whether I had tried to do the same with Kiro (Kiro is an AI‑powered IDE from AWS) with AWS MCP for diagrams ( https://awslabs.github.io/mcp/servers/aws-diagram-mcp-server).

I had not, but when I heard about the MCP for Diagrams (which I will refer to as the MCP moving forward), I had to test it and decided to write this blog with the results. The MCP is, as the name states, using the same Python library, Diagrams, as we used in the previous blog to create the diagrams.

Set up the environment

First of all, I want to make it clear that I am a beginner with Kiro, and this was my first “project” with the IDE. So there might be better ways to set this up, but this is how I did it.

We will need to install Kiro. Go to https://kiro.dev/ and follow the instructions to download and install it for your OS.

At the time of writing this blog there is a waitlist to be able to download Kiro.

We then need to install the dependencies of Diagrams, which are Graphviz and Python (I will assume you have Python installed, otherwise, there are many guides on how to install it).

brew install graphviz # For Mac

If you are not using a Mac, follow the Graphviz instructions on how to install it.

We are then ready to configure Kiro to use the MCP and begin building diagrams.

Getting the MCP configuration

Before we can configure Kiro, we will need the MCPs configuration. For the AWS Diagram MCP Server, it can be found here.

The configuration we are looking for is:

{
  "mcpServers": {
    "awslabs.aws-diagram-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-diagram-mcp-server"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}

Configuring Kiro

To use the MCP, we will need to configure Kiro to use it. You can configure MCP on a User level or on a Workspace level. We will configure it on a Workspace level in this blog.

Open Kiro and select the Project we are going to use. For me, it was the Terraform module that I wanted to create the diagram for.

Click on the Kiro logo in the left menubar.

You will then gain access to additional Kiro configuration. At the bottom of that list, you will see MCP Servers. Select to edit this.

In the JSON document that opens, select Workspace Config.

Update it with the config we got from the MCP.

After you have saved it, you will see that it appears in the MCP Servers list.

If you click on one of the tools, for example, generate_diagram, a prompt will be automatically added to the session to ask Kiro to test the MCP tool: Help me test the MCP tool generate_diagram from the awslabs.aws-diagram-mcp-server server. Now Kiro will test the tool and “learn” from it:

> I'll help you test the generate_diagram tool from the awslabs.aws-diagram-mcp-server server.
> Let me start by getting some example code to understand the syntax, then generate a test diagram.
...
> Called MCP tool
...
> get_diagram_examples
> Now let me test the tool by generating a simple AWS architecture diagram:
...
> Called MCP tool
...
> generate_diagram
> Great! Now let me test with a more complex diagram using custom styling:
...

This is technically not needed. I tested adding the MCP without testing the tools, and it worked just as well. It might have taken some more time, though.

You are now ready to use the MCP to create diagrams with Kiro.

Building the Diagram

I give Kiro the simple prompt: Can you now create me an AWS Diagram from the Terraform Module we are currently in.

It then starts to create the diagram. It didn’t run into the same issues we had when not using the MCP with import errors, so the diagram were made a lot quicker. The only problem was that it was not in the workspace.

When I asked Kiro where it was, it informed me that it was in the /tmp/ folder. And when I informed Kiro I wanted it in the current folder, it copied it there, but ran into some issue and got stuck. This happened multiple times when copying files, so it's probably something that will get fixed in a future version.

But the diagram was created and looked good. Not perfect, but a great start and probably good enough for most.

The Diagram

Here is the finished diagram.

The Code

Here is the code Kiro generated with the help of the MCP. As you will see, the code is not runnable by itself in its current form. It is missing imports, and according to Kiro, this is by design. The guide from the MCP instructs it to ignore imports and focus solely on the code. But if we want to get functional code from it, we only need to ask Kiro to fix this, so it’s not a big thing.

with Diagram("Terraform S3 Backend - Service Architecture", show=False, direction="TB"):
    # Entry Point
    terraform_cli = General("Terraform CLI")

    with Cluster("AWS Services"):
        # Primary Services
        with Cluster("Storage Services"):
            s3 = S3("Amazon S3")
            s3_bucket = S3("Backend Bucket")

        with Cluster("Database Services"):
            dynamodb = Dynamodb("Amazon DynamoDB")
            lock_table = DynamodbTable("terraform_state")

    with Cluster("Resource Configuration"):
        # S3 Features
        with Cluster("S3 Configuration"):
            versioning = S3("Versioning: Enabled")

        # DynamoDB Features
        with Cluster("DynamoDB Configuration"):
            hash_key = DynamodbAttribute("LockID (String)")
            capacity = Dynamodb("Lock")

    # Service Relationships
    terraform_cli >> Edge(label="stores state", color="green", style="bold") >> s3
    (
        terraform_cli
        >> Edge(label="manages locks", color="orange", style="bold")
        >> dynamodb
    )

    # Service to Resource Mapping
    s3 >> Edge(label="contains", color="green") >> s3_bucket
    dynamodb >> Edge(label="contains", color="orange") >> lock_table

    # Configuration Relationships
    (s3_bucket >> Edge(label="configured with", color="blue") >> [versioning])
    lock_table >> Edge(label="configured with", color="blue") >> [hash_key, capacity]

Using the MCP with Amazon Q Developer

When reading the instructions for setting up the MCP I saw that we can use it with Amazon Q Developer as well. So I configured Q to use the MCP as well and asked it to create the same diagram. And it was just as easy as with Kiro.

Configure Q to use the MCP

To configure Q to use MCP we need to update a configuration file with the MCP configuration. Add the same MCP configuration as we added to Kiro to ~/.aws/amazonq/mcp.json for a User configuration or to . amazonq/mcp.json in your workspace folder for Workspace configuration.

To test that the configuration works, we can check the loaded MCP in q and should see awslabs.aws-diagram-mcp-server.

> qchat mcp listbash
> workspace:
  /Users/USERNAME/WORKSPACE/.amazonq/mcp.json
    (empty)

🌍 global:
  /Users/USERNAME/.aws/amazonq/mcp.json
    • awslabs.aws-diagram-mcp-server uvx

Then we can ask Q to create the diagram just as we did before. And it did without any issues.

The Diagram

Here is the Diagram from Q Developer using the MCP.

Final Thoughts

Using the MCP with either Kiro or Amazon Q works really well and makes it easier to create the diagrams.

I tested both with more advanced Terraform modules, and it works just as well, almost better in fact. It can become a little weird sometimes, but I would suggest asking the AI to create multiple diagrams at different detail levels for you to choose from.

Some of the issues I ran into with Kiro, such as the diagrams in the wrong folder, the code not created in the workspace, or not runnable manually, can all be handled with better prompting, my prompting was really basic.

So if you are looking into building Diagrams with Code and using AI, I would suggest configuring it to use the AWS MCP for diagrams.

But as always, when using AI to build something, don’t forget to learn the code it uses so you can modify it and address any issues with it.

Create AWS Diagrams with Python and Q in the CLI

Jens Båvenmark — Thu, 24 Jul 2025 18:36:21 +0000

You can utilize Amazon Q Developer in the CLI to create your AWS Diagram from your Terraform code.

This is how I made my first Diagrams with Code with the help of Amazon Q.

Just a quick note: This is not a “AI can create everything for me and I don’t need to know anything” blog. I used AI to help me create some diagrams and it was so convenient that I wanted to share the process.

The problem

The last part I always have to do after creating a Terraform module for AWS is to spend some time in draw.io to create a diagram of the AWS resources and their connections within the module for the documentation. Later, when I have to make a change to the module, I need to find the source document for the diagram to be able to update it. And this is not a good way to keep the documentation in the code.

I have read about Diagram as Code, but never looked into it. But during a drive to update the documentation of all my Terraform modules, I decided to look into it to see if it could help me not just quicken up the work but also make it more available and easier to update.

Since I often use Python, I decided to look into Diagrams ( https://diagrams.mingrammer.com) and was impressed by how easily the code was to understand. Started writing diagrams for my Terraform modules, and it worked well.

But as always, I wondered if I could speed it up some more with help from AI.

So I went to my “trusty” Sidekick ChatGPT to ask it to create the code for me (to be honest, it is not as trusty anymore). I explained the module and the resources in it, and it created the code for me. And when I ran the code, it failed with an import error (every Node (resource) you want to use in your diagram needs to be imported). Went back to ChatGPT with the error and got new code. And it failed again. After doing this back and forth a couple of times, my patience was spent.

But then I remembered that I had started testing Amazon Q Developer in my CLI and wondered if it would be a better option. And that is what this blog post is about.

Setting up the environment

First, let's install the programs and set up the environment. My guides will be for Mac.

Amazon Developer Q

You will need an AWS Builder ID (or IAM Identity Center user) to use Amazon Developer Q. The Builder ID is free. To create one, follow AWS instructions.

Follow AWS instructions to install Amazon Q Developer and give it access to the CLI.

Environment and Diagrams

Create a folder for your code and diagrams.

mkdir terraform_diagrams
cd terraform_diagrams

I suggest setting up a virtual environment with venv before installing dependencies.

python3 -m venv virtual_env
source virtual_env/bin/activate

Then we will install Diagrams and its dependencies. Diagrams require Graphviz to render the diagrams.

brew install graphviz

Then we will install Diagrams.

pip install diagrams

Now we are ready to create some diagrams. I would suggest reading the official documentation for Diagrams so you are avare on how it works since it will help with your understanding of the code.

Amazon Q Developer creates diagrams

This time, I started Q on the CLI and asked it to review a Terraform module and create the code for the diagram for me.

My prompt was: Can you check this Terraform module ${Path To Module} and create the code for me to create a AWS Diagram with Python diagrams package.

Q then started reading the files in the module and the README.md file to understand what the module was used for and how it worked.

Then it checked if Diagrams was installed and stated it would install it otherwise (not sure if it would try to install it, but I wouldn't suggest allowing AI to install packages on your computer). Since it was installed, it continued creating the code and running it to create the diagrams.

You will get prompted for allowing Q to do actions and I would suggest not allowing all actions being run without reviewing them. It will take some more time but give you more control.

And Q got the same import errors as ChatGPT got (importing the SNS node). But here is where I really got impressed with Q. It tried to fix the issues with the imports twice and failed both times. It then decided to check the Diagrams package for the available modules for AWS.

> Let's check the available modules in the diagrams package
> find virtual_env/lib/python3.12/site-packages/diagrams/aws -name "*.py" | grep -v "__" | sort

It then checked through all the modules and their classes, looking for the SNS nodes class, and found it in the integration module.

> Let's check the available classes in the engagement module
> grep -A 50 "class" virtual_env/lib/python3.12/site-packages/diagrams/aws/engagement.py
....
> Let's check the integration module for SNS
> grep -A 50 "class" virtual_env/lib/python3.12/site-packages/diagrams/aws/integration.py
....
> Great! Now I can see that SNS is in the integration module. Let's update our script

It then updated the code and tried to run it again. Now getting new errors as other imports were wrong. It then went through the modules again and found the correct node classes and updated the code until it worked.

It then ran the final code and created a diagram for my Terraform module, which creates an S3 bucket and DynamoDB to use as a Terraform backend.

Was the diagram perfect? No. But was it a great start. And if you then ask Q to fix the issues you have with the diagram, or you do it yourself, you can get it to the point where you want to add it to your documentation.

The diagram

Here is the diagram that Q created for me.

The code

Here is the code that Q created for this Diagram. Note that it imports classes that are not used. So not perfect but good enough.

from diagrams import Diagram, Cluster, Edge
from diagrams.aws.storage import S3
from diagrams.aws.database import DynamodbTable
from diagrams.aws.management import Config
from diagrams.aws.devtools import Codebuild
from diagrams.aws.compute import Lambda
from diagrams.onprem.client import User

# Create the diagram
with Diagram("AWS S3 Backend for Terraform State", show=True, direction="TB"):

    # Terraform users/clients
    with Cluster("Terraform Clients"):
        terraform_users = [\
            User("Developer 1"),\
            User("Developer 2"),\
            User("CI/CD Pipeline"),\
        ]

    # Terraform state management
    with Cluster("Terraform State Management"):
        terraform = Config("Terraform")

    # S3 Backend components
    with Cluster("S3 Backend Infrastructure"):
        # S3 bucket with versioning
        s3_bucket = S3("State Bucket\nwith Versioning")

        # DynamoDB for state locking
        dynamodb = DynamodbTable("DynamoDB\nState Lock Table")

    # Connect components
    for user in terraform_users:
        user >> Edge(label="terraform apply") >> terraform

    terraform >> Edge(label="read/write state") >> s3_bucket
    terraform >> Edge(label="acquire/release lock") >> dynamodb

Final thoughts

I was quite amazed that Q looked through the actual package for the classes we needed and found them. It worked much better than I predicted, and I didn't have to do the regular AI back-and-forth dance.

But don't just let the Q create the diagrams for you, learn the code as well, so you can polish the code for the diagram after Q creates the initial version.

Final note when using Amazon Q in the CLI. Remember to commit your changes between runs, as it can overwrite the files it’s working on, and you may lose some working code for broken code if you are not careful. But you can use Amazon Q to commit the files for you.

LinkedIn for New Technicians

Jens Båvenmark — Mon, 21 Jul 2025 11:01:37 +0000

Create the best profile you can to set yourself up for success.

In my last blog post, “ Growing your Professional Persona”, for New-ish to Newbies: Navigating DevOps Together, I discussed the importance of LinkedIn. However, I felt that there was more to say about LinkedIn, so I have decided to focus this post on your LinkedIn profile and how it can help you as a new IT technician. The post is focused on helping new technicians, but many of the tips can also help more experienced technicians.

I have spoken with several IT recruiters, and many more responded to a questionnaire I sent to gather the information I wrote about in this post. This information comes directly from the individuals who will review your profile and decide whether to proceed with you for their available positions. All the recruiters work with technicians in Sweden, but some also recruit for companies outside the country.

We will look at these different parts of the profile and what to think about:

Headline
About
Experience
Projects
Skills
Recommendations

I will outline the key points that recruiters emphasized in each section, as well as common mistakes to avoid.

I will then provide a summary of the key points.

On some of the questions, the recruiter had very divided standings, and I will be sure to add that when writing their answers.

Headline Section

Key points recruiters find attractive in LinkedIn Headlines

Mention your area of expertise or specialization (e.g., “Java Developer,” “Azure Architect,” or “Senior DevOps Engineer”).
Avoid overly generic or broad titles (e.g., refrain from using “IT Engineer” or “Consultant” without providing context).
Use job titles that directly match or closely align with the roles you want to be found for. Recruiters often search using specific skills or job titles.
Indicate seniority when applicable (e.g., “Senior DevOps Engineer,” “Chief Cloud Architect”).
It’s beneficial if you reflect genuine enthusiasm or career goals in your headline (e.g., “Aspiring DevOps Professional” or “DevOps Specialist with Love for Automation”).

Common mistakes to avoid

Avoid overstating or exaggerating your seniority or expertise. Don’t claim advanced titles like “Cloud Architect” if your experience doesn’t match.
Headlines that include too many certifications or details appear cluttered. Keep it succinct and easy to read.
Don’t use overly broad or vague titles (“Consultant” without clear context can confuse recruiters).
Ensure your title accurately represents your role and responsibilities.
Avoid explicitly mentioning “Junior” in the title. Instead, position internships or entry-level roles in a professional and appealing way.

Asking recruiters to rate different headlines

I gave the recruiters four different headlines I had seen on LinkedIn and asked them to rate them from 1 to 5.

“CloudOps Engineer | AWS Certified (5x) | Terraform Certified | Focus on Secure Automation” — 4.25

“CloudOps Engineer @ Company” — 3.88

“CloudOps Engineer” — 3.25

“Creating the future for digital work” — 1.38

Summary

A concise and clear headline is most attractive.

Ensure your job title is clear and specific, matching the position you are seeking. Specify your area of expertise, but do not exaggerate your seniority or expertise level.

About Section

Compelling Details & Themes Recruiters Look For

Clearly state your current role, primary responsibilities, and technical expertise.
Clearly state what motivates you professionally and your career aspirations.
Share your passion or enthusiasm for specific technologies or areas within the tech industry.
Briefly describe your significant accomplishments and how you personally contributed to them.
Recruiters highly value soft skills — qualities such as teamwork, problem-solving, communication, and adaptability.
Include personal touches to stand out, but keep them relevant and meaningful (avoid clichés like “coffee lover”).

Recommended Length & Detail Level

Keep it direct, clear, and easy to read.
Approximately 3–5 lines or a short, focused paragraph is ideal.
Avoid “fluff” — every detail included should add genuine value or insight.
Provide enough detail to distinguish yourself from peers, especially for new technicians with limited experience.

Common Pitfalls & Clichés to Avoid

Avoid overly polished AI-written bios; recruiters can easily identify inauthentic content.
Utilize AI tools for support, but ensure the content accurately reflects your genuine personality and professional identity.
Write in the first person to maintain authenticity and engagement.
Avoid extensive personal hobbies or childhood anecdotes that don’t directly relate to your professional skills.
Steer clear of clichés such as “building computers since childhood” or vague statements like “I want to join a company to develop my skills.”
Avoid begging language; emphasize what value you bring rather than what you seek.
Don’t leave the “About” section empty or overly vague; it’s a key opportunity to highlight your distinct professional profile.

Summary

Where the headline makes the recruiter click on your profile, the About section will make them start to know you.

Keep it clear and easy to read. Do not write a book and avoid fluff.

Clearly state your current role, expertise, and what motivates you. Do not forget about your soft skills.

Only the first three lines are shown unless you expand the section. So make sure the most important is there.

Experience Section

Duration & Job Stability

How long you’ve worked at each job to assess stability and progression.
Identifying a clear career progression or “red thread.”

Job Titles & Keywords

A quick scan of your job titles to see immediate alignment with roles they’re recruiting for.
Relevant technical keywords and specific technologies used (e.g., AWS, Azure, Terraform, programming languages).
Some recruiters interpret skill order as an indicator of proficiency, so list your most relevant skills prominently.

Responsibilities are generally preferred overall, but accomplishments are valuable as well

Recruiters strongly prefer to see a clear summary of your role’s primary responsibilities outlined.
Responsibilities provide immediate insight into what you have done regularly and can quickly show alignment with a new role.
Specific projects or achievements demonstrate the tangible value you’ve provided in your roles.
Ideal descriptions blend both but emphasize your daily responsibilities clearly.

Balanced Approach

The best practice is to combine responsibilities (primary) and accomplishments/projects (secondary but significant) to convey comprehensive professional value clearly.

Commonly Overlooked Details & Pitfalls:

Avoid overly vague descriptions (e.g., “I worked as a Java developer” alone isn’t sufficient).
Not clearly stating specific tasks, tools, and technologies used.
Essential skills and accomplishments should appear at the beginning of the description. Recruiters often skim-read quickly and may miss details placed later in the text.
Avoid descriptions that merely state what the company does. Recruiters want to know what you did specifically, how you did it, and why it matters professionally.
Ensure descriptions directly relate to the job roles you want to attract, as irrelevant experiences dilute the profile’s focus.

Summary

Be specific when describing your responsibilities and the tasks you performed in the position and the technologies you worked with.

While it can be hard as a Junior Technician to have a clear career progression in IT, try to focus on the skills in the jobs where you have worked that closely align with the requirements for the career you are looking for. An earlier job might not have required the technical skills needed, but many of the soft skills or management skills you developed can be “translated” to a new career.

Projects Section

The importance of projects was split among the recruiters. Some saw them as important, while others didn't see the importance of them, especially if they were not directly relevant to the role they were looking for.

Importance of Personal/Open-source Projects:

Average importance rating: 5 out of 10 (mixed opinions)
High importance: Some recruiters value these projects highly (ratings: 7, 8, 9) as indicators of initiative, skill, and passion.
Low importance: Others view them as less impactful (ratings: 1, 3) unless directly relevant to the role.

Most Relevant Project Details Recruiters Look For

Purpose/Problem: Clearly describe what problem the project aims to solve.
Role/Responsibility: Specifically outline your individual contributions and responsibilities.
Tech Stack: Clearly state the technologies/tools used and justify their choice.
Results/Impact: Summarize what was achieved or the current status of the project.
Relevance: Explain how the project aligns with your career goals or targeted roles.

Recruiters prefer clarity and specificity in these details to better assess your capabilities and independence in handling tasks relevant to potential roles.

It’s beneficial to include links to GitHub, websites, or demos if they clearly showcase relevant, updated, and high-quality work.
Avoid linking if your profiles or projects are outdated, incomplete, or do not positively enhance your overall professional image.

Summary

While some recruiters do not see the Projects as that important, some do. And when you specify your project, be sure to clearly explain what the project does and how you solved it. Include links. Think about the fact that many recruiters are not technicians themselves, so the explanations need to be clear for non-technicians.

Skills Section

Importance of Listing Skills

Average importance rating: 8.6 out of 10

Most recruiters strongly emphasize the importance of explicitly listing skills due to:

Enhanced visibility through searchability (keywords).
Immediate clarity of your primary technical competencies.

Recruiter Perception of Skill Endorsements

Moderate Impact:

Skill endorsements have some influence but are not decisive.

Positive Impact:

Endorsements by relevant colleagues or credible sources strengthen perceived credibility.
High endorsements in key skills can make candidates more attractive initially.

Limited Impact:

Recruiters generally don’t rely heavily on endorsements, especially if the profile clearly outlines skills elsewhere.
Generic endorsements or those from non-technical contacts have minimal value.

Summary

Listing your skills is important, especially for recruiters searching for specific skills. It also clarifies the technical competencies you possess.

Endorsement of skill can have some influence, but it also needs to come from colleagues or credible sources.

Recommendations Section

The importance of recommendations was also a point of contention, with recruiters divided on the issue.

Do Recruiters Read Recommendations?

Most recruiters rarely or occasionally glance at recommendations, but they’re generally not decisive.
Some recruiters read them, but often after already making an initial decision on whether to contact the candidate or not.

Impact of Recommendations:

Average impact rating: 5.5 out of 10 (varied significantly from very low to very high importance)
Some recruiters rate them highly impactful (8–10), while others see minimal influence (2–6).

Should Technicians Actively Seek Recommendations?

Yes, but selectively.

Recommendations from well-respected individuals or those known in the tech community lend credibility.

Prioritize obtaining recommendations from:

Technical colleagues or peers with direct experience of your skills.
Managers who can describe both technical and soft skills, though technical endorsements typically carry more weight.
Recent, relevant recommendations (avoid outdated ones).

What Makes a Recommendation Credible and Impactful?

Specific and skill-focused: Clearly describes the candidate’s technical skills, strengths, and the value they brought to projects.
Positive yet authentic: Uniformly positive recommendations make candidates appealing, but they must feel genuine and specific rather than generic praise.
Tech-focused descriptions: Recommendations emphasizing direct technical contributions or problem-solving abilities are most impactful.

Summary

Recommendations can be impactful with the correct recruiter, but will probably not prompt them to reach out to you if your profile to this point has not piqued their interest. However, if it has, it can help you get the whole way.

Ensure your recommendations are recent and from individuals with relevant experience in your field.

Final Thoughts

I hope this will help some of you on your IT journey. It became a lot more text then I had anticipated but after compilling all the answers from the questionnaire (with help from AI) I didnt want to edit to much away as the recruiter had a lot to say about the different sections.

Two important notes that the recruiters made that I want to share as the final points are:

Ensure your LinkedIn profile aligns with your CV, and make it personal. The LinkedIn profile is about you.

AWS Alert Validation - Lambda

Jens Båvenmark — Mon, 19 May 2025 08:02:58 +0000

We are continuing the blog series about testing your AWS alarms. The first part of the series, which looked at CloudWatch actions and EC2 alarms, can be found here.

An untested alarm is not one you can trust.

This time we will look at alarms for your Lambda functions. As before, we will test the alarms by ”breaking” the Lambda so you get the same outcome as when a real issue would occur.

Since this is Lambda, we will add code (or entire Lambdas) to make the Lambda act as we want. I will use Python, but the logic works for all the other supported languages.

I have an examples repo where you can find Terraform code to deploy Lambas and required resources to AWS to test the alarms. You will need to connect your alarms to the Lambda functions, though.

Remember to lower the thresholds on your alarms so they trigger more easily. If they trigger for one value, they will trigger for your real value as well.

Lambda alarms

The alarms we are going to look at are:

Error Alarm
Throttling Alarm
Timeout Alarm
High Duration Alarm
Out of Memory Alarm
Log Alarm
Failed Lambda message to DLQ Alarm
Dead Letter Failure Alarm

Error Alarm

The Error alarm is the most common Lambda alarm. To test it we just need to crash the Lambda or exit it in a TODO state.

We will manage this by running a Lambda that is monitored with this code snippet, making it crash:

def lambda_handler(event, context):
    raise Exception("Triggered error alarm for testing purposes.")

An example Lambda can be found here.

To trigger the alarm, invoke the Lambda with this CLI command.

aws lambda invoke --function-name {FunctionName} outfile

Throttling Alarm

To test throttling, we need to deploy a Lambda with a reserved concurrency limit set to one, so only one Lambda can be run at a time.

I would suggest having the Lambda run a sleep or similar to keep it running so you can trigger multiple runs easily.

Example Lambda and Terraform can be found here.

To trigger the alarm, we will need to invoke the Lambda at least two time by running this command simultaneously in multiple terminals.

aws lambda invoke --function-name {FunctionName} outfile

Timeout Alarm

If you are monitoring for Lambda timeouts (timeout creates log entries that can be checked for with a metric filter) we can test that alarm with just adding a sleep in a Lambda that is longer than the configured timeout.

import time

def lambda_handler(event, context):
    time.sleep(25)

Example Lambda and Terraform can be found here.

To trigger the alarm, invoke the Lambda with this CLI command.

aws lambda invoke --function-name {FunctionName} outfile

High Duration Alarm

To test for Lambda that takes a long time to finish (high duration), we will use the same setup as for Timeout Alarms, but we will set the Lambda timeout to longer than the sleep set in the Lambda.

Make sure to set your alarm threshold lower than the time set to sleep in the Lambda function.

import time

def lambda_handler(event, context):
    time.sleep(15)

Example Lambda and Terraform can be found here.

To trigger the alarm, invoke the Lambda with this CLI command.

aws lambda invoke --function-name {FunctionName} outfile

Out Of Memory Alarm

If you are monitoring for Out Of Memory (OOM) events on your Lambdas (when your Lambdas are using more memory than they are assigned, they will crash and log: Error Type: Runtime.OutOfMemory), we will run a Lambda that will use more memory than it has been assigned.

def lambda_handler(event, context):
    mem_size_mb = 128

    # Allocate memory slightly over the limit
    bytes_to_allocate = (mem_size_mb + 10) * 1024 * 1024  # exceed by 10 MB
    memory_hog = "X" * bytes_to_allocate
    return len(memory_hog)

Example Lambda and Terraform can be found here.

To trigger the alarm, invoke the Lambda with this CLI command.

aws lambda invoke --function-name {FunctionName} outfile

Log Alarm

To test log alarms from Lambdas, we just need to run a Lambda that logs what your metric filter is checking for.

So if for example, you have a metric filter for the string “This is a test log line” run this code.

import os
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info("This is a test log line")

    return {"statusCode": 200, "body": "Test completed successfully."}

Example Lambda and Terraform can be found here.

To trigger the alarm, invoke the Lambda with this CLI command.

aws lambda invoke --function-name {FunctionName} outfile

Failed Lambda async message to DLQ alarm

If you send the event triggering the Lambda to an SQS Dead Letter Queue (DLQ) if the Lambda fails, and monitor whether the DLQ gets messages, we can test it the same way we did with testing error alarms.

def lambda_handler(event, context):
    raise Exception("Triggered error alarm for testing purposes.")

Example Lambda and Terraform can be found here.

To trigger the alarm, invoke the Lambda with this CLI command (DLQ only works for asynchronous invocations).

aws lambda invoke --function-name {FunctionName}--invocation-type Event output.json

The DLQ can take a little time to report the message, so do not stress if you don't see the message there straight away.

Dead Letter Errors Alarm

If you are monitoring for failure to send messages to the DLQ (DeadLetterError) in case of async event failures with your Lambda, we can test it almost the same way as with the DLQ alarm above.

The difference will be that we will remove the IAM permission for the Lambda to publish the message to the DLQ. This will trigger any monitoring set on the metric DeadLetterErrors.

Example Lambda and Terraform can be found here.

After deploying the Lambda with the DLQ, you will need to remove the permissions for the Lambda to post to the DLQ. Terraform will block the setup of the Lambda with DLQ configured if it doesn't have access to post to it.

Final Thoughts

Testing that your alarms work as you expect can save you a lot of headaches in the future.

I hope that these tests will make your Lambda monitoring more secure.

This was the second part in this series. In the first part, we looked at tests for EC2 alarms and CloudWatch actions. In the upcoming part we will look at alarms for other resources.

AWS Alert Validation - EC2

Jens Båvenmark — Thu, 08 May 2025 11:23:31 +0000

For monitoring, the golden rule (at least in my opinion) is that an untested alarm is not one you can trust.

An untested alarm is not one you can trust

In this blog series, I will describe different ways you can test your monitoring, both metric and service monitoring, to be sure that it works as you want.

So, what will that entail? Well, you will need to break stuff—at least enough so that your alarms will trigger.

Testing monitoring can be time-consuming especially if you want to test real alarms. Usually, you don’t want to get notified for every spike on an EC2, but more if it persists over a set time. And checking if scheduled tasks work will require you to wait for the schedule to run.

Before we start going through different tests, I suggest you run these tests in a non-production account, and that all monitoring (and its dependencies) is deployed with IaC. That way, you can be sure that the monitoring you have tested in your Dev account will work in your production account as well.

In this first part of this blog series, we will examine testing EC2 alarms and ensuring that your CloudWatch alarm actions are triggered correctly.

Testing CloudWatch Actions

One common thing many want to test is whether they will receive a notification when their CloudWatch alarm is triggered, whether it triggers their Lambda as expected, and whether CloudWatch can trigger the action they have specified.

We usually want to test this without triggering the real alarm, as that can be time-consuming. We can easily do this with the AWS CLI.

With the CLI, we will change the state of the CloudWatch alarm to Alarm.

aws cloudwatch set-alarm-state --alarm-name "AlarmName" --state-reason "Testing alarm" --state-value ALARM

This will trigger the action you specified on your alarm when in state ALARM.

You will also get to test the action you set for the OK state. When your CloudWatch alarm checks the required metric against the threshold within the specified period for the alarm, it returns an OK state (since the metric should be at an OK level compared to the threshold) and triggers the action.

If you don’t want to wait for the period to pass, you can also send the same CLI command again, but with the OK status.

aws cloudwatch set-alarm-state --alarm-name "AlarmName" --state-reason "Testing alarm" --state-value OK

If you want to test for actions for missing data (insufficient data), then set the state to INSUFFICIENT_DATA.

aws cloudwatch set-alarm-state --alarm-name "AlarmName" --state-reason "Testing alarm" --state-value INSUFFICIENT_DATA

Testing EC2 larms

We will look at how you can test the most common alarms for EC2 by triggering them by increasing the metric monitored by utilizing special applications or commands to mimic usage on the EC2 instance (we will test on Linux instances)

The application we will use is called stress-ng.

Installing stress-ng

To install stress-ng, run this command.

Amazon Linux/RHEL/CentOS/Fedora/Rocky

sudo dnf install stress-ng

Ubuntu/Debian

sudo apt install stress-ng

You don't need to do anything more than install the application. We will look into the commands when testing the different alarms.

Before starting testing the alarms, I suggest you modify the thresholds on your alarms to make them easier to trigger. If they trigger on a higher or lower threshold, they will trigger on the correct threshold as well.

All stress-ng commands are “run forever,” so remember to cancel them with CTRL+c when your alarm triggers.

CPU

To test CPU alarms, we will mimic CPU load with the stress-ng application. In these examples, we will trigger a CPU usage alarm by running all cores on the EC2 to a set percentage.

sudo stress-ng --cpu {Number of cpus} --cpu-load {Load in percentage per cpu}

All tests are run on a burstable EC2 instance with two cores.

CPU Usage

To test CPU usage, I have lowered the alarm's threshold to 50%, so I will run the test at 75%.

sudo stress-ng --cpu 2 --cpu-load 75

CPU Load

To test CPU Load, we will run the test with more CPU threads than the instance has.

sudo stress-ng --cpu 4--cpu-load 100

CPU Credits

If you have a burstable instance and want to test the CPU Credits alarm, we run the test on the CPU with a high load. Remember to raise the alarm's threshold to limit the time you will need to wait until it triggers.

sudo stress-ng --cpu 2 --cpu-load 100

Memory

To test memory alarms, we will mimic Memory usage with the stress-ng application. In this example, we will trigger memory usage with the vm flag and set the available memory usage to a set percentage.

sudo stress-ng --vm {Number of workers to use memory} --vm-bytes {Bytes or percent of available memory} --vm-keep

Using more memory than the instance has will result in OOM (Out Of Memory).

Memory Usage

To test Memory Usage, we will run two workers using 80% of the available memory.

sudo stress-ng --vm 2 --vm-bytes 80% --vm-keep

Swap Usage

To test Swap Usage, we will run one worker using 150% of total memory to get swap to be used quickly. The command will retrieve the total memory and multiply it by 1.5. Remember that this can cause OOM issues.

  sudo stress-ng --vm 1 --vm-bytes $(awk '/MemTotal/ {print int($2 * 1.5) "k"}' /proc/meminfo) --vm-keep

Disk

To test disk alarms, we will create disk usage with fallocate or dd to create a dummy file of a specific size.

sudo fallocate -l {Size of file} {Path to file}

If fallocate doesn't work on your Linux distribution, you can use dd instead.

sudo dd if=/dev/zero of={Path to file} bs={Size of block} count={number of count}

Disk Usage

To test disk usage, we will create a dummy file of a specific size on the disk you are monitoring, raising the disk usage above the threshold you have set for your alarm.

sudo fallocate -l 2G /var/filldisk.img

If fallocate doesn't work, use dd instead.

sudo dd if=/dev/zero of={Path to file} bs={Size of block} count={number of count}

Final Thoughts

Testing that your alarms work as you expect can save you a lot of headaches in the future. The tests we have done here are not unique to AWS since all are done with Linux tools.

This was the first post in this series, and in the upcoming posts, we will look at testing alarms for other AWS resources.