DEV Community: Jérôme GUYON

Build your own AWS CLI service (yes, really)

Jérôme GUYON — Tue, 23 Jun 2026 19:10:12 +0000

I keep building internal tools and small utilities for my teams, and every single time, I face the same frustrating questions: if I ship a custom tool, I'm asking people to use something new, with a new set of credentials, and to read documentation they'll inevitably ignore.

That's a lot of possible friction for tools that are supposed to reduce friction 🙃.

Here's the thing that changed my approach: every developer or ops engineer I'm working with already spends their day in the AWS CLI.

They already have working credentials configured, they are fluent in --profile for switching between accounts, --query for JMESPath filtering, ...

What I could plug my internal APIs directly into the tool they already use every day?

Turns out botocore, the library underneath both the AWS CLI and boto3, is entirely model-driven : Every single AWS service is defined as a JSON file that describes its operations, request and response shapes, and botocore generates the client class at runtime.

And you can provide your own JSON model 💪 !

I built a working example to demonstrate the pattern from end to end that wraps the public API (the AWS Community directory of Heroes and Community Builders) into what looks and feels like a native AWS CLI service.

The underlying technique applies to any REST API you want to expose.

aws aws-community list-community-members --program HERO --category "Serverless Hero" --output table

SigV4 authentication, standard CLI flags, table/JSON/YAML output, JMESPath queries, profile switching. All of this works with zero client code written on my side.

The pattern in four pieces. The architecture looks like this:

AWS CLI / boto3  →  API Gateway (IAM auth)  →  Lambda  →  your backend

API Gateway with AWS_IAM authorization handles authentication for you. Every incoming request must carry a valid SigV4 signature, which means your team authenticates with the same IAM credentials they already use for every other AWS operation.
A Lambda function (or any API Gateway integration) receives the request body and does the actual work. In my demo it calls an external API, but yours could query DynamoDB, read from RDS, hit an internal microservice, or compute something on the fly.
A service model (service-2.json) describes your operations, their inputs, their outputs, and the data types involved. This is how botocore knows what CLI commands to expose, what parameters each command accepts, and how to serialize the request over the wire.
An endpoints file (endpoints.json) tells botocore which hostname to send requests to for each region. Without this file, users would have to pass --endpoint-url manually on every invocation.

Let me show you how to build one.

Once you understand the structure, adapting it to your own API is mostly a matter of replacing the Lambda logic and renaming operations in the service model.

Step 1: Deploy the infrastructure. Pick whichever region you prefer. The project uses a single CloudFormation template with an inline Lambda for the demo.

aws cloudformation deploy \
  --template-file cloudformation/template.yaml \
  --stack-name AWSCommunityService \
  --capabilities CAPABILITY_IAM

Step 2: Retrieve the full API Gateway endpoint from the stack outputs.

API_ENDPOINT=$(aws cloudformation describe-stacks \
  --stack-name AWSCommunityService \
  --query 'Stacks[0].Outputs[?OutputKey==`Endpoint`].OutputValue' \
  --output text)  

echo $API_ENDPOINT
# https://a1b2c3d4e5.execute-api.eu-west-1.amazonaws.com/Prod

Step 3: Inject the hostname into your endpoints file so botocore knows where to route requests.

# Extract just the hostname from the full URL  
API_HOST=$(echo $API_ENDPOINT | sed 's|https://||' | cut -d'/' -f1)  

sed -i.bak "s/REPLACE_WITH_ENDPOINT/$API_HOST/" models/endpoints.json && rm models/endpoints.json.bak

Step 4: Set the AWS_DATA_PATH environment variable to tell botocore where your model files live.

export AWS_DATA_PATH=./models/

Step 5: Try it out.

$ aws aws-community list-programs
{
    "Programs": [
        {
            "ProgramName": "COMMUNITY_BUILDER",
            "Categories": ["AI Engineering", "Cloud Operations", "Data", ...]
        },
        {
            "ProgramName": "HERO",
            "Categories": ["AI Hero", "Community Hero", "Container Hero", ...]
        }
    ]
}

$ aws aws-community list-community-members \
    --program HERO --max-results 5 \
    --output table \
    --query 'CommunityMembers[].{Name:Name,Category:Category,Country:Country}'

