My kids are working on touch typing, so I decided to recreate the simple “falling letters” game I played as a child. The concept is straightforward: letters drop from the top of the screen, and you type them before they reach the bottom.

Rather than writing the code myself (I haven’t done THAT for a while since coding assistants make it so easy), I used the opportunity to compare two AI coding assistants side by side using the same detailed prompt:

• Claude AI with its Code CLI
• Kiro CLI from @kirodotdev

I asked both tools to build a modern version of the game using Three.js, with neon visuals, particle effects, combo scoring, lives, progressive difficulty, and polished controls.

What Each Tool Delivered

Claude Code CLI completed the task in 12 minutes and 37 seconds. It produced a fully functional game featuring a starfield background, glowing neon letters with pulse animations, particle explosions on successful hits, red bursts and camera shake on misses, combo multipliers with visual feedback, and a complete scoring and lives system.

Kiro CLI finished in 3 minutes and 6 seconds. The output was comparable in quality and features — same visual style, animations, physics, and gameplay mechanics.

The main differences were speed and cost. Kiro’s smart router selected appropriate models for different parts of the implementation (visuals, physics, UI logic), resulting in significantly lower token usage — roughly one-fifth the cost of the Claude run.

Here are screenshots of the running game and the CLI outputs for reference:

Claude:

Kiro:

Claude:

Kiro:

Observations from the Experiment

The project reinforced a few practical points I see in my day-to-day work with GenAI workloads and cloud-native development:

• Tool selection has become an important part of efficiency. Different AI coding environments handle speed, cost, and specialization differently, even when given identical prompts.
• Rapid prototyping has accelerated dramatically. Features that once required hours of manual coding can now be generated, iterated, and made playable in minutes.
• Complementary use of tools makes sense. I continue to use Claude for deeper reasoning and system design tasks, while Kiro has become useful for faster implementation passes.

Even small personal projects like this help me stay connected to the evolving developer tooling landscape. As someone who works with customers on GenAI search solutions (OpenSearch + RAG pipelines with LangGraph, Cohere embeddings, vector stores), cloud migrations, and scalable SaaS architectures, these hands-on experiments keep my perspective current when advising teams on their own AI adoption strategies.

I highly recommend to experiment with tools if you’re in the field — don’t just settle for something you’re used to. This simple typing game experiment sits at the intersection of family, fun, and technology. It reminded me how quickly AI tools are changing the way we build, and how staying hands-on with them remains valuable regardless of role or seniority.

If you’ve run similar comparisons with Claude Code CLI, Kiro, Cursor, or other AI coding tools, I’d be interested in your experiences in the comments. What’s working well for you in 2026?

A few months ago, I was still manually stepping through the same AWS deployment ritual for every Single Page Application (SPA): configuring S3 buckets with website hosting and CORS, creating CloudFront distributions, handling ACM certificates, syncing files via CLI, and running cache invalidations. Each run took 20–40 minutes of undivided attention. A single oversight — wrong policy, missing OAC, skipped invalidation — meant rework or silent failures later.

That repetition was eating real time and mental energy I wanted to spend on features, experiments, or new projects. So I decided to eliminate it once and for all.

I vibe-coded the solution in one focused session, leaning on code-assistants to turn high-level intent into clean, working Python code at high speed. The result is a single script that handles the complete end-to-end deployment:

- Creates or reuses the S3 bucket and enables static website hosting
- Provisions a CloudFront distribution with HTTPS-only redirection
- Manages ACM certificates (requests new ones when required or attaches existing valid ones)
- Syncs built SPA files efficiently with — delete
- Triggers cache invalidation so changes are live instantly

The script is idempotent where it counts, logs every meaningful step, fails fast on clear misconfigurations, and lets you override defaults via arguments or environment variables.

What once took 30+ minutes of manual work now completes in under 30 seconds — frequently 15–20 seconds depending on file count and region. The reduction in cognitive load is even more valuable than the raw time saved.

Vibe-coding with assistants is a massive value-add for any developer or architect. It collapses the gap between idea and implementation, keeps you in flow instead of fighting syntax or boilerplate, and lets domain knowledge guide the outcome while the heavy lifting happens instantly. The productivity multiplier is real and compounding.

I’ve open-sourced the project so anyone building SPAs on AWS can bypass the same grind:
https://github.com/vbudilov/spa-deploy

It’s kept deliberately lightweight — just boto3 plus sensible defaults — so it’s easy to read, fork, or extend for your own needs.

