<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>AWS - Tag - AWS Sensei</title><link>https://aws-sensei.cloud/tags/aws/</link><description>AWS - Tag - AWS Sensei</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Fri, 22 May 2026 00:00:00 +0200</lastBuildDate><atom:link href="https://aws-sensei.cloud/tags/aws/" rel="self" type="application/rss+xml"/><item><title>Smarter S3 Triggers: Hash Files, SNS Fanout, and No More Redundant Calls</title><link>https://aws-sensei.cloud/posts/2026-05-22-smarter-post-triggers/</link><pubDate>Fri, 22 May 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-05-22-smarter-post-triggers/</guid><description>🔊 Voiced by Amazon Polly
The Polly TTS setup worked well, but there was a flaw: every deployment triggered the Polly Lambda for every post, even when nothing had changed. The Lambda&amp;rsquo;s content-hash check caught duplicates after the fact, but the invocations still happened for all posts on every push. At the AWS Summit in Hamburg on May 20th I had some time to think through a cleaner solution.</description></item><item><title>AWS MCP Server with Claude Code</title><link>https://aws-sensei.cloud/posts/2026-05-08-aws-mcp-server-claude-code/</link><pubDate>Fri, 08 May 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-05-08-aws-mcp-server-claude-code/</guid><description>🔊 Voiced by Amazon Polly
AWS recently announced the general availability of the AWS MCP Server. It gives AI coding assistants like Claude Code direct access to over 15,000 AWS API operations, live documentation, and sandboxed script execution — all via the Model Context Protocol.
I set it up for my own workflow and ran into a few stumbling blocks. Here&amp;rsquo;s the short version of what actually works.
What is the AWS MCP Server?</description></item><item><title>Voiced by Amazon Polly — Adding TTS to a Static Blog</title><link>https://aws-sensei.cloud/posts/2026-04-30-polly-tts/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-30-polly-tts/</guid><description><![CDATA[🔊 Voiced by Amazon Polly
You&rsquo;ve probably noticed the audio player at the top of this post. That&rsquo;s Amazon Polly — AWS&rsquo;s neural Text-to-Speech service. Here&rsquo;s how it works and why I built it the way I did.
The Goal Every blog post should have a &ldquo;listen&rdquo; option. Audio is generated automatically when a post is published or updated — no manual steps, no third-party service.
Architecture Git Push → Frontend Pipeline (Hugo build + S3 sync) → Markdown files synced to S3 (_content/posts/) → S3 Event triggers Lambda → Lambda reads HTML from S3 → Polly synthesizes speech (SSML) → MP3 saved to S3 (audio/{slug}.]]></description></item><item><title>Contact Form in the Blog — with AWS SES, Lambda and API Gateway</title><link>https://aws-sensei.cloud/posts/2026-04-27-contact-form/</link><pubDate>Mon, 27 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-27-contact-form/</guid><description>🔊 Voiced by Amazon Polly
Static blogs have no backend — but sometimes you still need a way for visitors to get in touch. The usual solution is a third-party service like Formspree or Netlify Forms. My solution: build everything on AWS myself.
The Architecture Browser → API Gateway → Lambda → SES → Email Three AWS services, all serverless. The visitor fills out the form, Lambda validates the input and calls SES — the email lands in my inbox.</description></item><item><title>Real-Time Comments in the Blog — with WebSocket API Gateway, Lambda and DynamoDB</title><link>https://aws-sensei.cloud/posts/2026-04-20-realtime-chat/</link><pubDate>Mon, 20 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-20-realtime-chat/</guid><description>🔊 Voiced by Amazon Polly
Static blogs have a problem: no interaction. Comment systems like Disqus exist, but they load third-party JavaScript, track visitors, and never quite fit the blog&amp;rsquo;s look. My solution: build a custom real-time comment section directly on AWS.
The result is the widget at the bottom of this post — you can try it out right now.
The Architecture Browser ←→ WebSocket API Gateway ←→ Lambda ←→ DynamoDB The key difference from a regular REST widget: WebSocket.</description></item><item><title>What Does This Blog Cost? — A Live Cost Dashboard with AWS Cost Explorer</title><link>https://aws-sensei.cloud/posts/2026-04-14-cost-dashboard/</link><pubDate>Tue, 14 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-14-cost-dashboard/</guid><description>🔊 Voiced by Amazon Polly
One question I ask myself with every AWS project: what does this actually cost? For this blog I built the answer directly in — at the bottom of this post you can see live what aws-sensei.cloud has cost in the current month, broken down by AWS service.
The Idea The goal was not a static screenshot dashboard, but real live data straight from AWS — updated daily, embedded directly in the blog.</description></item><item><title>Sentiment Analysis in the Blog — with AWS Comprehend, Lambda and API Gateway</title><link>https://aws-sensei.cloud/posts/2026-04-10-sentiment-widget/</link><pubDate>Fri, 10 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-10-sentiment-widget/</guid><description>🔊 Voiced by Amazon Polly
The APIs pipeline from the previous post was ready — waiting for its first feature. The result is the sentiment analysis widget you can try out at the bottom of this post: type a sentence, AWS Comprehend analyzes it in real time and tells you whether it reads as positive, negative, neutral, or mixed.
The Architecture Browser → API Gateway → Lambda → AWS Comprehend Three AWS services, all serverless.</description></item><item><title>Three Pipelines, One Platform — My CI/CD Architecture on AWS</title><link>https://aws-sensei.cloud/posts/2026-04-02-three-pipelines-one-platform/</link><pubDate>Thu, 02 Apr 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-04-02-three-pipelines-one-platform/</guid><description>🔊 Voiced by Amazon Polly
In the first post I described how aws-sensei.cloud is set up — Hugo, S3, CloudFront, a CodeBuild pipeline. That was a good start. But one pipeline for everything doesn&amp;rsquo;t scale.
The problem showed up in practice faster than expected: with a single pipeline, I kept hitting the CodeBuild free tier limit just by writing blog posts — even though I had only changed Markdown. Every commit triggered the full pipeline: Hugo build, infrastructure deploy, everything.</description></item><item><title>From Vercel to AWS — Migrating My Blog to the Cloud</title><link>https://aws-sensei.cloud/posts/2026-03-26-aws-cloud-migration-blog/</link><pubDate>Thu, 26 Mar 2026 00:00:00 +0200</pubDate><author>Marcel</author><guid>https://aws-sensei.cloud/posts/2026-03-26-aws-cloud-migration-blog/</guid><description>🔊 Voiced by Amazon Polly
I have been working with AWS for over six years — in projects, in architecture, day to day. At some point it became clear: if I take my AWS knowledge seriously and want to show it to the world, my own infrastructure should reflect that.
That is how AWS Sensei came about — as a platform to share knowledge, try things out, and make AWS skills visible.</description></item></channel></rss>