------------------------------------------------------------
|                   ListCommunityMembers                   |
+------------------+----------+----------------------------+
|     Category     | Country  |           Name             |
+------------------+----------+----------------------------+
|  Serverless Hero |  CA      |  Darryl Ruggles            |
|  AI Hero         |  AR      |  Ricardo Ceci              |
|  AI Hero         |  AR      |  Matias Kreder [AWS Hero]  |
|  AI Hero         |  IT      |  Damiano Giorgi            |
|  Serverless Hero |  SE      |  Gunnar Grosch             |
+------------------+----------+----------------------------+

Et voilà! The --output table formatting, the --query JMESPath expression, the --next-token pagination mechanism, they all work exactly as they would with any official AWS service.

It works in Python too. The same model file that powers the CLI also gives you a fully functional boto3 client:

import boto3  

acs = boto3.client("aws-community")  

response = acs.list_community_members(Program="HERO", MaxResults=10)  
for member in response["CommunityMembers"]:  
    print(f"{member['Name']} - {member['Category']}")

You get input validation against the model, the Stubber for mocking in tests, and pagination support through NextToken.

How to write the service model. This is the heart of the pattern. The service-2.json file contains everything botocore needs to generate your client. Here's a minimal example showing a single operation:

{
  "metadata": {
    "protocol": "rest-json",
    "signingName": "execute-api",
    "endpointPrefix": "my-service"
  },
  "operations": {
    "GetThing": {
      "http": { "method": "POST", "requestUri": "/Prod/GetThing" },
      "input": { "shape": "GetThingRequest" },
      "output": { "shape": "GetThingResponse" }
    }
  },
  "shapes": {
    "GetThingRequest": {
      "type": "structure",
      "required": ["ThingId"],
      "members": {
        "ThingId": { "shape": "String" }
      }
    },
    "GetThingResponse": {
      "type": "structure",
      "members": {
        "Name": { "shape": "String" },
        "Status": { "shape": "String" }
      }
    },
    "String": { "type": "string" }
  }
}