I’ve already used it across personal projects and small client work; it consistently saves hours and prevents silly errors.

If you’re still tab-switching between console, CLI, and docs for frontend deploys, this might be worth a try.

I’d love to hear your take:
- What’s your current SPA / frontend deployment flow on AWS (or other clouds)?
- Have you automated away a repetitive infrastructure task that used to drain you?
- How has vibe-coding (or AI-assisted coding) changed your own workflow?

Fork it, break it, improve it — feedback, issues, and PRs are very welcome.

I built a small mobile app for stock analysis + financial reminders, using both kiro-cli and Claude Code (CLI-only, no IDEs) on the exact same project. I’d prompt the same task, git-revert changes, and compare how each handled it — including code quality, verbosity, and token/credit burn.

Quick & dirty takeaways:

kiro-cli is noticeably more succinct and developer-in-the-loop — it does a focused chunk of work, then waits for your feedback. Claude Code goes “all in,” often building way more than requested.

→ Result: kiro-cli used far fewer tokens/credits. I burned through Claude Code’s limits in ~30 minutes of heavy prompting, while kiro’s free tier kept me going much longer.

Claude Code has killer built-in features like Plan Mode (read-only planning without changes). Super handy. kiro-cli lacks a dedicated mode, but a simple prompt (“Plan everything first, no changes yet”) gets it to behave similarly.

→ Close call — Claude wins on convenience, kiro isn’t far behind.

Subagents in Claude Code look amazing for parallel work… until you see the token meter. They often fire off automatically and drain limits fast, even on moderate tasks.

→ Big advantage in theory, but in practice, they eat tokens aggressively.

Bottom line: For day-to-day, budget-conscious use, I lean toward kiro-cli — it’s efficient and predictable. But I’m keeping my Claude Code sub (no upgrade to the higher, $100/month, tier though) because it’s really good when I want maximum “hands-off” power (and also as a backup).

What’s your experience with kiro-cli vs. Claude Code? Which one wins for you in real projects?

The Many Layers of Amazon Bedrock Knowledge Bases and Why You Should Give It a Try

Building a Retrieval-Augmented Generation (RAG) system from scratch is no small feat. It involves stitching together data ingestion pipelines, text chunking algorithms, vector databases, search mechanisms, and generative AI models — all while ensuring security, scalability, and performance. Each component requires expertise, time, and resources, often leading to a complex web of microservices that can drain budgets and delay projects. Enter Amazon Bedrock Knowledge Bases, a fully managed service that takes away much of this “plumbing,” enabling developers to create robust RAG systems quickly and cost-effectively. In this article, I’ll explore the many layers of Bedrock Knowledge Bases and why it’s a game-changer for businesses and developers alike.

What Is Amazon Bedrock Knowledge Bases?

Amazon Bedrock Knowledge Bases is a managed service within AWS’s Bedrock platform, designed to simplify the creation of RAG workflows. RAG systems combine the power of information retrieval with generative AI to deliver accurate, context-aware responses. For example, a customer support chatbot might retrieve relevant documents from a company’s knowledge base and use a large language model (LLM) to generate a natural, user-friendly answer. Bedrock Knowledge Bases abstracts away the complexity of building such systems by providing an end-to-end solution — from data ingestion to response generation — saving you from managing a bunch of microservices.

The Layers of Bedrock Knowledge Bases

To understand why Bedrock Knowledge Bases is so powerful, let’s break down its architecture into its core layers. Each layer handles a critical part of the RAG workflow, eliminating the need for custom-built components.

1. Data Ingestion: The Foundation 📂

The first layer is all about getting your data into the system. Bedrock Knowledge Bases supports a wide range of data sources, including Amazon S3, Confluence, Salesforce, SharePoint, and even web crawlers (currently in preview). It can ingest both structured data (e.g., databases) and unstructured data like text, images, tables, and charts. This multimodal capability means you don’t need separate tools for processing PDFs, images, or tabular data.

What It Replaces: Without Bedrock, you’d need to build custom ETL (Extract, Transform, Load) pipelines using tools like Apache NiFi or AWS Glue, or write scripts to scrape and process data from various platforms. Bedrock’s intelligent document processing (IDP) automates this, saving hours of development time.

Why It Matters: By handling data ingestion across diverse sources, Bedrock reduces setup time and ensures your RAG system can pull from wherever your data lives — without manual intervention.

2. Data Processing: Chunking and Embedding ✂️🔢

Once data is ingested, Bedrock processes it into a format suitable for retrieval. This involves two key steps:

