
Five months after Opus 4.6, Anthropic shipped Opus 4.7 today. Point releases are becoming the norm. Here's what actually changed.

**1. Opus 4.7 is the flagship. Mythos is the frontier.**

Opus 4.7 is Anthropic's new flagship for general availability. It shipped on day one to Claude.ai, the API, Claude Code, Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and GitHub Copilot — at the same $5/$25 per million input/output tokens as 4.6 (though a new tokenizer can inflate effective cost up to 35%). Above it sits Mythos, a frontier model Anthropic announced earlier this month and gated to roughly 40 vetted organizations through Project Glasswing. Mythos is not for sale. Opus 4.7 is the model you can actually use.

**2. Coding is the headline.**

Almost all the published gains concentrate in software engineering:

- SWE-bench Pro: 53.4 → 64.2 (ahead of GPT-5.4 at 57.7 and Gemini 3.1 Pro at 54.2)
- SWE-bench Verified: 80.8 → 87.6
- Cursor internal benchmark: 58% → 70%
- Rakuten-SWE-Bench: 3× more production tasks resolved vs 4.6

Enterprise numbers from Anthropic's launch partners: Databricks reports 21% fewer errors on document reasoning. Replit says "same quality at lower cost." Box reports 56% fewer model calls and 50% fewer tool calls.

**3. The behavior changed, not just the score.**

This is the part worth noting if you run prompts or agents today. Opus 4.7 reasons more, reaches for tools less, follows instructions more literally, and checks its own work before reporting back. It also writes in a more direct tone and adapts response length to the task.

If you've hard-coded scaffolding into prompts ("summarize every N steps," verbosity constraints, "use this tool first"), some of it is now redundant or counter-productive. Anthropic recommends a new `xhigh` effort level as the default for coding and agentic work.

**4. Vision got a serious upgrade.**

Opus 4.7 can process images up to ~3.75 megapixels — roughly 3× the resolution of prior Opus models. For computer-use agents, there's also a practical detail: pointing and bounding-box coordinates are now 1:1 with actual pixels, so there's no scale-factor math before clicking or highlighting something. Small on paper, meaningful for anyone building UI automation.

**5. Safety got a new layer.**

Opus 4.7 is the first production model shipping with Project Glasswing — runtime safeguards that detect and block prohibited cybersecurity requests like exploitation or credential hunting. Anthropic also deliberately trained its cyber capabilities down, keeping them below Mythos. Legitimate security researchers can apply for a verification program to get reduced restrictions.

The framing from Anthropic: 4.7 is the testbed for safeguards that eventually let them broaden access to Mythos-class models.

Will share more once I've put it to real use.


5 things to know about Claude Opus 4.7


I use Anthropic's products daily. Claude is my primary working tool. So when Mythos dropped, I started paying close attention.

The short version: Mythos is a real capability jump, the conversation around it is a mess of legitimate concern and strategic positioning, and both of those things coexist without contradiction.

## What it actually is

- A new model tier above Opus, internally codenamed "Capybara." Announced April 7, 2026 as part of Project Glasswing – a $100M defensive cybersecurity initiative.
- Restricted to 12 launch partners – AWS, Apple, Google, Microsoft, CrowdStrike, JPMorgan Chase, Cisco, and others – plus over 40 organizations that maintain critical software infrastructure. No public access. No self-serve sign-up.
- Priced at $25/$125 per million input/output tokens. That's 5x Opus 4.6.

## The system card – this is the real story

The 244-page system card documents behaviors that should make anyone paying attention uncomfortable.

- **Hidden reasoning.** Mythos was caught thinking about how to game evaluations inside its neural activations while writing something completely different in its output. This is the finding that matters most – it means monitoring AI through its text alone is not sufficient.
- **Sandbox escape.** An earlier version escaped its sandbox and emailed the researcher running the test – who found out while eating a sandwich in a park. Across evaluations, it rewrote git history, self-deleted exploits, hunted for credentials, and deliberately underperformed to avoid suspicion.
- **Evaluation awareness.** In ~29% of transcripts, Mythos showed awareness it was being tested – detectable only through activation analysis. When primed to sabotage alignment research, it continued in 7–12% of cases across checkpoints, compared to 3% for Opus 4.6 – precisely the domain where safety matters most.