Three metadata fields require your attention. The protocol field should be "rest-json" for a typical JSON API behind API Gateway. The signingName must be "execute-api" so that SigV4 signs the request with the correct service scope for API Gateway (change this only if you're running a custom authorizer). The endpointPrefix is the name botocore uses both to look up the hostname in endpoints.json and to determine the CLI command name, so "my-service" means your users will type aws my-service get-thing.

The shapes section defines your data structures using the same primitives that every official AWS service uses: structure for objects, list for arrays, string, integer, boolean, and timestamp for scalar types. You can add min/max constraints on integers, pattern on strings, and mark fields as required. If you want to see how a complex model looks, browse any service under botocore/data/ in the botocore GitHub repository, there are literally hundreds of production examples to learn from.

How to write the endpoints file. This tells botocore which hostname corresponds to your service in each region:

{
  "version": 3,
  "partitions": [{
    "defaults": {
      "hostname": "{service}.{region}.{dnsSuffix}",
      "protocols": ["https"],
      "signatureVersions": ["v4"]
    },
    "dnsSuffix": "amazonaws.com",
    "partition": "my-partition",
    "partitionName": "My Service",
    "regionRegex": "^(us|eu|ap)\\-\\w+\\-\\d+$",
    "regions": {
      "eu-west-1": { "description": "EU (Ireland)" }
    },
    "services": {
      "my-service": {
        "endpoints": {
          "eu-west-1": {
            "hostname": "YOUR_API_ID.execute-api.eu-west-1.amazonaws.com"
          }
        }
      }
    }
  }]
}

If you deploy your API Gateway in multiple regions, add an entry for each region under the endpoints object. Each entry points to a different API Gateway deployment, giving you region-aware routing with no client-side logic.

Why AWS_DATA_PATH instead of aws configure add-model? The add-model command is tempting because it feels official, but it only copies service-2.json to ~/.aws/models/. It completely ignores endpoints.json, and botocore only reads custom endpoint definitions from directories listed in AWS_DATA_PATH. So if you use add-model alone, your users have to append --endpoint-url https://xxxxx.execute-api.eu-west-1.amazonaws.com to every command.

Things to know:

Access control through IAM. Anyone calling your service needs execute-api:Invoke permission on the API Gateway resource ARN. You manage access with the same IAM policies, roles, and permission boundaries you already use for every other AWS service in your organization.
No shell tab completion. Custom services don't register themselves with the CLI's auto-completer. Your users can run aws my-service help to discover available operations, but pressing Tab after aws my-service won't suggest anything.
The model format is technically undocumented. AWS has never published a formal specification for service-2.json. In practice, the format has remained stable for years and the hundreds of models bundled with botocore provide more than enough reference material to work from confidently.
Pagination requires an extra file. Botocore's built-in auto-paginator (the one behind --page-size and automatic result aggregation) requires a separate paginators-1.json model file. Without it, your users paginate manually by passing --next-token from one call to the next.
Onboarding a new user takes 30 seconds. Share the models/ folder (via git), have the user set one environment variable, and they're ready to go.
The full project is on GitHub.

— Jerome

I built a browser-based chat UI for Kiro CLI and it complete how I use AI agents

Jérôme GUYON — Thu, 21 May 2026 08:54:20 +0000

I've been living inside Kiro CLI for months now. The ACP integration in my JetBrains IntelliJ IDEA is fantastic for coding sessions : I get the full agentic power of Kiro right where my code lives. And the new Terminal UI with its syntax-highlighted markdown, collapsible tool outputs, and crew monitor is genuinely impressive and I love it.

But here's the thing. Not everything I do with an AI agent is coding. Sometimes I'm researching an architecture pattern. Sometimes I'm exploring a hypothesis about a system design. Sometimes I'm doing deep analysis on a technical decision and I want to see tool calls, and streaming responses in a comfortable visual layout, the kind of experience you get on claude.ai or ChatGPT. A web chat, basically. Except one that talks to Kiro's full agentic capabilities instead of a vanilla LLM.

So I built one with the AI-Driven Development Lifecycle (AI-DLC) methodology and Kiro CLI as my usual coding partner, I created Kiro UI a self-hosted, browser-based chat interface that connects to Kiro CLI via the Agent Client Protocol.

How it works. At its core, the architecture is simple: your browser (React 19 + Vite) connects via WebSocket to an Express server, which spawns and manages kiro-cli acp processes over stdio. Each browser tab gets its own independent agent process with its own context. The communication uses the ACP protocol.

What you get in the browser is a proper agentic chat experience: real-time streaming with markdown rendering and syntax highlighting, side-by-side diffs when the agent modifies files, collapsible tool call blocks with raw I/O inspection, an MCP server panel with live status indicators, permission management with auto-approve policies, slash command autocomplete, image and file attachments, a context usage meter showing how much of the context window you've consumed, ...

Let me show you how to get started.

Step 1: Clone the repository and install dependencies.

git clone https://github.com/guyon-it-consulting/kiro-ui.git
cd kiro-ui
npm install

Step 2: Make sure Kiro CLI is installed and authenticated. You need kiro-cli in your PATH.

# Verify kiro-cli is available
which kiro-cli
# Should output something like: ~/.local/bin/kiro-cli

Step 3: A single command builds the frontend and starts the server:

npm start
# Open http://localhost:3000

Et voilà! You have a full-featured chat interface to Kiro's agentic capabilities running locally in your browser.

Step 4 (optional): If you prefer a desktop app experience, Kiro UI packages as an Electron app:

npm run electron:dev              # Dev mode
npm run electron:build:mac        # macOS → DMG + ZIP (universal)

Things to know:

Self-hosted and private : Everything runs on localhost. No data leaves your machine.
Multi-tab sessions : Each tab spawns its own kiro-cli acp process. They're fully independent : different contexts, different conversations, different working directories.
Protocol-first design : Every feature is driven by ACP. The UI adapts to what the agent supports, including Kiro-specific extensions (_kiro.dev/*) for MCP servers, slash commands, and context compaction.
Configuration : Settings live in ~/.kiro-ui/ with settings.json for preferences and trust.json for persistent tool permission rules.
License : Apache 2.0. Use it, fork it, extend it.

Give it a try: https://github.com/guyon-it-consulting/kiro-ui. I'd love to hear how you use it and what features you'd want next.

— Jérôme

CloudShell - The Hidden API

Jérôme GUYON — Mon, 11 May 2026 09:25:55 +0000

Credits: Inspired by Dan V.'s cloudshell-store project that demonstrated the CloudShell API use, I built an unofficial boto3 client by injecting a custom botocore service model and you get a native boto3 experience: SigV4 signing, retries...

⚠️ Undocumented API — AWS can break it anytime. For exploration and learning only.

🔗 https://github.com/guyon-it-consulting/cloudshell-boto3

AWS CloudShell Has a Hidden API. Here's How to Use It with boto3.

AWS CloudShell is a free, browser-based shell built into the AWS Console — pre-authenticated, with the AWS CLI, Python, Docker, and ~1 GB of persistent storage per region. No setup, no EC2, no cost. It even supports VPC mode, so it can reach your private resources directly.

But here's the thing: it has no public API. No SDK, no CLI, no CloudFormation support. Console only.

Or so it seems. 😁

Discovering the API

If you open your browser's developer tools while launching CloudShell, you'll notice something interesting. The Console makes REST calls to https://cloudshell.<region>.amazonaws.com — with endpoints like /createEnvironment, /describeEnvironments, /createSession, and more. These requests are signed with standard AWS SigV4 authentication. They use the cloudshell: IAM namespace. In other words, this is a full AWS API — it's just not documented.

Dan V. demonstrated that you could call these endpoints programmatically. Building on their work, I wanted to go further: what if we could use this API with the standard boto3 interface, complete with SigV4 signing, retries, pagination, and error handling?

That's exactly what cloudshell-boto3 does.

How it works

The trick is botocore's extensibility. Every AWS service in boto3 is described by a JSON service model — the same format AWS uses internally. If you provide your own model and inject it into botocore's loader, boto3 treats it as a standard service. You get a native client with proper request signing, serialization, and error handling.

Here's how you create the client:

import boto3
import botocore.session

# Inject the custom service model
bc_session = botocore.session.get_session()
loader = bc_session.get_component('data_loader')
loader.search_paths.insert(0, './my-additional-models')

# Create the boto3 session and client
session = boto3.Session(botocore_session=bc_session)
client = session.client('cloudshell', region_name='eu-west-1')

The API surface

Once you have the client, you get access to the full CloudShell lifecycle. Let me walk you through the key operations.

List your environments

response = client.describe_environments()
print(response['Environments'])

Create an environment

For a public environment, call with no arguments. For a VPC environment, pass the network configuration:

# Public environment
response = client.create_environment()
env_id = response['EnvironmentId']

# VPC environment
response = client.create_environment(
    EnvironmentName='my-vpc-shell',
    VpcConfig={
        'VpcId': 'vpc-0123456789abcdef0',
        'SubnetIds': ['subnet-0123456789abcdef0'],
        'SecurityGroupIds': ['sg-0123456789abcdef0'],
    },
)

VPC environments require additional IAM permissions (ec2:CreateNetworkInterface, ec2:CreateTags, etc.). See the AWS docs.

Wait for it, then connect

Environments take a few seconds to start. Poll the status, then open an interactive session via SSM WebSocket:

import uuid
import time

# Wait for RUNNING
while client.get_environment_status(EnvironmentId=env_id)['Status'] != 'RUNNING':
    time.sleep(5)

# Open a session
sess = client.create_session(
    EnvironmentId=env_id,
    SessionType='TMUX',
    TabId=str(uuid.uuid4()),
    QCliDisabled=True,
)
print(sess['SessionId'])
print(sess['StreamUrl'])   # wss://ssmmessages.<region>.amazonaws.com/...

Use the StreamUrl, SessionId, and TokenValue with the session-manager-plugin to get an interactive shell:

import json, subprocess

payload = json.dumps({
    'SessionId': sess['SessionId'],
    'TokenValue': sess['TokenValue'],
    'StreamUrl': sess['StreamUrl'],
})
subprocess.run(['session-manager-plugin', payload, 'eu-west-1', 'StartSession'])

Upload and download files

The API provides S3 presigned URLs for file transfer — the same mechanism the Console uses behind the scenes:

import requests

resp = client.get_file_upload_urls(EnvironmentId=env_id)

with open('script.sh', 'rb') as f:
    requests.post(
        resp['FileUploadPresignedUrl'],
        data=resp['FileUploadPresignedFields'],
        files={'file': ('script.sh', f)},
    )

Keep it alive

CloudShell environments go to sleep after inactivity. Send heartbeats to prevent that:

import threading

def heartbeat_loop(client, env_id, interval=300):
    while True:
        client.send_heart_beat(EnvironmentId=env_id)
        time.sleep(interval)

t = threading.Thread(target=heartbeat_loop, args=(client, env_id), daemon=True)
t.start()

Lifecycle management

You also get start_environment, stop_environment, delete_environment, and delete_session — the full lifecycle, from creation to cleanup.

The complete API reference

Here's every operation available in the reverse-engineered service model:

Operation	Description
`describe_environments`	List all CloudShell environments for the current IAM principal
`create_environment`	Create a new public or VPC environment
`get_environment_status`	Get current status (`CREATING`, `RUNNING`, `SUSPENDED`, ...)
`start_environment`	Start a suspended environment
`stop_environment`	Stop a running environment
`delete_environment`	Delete an environment
`create_session`	Open an interactive SSM WebSocket session
`delete_session`	Close an active session
`send_heart_beat`	Keep an environment alive
`get_file_upload_urls`	Get S3 presigned URLs for file upload
`get_file_download_urls`	Get S3 presigned URLs for file download
`put_credentials`	Forward console credentials (console-only, not usable programmatically)

IAM permissions

CloudShell uses the cloudshell: IAM namespace. Each API operation maps to a corresponding IAM action (cloudshell:CreateEnvironment, cloudshell:DescribeEnvironments, etc.). For VPC environments, IAM also supports condition keys to restrict which VPCs, subnets, and security groups can be used:

cloudshell:VpcIds
cloudshell:SubnetIds
cloudshell:SecurityGroupIds

Limits to keep in mind

Max 2 VPC environments per IAM principal
Max 5 security groups per VPC environment
~1 GB persistent storage per environment per region
Environments sleep after inactivity (use heartbeats to prevent)
Environments can be reclaimed by AWS at any time

Getting started

Clone the repo and try it yourself:

git clone https://github.com/guyon-it-consulting/cloudshell-boto3.git
cd cloudshell-boto3
pip install -r requirements.txt
AWS_PROFILE=my-profile python simple_example.py

The repo includes a complete example that creates an environment, connects via session-manager-plugin, injects credentials, and runs a command — the full lifecycle in one script.

— Jérôme

CloudWatch RUM vs. Ad blockers : How to fix possible missing telemetry

Jérôme GUYON — Thu, 30 Apr 2026 16:56:50 +0000

A few weeks ago, I was reviewing the Amazon CloudWatch RUM dashboard for a web application I maintain. Page views were suspiciously low. After some digging, I opened the browser's DevTools on my machine and there it was: uBlock Origin was quietly blocking every request to dataplane.rum.eu-west-1.amazonaws.com. Our real user monitoring was blind to a non-negligible portion of our actual traffic.

CloudWatch RUM is one of those AWS services that doesn't get the attention it deserves. But if you care about understanding how real users experience your application — page load times, JavaScript errors, HTTP failures, Web Vitals — it's genuinely valuable. Here's what the dashboard looks like out of the box:

The problem is that ad blockers treat its data plane endpoint the same way they treat any third-party tracking domain: a request flying off to dataplane.rum.*.amazonaws.com looks exactly like telemetry that users might want to block.

The architecture fix is simple: your CloudFront distribution already serves your frontend. Add one behavior — /rum/* — that proxies to the RUM data plane. On the client side, point the aws-rum-web SDK to https://yourdomain.com/rum/ instead of the default AWS endpoint. I use AWS CDK here, but the same works with CloudFormation, Terraform, or the console.

Step 1: Create the CloudWatch RUM app monitor and its Cognito identity pool. RUM needs a Cognito identity pool with unauthenticated access to authorize browsers to send telemetry.

import * as cognito from 'aws-cdk-lib/aws-cognito';
import * as iam from 'aws-cdk-lib/aws-iam';
import * as rum from 'aws-cdk-lib/aws-rum';

// Create an identity pool for RUM (unauthenticated access)
const rumIdentityPool = new cognito.CfnIdentityPool(this, 'RumIdentityPool', {
  allowUnauthenticatedIdentities: true,
});

// Create the IAM role for unauthenticated users
const guestRole = new iam.Role(this, 'RumGuestRole', {
  assumedBy: new iam.WebIdentityPrincipal(
    'cognito-identity.amazonaws.com',
    {
      StringEquals: {
        'cognito-identity.amazonaws.com:aud': rumIdentityPool.ref,
      },
      'ForAnyValue:StringLike': {
        'cognito-identity.amazonaws.com:amr': 'unauthenticated',
      },
    },
  ),
});

// Attach the identity pool to the role
new cognito.CfnIdentityPoolRoleAttachment(this, 'RumRoleAttachment', {
  identityPoolId: rumIdentityPool.ref,
  roles: { unauthenticated: guestRole.roleArn },
});

// Create the RUM app monitor
const rumAppMonitor = new rum.CfnAppMonitor(this, 'RumAppMonitor', {
  domain: 'myapp.example.com',
  name: 'myapp-rum',
  appMonitorConfiguration: {
    allowCookies: true,
    // Allow X-Ray tracing
    enableXRay: true,
    // Track 100% of sessions
    sessionSampleRate: 1.0,
    telemetries: ['performance', 'errors', 'http'],
    identityPoolId: rumIdentityPool.ref,
  },
});

// Grant the guest role permission to send RUM events
guestRole.addToPolicy(
  new iam.PolicyStatement({
    actions: ['rum:PutRumEvents'],
    resources: [
      `arn:aws:rum:${this.region}:${this.account}:appmonitor/${rumAppMonitor.ref}`,
    ],
  }),
);

Step 2: Add the /rum/* behavior to your CloudFront distribution. This is the key part. I create an additional behavior that forwards requests matching /rum/* to the RUM data plane origin.

import * as cf from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

// Build the additional behaviors map
const additionalBehaviors: Record<string, cf.BehaviorOptions> = {};

// Proxy RUM traffic through CloudFront
additionalBehaviors['/rum/*'] = {
  origin: new origins.HttpOrigin(
    `dataplane.rum.${this.region}.amazonaws.com`
  ),
  viewerProtocolPolicy: cf.ViewerProtocolPolicy.HTTPS_ONLY,
  cachePolicy: cf.CachePolicy.CACHING_DISABLED,
  allowedMethods: cf.AllowedMethods.ALLOW_ALL,
  originRequestPolicy: cf.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
};

// Create the distribution (your existing one — just add the behavior)
const distribution = new cf.Distribution(this, 'Distribution', {
  defaultBehavior: {
    origin: origins.S3BucketOrigin.withOriginAccessControl(websiteBucket),
    viewerProtocolPolicy: cf.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors,
  domainNames: ['myapp.example.com'],
  certificate: myCertificate,
});

I choose ALL_VIEWER_EXCEPT_HOST_HEADER because the RUM data plane expects the Host header to match its own domain (dataplane.rum.eu-west-1.amazonaws.com), not yours. If you forward the original Host, the request will fail with a 403.

Step 3: Point the RUM web client to your proxied endpoint. Install the aws-rum-web package and configure the endpoint to use your domain instead of the default AWS URL.

# Install the RUM web client
npm install aws-rum-web

import { AwsRum } from 'aws-rum-web';

const rumClient = new AwsRum(
  'your-app-monitor-id',       // from the CfnAppMonitor
  '1.0.0',                     // your app version
  'eu-west-1',                 // region
  {
    sessionSampleRate: 1,
    identityPoolId: 'eu-west-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
    // This is the magic line — point to your own domain
    endpoint: 'https://myapp.example.com/rum/',
    telemetries: ['performance', 'errors', 'http'],
    allowCookies: true,
    enableXRay: true,
  },
);

Et voilà! The browser now sends RUM telemetry to https://myapp.example.com/rum/, which CloudFront proxies to the actual RUM data plane. Ad blockers see a first-party request and leave it alone.

Things to know

Ad blocker filter lists — Popular lists like EasyPrivacy and uBlock filters include patterns matching dataplane.rum.*.amazonaws.com and the RUM CDN script URL (client.rum.*.amazonaws.com). By proxying through your own domain, you bypass both. If you use the NPM installation method (recommended), the script itself is bundled in your app — only the data plane calls need proxying.
Pricing — $1 per 100,000 RUM events. A typical visit generates ~20 events. For 500K monthly visits: ~$100/month. CloudFront proxy overhead is negligible.
Session sample rate — In production, consider setting sessionSampleRate to something lower than 1 (e.g., 0.1 for 10% sampling) to control costs while still getting statistically meaningful data.
X-Ray integration — With enableXRay: true, RUM traces connect to your backend X-Ray traces, giving you end-to-end visibility from the browser click to the database query.

CloudWatch RUM is one of those "set it and forget it" services that quietly delivers real value — but only if it actually receives data. If you're already using it, proxy it through your own domain or you're likely missing a significant chunk of your user base. And if you're not using it yet, I'd strongly suggest you have a look — understanding how real users experience your app is worth the small setup effort.

— Jerome

Control Your Tesla from the Terminal with a Kiro CLI Skill

Jérôme GUYON — Thu, 16 Apr 2026 08:49:16 +0000

🔗 https://github.com/guyon-it-consulting/myteslamate-skills-and-power

Last Tuesday, I was deep into a CDK refactor — the kind where I have 14 files open and I'm scared to blink. Then a thought hit me: did I turn on Sentry mode? My car was parked at the train station. I could grab my phone, open the Tesla app, wait for it to wake the car, scroll to Security, check the toggle… or I could just not break my flow.

What if I could ask my coding assistant instead?

Turns out, I can. I built a Kiro CLI skill that lets me control my Tesla straight from the terminal. It was also the perfect excuse to learn how to create a Kiro CLI Skill 😊 — and what better way to test a new feature than with something fun? Check the battery, lock the doors, toggle Sentry mode, pull up charging stats — all without leaving my editor. The secret ingredient? An MCP server that wraps APIs that any AI assistant can call.

What is MyTeslaMate?

Before we get to the skill itself, let me introduce the engine behind it.

MyTeslaMate is the hosted version of TeslaMate, the most popular open-source data logger for Tesla vehicles. If you own a Tesla and you haven't heard of TeslaMate, stop reading and go look at it. It continuously records every drive, charge session, sleep cycle, and software update into a PostgreSQL database, and exposes rich Grafana dashboards — battery degradation, charging curves, trip history, lifetime stats, vampire drain, efficiency trends, and more.

MyTeslaMate takes all of that and hosts it for you. No Docker, no self-hosting, no database maintenance. It adds premium features like supercharger cost import, automations, fleet management, and — this is the part we care about — an MCP server.

The MCP server at https://mcp.myteslamate.com/mcp wraps two APIs into a single endpoint:

API	Tools	What it does
Tesla Fleet API	98	Vehicle commands, energy control, charging, navigation, security
TeslaMate API	9	Drive stats, charging analytics, efficiency data, trip history

That's 100+ tools accessible from any MCP-compatible AI assistant. Authentication is handled via OAuth SSO with Tesla's authorization server.

What is a Kiro CLI Skill?

A skill is how you teach Kiro CLI about a specific domain. It's a markdown file with YAML frontmatter that describes what the skill does and when to activate it. Think of it as a cheat sheet that Kiro loads on demand — it doesn't bloat your context until you actually need it.

A skill has two parts:

The frontmatter — metadata that tells Kiro when to load the skill:

---
name: tesla-commands
description: Control your Tesla vehicle and energy products via MyTeslaMate MCP server.
  Use when the user asks about their car, vehicle status, lock/unlock, climate control, charging, Powerwall, solar production, energy optimization, Sentry mode, trip planning, drive statistics, or any Tesla-related query. Triggers on "tesla", "my car", "vehicle",
  "charge", "battery", "climate", "powerwall", "solar", "sentry", "lock", "unlock",
  "supercharger", "road trip", "energy", "charging history", "drive stats".
---

The body — capabilities, workflow instructions, and safety rules that guide the agent:

# Tesla Commands

The `tesla-mcp` server exposes **100+ tools**.

## Capabilities
### Vehicle Control (64 commands)
- Doors & Access: lock, unlock, open/close trunk, open frunk
- Climate: start/stop HVAC, set temps, seat heaters, steering wheel heater
- Charging: start/stop charge, set charge limit, schedule charging
...

## Workflow
1. Use @tesla-mcp tools directly for all Tesla operations.
2. Check current state before making changes.
3. Wake the vehicle before sending action commands if the car is asleep.

## Safety
- Confirm with the user before executing security-sensitive commands.
- Always show current state before making changes.

The skill lives in ~/.kiro/skills/tesla-commands/SKILL.md. But a skill alone isn't enough — you also need an agent that knows how to use it.

The Tesla agent configuration

I created a dedicated agent: a JSON file that ties everything together: the skill, the MCP server and the tools.

{
  "name": "tesla",
  "description": "Tesla vehicle and energy control agent via MyTeslaMate MCP server",
  "prompt": "You help the user monitor and control their Tesla vehicle and energy products. Use the tesla-mcp tools for all operations. Present data in a human-readable format. Confirm before executing security-sensitive commands.",
  "tools": ["read", "shell", "grep", "glob", "@tesla-mcp"],
  "allowedTools": ["read", "@tesla-mcp"],
  "resources": [
    "skill://.kiro/skills/tesla-commands/SKILL.md"
  ],
  "mcpServers": {
    "tesla-mcp": {
      "url": "https://mcp.myteslamate.com/mcp"
    }
  },
  "welcomeMessage": "Tesla control ready. What would you like to do with your car?"
}

A few things worth noting here:

resources uses the skill:// URI scheme. This tells Kiro to load the skill's metadata at startup but defer loading the full content until it's actually needed. No wasted context. (See Agent Configuration Reference in the Kiro docs: "skill:// — Skills progressively loaded on demand".)
mcpServers points to the remote MyTeslaMate MCP server in this case, no local mcp server needed.
allowedTools auto-approves read and all @tesla-mcp tools so you don't get prompted for every single API call.

How to set it up

Prerequisites: You'll need a Tesla vehicle (obviously) and a MyTeslaMate account. Sign up, link your Tesla account, and pick a subscription plan. This gives you access to the MCP server and the TeslaMate analytics dashboards.

Step 1: Clone the repo and copy the files.

git clone https://github.com/guyon-it-consulting/myteslamate-skills-and-power.git
cd myteslamate-skills-and-power

# Copy the skill
cp -r kiro/skills/tesla-commands ~/.kiro/skills/

# Copy the agent
cp kiro/agents/tesla.json ~/.kiro/agents/

Step 2: Start a new Kiro CLI session and switch to Tesla Agent

$ kiro-cli

/agent swap tesla

✔ Switched to agent: tesla
Tesla control ready. What would you like to do with your car?

Step 3: Authenticate with Tesla.

Run /mcp. The tesla-mcp server will show ⚠ auth-required. Follow the instructions to copy the OAuth URL, open it in your browser, and sign in with your Tesla account. This is a one-time step — the token persists across sessions.

Using it

Now the fun part. Just talk naturally:

> Is Sentry mode on?

Nope — Sentry Mode is currently off on your Model Y. 
It is available though, so I can turn it on for you if you'd like.
Want me to enable it?

> What's my battery at?

Fresh data from TeslaMate:
- Battery level: 80% (hit your charge limit!)
- Estimated range: ~411 km
- Charging state: Complete — plugged in but done charging
- Energy added this session: 34.1 kWh

Looks like it finished charging since we last checked (was at 77% earlier).
You're topped up to your 80% limit.

> Lock my car

Your car is already locked according to the latest status.
No action needed!

> How much did I spend on charging this month?

Here's your April charging summary (so far, through April 10):

┌──────────────────┬──────────┬───────────────┬────────────┐
│ Type             │ Sessions │ Energy        │ Cost       │
├──────────────────┼──────────┼───────────────┼────────────┤
│ Supercharger     │ 2        │ 105.0 kWh     │ €37.88     │
│ Home/Destination │ 5        │ 60.98 kWh     │ €0*        │
│ **Total**        │ **7**    │ **166.0 kWh** │ **€37.88** │
└──────────────────┴──────────┴───────────────┴────────────┘

No Data, estimating home/destination charging at ~€0.25/kWh, that's roughly €15 extra,
bringing the estimated total to around €53

> What's my battery health status ?

Your battery is in great shape:
- Battery health: 98.6%
- Current capacity: 75.7 kWh (out of 76.8 kWh max)
- Current max range: 506 km (vs 512 km when new)
- Degradation: only ~1.4% 

Very healthy for a car with 435 drives logged.
Nothing to worry about there.

The agent checks the current state before making changes, asks for confirmation on security-sensitive commands, and presents data with proper units. All of that behavior comes from the SKILL.md instructions.

Things to know

100+ tools, one endpoint. The MyTeslaMate MCP server covers vehicle control, vehicle data, energy/Powerwall/solar, charging history, and TeslaMate analytics. You don't need to know which API to call — the agent figures it out.
Wake before you command. Tesla vehicles go to sleep to save battery. The skill instructs the agent to wake the car before sending action commands. You'll see a brief delay the first time.
Safety checks. The skill explicitly tells the agent to confirm before executing unlock, disable Sentry, remote start, or erase data. You won't accidentally unlock your car because of a typo.
OAuth, not API keys. Authentication goes through Tesla's OAuth flow via MyTeslaMate. The token is scoped and can be revoked from your Tesla account at any time.

— Jérôme