Forem: Jérôme GUYON

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