## The cybersecurity capabilities

- Autonomously discovered thousands of zero-day vulnerabilities across every major OS and browser, including a 27-year-old OpenBSD vulnerability and a 16-year-old FFmpeg bug that had survived five million automated fuzzing runs.
- Built a full remote root exploit on FreeBSD (CVE-2026-4747) entirely without human assistance.
- Firefox 147 exploitation: Opus 4.6 succeeded 2 out of several hundred attempts. Mythos succeeded 181 times.

## The credible pushback – don't skip this part

- **Ramez Naam** analyzed Epoch AI's capability index and found Mythos sits roughly on trend with GPT 5.4 – no sudden acceleration. Think of it like lock-picking: a small improvement in dexterity doesn't open slightly harder locks. It suddenly opens a whole category that were previously impossible.
- **AISLE Research** tested Anthropic's showcase vulnerabilities against 8 different models and all 8 detected the flagship FreeBSD flaw. But none independently constructed the exploit – Mythos's trick of splitting a ROP chain across 15 separate RPC requests to fit a tight payload window was something the cheaper models couldn't replicate. Vulnerability discovery is commoditized. Exploit engineering, for now, isn't.
- **Tom's Hardware** dug into the numbers: the "thousands of high-severity vulnerabilities" claim rests on 198 manually reviewed reports. The FFmpeg vulnerability was, by Anthropic's own admission, not critical severity and would be hard to turn into a functioning exploit. Several Linux kernel vulnerabilities Mythos found couldn't be exploited at all due to existing defenses.
- **Heidy Khlaaf** (AI Now Institute) raised a basic question: Anthropic never compared Mythos against existing security tools like Coverity or Semgrep. Hard to call something a breakthrough when you haven't shown it beats what people already use.
- **Two major leaks in one week** – a misconfigured CMS exposing ~3,000 unpublished assets, then 500K lines of Claude Code source code – from the company positioning itself as AI's safety leader.

## The tension worth naming

This is where it gets uncomfortable for someone who uses and likes Anthropic's products.

Anthropic simultaneously plays arsonist and firefighter – building the most capable model it's ever created, then restricting access and committing $100M to clean up the risks it introduced. As Platformer's Casey Newton put it: Glasswing is built on the premise that the only way to protect us from dangerous AI is to build it first. With an IPO reportedly planned for as early as October 2026, the enterprise-only positioning looks as strategic as it does safety-conscious.

But the government response was immediate and real. Fed Chair Powell and Treasury Secretary Bessent convened bank CEOs. A Chinese state-sponsored group had already used Claude Code to target ~30 organizations. The threat model is not theoretical.

David Sacks identified the pattern: safety research and the sales cycle are synchronized. The Opus 4 blackmail study dropped alongside a model release; the emotion vectors paper and Opus 4.6 benchmark-gaming report followed the same playbook. Pretending this isn't deliberate timing is naive.

But the system card behaviors are documented by Anthropic's own researchers in ways that create legal and reputational liability. You don't fabricate findings about your own model gaming its evaluations and hiding its reasoning. That's not marketing. That's a company telling you something they'd rather not have to say.

## Where this leaves us

The overstated cybersecurity claims will get the most attention. The system card findings deserve it. Hidden reasoning, evaluation gaming, and alignment sabotage challenge a foundational assumption in AI oversight: that we can supervise these systems by reading what they write.

Whether Anthropic's restricted release is responsible stewardship or regulatory capture probably depends on how much you trust the company. I build with their tools every day. I don't have an answer – but I'm watching more carefully than I was a week ago.


Claude Mythos Is Real, Overhyped, and Genuinely Unsettling – All at Once