• Chunking: Bedrock splits documents into manageable pieces using semantic, hierarchical, or fixed-size chunking. You can even customize chunking with AWS Lambda for specific use cases.
• Embedding Generation: It converts these chunks into vector embeddings using models like Amazon Titan or Cohere, supporting both text and multimodal data (e.g., images).

What It Replaces: Normally, you’d rely on libraries like LangChain or Hugging Face for chunking and embedding, requiring custom code to handle text segmentation and vectorization. You’d also need to manage compute resources for embedding generation, which can be resource-intensive.

Why It Matters: Bedrock automates these steps, ensuring high-quality embeddings without the need for external libraries or infrastructure management. This speeds up development and reduces costs.

3. Vector Storage: The Memory Bank 💾

After processing, Bedrock stores embeddings in a managed vector database. Supported options include Amazon OpenSearch Serverless, Amazon Aurora, Amazon Neptune Analytics, MongoDB, Pinecone, and Redis Enterprise Cloud. It also handles metadata (up to 10 KB per document) for filtering and hybrid search (semantic + keyword).

What It Replaces: Setting up and maintaining a vector database like Pinecone or Elasticsearch is a significant undertaking, requiring expertise in database configuration, scaling, and indexing. Bedrock’s managed vector stores eliminate this overhead.

Why It Matters: You get a scalable, secure storage solution without provisioning servers or managing database operations, saving both time and operational costs.

4. Query Processing: Smart Retrieval 🔍

When a user submits a query, Bedrock processes it to retrieve relevant data. It supports natural language queries, converting them into vector searches or SQL queries for structured data stores like Amazon Redshift. Features like hybrid search and GraphRAG (using Amazon Neptune Analytics) enhance retrieval accuracy by linking related content.

What It Replaces: Without Bedrock, you’d need to build custom search algorithms or integrate tools like OpenSearch for semantic search and SQL engines for structured data. GraphRAG would require a separate graph database setup.

Why It Matters: Bedrock’s query processing layer simplifies retrieval, making it accessible to non-experts while delivering precise results, reducing the need for specialized search infrastructure.

5. Response Generation: The Final Touch 💬

The final layer combines retrieved data with foundation models (e.g., Claude, Llama, Nova) to generate natural, context-aware responses. Bedrock’s RetrieveAndGenerate API streamlines this process, handling session context for conversational continuity.

What It Replaces: Building a RAG system typically requires custom orchestration to integrate retrieval and generation, often using frameworks like LangChain or custom APIs. Bedrock’s single API call eliminates this complexity.

Why It Matters: By automating response generation, Bedrock ensures fast, accurate answers without the need for custom integration code, saving development effort.

6. Security and Integration: The Glue 🔒🔗

Underpinning these layers are Bedrock’s security and integration capabilities. It manages IAM roles, supports customer-managed KMS keys for encryption, and ensures data isolation. Integration with AWS services like Lambda, S3, EventBridge, and Bedrock Agents enables seamless workflows and automation.

What It Replaces: You’d otherwise need to configure IAM policies, encryption, and integration scripts manually, often using tools like AWS SDK or custom middleware.

Why It Matters: Bedrock’s built-in security and integration reduce setup time and ensure compliance, while enabling easy connection to your broader AWS ecosystem.

Give Bedrock Knowledge Bases a Try

It’s the fastest way for you to build out your own RAG without coding up multiple microservices and ingestion pipelines.

https://assetsmaven.com

Three years ago, my family and I relocated to Florida. Along with the warmer weather and beach life, we also experienced a significant spike in our credit card spending. This unexpected rise in expenses made me realize how crucial it was to have a better handle on our finances. That’s when I decided to create an app that has since transformed the way we manage our money.

The app I developed allows users to upload their credit card and bank statements in PDF format, as well as take snapshots of their receipts, and then automates the entire process. It itemizes and categorizes transactions, providing insightful analytics and a powerful search functionality. But that’s just the beginning — the app also generates graphs and detailed analyses, making it easier to understand and manage your spending habits.

The Tech Stack: From LLMs to Kubernetes and Lambda

Building this app was an exciting challenge. I leveraged Amazon Bedrock’s Claude Sonnet 3.5, a cutting-edge large language model (LLM), to manage the complexities of natural language processing and data categorization. Claude Sonnet 3.5 was instrumental in making the app smart enough to understand and sort through the vast amounts of data that users upload.

In addition to the LLM, I used Amazon Textract for extracting text and data from documents. The backend of the app is powered by a combination of Kubernetes and AWS Lambda.

