JAWS DAYS 2025 Event Report

A report on attending JAWS DAYS 2025 in Tokyo, including the System Architecture Dojo hands-on workshop, TiDB session, and AWS engineer lightning talks.

5 min read

Event Overview

Event Overview
  • Date: March 1, 2025 (Saturday)
  • Venue: Ikebukuro Sunshine City Exhibition Hall A
  • Address: 3-1 Higashi-Ikebukuro, Toshima-ku, Tokyo 170-8630
  • Organizer: JAWS-UG (AWS User Group – Japan)
  • Official website: JAWS DAYS 2025

JAWS DAYS is the largest AWS user community event in Japan, organized by JAWS-UG and supported by Amazon Web Services Japan. Numerous sessions on the latest AWS technologies and implementation cases were available, with a broad audience of engineers, architects, and business professionals attending.

I don’t directly use AWS in my regular work, but I attended to explore its use in side projects and as part of learning cloud technologies. This article summarizes the event atmosphere and sessions that stood out.

Venue Atmosphere

The venue was divided into 6 tracks with quite a spacious layout.

Floor Map

Supporter booths and novelty distribution areas were also very popular, making it a valuable opportunity to gather information about AWS-related companies and services.

Floor View 2 Floor View 3
Floor View 4

Participating in the “System Architecture Dojo”

The most interesting session was the “System Architecture Dojo.”

Session Details

Overview

This session required pre-registration. Participants formed teams and designed system architectures using AWS to solve challenges posed by instructors – a hands-on format. The challenge was “Migrating a fictional aquarium’s on-premises system to AWS.”

Challenge Details (click to expand)

Background

  • The legacy system was on-premises, with hardware maintenance expiring at the end of October 2025.
  • Spike access caused frequent site outages, taking hours to recover.
  • No design documents were delivered, making maintenance and feature additions impossible.
  • Mobile support used separate pages, resulting in high update costs.
  • Cost reduction was urgent (rising feed, electricity, and gas costs).

Business Requirements

  1. Admission Reservation System

    • 15-minute reservation slots, with last entry 1 hour before closing.
    • Reservations open at midnight, 1 month in advance.
    • Contactless entry via QR code (members: My Page, non-members: email).
    • Real-time congestion display and off-peak time recommendations for spike mitigation.

  2. Repeat Visitor Initiatives

    • Fan club member gifts based on visit frequency.
    • Measures to promote weekday pre-reservations.
    • Admin dashboard with visitor analytics (year-over-year, month-over-month, reservation conversion rate).
    • Credit card only payment.

Non-functional Requirements

  • Personal information leak prevention measures.
  • Shark Shine Fan Club members: 900,000, annual visitors: 3 million (2 million with reservations).
  • Access patterns
    • Spike: 6,000 rpm, 1.3 GB/m
    • Normal: 2,100 rpm, 0.5 GB/m
  • External system integration
    • VPN connections with feed suppliers, veterinarians, and souvenir vendors.
    • Supply chain risk and ransomware countermeasures required.

Constraints

  • Operational cost reduction (AWS costs, work hours) is the top priority.
  • Modern architecture following AWS Well-Architected recommended.
  • Non-AWS services allowed but preference for AWS.

Architecture Design Approach

  1. Prototype stage: Security considerations not required.
  2. Design stage: Security considerations included.
  3. Production: Optimize balance between security and service.

Our Team’s Deliverable

After discussion, our team came up with the following architecture:

Our team’s system diagram

Key Design Decisions

  1. Spike Access Mitigation (CloudFront + Lambda)

    • Introduced Amazon CloudFront for request caching.
    • Used AWS Lambda to reduce backend load.
    • Achieved stable processing during spikes through API Gateway integration.

  2. Security Measures

    • Introduced AWS WAF to prevent bots and unauthorized access.
    • Strengthened DDoS protection with AWS Shield.
    • Built authentication infrastructure using Amazon Cognito.
    • Monitored configuration compliance and threats using AWS Config & GuardDuty.

  3. AI Utilization (Bedrock)

    • Introduced AWS Bedrock for a recommendation engine.
    • Suggested optimal visit times based on user behavior data.

  4. Serverless Architecture

    • Adopted DynamoDB for fully managed database operations.
    • Used AWS Lambda for scalability.
    • Utilized Amazon SES for efficient email delivery.

Other Teams

Other teams came up with architectures like these:

Other team's system diagram 1
Other team's system diagram 2
Other team's system diagram 3

The idea of using a queue for spike mitigation was something our team hadn’t thought of, so it was a great learning experience.

Summary

The approach the instructor explained at the end really resonated with me:

  1. Build a prototype without worrying about security
  2. Lock down security thoroughly (consider maintenance paths)
  3. Balance service, security, and cost

Interesting Sessions

The Struggles of Distributed SQL Databases

Session Details

This session at JAWS DAYS 2025 provided a detailed explanation of TiDB’s architecture.

TiDB Overview

As a database supporting both OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing), I was curious about TiDB’s internal structure, and this session gave me the details I wanted.

TiDB Architecture Diagram
TiDB Component Diagram

TiDB uses an architecture where TiDB Server provides the SQL interface, interprets queries, and distributes requests to the distributed storage layer. The storage layer has two types:

  • TiKV (Row-oriented storage): A key-value storage engine for OLTP
  • TiFlash (Column-oriented storage): A columnar storage for OLAP

This design allows users to leverage the optimal storage for their workload.

TiFlash automatically syncs and converts data from TiKV, enabling efficient processing of OLAP queries. This gives TiDB its HTAP (Hybrid Transactional and Analytical Processing) database characteristics, enabling real-time analytics.

Also impressive was the timestamp-based Multi-Version Concurrency Control (MVCC), where TiFlash waits for replication to complete before returning results, maintaining consistency.

The session also covered TiDB’s parser implementation and replication details, deepening my technical understanding.

NewSQL

Looking back at the evolution of NoSQL – from BigTable, Cassandra, and Dynamo – the NewSQL trend has strengthened, and distributed SQL databases like Aurora DSQL and TiDB are now in the spotlight.

This session was presented by someone from PingCAP, the company developing TiDB, and they also had a booth at the venue. Being able to talk directly with them made it a very valuable experience.

While performance tuning and data consistency challenges in distributed SQL databases were highlighted, I’m excited to see how HTAP architectures like TiDB will evolve.

The Annual: AWS Engineers’ Rapid-Fire LTs

Session Details

This session featured AWS cloud support engineers giving 3-minute lightning talks one after another.

Various topics were covered by AWS cloud support engineers in their continuous 3-minute LT session.

Memorable Talks

  • SMS Pumping Attacks A presentation on SMS Pumping attacks (financial damage through SMS abuse) that have been in the news recently, reinforcing the importance of countermeasures.
  • System Prompt Tips Tips on AI prompt engineering. (See attached image below)
  • Latest AWS News Use cases for generative AI with Amazon Bedrock, operational tips for EKS Anywhere, and more.
System Prompt Tips

The fast pace of presentations made it easy to follow.

Other Notes

Sponsor booths had a stamp rally, and I decided to complete the full set. (Got commemorative stickers as a reward.)

Stamp Rally Collected Novelties

I also won a wireless charger in the after-party raffle.

Thank you for the great opportunity.

関連記事