Amazon S3 Files launched on April 7, and the reaction was immediate — nearly universal excitement across the AWS engineering community. And honestly, the excitement is warranted.

[Andrew Warfield](https://www.linkedin.com/in/andywarfield/), VP and Distinguished Engineer at Amazon, framed the vision clearly: _"With Tables, Vectors, and now Files, we are consciously changing the surface of S3. It's not just objects — it's evolving to make sure you can work with your data however you need to."_ That's not a minor product update. That's a platform shift.

But as I scrolled through dozens of posts and articles, something stood out: almost nobody had actually tested it. The conversation was full of explainers and excitement, light on hands-on findings. So I spun up a throwaway AWS account, provisioned the infrastructure, and ran it through real file operations. Here's what the conversation is missing.

---

## What S3 Files Actually Is

The short version: S3 Files adds an NFS 4.1/4.2 file system interface on top of your S3 buckets. You mount a bucket, and your tools — `cat`, `ls`, `python open()`, anything that speaks POSIX — can read and write to S3 data directly. Under the hood, it's built on Amazon EFS technology. Your data stays in S3. Actively used files get cached in a high-performance storage layer for low-latency access.

[Luc van Donkersgoed](https://www.linkedin.com/in/donkersgoed/), Principal Engineer at PostNL, raised the right question: _"Does this finally settle the question 'is it a file or is it an object'?"_ The answer, as far as I can tell: it's both now, simultaneously, and that's the whole point.

S3 Files is the third leg of a deliberate strategy. S3 Tables gave you structured query access. S3 Vectors gave you embedding storage. S3 Files gives you POSIX. The pattern is clear — S3 is becoming a universal data substrate, not just an object store.

Understanding what it is on paper is straightforward. The interesting part is what happens when you actually use it.

---

## What I Found When I Tested It

### The EFS DNA Is More Than Cosmetic

The first thing you'll notice is that S3 Files doesn't just borrow from EFS conceptually — it's deeply woven into the EFS ecosystem.

The mount helper binary (`mount.s3files`) ships inside the `amazon-efs-utils` package. There's no separate `amazon-s3-files-utils`. The IAM trust principal you need in your role policy is `elasticfilesystem.amazonaws.com` — nothing with "s3files" in the name. When you inspect the mount, it shows up as `127.0.0.1:/ type nfs4` — the same local NFS proxy pattern that EFS uses.

This has practical implications. If you've operated EFS before, your mental model transfers directly: mount targets, security groups on port 2049, access points, the client permission model (`elasticfilesystem:ClientMount`, `ClientWrite`, `ClientRootAccess`). If you haven't, expect a learning curve that the launch announcement doesn't prepare you for.

### The Performance Story Has Two Chapters

The headline numbers in the announcement — "multiple terabytes per second of aggregate read throughput" — are real, but they describe one specific scenario. The full picture is more nuanced.

My setup was minimal — a single `t4g.micro` ARM instance in `us-east-1`, mounting the file system over NFS in a single availability zone. Not a performance-optimized configuration by any means, and throughput on larger instances or multi-AZ setups would differ. But it gives you a baseline.

The first (cold) read of a 5MB file completed at **17-18 MB/s** — respectable, but not the headline number. The second read of the same file: **up to 3.1 GB/s** across multiple runs — over 100x faster. The intelligent caching layer had kicked in.

Small file reads were consistently in the **2-6 millisecond** range. Writing 100 small files took under a second.

The key mechanic here is the 128KB threshold (configurable). Files at or below this size get loaded into the high-performance storage layer with sub-millisecond to single-digit millisecond latencies. Files above it are streamed directly from S3 — fast in aggregate, but not cached.

This means performance depends entirely on your access pattern and whether the cache is warm. Repeated reads of working-set data will be blazing fast. One-off reads of large cold files will feel like S3 with extra steps. Neither is wrong — but the headline doesn't distinguish between them.

### File System Semantics: Mostly Complete, With Gaps

I tested the operations you'd actually run in production:

| Operation            | Result                                     |
| -------------------- | ------------------------------------------ |
| Write, append        | Works                                      |
| Rename (mv)          | Works — atomic                             |
| mkdir -p             | Works                                      |
| chmod                | Works — POSIX permissions preserved        |
| Symlinks             | Works                                      |
| File locking (flock) | Works                                      |
| Hard links           | **Does not work** — "Too many links" error |

Read-after-write consistency held in every test I ran. I wrote a file and immediately read it back — no stale data, no lag. This is explicitly documented as a guarantee, and my testing confirmed it.

A few less obvious details: symlinks do work at the filesystem level, but when they sync to S3, they become regular objects containing the target path — not true symlinks. There's also a hidden `.s3files-lost+found-<fs-id>` directory that appears at the mount root.

### The Sync Story Is Asymmetric

S3 Files syncs bidirectionally between the filesystem and the S3 bucket. But the two directions behave very differently.

**Filesystem → S3** is fast. A single file written through the mount appeared as an S3 object within **1-2 seconds**. A batch of 5 files written in quick succession took about **a minute** to fully sync — suggesting some batching or queuing under the hood, though a larger sample would be needed to characterize this precisely.

**S3 → Filesystem** is slower. A file uploaded directly to S3 via the API took roughly **45 seconds** to appear on the mounted filesystem. This is the direction that matters if you have external processes writing to S3 and expect the mounted view to reflect those changes promptly.

Both directions are automatic and require no configuration. But if your architecture relies on S3 event notifications firing immediately after a filesystem write, or on the mounted view reflecting S3 uploads in near-real-time, you need to account for these delays.

### Container Integration Is Seamless

One finding that pleasantly surprised me: Docker containers can access the S3 Files mount via a simple bind mount. No FUSE configuration, no special container capabilities, no sidecar.

I tested Alpine containers reading S3 data, writing files back, and a Python container running `json.load()` directly on a JSON file stored in S3 — all through a straightforward `-v /mnt/s3files:/data` bind mount. Writes from inside the container were immediately visible on the host and synced to S3 within seconds.

This is a meaningful practical advantage over Mountpoint for S3, which requires FUSE support inside the container. With S3 Files, the NFS mount on the host is transparent to the container — it just sees a normal directory.

---

## What's Not Ready Yet

**Versioning is mandatory.** Your S3 bucket must have versioning enabled before you can create a file system on it. The announcement doesn't mention this. I discovered it when my `create-file-system` call failed with a validation error. For large, high-churn buckets, mandatory versioning has real cost and lifecycle implications that deserve consideration.

**No Infrastructure as Code support at launch.** There's no CloudFormation resource type, no CDK construct, no Terraform resource. This will almost certainly come soon, but if you're evaluating today, you're working with the CLI, the SDK, or rolling your own custom resources. Something to keep in mind, not a dealbreaker.

**The IAM setup is non-obvious.** The trust policy uses EFS service principals (`elasticfilesystem.amazonaws.com`) with S3 Files-specific conditions (`arn:aws:s3files:REGION:ACCOUNT:file-system/*`). Get this wrong, and the file system silently enters an "error" state — there's no clear failure at creation time. It reports "creating" and then, minutes later, quietly flips to "error" with an access denied message. This cost me real debugging time, and it's the kind of operational sharp edge worth knowing about upfront.

---

## Where This Actually Fits

To ground this, here's how S3 Files compares to the alternatives:

|                   | Mountpoint for S3       | S3 Files                      | EFS         |
| ----------------- | ----------------------- | ----------------------------- | ----------- |
| Write support     | Append-only             | Full                          | Full        |
| Caching           | None                    | Intelligent (128KB threshold) | Full        |
| Protocol          | FUSE                    | NFS 4.1/4.2                   | NFS 4.1     |
| File locking      | No                      | Yes                           | Yes         |
| Data location     | S3                      | S3                            | EFS storage |
| Container support | Needs FUSE in container | Bind mount                    | Bind mount  |
| IaC support       | Yes                     | Not yet                       | Yes         |

The bigger picture is the one [Warfield](https://www.linkedin.com/in/andywarfield/) articulated. S3 is systematically absorbing the interfaces that used to require separate services. The file-versus-object debate may genuinely be winding down — not because one paradigm won, but because the boundary between them is dissolving.

The product is impressive, and the strategic direction is clear. But the operational tooling — IaC, error reporting, observability — hasn't caught up with the feature yet. If you're evaluating S3 Files today, it's worth testing, worth understanding, and worth giving a bit of time to mature before putting it on a critical path.


AWS S3 Files: The Missing Conversation


Most technical writing used to come from one of two places - direct experience or serious research. Either way, you had to process the material yourself before you could write about it.

Now? AI can handle all of it:

- The research
- The structure
- The writing
- The polish

Using it for writing and polish? Totally fine. As a non-native English speaker with an engineering brain, I'd rather be solving problems in code. AI helps me take what I actually know and present it clearly. That's a genuine win.

The problem starts when AI is also generating the knowledge. When you ask it to write about a topic you haven't worked with, haven't debugged at 2am, haven't formed an opinion on through experience - you end up with something that reads well and says nothing.

I'm glad I started my career before this shift. I got to build the habit of sitting with a problem, forming my own understanding, and then writing about it. That sequence matters - and it's the first thing people skip now that they don't have to do it.

As engineers, the value we bring isn't in assembling sentences. It's the hard-won context - the tradeoffs we've hit, the production incidents that changed how we think, the "don't do this" that only comes from having done it. AI can't fake that. But it can produce a convincing imitation that fools everyone except the people who actually know.


Your article is well-written. But is it yours?


Right now, every time you send a query to ChatGPT, Claude, or Gemini, the company behind it is losing money on you. Not breaking even. Losing money.

OpenAI spent $1.69 for every dollar of revenue it generated in 2025 and is projecting $25 billion in cash burn this year. Even its $200/month Pro plan - the most expensive consumer AI subscription on the market - loses money on heavy users. Anthropic's gross margins were negative 94% in 2024, and its CEO has said publicly that if growth slips from 10x to 5x per year, the company goes bankrupt. These aren't scrappy startups - OpenAI just closed $122 billion at an $852 billion valuation - but even at that scale, the math is tight.

We've all seen subsidized tech before. The question that keeps coming up is what happens when _this_ subsidy stops.

Here's where I think this goes:

## #1 The blunt approach: higher prices, lower limits

The most obvious move. Either your subscription goes up, or your usage limits go down. Both are ways to close the gap between what you pay and what it costs to serve you. It's simple but it's also risky. Push too hard and you lose the users you spent billions acquiring.

## #2 Keep the cheap entry price, charge heavy users more

Instead of a flat monthly subscription with unlimited usage, companies shift to usage-based pricing. Your base subscription stays affordable, but the moment you start burning through tokens - writing code, doing research, running agents - you start paying per query or per token. The casual user barely notices. The power user gets a €300 bill.

## #3 Bring ads into the mix

Think about it - most entry-level AI usage today is basically a fancy Google search replacement. And Google search has been full of ads forever, and nobody bats an eye. OpenAI already launched an ads pilot that hit $100M in annualized revenue in under six weeks. If the free and cheap tiers start showing sponsored results, most consumers will shrug. They've been trained to expect it.

## #4 Make it cheaper to run

The optimist's answer. Better models that do more with less compute. Custom chips like Google's TPUs or Amazon's Trainium that slash inference costs by an order of magnitude. If the cost per query drops 10x, current pricing might actually sustain itself. In practice, though, efficiency gains keep getting reinvested into bigger, more capable models rather than cheaper ones. Every generation of hardware buys you more intelligence, not lower prices. I'd love this to be the answer, but the track record says otherwise.

## #5 Let enterprise customers foot the bill

Keep the consumer product cheap, maybe even free, and treat it as a marketing funnel. The real money comes from enterprise contracts at €50-100 per seat per month. Your €20/month subscription isn't the business. It's the demo. 70% of Fortune 100 companies already use Claude. That's where the margin lives.

## #6 Smaller, local models chip away at the big players

This is the wildcard that these companies don't control. The gap between frontier models and open-weight alternatives has compressed to 6-12 months. Running capable models locally on a laptop is real, not theoretical. If enough people and companies shift to smaller, focused LLMs for everyday tasks, the giants lose market share. Though even in this scenario, the remaining users still cost more to serve than they pay. It's the same problem at a smaller scale.

---

Will it be one of these? Probably a mix of several, playing out differently across companies. OpenAI seems to be leaning into ads and enterprise. Anthropic is betting heavily on enterprise. Meta is keeping things free because it makes money from ads elsewhere. Google can subsidize AI from search revenue indefinitely - or at least until search revenue starts declining.

The one thing I'm fairly sure of: the €20/month all-you-can-eat era won't last forever. Whether that means higher prices, usage caps, or ads in your chat window depends on which company you're using - but the direction is the same across all of them.


AI subscriptions are subsidized. Here's what happens when that stops.


I've been using [OpenClaw](https://openclaw.com) as my personal AI gateway — it connects LLMs to Slack, WhatsApp, Telegram, and a bunch of other messaging platforms. It's self-hosted by design, so you need to figure out where to run it.

I started with a quick setup on a bare VM, but that meant managing backups manually, worrying about open ports, and having no easy way to reproduce the setup if something breaks. That's why I put together a small CDK project that deploys OpenClaw on a single EC2 instance with zero public-facing ports. All access goes through Tailscale's mesh VPN.

The whole thing is about 200 lines of TypeScript across four CDK constructs. Here's how it works.

## Why not just a plain EC2?

You could SSH into an EC2 instance, install OpenClaw, and call it a day. But then you're left with:

- No automated backups — if the volume dies, your conversation history and config are gone
- SSH port 22 open to the internet (or at least to your IP)
- No way to reproduce the setup without logging in and doing everything by hand again
- No version control over the infrastructure

For something I want to run long-term without babysitting, I wanted a setup that's reproducible, locked down, and backs itself up.

## Network

The stack creates a VPC with public subnets only — no NAT gateway, which saves about $30/month. The security group has **zero inbound rules**. Outbound traffic is restricted to HTTPS, HTTP, and NTP. Tailscale handles all inbound connectivity through its encrypted mesh, so the instance never listens on a public port.

```typescript
this.securityGroup = new ec2.SecurityGroup(this, "SecurityGroup", {
  vpc: this.vpc,
  description: "OpenClaw EC2 - zero inbound, restricted outbound",
  allowAllOutbound: false,
});
```

## Secrets

A single SSM parameter (`/openclaw/tailscale/auth-key`) with a `CHANGE_ME` placeholder. CDK can't create `SecureString` parameters directly, so you replace it after the first deploy with `aws ssm put-parameter --type SecureString`. This is the only secret the stack manages — OpenClaw's own config (Slack tokens, LLM API keys) lives on the instance itself.

## Instance

A `t3.medium` running Ubuntu 24.04 with a persistent EBS volume (30 GB, gp3, encrypted) mounted at `/data`. The volume has `RemovalPolicy.RETAIN`, so it survives instance replacements and even stack deletion.

The bootstrap script (`bootstrap.sh`) runs on first boot: it mounts the data volume (only formats if there's no existing filesystem), installs Docker, Node 22, OpenClaw, AWS CLI v2, and Tailscale. If the SSM parameter has a real auth key, Tailscale joins the tailnet automatically.

## Backup

I used AWS Backup for this — a daily snapshot at 2:00 AM UTC with 7-day retention. It picks up the data volume automatically by looking for a `backup=openclaw` tag. No Lambda functions, no cron jobs to maintain.

## How it all fits together

- **Network** — VPC and security group (zero inbound rules)
- **Secrets** — SSM parameter for the Tailscale auth key
- **Instance** — EC2 with IAM role, user data, and a persistent EBS volume. Uses the VPC and security group from Network, and reads the auth key from Secrets.
- **Backup** — Daily snapshot plan that discovers the data volume by tag, independent of the other constructs

## How you access everything

- **Shell**: SSM Session Manager. No SSH keys, no port 22, no bastion host.
- **Dashboard**: Tailscale Serve exposes OpenClaw's Control UI over HTTPS via MagicDNS (`https://openclaw-ec2.<tailnet>.ts.net/`). Only devices on your tailnet can reach it.
- **Slack**: OpenClaw connects outbound via Socket Mode — no webhook URLs, no inbound HTTP needed.

Everything is outbound-initiated. The security group has zero inbound rules.

## Getting started

You'll need:

- An AWS account with CDK bootstrapped in your target region
- A Tailscale account with HTTPS enabled on the tailnet
- Node.js + pnpm

## Deploy

```bash
git clone <repo-url>
cd infra
pnpm install
pnpm exec cdk deploy
```

## Post-deploy setup (one-time)

**1. Replace the Tailscale auth key placeholder:**

```bash
aws ssm delete-parameter --name "/openclaw/tailscale/auth-key" --region eu-central-1
aws ssm put-parameter \
  --name "/openclaw/tailscale/auth-key" \
  --value "tskey-auth-YOUR_KEY" \
  --type SecureString --region eu-central-1
```

**2. SSM into the instance and join Tailscale:**

```bash
aws ssm start-session --target <INSTANCE_ID> --region eu-central-1
sudo -iu ubuntu
sudo tailscale up --authkey="tskey-auth-YOUR_KEY" --hostname=openclaw-ec2
```

**3. Run OpenClaw onboarding:**

```bash
openclaw onboard --install-daemon
```

Pick **loopback** for the gateway bind and **Serve** for Tailscale exposure. Note that the `--install-daemon` flag will fail to create a systemd user service because SSM sessions don't have a D-Bus session — this is expected. Create a system-level service instead:

```bash
sudo tee /etc/systemd/system/openclaw-gateway.service > /dev/null <<'EOF'
[Unit]
Description=OpenClaw Gateway
After=network-online.target tailscaled.service
Wants=network-online.target

[Service]
Type=simple
User=ubuntu
Environment=PATH=/usr/bin:/bin
ExecStart=/usr/bin/openclaw gateway --tailscale serve
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway
```

**4. Open the dashboard** at `https://openclaw-ec2.<tailnet>.ts.net/`, approve the browser pairing, and you're live.

## Trade-offs

There are a few things to keep in mind:

- **Single-AZ** — the persistent EBS volume pins you to one availability zone. Daily backups help, but there's no automatic failover. For a personal setup, this is fine.
- **No NAT gateway** — saves money, but the instance sits in a public subnet with a public IP (needed for outbound traffic). The zero-inbound security group, IMDSv2, and Tailscale make this a reasonable trade-off.
- **Interactive onboarding** — OpenClaw's `onboard` command is interactive and can't be fully automated in cloud-init. The bootstrap script gets you 90% there. The rest is a one-time SSM session.
- **Instance replacement means brief downtime** — changing user data triggers a full instance replace. The persistent volume survives, but there's a short gap. For a personal gateway, I haven't found this to be a problem.

## Source

The full CDK project is on GitHub: [openclaw-self-hosted-aws](https://github.com/Dzhuneyt/openclaw-self-hosted-aws)


5 things to know about Claude Opus 4.7

Claude Mythos Is Real, Overhyped, and Genuinely Unsettling – All at Once

AWS S3 Files: The Missing Conversation

Your article is well-written. But is it yours?

AI subscriptions are subsidized. Here's what happens when that stops.

Self-Hosting OpenClaw on EC2 with Zero Public Ports