On the storage side, I utilized AWS S3 for storing user-uploaded files and Amazon DocumentDB for managing structured data. To manage communication between different parts of the app, I used Amazon SQS, which helps ensure everything runs smoothly, even under heavy load.

Key Features: Search, Graphs, and In-Depth Analysis

The app is more than just a transaction tracker. It offers a suite of features designed to give users a deeper understanding of their finances:

• Search Functionality: The app allows users to search through their transactions with ease. Whether you’re looking for a specific purchase or trying to find all transactions related to a certain category, the search functionality makes it simple.
• Graphs and Visualizations: Visualizing data is key to understanding it. The app generates a variety of graphs that show spending trends, categorize expenses, and highlight patterns that might otherwise go unnoticed.
• In-Depth Analysis: Beyond just itemizing expenses, the app provides detailed analyses of your spending habits. It helps identify unnecessary subscriptions, recurring charges, and other financial insights that can save you money.

Discovering Hidden Costs: Uncovering Unnecessary Subscriptions

One of the most useful features of the app, at least for me, has been its ability to identify unnecessary subscriptions. For instance, I discovered three subscriptions that had been silently draining money, including a $19.99 monthly charge for an Adobe account we hadn’t used in ages. Thanks to the app, I was able to cancel those subscriptions and save some cash.

Looking Ahead: Opening the App to the Public

I’m opening the app to the public today! The architecture and technology behind it have been fun to work with, and I plan to share more details in future posts. If you’re a developer, you’ll definitely want to stay tuned — I’ll be discussing some of the more technical aspects, such as handling context window limits in LLMs, ensuring response continuity, and the interplay between Kubernetes and Lambda.

In the meantime, if you’re curious about the product, you can check out the homepage at https://assetsmaven.com.

Stay tuned for more insights and updates as I continue to refine and expand the app. Your financial health might just thank you for it!

Please share this Medium article with others who might be interested in personal finance, app development, or simply keeping a closer eye on their spending. Feedback is always welcome as I continue to improve and iterate on the app.

1. All In. By far one of the most enjoyable podcasts I’ve stumbled upon in 2023 is the All In pod. It’s led by Chamath Palihapitiya, Jason Calacanis, David Sacks & David Friedberg and they “cover all things economic, tech, political, social & poker.” I’ve learned a TON about business, VCs, tech, and enjoyed their political debates (not the ‘debates’ part — each one of them has his own opinion on what’s happening in this world and the conversations are usually very lively and informative).
2. Modern Wisdom. The second-most interesting podcast I’ve started listening to is Modern Wisdom. It’s led by Chris Williamson and he’s doing an excellent job of letting people speak, while asking the right questions to make the pod more interesting and engaging.
3. The AI Breakdown. By far the most informative AI-related pod I’ve listened to. Not sure where the narrator is getting his info or how he’s curating it, but it’s massive.
4. a16z. Interested in the intersection of business and technology? Look no further. I learned a lot abou the current and future trends as well as concerns.

Books

Below are some of the more interesting books I’ve read or listened to.

Blueprint by Nicholas A. Christakis. How are successful societies formed? What are the traits of the failed ones? This book explores these nuances through historical stories and analysis.

The Bomber Mafia by Gladwell. Malcolm Gladwell is one of my favorite authors. He masterfully tells excellent stories, which makes them easy to consume. This book is a good example of that, covering airplanes during WW2.

The Dorito Effect by Mark Schatzker. Want to understand why our food industry is unhealthy? Read this book.

Elon Musk by Walter Isaacson. Wow, what a story!

Conferences

All In Summit. I used to be a huge fan of TED talks but the quality has went down quite significantly so I’m glad that the guys at the All In podcast decided to organize a Summit. Here’s an example of what to expect: Bill Gurley discusses Regulatory Capture and how it’s detrimental to us all.

reInvent 2023 -> Kinda expected, isn’t it? :)

goto: 2023 → Love the GOTO conference. It’s a great forum for tech professionals that love to dive deep and innovate.

Hope you found this useful.

Enjoy and Happy New Year!

1. Address space availability ➡ IPv6-based clusters have SIGNIFICANTLY more available address-space compared to IPv4 ones.
2. NAT (Network Address Translation) Avoidance ➡ Yes, that’s a biggy. IPv6 would allow you to avoid using a NAT and saving your org some 💲. You will still need a NAT if your services need to talk to IPv4 endpoints, but there are plenty of AWS services (and external services) that support IPv6 traffic for you to see cost savings.
3. Future-proofing ➡ The end result is going to be IPv6 so the sooner you make the move (with reasonable tradeoffs, if any) the better.

