DEV Community: Alexy Grabov

AWS who? Meet AAS

Alexy Grabov — Thu, 26 Feb 2026 16:14:32 +0000

Yes, I know that predicting the downfall of SaaS and SaaS providers is all the rage right now, and no - this is not an AWS doomsday prophecy. AWS still holds about 30% of the cloud market (although Microsoft is really closing the gap with 20% market share) and remains, at least in my personal opinion, a market leader in terms of stability, features and innovation. AWS is not the best at everything, but is the best at most things, and that how it holds a third of the market (and half of Amazon's profits).

Do you remember when AWS was pushing serverless compute? Seems so long ago, a time when we were all still spinning VMs on our vCenters. They were offering S3, when companies were still piling on VNX storage racks. I know, I was there, at EMC², when it was happening.

In the Beginning There Was Cloud

That kind of forward thinking approach put AWS in the lead, and allowed it to maintain it's lead over the years. A few years ago- cloud is all anyone talks about. SaaS companies rise. Server racks are a thing of the past. Everybody is developing a cloud-native something. Consuming and managing resources made simple, accessible, cheap.

Unfortunately for AWS, this business model was disrupted recently. AI came barging into everyone's life - and is threatening AWS' dominance. I predicted the SaaSpocalipse almost a year ago, without even realizing. I wrote how we would shift from consuming software to consuming the underlying service this software provides - using agents.

AAS

Being the innovative company that it is, AWS also noticed the same paradigm shift I have. AWS is telling us what it's focusing on, as a company. All we have to do is listen (and be a little bit observant).

So, lets look at the facts.

AWS has been expanding its Bedrock AgentCore offering, packing it with features and trying to make it into a one-stop-shop for all of your agentic needs. Want to create an agent? easy. Need to safeguard it? they've got you there as well. Need some tools for your agent? no problem - a full MCP suite is available for you.

On top of providing a toolbox for agent builders and administrators, AWS has some agents of its own. Perhaps you've heard about the DevOps Agent and Security Agent. They are Agent-as-a-service type of offerings (or - service-as-a-service, if you will). Instead of building an agent, AWS provides a working one for you, tailored to perform a specific task. Enterprise customers are moving away from leasing static infrastructure or basic software tools, and are instead leasing automated digital labor. Who needs WIZ when you have a security auditing agent which is, according to a customer quoted by AWS "reducing the typical testing duration by more than 90%"?

Another honorable mention are the agent plugins, "an open source repository of curated plugins that bring packaged AWS expertise directly into AI coding assistants" said Laith Al-Saadoon, Principal AI Engineer at AWS.
The pattern is clear. AWS wants to be your one-stop-shop for any and all agentic needs, just like it has become a one-stop-shop for anything cloud related. Thus, I propose a new conceptual name for the provider - AAS: Amazon Agentic Services.

Agentic Tides

The AI tsunami did not spare AWS. Even though they are still actively developing "legacy" cloud native services , the shift in focus is evident. Even new features, like Lambda Durable Functions, is clearly a direct response to the rise of specialized durable execution engines such as Temporal, Azure Durable Functions, Cadence, and Cloudflare Workflows. These competing platforms have explicitly targeted the orchestration of agentic workflows.
AWS wants to be a Swiss army knife when in comes to building anything agent \ LLM related. Any model, any complimentary service, on demand.

We can assume that AWS will continue expanding its AI-related portfolio, with even more ready to go agentic services and more tools for builders, striving to become an AI platform, by spending 200 billion dollars on AI infrastructure. To accurately conceptualize this scale, Amazon will be spending approximately $548 million every single day, or $21 million every hour procuring, powering, and deploying artificial intelligence infrastructure for AWS data centers globally.

Unlike Wall Street, AWS leadership views this monumental investment not as a speculative risk, but as an absolute, existential necessity.

How to Train Your ̶D̶r̶a̶g̶o̶n̶ ̶ Model

Alexy Grabov — Mon, 05 May 2025 10:12:27 +0000

In one of my previous posts, we’ve discussed how we can utilize the AWS Bedrock suite of services to provision and run Agents that are 100% serverless.

We were able to achieve it because AWS was kind enough to host some of the most popular models for us, granting access on a pay-per-usage model. This might work for rapid prototyping or PoCs, but using this payment model in production will have 3 major disadvantages.

First, you will hit quota limit pretty fast. Since this model is shared, AWS limits the number of requests you can do in a given time slot. For example, Cross-Region InvokeModel tokens per minute for Anthropic Claude 3.5 Sonnet V2 is limited to 800,000. That might sound like a lot, but note that this limit is for a whole minute, for all requests (i.e. is shared by all sessions you might open to that model in a region). I’ve even hit this limit during my PoC!

Second, is pricing. The pricier models, like the various versions of Claude Sonnet models, can run up quite a bill. You are charged per 1,000 input/output tokens (batching is a bit cheaper) and per caching. I’ve tried conversing with my Claude 3.5 Sonnet V2 based agent, and as the context grew I reached $0.1 per interaction (question\answer).

Third, is speed. This is not true for all models, but it is for the large, multi-purpose ones. They can take a good 30 seconds to think, reason and generate responses sometimes. That’s understandable, as those models are very large and are shared. For real, production, loads that’s probably not acceptable.

Now, we understand that not everyone can just host ChatGPT 4.5 on their laptop, and paying AWS to host a dedicated huge LLM just for you is not going to be cheap. The solution? Creating your own models.

It might sound like something that only AI engineers can do, but using AWS Model Distillation in the Bedrock suite — this process can be quick, cheap and very easy.

In this blog we’ll learn how to distill, host, and query your very own LLM using AWS Bedrock & Provisioned Throughput.

AWS Model Distillation

Model distillation is a machine learning technique where knowledge from a large, complex model (teacher) is transferred to a smaller, simpler model (student). The student model learns by mimicking the outputs or internal representations of the teacher, aiming to achieve similar performance with reduced computational resources. This approach enables deployment of efficient models suitable for resource-constrained environments without significantly sacrificing accuracy — for a very specific use case.

Quick side note here — I personally think this is what this whole “AI” frenzy will eventually come down to — small, fast, specialized models that run everywhere, and can collaborate with other models if they need to do something outside of their expertise.

Luckily for us, AWS Bedrock offers a very easy, fully managed process that allows you to train your own models to suit your specific business flow. The resulting model will (hopefully) mimic the larger, slower, expensive model that trained it, for the specific task it was trained on. This is also the place to note that the trainer and trainee models must be of the same model family. You can’t use AWS’ Nova Pro to train AI21 Labs’ Jamba 1.5 Mini, for example.

For the purposes of this blog, we will use Nova Pro to train a Nova Micro, because I already used Claude 3.5 for my AI real-estate agents and have some conversation history I can use (which we are going to use to train Nova Micro).

The training dataset needs to be in a very specific JSONL format, which can take some time to prepare. I used another model, Gemini 2.5 Pro, ironically, to structure the prompts from my chat history in a format that Bedrock Model Distillation can read.

Other Training Methods

A quick side note here about Fine-tuning and Continued Pre-training, which are two additional training methods that AWS Bedrock offers. Fine-tuning is somewhat similar to Distillation, but focuses on a specific task. You have something that the model does, and you want to make it better at doing exactly that. Model distillation is about focus — strip the dead weight from a bigger, more capable model, and only keep what you need from it, instead of training the larger model to be better at doing something very specific.

Continued pre-training is a broader training option, used when you need a model to become familiar with your industry, company and professional jargon. This method is most relevant when embedding an Agent into your company and you want the base model (say, GPT-4.1) to “know” what your employees are talking about when they use industry or company specific lingo.

Creating a Distilled Model

Distilling a model using the AWS Bedrock console is very easy. Going to the “Custom Models” tab reveals all the available jobs that you can run to customize models. We are going to select “Model Distillation”.

Then, we will select the teacher mode, the student model, and our dataset to be used for training. As mentioned before, the teacher and student models must be of the same model family, i.e. you must use models from the same vendor.

The distillation job can run for quite a while, depending on your dataset, but at the end of it you should have a distilled model in your Models tab.

Congratulations! It’s a model!

Running Your Model

Now, this is a bit of a “gotcha”. To run a model, you need to purchase Provisioned Throughput. That means that AWS will provision some resources, 100% dedicated for your model — and it may cost you a very pretty penny.

I had issues purchasing Provisioned Throughput myself, and even reached out through internal channels for AWS Builders and got some help from a Principal AI Architect on the Bedrock team (thanks guys!). Because purchasing Provisioned Throughput can cost you literally hundreds of thousands of dollars per month for some of the larger models — it’s not the go-to solution for most individuals — even most companies.

A smaller Nova Micro did not break my bank, but pricing quotes are not to be taken lightly here. Only those with consistently steady, predictable, production-grade throughput should opt in for purchasing reserved throughput over Inference.

However, we are experimenting here, and we need to check out the result of our distillation job, so… let’s do it!

Comparing Model Results

Once we have purchased Provisioned Throughput, you can run your custom model.

We will use the “Chat” option, and compare the AWS-hosted Nova Pro model vs. our distilled Nova Micro-based model.

As we can see, our custom Nova Micro model was twice as fast and provided more accurate information. Our distilled model took 1527ms, while Nova Pro took 2623ms. Also, it used ILS as the main currency (but still converted to USD, for some reason) because the prices in its training data were in ILS. The only thing I’m not sure about is the fact that Nova Micro said its information is updated for the year 2023, when my listing information was very recent. Post in the comments if you know why that happened.

I am not going to use this model for my real-estate agents, for now. Provisioned Throughput is still very expensive to just leave running and forget about it. However, I hear that AWS is working on a new version, internally dubbed as “Provisioned Throughput 2” which will be available in Q3 of 2025. I don’t know exactly what’s going to be different there, but it will “make Provisioned Throughput a viable option for more of our customers”.

I’ll be sure to check that out once it’s available.

Closing Thoughts

In this short technical blog, we have created a custom, one-of-a-kind, language model. It’s still very pricy to run 24/7, but if you have a production-grade, predictably and long running GenAI backed workload — this can really save you a pretty penny, while offering a lot more throughput.

P.S.
Did I mention this whole project was done using only the web browser?

Who Needs Software for Development Anyway?

Alexy Grabov — Fri, 17 Jan 2025 11:40:49 +0000

We already know that we don't need servers to run software, right? We're all about serverless and IaC here. But what about the software and supporting applications that we need to actually ship that software out of the door?

With the rise of AI driven, online generation code and AWS pushing it's browser-based Console experience to new levels - such as improving the UI and incorporating a VSCode-like experience directly into the Lambda Code tab - has there ever been a better time to move to developing 100% using just your browser?

Perhaps. But, what AWS has giveth it can also taketh, and it has. Some development-friendly tools, like the Cloud9, CodeCommit and CodeStar being axed by AWS without notice can indicate that this might not be a priority for them. Yes, they are sort-of being integrated into CodeCatalyst, which is more managed and should be easier to use, but to me it feels more focused on DevOps (or, maybe, Platform Engineering) teams and not for individual developers. AWS even states it's an "Integrated DevOps Service".

We will explore two of the available options, the native CodeCatalyst and it's popular rival GitHub, discuss their pros and cons so that you can choose the option (or combination of multiple options) that works best for you.

Quick side note about AWS Proton, which I feel like people sometimes compare to CodeCatalyst. While some features do seem similar, AWS Proton is really more of an infrastructure to deploy & run your code as a service on AWS - which might be exactly what you want - and less a suite for project development.

The AWS Way

Since it feels like AWS wants to pull you away from the Code<*> service pack, let's take a look at what they offer as an alternative. AWS CodeCatalyst is a fairly new service, about 2 years of age, and it offers a complete way to mange your codebase, build and deploy your applications (or just infrastructure) on one or more AWS accounts, and in one or more environments (i.e. dev, staging and production).

We should first take note that AWS treats this as an external service. just look at the URL - "codecatalyst.aws". This is because you connect your existing resources to it, such as GitHub repositories and AWS accounts to it. It's just managing them.

So the first thing you need to do is to create a new project in CodeCatalyst. We are all about serverless here, so lets use the serverless application blueprint for the sake of this demo.

Creating a New Project

You can configure some options for your selected project, like which language you want tom develop in. For more complicated blueprints that have databases, for example, you have more robust configuration options, like schemas or even the type of provisioned database you want to use.

!

Project Customization Options

Like I said, this is an external service to AWS, and when you link an AWS account to be used as a resource - all you will see in your AWS account is some information about it being used in a CodeCatalyst "space". All of the orchestration is done from the CodeCatalyst console.

I'm not sure why that is. Maybe AWS thinks that DevOps are afraid of the Console?

The View From Your AWS Account

After your project is created, you can access your repositories, browse them, create pull requests and review them, merge, track branches and even - God forbid- clone them to your local code editor. All the usual things you might expect from a Git tracker. You can also setup remove development environments if you're into that kind of a thing. Strangely, here Cloud9 is still one of the options.

Your Git Project

Code Editor

Now, after you have got your pull request approved and merged to your Main branch, it's time to build, test and deploy!
AWS CodeCatalyst supports drag-and-drop, editable workflow steps that you can arrange to look much like the ones you are probably familiar with from the Blue Ocean view in Jenkins.

Workflows

It allows you to build, test, deploy (in stages) to your environments, test between deployments and even automate actions that are to be carried out in case of failures in any of the stages. The AWS integration here is remarkable and the level of fine-grained control offered is amazing.

Editing Workflows

For example, you can track per-commit changes to your deployments and rollback or sync specific deployment environments to other (successful) deployments. I mean, for Ops personnel - this is like learning magic spells.

Change Tracking

The GitHub Way

Now lets take a look at what your life might look like if you choose GitHub - but still would like you deploy your infrastructure on AWS. When working in GitHub you can choose any number of targets for your deployment, but for an apples-to-apples comparison, we will choose AWS (and also because I am an AWS Serverless Builder).

I would wager that the vast majority of you know how a GitHub project looks like. This familiar interface packs all of the actions that you might want from a Git provider, but without any of the AWS-specific features of CodeCatalyst, like per-role management of access or pull request approval. That might be an upside or a downside for you, depending on how much you are integrated into AWS and how comfortable you are with managing your collaborator's Roles.

My GitHub Project

The GitHub code editor (immediately accessible by changing the ".com" to ".dev" in your browser URL, in case you didn't know) is miles, leagues ahead of what AWS has to offer. It has a full, working version of vscode.dev, which is pretty much the same as github.dev those days, I hear. It will allow you to install supported extensions, do some code completion, run your tests - and even has a shell! You can't install Copilot extension for that sweet AI-assisted programming, though.

GitHub Code Editor

However, this is the best experience for a web-based IDE that I've seen, and is the closest to an actual IDE running on your machine locally.

There is also an option for remote and collaboration development environments, just like the AWS CodeCatalyst, called Codespaces.

As for the Ops side of things, GitHub has Actions and Security tabs to help with that. The Security tab includes built-in scanners. which are ready-to-use tools you can run to check your repository for potential risks. It's a great feature because it simplifies security and puts it front and center. Be honest, though - how often do you think about security when you're in the middle of developing?

GitHub Security

As for the Actions, these are runnable, YAML-based workflows that you can trigger on events. There isn't a fancy UI interface for creating or editing them, but GitHub does provide a simple text editor with syntax highlighting and some starter templates. The runtime interface is somewhat similar to what you get in CodeCatalyst.

Workflow YAML

You can build, test, and deploy with GitHub Actions as well, but here you're missing the seamless AWS integration. You'll need to manage your deployments, stages, and AWS secrets for your accounts manually (there's a "Secrets" tab for that in GitHub). You'll also have to handle any failed deployments, either by coding in the logic or addressing them manually.

GitHub Pipeline

Final Thoughts

If you are building your project on AWS, and do not have a full-fledged DevOps group, you can't go wrong with using CodeCatalyst for your deployments. The integration and the level of abstraction they achieved is something special, and other cloud providers should really take notes here.

With that being said, it just can't compare to GitHub when it comes to coding. GitHub's VSCode web offer is so much more advanced and can even accommodate small to medium sized teams, if you ask me.

Luckily, you can connect your GitHub project as a source repository to AWS CodeCatalyst and enjoy the best of both worlds. You can even use some of the built-in security scanners in GitHub and some of the pre-made Actions, while CodeCatalyst will manage your AWS account resources, environments and deployments. It's a setup that, in my opinion, is hard to beat, and it should serve you well whether you're building a small project or launching a startup on AWS.

As always, thanks and love to my beautiful wife and talented DevOps Architect Yafit Tupman, who helps me navigate the strange and scary world of modern build platforms.

AWS Resource Names Validation and Generation

Alexy Grabov — Fri, 28 Jun 2024 15:04:11 +0000

Have you ever wondered how can you validate AWS resource definitions (names, ARNs, patterns) in runtime? Well, if you have, you probably know that you can’t.

In this blogpost we’ll cover the current solutions, their limitations and introduce a new open-source package that actually can perform those validation for you automatically. It can also generate said patterns for your testing and mocking needs.

Workflows Without Validation or Generation

Let me tell you a short story and see if it sounds familiar to you.

You make changes to your CDK code, you deploy. A CloudFormation template is synthesized, which takes a good minute. Then, AWS starts creating the resources you requested. It runs for a few minutes — and fails. Your Lambda function name is too long.

This, of course, is not the only workflow that might be affected by validations that are performed too late. Imagine your code receives a string during a business flow, either as user input or from another application it interacts with. It’s supposed to represent an ARN of a resource — but it doesn’t. You code tries to “access” this resource using a boto3 client — and fails. Now, you need to debug. Is this resource really missing? was is deleted? did AWS fail to find it? did the boto3 client expect to receive it in a different format?

Let's also consider testing. Often when you need to test your logic flows, you might need to somehow get your hands on “real” AWS resource ARNs or paths. You might need them to check your internal validations and error flows, or just use them as return values to your mocks. What most developers do in those cases is just go to their development AWS environment, find the suitable resource — and copy names or parameters to their test code.

Resource Schemas and Constraints Sources

AWS is usually really good with documentation, and this case is no different. You can actually find CloudFormation schemas publicly published, but I really doubt anyone actually reads those.

A more convenient way would be to search for any constraints or validation patterns in docs.aws.amazon.com, and indeed we can have a look at this example for a Lambda Function create body:

It’s not bad, as far as documentation goes. But who has the time or patience to read it, or search for it every time it’s required?

Current Solutions

You probably know that in software engineering you’re probably not the first ever to hit a certain issue. Someone has probably already dealt with this same exact thing, there are probably already 10 threads on StackOverflow and Reddit discussing it, other engineers have suggested solutions etc. Just pick a solution you like and copy-paste.

In this case, unfortunately, I was unable to find a suitable solution to some of the problems I was facing.

First, AWS itself have recently acknowledged my pain and have baked some of the validation functionality into AWS CloudFormation.

AWS CloudFormation improves its deployment experience to validate customer stack operation upfront for invalid resource property errors.

{
  "StackId": "arn:aws:cloudformation:us-west-2:123456789012:stack/MyStack/50d6e750-5a71-11e6-afc7-50d5ca9f1234",
  "EventId": "6ba1a560-5a71-11e6-bf4a-500c28168c4b",
  "StackName": "MyStack",
  "LogicalResourceId": "MyS3Bucket",
  "ResourceType": "AWS::S3::Bucket",
  "Timestamp": "2024-03-14T19:57:18.129Z",
  "ResourceStatus": "CREATE_FAILED",
  "ResourceStatusReason": "Property validation failure: [unexpected property PropertyName1]",
  "ResourceProperties": {
    "BucketName": "my-bucket",
    "PropertyName1": "invalid-value",
    "AccessControl": "PublicRead"
  }
}

What this means is that your deployments will fail much sooner, when CDK generates the CloudFormation template, instead of during the later deployment stage, without creating any actual resources on AWS. Great news!

If you like your validation a little bit more hard-core, you might want to look at AWS CloudFormation Linter. Remember all those CloudFormation chemas nobody reads? Well, those guys have (or, at leased, parsed) and have created a linter based on them.

It can run as a standalone linter before CF tried to template your CDK code and also supports custom rules. This allows you to add custom validations for conventions that might be specific to your organization.

Very cool, but still does not solve our runtime and testing challenges.

Runtime Resource Property Validator and Generator

To solve our real-time validation and testing problems, we must have a solution that runs on-demand, and not in the linting to deployment stage.

Exactly for those purposes, I have developed the aws_resource_validator package.

It contains auto-generated classes from this botocore dataclasses repository (special shout-out to fellow AWS Community Builder Michael Kirchner who made me aware of it). Each respective class represents an AWS service. Within each service there are resources which can be accessed using CamelCase and snake_case names. Each resource has some informative fields about it’s own limitations and expected pattern. It can also validate itself — and generate a string conforming to all validations and patterns for your testing needs.

So a typical resource looks like this:

lambda
  - name (or Name)
    - .validate()
    - .generate()
    - pattern
    - min_length
    - max_length
  - arn (or Arn)
    - .validate()
    - .generate()
    - pattern
    - min_length
    - max_length

And a usage example might look like this: (note the mixed usage of camel & snake cases)

from aws_resource_validator.class_definitions import Acm, class_registry

# Use type hint so that you can use `api_registry` with full class definitions
acm: Acm = class_registry.Acm

print(acm.Arn.pattern)
print(acm.Arn.type)
print(acm.arn.validate("example-arn"))
print(acm.Arn.generate())

It’s that simple!

All you have to do is install the package from PyPI and you’re good to go:

pip install aws_resource_validator

By the way, those auto-generated classes I’ve mentioned? They are pretty cool. They are deducted from the JSON files in the botocore repository, their members are generated and then written, as Python-readable code, into a file. It’s actually Python code that writes Python code. No AI, but still makes you wonder when you’re going to be replaced, right?

Anyway, if you want to check out the logic behind this package, you can check out my GitHub repository — it’s open source. Special thanks to my beautiful wife and talented Principal DevOps engineer Yafit Tupman who added GitHub Action based pipelines and overall repository productization, so that you can be sure each release is tested and uploaded to PyPI automatically.

Feel free to open bugs, report issues or contribute code to this project if you find it useful or interesting.

A Common Use Case Example

Let’s take a quick look of a concrete usage example. We will consider a typical Lambda function code where a 3rd party service is passing items for it to process. For the purposes of the example, we will assume those items represent ARNs of IoT Job templates.

from http import HTTPStatus
from typing import Any, Dict, List

from aws_lambda_context import LambdaContext
from aws_resource_validator.class_definitions import JobTemplateArn, class_registry

def handler(event: Dict[str, Any], context: LambdaContext) -> Dict[str, Any]:
    arn_list: List[str] = event['body']  # we would parse and validate the event first, of course
    job_template_arn: JobTemplateArn = class_registry.JobTemplateArn
    if not all(job_template_arn.validate(template_arn) for template_arn in arn_list):
        return {'statusCode': HTTPStatus.BAD_REQUEST, 'headers': {'Content-Type': 'application/json'}, 'Your ARNs are invalid'
    # some boto3 calls here
    return {'statusCode': HTTPStatus.OK, 'headers': {'Content-Type': 'application/json'}, None

As you can see, not only did we not perform any boto3 calls (where we would have discovered the error) — we can also report back to the calling service to inform it of an issue in it’s code.

Now, let’s look at a usage example inside a test. We will test the same handler code.

from typing import Any, Dict, List

from aws_resource_validator.class_definitions import JobTemplateArn, class_registry

def test_handler():
    job_template_arn: JobTemplateArn = class_registry.JobTemplateArn
    arns_list: List[str] = [job_template_arn.generate() for _ in enumerate(10)]
    event = {'body': arns_list}
    assert(handler(event, None))

With just 2 lines of code we have generated a list of 10 valid ARNs that represent IoT job templates to be used in our test. No mocks necessary!

Recap

We have discussed validators for AWS resources naming conventions and why they are important. We have also mentioned the different times when said validators can be run — at code runtime, during the linting stage or during CloudFormation template generation.

We also briefly mentioned the usability of generated resource names during testing and how the aws_resource_validator package can help you with that as well.

Thanks for reading and I hope you learned something new :)