Steps

VPC

You will need to create a dualstack VPC. Here’s a great resource to follow. Note that you need to enable egress-only IG and no need for a NAT (well, not really, since most likely you will still need to talk to non-IPv6 address and you’ll need one, but at least you won’t need it for all egress). Also, make sure the subnets auto-assign IPv6 addresses:

The last step is for you to add the appropriate tags for EKS to autodiscover the correct subnets:

• kubernetes.io/cluster/<name> tag set to either shared or owned
• kubernetes.io/role/internal-elb tag set to 1 for private subnets
• kubernetes.io/role/elb tag set to 1 for public subnets

Here’s what a sample network diagram would look like:

EKS

The easiest way to provision an EKS cluster is to use eksctl. It’s also the easiest way to add/remove nodegroups and perform EKS-specific tasks.

Here’s a sample IPv6 eksctl yaml declaration:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: main
  region: us-east-1
  version: "1.28"

kubernetesNetworkConfig:
  ipFamily: IPv6 

vpc:
  id: "vpc-XXXXXX"
  subnets:
    private:
      us-east-1a-private: { id: "subnet-XXXXXX1" }
      us-east-1b-private: { id: "subnet-XXXXXX2" }
      us-east-1a-public: { id: "subnet-XXXXXX3" }
      us-east-1b-public: { id: "subnet-XXXXXX4" }

addons:
  - name: vpc-cni
  - name: coredns
  - name: kube-proxy

iam:
  withOIDC: true

managedNodeGroups:
  - name: t3small-ondemand-private
    instanceType: t3.small
    privateNetworking: true
    subnets:
      - us-east-1a-private
      - us-east-1b-private
    ssh:
      allow: false
    minSize: 1
    maxSize: 5
    desiredCapacity: 1
    labels: {role: worker}
    volumeSize: 100
    tags:
      nodegroup-role: worker
    iam:
      withAddonPolicies:
        externalDNS: true
        certManager: true

Note that the ipFamily is IPv6.

ALB (Application Load Balancer)

After you create the appropriate IAM policy and serviceaccount you can deploy your app. But in order for it to be accessible you need an ALB (since you’re deploying your app, hopefully, in a private subnet). Here’s a sample definition for an ingress (btw what I usually do is create an ALB separately via CDK and then reuse it for my apps, but that’s for a different blog post):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myservice
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/ip-address-type: dualstack
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
        - path: /mypath
          pathType: Prefix
          backend:
            service:
              name: my-service
              port:
                number: 8080

Note that the target type is ‘ip’, not the usual ‘instance’ and ip-address-type is dualstack.

That’s it! Enjoy! Let me know if you found this useful.

Next Step: Show how to completely decouple the ALB from the Services to save some $ and reuse it with multiple Services. Stay tuned.

The next part will dive deep into the Lambda code.

You can find the CDK code here: https://github.com/vbudilov/amazon-textract-async-invocation

Enjoy!

This is probably the hardest part for me since I don’t have an iota of what any decent UI expert has — an artistic eye. None-the-less, it’s one of the most important ones. This step makes me think through the functional requirements of the app again, but from the perspective of the user. It’s a reinforcer that solidifies the already-defined use cases and some of the backend designs.

Here you can find a fully-functioning template I just created that will help you get started with ReactJS + Amazon Cognito + AntD. I’m not going to spend too much on this part since there aren’t a lot of architectural decisions to be made here, but I’ll go over the tech stack and some of the screens that I will implement later on.

Tech Stack

At this stage I usually pick my UI tech stack. Here’s what I’ve chosen:

1. ReactJS (notable libs/frameworks: AntD, React-Router, React-Player): ReactJS was created, and is being maintained, by Facebook. It’s a very mature and robust framework that has a very significant following. One of the reasons I like it is the ability to reuse some of my web app code in my React Native mobile apps.
2. Amplify SDK: This is my go-to SDK whenever I need to call AWS services form the UI, and, especially, whenever I need to add authentication to my apps. A long time ago (3 years ago), I created a very simple Angular/Cognito (soon to be deprecated) sample app before the Amazon Cognito service was released to the public. I used the “raw” SDK provided by Cognito, which required a LOT of tinkering and session management. What the Amplify SDK does it simplify this flow by managing the Cognito tokens for you, therefore allowing more time for business logic creation rather than the usual plumbing work you’d do.
3. Amazon Cognito for Auth: I’m a notable fan of Cognito since I worked with it even before it was released. It’s a great service and with the pricing model of 50,000 MAU for free it can go a long way for any startup. Cognito provides for an easy way to
4. Route 53 → CloudFront → S3 (actual place where the Single Page App will live) for hosting and code delivery
5. Lambda function that copies data from Amazon Cognito to DynamoDB

Screens

Remember those initial business requirements in Part 1 of this series? Well now I’m trying ti visually express them. I’m going to skip some screens and steps and concentrate on the main functionality, which is searching and displaying the search results. Here are the screens that I came up with:

Here’s a detailed (albeit very minimal) view of a particular episode.

And here’s what the actual app that I programmed in ReactJS looks like:

Again, here’s the code that you can use out of the box to get started with ReactJS/Cognito. You will see the above screen-shot once you clone the repo and run it locally.

What we have so far

Check out the current version of the app here: https://www.brainyninja.com. Feel free to register and login — I will dive deeper into what’s going on in background once we get to the next step, but for now all you need to know is when you register, Cognito generates 3 JWT tokens for you and sends them back to the browser. There’s also a Lambda function that copied the newly-registered user to a DynamoDB table.

Next Steps

Remember that architecture diagram I shared in Part 1? In this post I chose and setup my hosting and delivery solution, as well as created a fully-functioning scaffold of the future web app. Here’s the part I’ve done:

In Part 4 I will take a major bite out of the backend by setting up the DynamoDB tables, talking about the data formats, and touching upon some aspects of the data flow.

Stay tuned!

P.S.

1. CloudFront — when you deploy a SPA to S3 and front it with CloudFront, you need to make sure that your error pages are setup correctly, otherwise the website users with see an AccessDenied when refreshing your page with a context root other than ‘/’. So here’s what you need to do on the CloudFront side to make react-router handle the actual routing:

2. Don’t overcomplicate your Cognito registration rules. Unless it’s a financial or medical (or the like) application, you don’t want your users to jump through hoops when choosing a password. Just make the rules simple. You can also auto-confirm users using a Lambda trigger. Here’s one I created.

Now that you know what I’ll be doing, and why, let’s get to the “how”. For starters, I’ll be using AWS — it’d be weird if I didn’t, being an AWS Solutions Architect :) Most of the services seen in that diagram are either part of our Serverless stack or completely managed — at the end of the day I don’t want to manage any servers. I’m seeking that durability, scalability, and availability. Let’s go over the services (I’ll dive deeper into the languages, frameworks, and sdks in future blog posts).

AWS Services (from bottom-left, following the arrows)

1. Amazon S3: used for hosting the Single Page Application (SPA)
2. Amazon CloudFront: CDN that will front S3
3. AWS Certificate Manager: certificate management service that will provision the website certificate
4. Amazon Cognito: user directory that will control the authentication and authorization aspects of the web app
5. Amazon Application Load Balancer: will front the Fargate instances
6. Amazon Fargate: fully managed container service
7. Amazon Parameter Store: used for storing secure parameters. This is a great service that allows you to externalize your secure parameters and never running into an issue where you checked in your passwords or access keys into GitHub.
8. Amazon DynamoDB: noSQL database that will be used as the primary data store
9. Amazon Kinesis: Used to copy the DDB data into ElasticSearch. Although DDB is a great noSQL database that is our “source of truth”, it doesn’t provide free-form text search capabilities that ElasticSearch provides out of the box. And since we want to be able to search for podcasts and episodes (and other things that we will discuss later on) we want to use the proper tech for that, which is ElasticSearch in our case.
10. AWS Lambda: functions in the cloud :)
11. Amazon ElasticSearch: it’ll be used for free-form text searching
12. Amazon SQS: multiple uses in this app, including asynchronous data retrieval
13. Amazon CloudWatch: this service has many features that are useful to any app, including logs and a cron-like feature that can kick-off a Lambda function on a consistent, periodic, basis
14. Amazon Transcribe: at some point of the development process I’d want to get the text of the audio or video and make it searchable. This service will allow me to accomplish the goal
15. Amazon Comprehend: to make this search engine smarter than what a regular Elasticsearch query response can provide, I will want to extract additional insights from the text

A video might do this architecture more justice than text, so I created one :)

P.S.

I needed a domain name and came up with BrainyNinja.com — kinda geeky and fun at the same time :) Later on I’ll need to setup a Route53 Hosted Zone to make things simpler with further integrations with Amazon ALB and CloudFront.