Are you a student? There are Student Builder Groups. An individual contributor looking to grow and connect with other builders? There’s the Community Builders program. Just starting your journey as a speaker? The AWS New Voices program is there to help. And for those who have gone above and beyond in sharing their knowledge and building communities, there’s the Heroes program.

But there’s one program I deliberately left out. Not because it’s less important, but because it’s particularly close to my heart: the User Groups program.

Why? Because it’s different from all the others.

Unlike many AWS community initiatives, User Groups weren’t originally created by AWS. They started organically, driven by passionate individuals who wanted to bring local cloud communities together. AWS eventually recognized their importance and began supporting the people behind them.

And that’s what makes this program so special. It’s built around the people who voluntarily dedicate their time and energy to making communities thrive.

The missing piece: bringing User Group Leaders together

AWS User Group Leaders regularly bring people together in their own cities and countries. They organize meetups, find speakers, book venues, welcome newcomers, and keep their communities alive.

But here’s the funny thing: while they’re busy connecting everyone else, they rarely get the opportunity to connect with each other.

Sure, there’s AWS re:Invent. For many of us, it’s the one time of the year when we get to meet fellow community leaders from around the world. But re:Invent is busy, hectic, and packed with activities. Finding time for meaningful conversations isn’t always easy.

And this is where an idea started to take shape.

How it all started

re:Invent is always the home of major AWS announcements, but for community leaders, it’s also where some of the best ideas are born.

Last year, I heard from Maria Encinar, AWS’s Global User Group Program Manager, that she was planning something special: regional User Group Leaders Summits.

Wow. That sounded amazing!

One of the things I appreciate most about AWS’s approach to its community is that it genuinely encourages feedback and new ideas. You can share your thoughts, propose something different, and sometimes, if you’re lucky, see those ideas become reality.

I decided to give it a try.

Since the goal was to bring community leaders together, I suggested connecting the summit to one of the biggest community events in my region: AWS Community Day CEE.

Why organize another standalone event when we could bring people together around an existing community gathering?

And AWS listened.

In May 2026, I received a message asking whether I’d be interested in partnering with AWS to host the first EMEA User Groups Summit, immediately following AWS Community Day CEE.

Of course!

What an honor.

Being from Budapest, I also loved the opportunity to show our beautiful city to fellow community leaders. For the venue, I proposed the European Youth Centre Budapest, a place that represents European unity, cooperation, and bringing people together.

I couldn’t think of a more fitting location for a gathering like this.

And so, together with AWS, we started planning something that would make history.

EMEA: Making history in Budapest

The result? 45 User Group Leaders from across EMEA came together for the first-ever EMEA User Group Leaders Summit.

For the first time, community leaders from across our region could meet in such numbers without having to cross the Atlantic to do so.

And it wasn’t just another networking event.

It was a day full of conversations, shared experiences, learning, and new connections. We brought together first-time User Group Leaders and seasoned veterans, people running communities of different sizes and facing very different challenges.

Yet we all shared something: the passion for bringing people together.

There were discussions about community building, program updates, exchanging best practices, and, most importantly, getting to know the people behind the groups we usually hear about from afar.

It was a milestone for our community, and I hope it was just the beginning.

If you’d like to get a more detailed perspective on the event from an attendee’s point of view, check out Hennie Francis’s recap.

But the story doesn’t end in Budapest.

Korea: Discovering that we’re more alike than different

I was fortunate enough not only to attend the EMEA summit but also to join the AWSKRUG User Group Leaders Summit 2026 in Seoul, South Korea.

And what an experience that was!

Held on October 24 at D.Camp in Seolleung, the event brought together 31 attendees from across the Korean AWS community.

The format was a little different, but the purpose was the same: bringing the people behind the communities together.

The day started with an introduction to AWSKRUG and its activities, followed by an update from Maria Encinar on the Global User Group program. We also got to hear about the Korean ecosystem, including student activities, individual study groups, and the wider community’s achievements throughout the year.

One particularly interesting aspect was learning how Korean User Groups organize and manage their activities centrally, and how supportive the different groups are of one another.

It was fascinating to see how a community ecosystem can develop in a different country and culture.

But perhaps the biggest takeaway wasn’t the differences.

It was the similarities.

Despite being on opposite sides of the world, we face many of the same challenges. Recruiting volunteers, keeping members engaged, finding speakers, organizing events, and making sure our communities remain welcoming and sustainable.

These are universal challenges for anyone who has ever tried to build a community.

We also had the opportunity to share experiences from other regions. I had the chance to present The Community Flywheel and highlight how AWS User Groups across Europe are driving community growth through their local activities, initiatives, and collaborations, while Raphael Quisumbing, AWS Hero and long-time co-leader of the AWS Philippines User Group, shared his experience from the Philippines.

The day included an icebreaker, quizzes, a fireside chat, brainstorming sessions, networking, and even recorded interviews with the leaders.

And, of course, no great community event is complete without spending time together over food!

What struck me most was how different the conversations were from the ones we usually have at re:Invent. There, everyone is rushing between sessions, meetings, announcements, and activities. At a dedicated User Group Leaders Summit, you finally have the time to sit down, exchange experiences, ask questions, and discuss the challenges that really matter.

That’s something special.

Why these summits matter

You might wonder why we need dedicated events for User Group Leaders in the first place.

After all, aren’t we already meeting at re:Invent? Can’t we just exchange ideas online?

Well, I think these two summits demonstrated exactly why we need them.

Running a User Group means being deeply involved in your local community. You work closely with your co-organizers, members, and speakers, and over time, you develop your own ways of doing things.

But it’s easy to get caught up in your local bubble.

You don’t always know how other communities operate, what challenges they face, or what creative ideas they’re experimenting with elsewhere. You might have found a great solution to a problem that another User Group is still struggling with. Or perhaps another community has developed an approach that you never would have considered.

And that’s exactly why these summits matter.

They give us the opportunity to step outside our local bubbles, exchange experiences, discover new approaches, and learn from people who share the same passion but may have completely different perspectives.

They also remind us that we’re not isolated local communities. We’re part of a much bigger global ecosystem, and we can learn so much from one another.

Sometimes, all it takes is one conversation to spark an idea that can make a difference back home.

Looking ahead: 2026 was just the beginning

One thing I hope is that these summits won’t be a one-time opportunity.

The EMEA and Korean gatherings showed two different ways of bringing User Group Leaders together, but they shared the same underlying idea: the people who build communities deserve a community of their own.

AWS has taken an important step in recognizing this, and I hope we can build on that momentum.

Because at the end of the day, AWS communities aren’t just about technology, presentations, or cloud services.

They’re about people.

And sometimes, the best thing you can do for a community is bring its leaders together.

2026 User Groups Summits

Here are the two summits I was fortunate enough to be part of this year:

• EMEA – Budapest, Hungary: The first EMEA User Group Leaders Summit, held following AWS Community Day CEE, bringing together 45 community leaders.
• Korea – Seoul, South Korea: AWSKRUG Summit 2026, held on October 24 at D.Camp, bringing together 31 members of the Korean AWS community.

Here’s to more opportunities to connect, learn, and build stronger communities together!

A From Local Meetups to Global Connections: The AWS User Groups Summits 2026 bejegyzés először Road to AWS-én jelent meg.

There is no perfect CFP selection process. It’s one of the hardest jobs in event organization, and you’ll only truly understand this when you’re on the other side of the table. As a speaker, you’re left waiting, hoping for that approval email, never knowing what happens behind the scenes or why your carefully crafted proposal might get rejected.

Let me take you inside our selection process for AWS Community Day CEE. Perhaps this transparency will help other Community Days refine their own CFP processes — and maybe give future speakers some insight into what we’re really looking for.

The Foundation: Building Your Selection Team

The most critical decision isn’t your scoring system or evaluation criteria — it’s assembling the right team. Never decide alone or in pairs. The ideal selection team consists of 5-10 people, and diversity isn’t just a nice-to-have — it’s essential for quality decisions.

We ensure at least two women are part of our selection committee. This isn’t tokenism; it’s about recognizing that diverse perspectives lead to better speaker lineups. The more evaluators you have, the clearer picture you’ll get of the top selections, but don’t exceed 10 people — that becomes ineffective and unwieldy.

Our Four-Round Selection Process

Round 0: Setting the Stage

Before any evaluation begins, we prepare the submissions for fair evaluation. We filter out duplicates, spam, and incomplete submissions to focus on legitimate proposals. Personal contact information like email addresses and phone numbers are removed from review materials for GDPR compliance, leaving reviewers with only the essential information: speaker names, talk titles, abstracts, speaker bios, and LinkedIn profiles.

Since we’ve already secured AWS speakers for keynotes and special sessions, we focus our CFP exclusively on community voices for the Main Stage presentation track. This approach ensures we maximize the unique perspectives that make community events special — the real-world experiences, hard-won lessons, and honest insights that complement official AWS content.

Round 1: The Numbers Game

Each reviewer selects their TOP 10 speakers using our point system:

• 1st choice: 12 points
• 2nd choice: 10 points
• 3rd-10th choices: 8, 7, 6, 5, 4, 3, 2, 1 points

Here’s what’s interesting: each voter’s first two submissions count extra, allowing them to significantly influence the top selections. But here’s the surprising part — more than half of our selected speakers never received a single maximum score of 12 points.

We evaluate based on:

• Stage performance ability – Can they actually present well?
• Previous presentation quality – We watch recordings when available
• Content uniqueness – Fresh perspectives win over recycled content
• Regional diversity – Avoiding speakers who’ve recently covered similar ground in CEE

Round 2: The Reality Check

We aggregate scores and handle the messy reality of multiple submissions per speaker. Through majority vote, we select one talk per multi-submission speaker. We ensure topic diversity — because nobody wants a conference that’s 80% GenAI presentations — and identify three backup speakers for the inevitable cancellations.

Round 3: Confirmation Anxiety

Selected speakers get invitations, and we hold our breath. Cancellations happen, and we had two this year — painful for a conference of our size, but you have to adapt.

Round 4: Going Public

The final lineup goes live across awscommunity.eu, Eventbrite, LinkedIn, and our other channels.

What We Learned: The Good, Bad, and Surprising

The Anti-Bias Rule That Works

We implemented a crucial rule: speakers need votes from at least two different evaluators to make it to the final selection. Some submissions received maximum points from just one passionate advocate but were ruled out to prevent bias. This might seem harsh, but it ensures broader appeal.

What Our System Doesn’t Solve

Despite having women on our selection committee, we still struggle with speaker diversity. The pipeline problem is real — we can only select from who applies. Including diverse voices in your selection process helps, but it’s not a magic solution.

Our Honest Mistakes

Multiple Submissions Per Person: We didn’t limit submission numbers, leading to some speakers submitting up to five different abstracts. This diluted their scoring potential and made selection unnecessarily complex.

Workshop Wishful Thinking: We really wanted community workshops, but almost no one chose this category. Speakers come prepared for presentations, not interactive sessions.

Session Length Confusion: Offering 30, 60, and 90-minute sessions (mainly for workshops that didn’t materialize) was a mistake. People can’t focus that long, and you sacrifice having more diverse sessions. Next time: 30 or 45 minutes maximum.

Post-Selection Analysis: Understanding Our Biases

At the end of our process, we ran an AI analysis of our selection patterns. The results were eye-opening:

Reviewer Insights

• Linda Mohamed: Focused on security and advanced architecture
• Lucian Patian: Emphasized serverless and data solutions
• Lydia Delyova: Balanced approach across IoT and infrastructure
• Michal Salenci: Security and AI-focused selections
• Mihaly Balassy: Cost optimization and architecture emphasis
• Philipp Bergsmann: Technical depth and emerging technologies

Quality Indicators

• Strong representation across all AWS service categories
• Balanced mix of theoretical and practical sessions
• Good distribution of foundational to expert-level content
• High proportion of real-world case studies and experiences

The Bottom Line

Our selection process isn’t perfect, but it’s transparent, systematic, and constantly evolving. We prioritize community voices over corporate messaging, diversity over convenience, and real-world insights over marketing polish.

To future speakers: we’re not looking for perfection. We’re looking for authenticity, unique perspectives, and the kind of hard-won wisdom that only comes from actually building things in production. Your war stories, your failures, your “here’s what nobody tells you” moments — that’s what makes community conferences special.

To fellow organizers: steal whatever works from our process, but remember — the system is only as good as the people implementing it. Invest in your selection team, be transparent about your criteria, and don’t be afraid to evolve your process based on what you learn.

The CFP selection process will always be imperfect, but with the right approach, it can be fair, effective, and focused on what really matters: delivering exceptional value to the AWS community.

A Behind the Scenes: CFP Selection for AWS Community Day CEE bejegyzés először Road to AWS-én jelent meg.

I recently wondered: could modern AI technology resurrect websites that aren’t preserved in the Internet Archive but exist as screenshots in publications like Internet Magazine? To explore this possibility, I turned to Amazon’s newest AI offering.

Introducing Amazon Nova

Amazon Nova represents a new generation of foundation models offering advanced intelligence with competitive pricing. Working through Amazon Bedrock, these models can generate text, code, and process images using natural language prompts. For my experiment, I focused on the three models with text and vision capabilities: Nova Lite 1.0, Nova Pro 1.0, and Nova Premier 1.0.

The Experiment: Recreating a Website from an Image

First Attempt

My initial prompt was straightforward: “Create a static HTML page from the provided image“

• Amazon Nova Lite: The most basic result — simply creating HTML that displayed the provided image.
• Amazon Nova Pro: This model correctly identified the website displayed within Internet Explorer and focused solely on the website content (ignoring the browser elements). It created functional HTML, though I needed to increase the default response length beyond 512 tokens to get complete code. While it successfully mimicked the website structure, it didn’t preserve the original colors and failed to recognize the frame-based design that was prevalent during that era.

• Amazon Nova Premier: This model showed more sophistication, recognizing the yellow background on the left side and implementing it in the recreation. However, like Nova Pro, it still missed the iFrame structure that was common in websites of that period.

Refining the Recreation

When I specifically asked, “Can you use iFrames?“, Nova correctly separated the website into the appropriate frame structure, providing three source files: index.html, content.html, and sidebar.html.

Taking modernization a step further with “Can you separate the CSS from the HTML?“, Nova produced clean, contemporary code with proper separation: index.html, content.html, sidebar.html, and styles.css.

This process effectively translated the old HTML 3/4 website into HTML5-compatible code accessible to modern browsers.

Working with Archived Content

I wanted to see how Nova would perform when provided with actual source code rather than just an image. To test this, I went to the Wayback Machine and retrieved a preserved 1996 version of the AltaVista search engine homepage.

Using the prompt: “Create a full copy of this website: https://web.archive.org/web/19961222232126/http://www.altavista.digital.com/“, I asked Nova to recreate the site from the archived URL.

Nova Premier produced a reasonable facsimile but candidly acknowledged its limitations: “This example captures the basic layout and style of the AltaVista homepage from 1996. However, it’s a simplified version and lacks many details, images, and functionalities present in the original site.”

Interestingly, Nova’s approach to working with actual source code versus just an image didn’t yield dramatically different results in terms of accuracy. The model still created a simplified interpretation rather than an exact replica, suggesting that Nova’s current design philosophy prioritizes approximation over perfect replication regardless of input format.

Safety Considerations

It’s worth noting that the current version appears intentionally designed not to create exact replicas of websites, which prevents potential abuse for phishing or impersonation. This limitation serves as an important safeguard.

Conclusion

While Nova Lite proved too basic for complex website recreation, both Nova Pro and Premier demonstrated impressive image analysis capabilities, distinguishing between content and browser elements with remarkably accurate OCR recognition even with low-quality images. Premier particularly excelled in color recognition and produced more accurate website recreations.

Amazon Nova models show tremendous potential for reconstructing website content from images — a valuable capability for digital preservation and historical research. These models process images exceptionally well, making them useful in scenarios where only visual references remain of digital content.

A Bringing ’90s Web Back to Life: Exploring Amazon Nova’s Website Recreation Abilities bejegyzés először Road to AWS-én jelent meg.

From Inspiration to Action

Upon returning from Stockholm, I began organizing the joint community. After researching existing groups, I noted successful regional collaborations like AWS Community DACH (covering Germany, Austria and Switzerland), the Nordics (encompassing Sweden, Finland, Norway, and Denmark), and Adria (covering Adriatic countries). Central and Eastern European countries clearly lacked this type of collaboration.

Assembling the Team

A good idea attracts strong partners naturally. I immediately reached out to my friends from Slovakia (Michael Salenci, Lydia Delyova) and Romania (Lucian Patian), who enthusiastically joined. It became evident that a joint organization would benefit our region tremendously. Michal helped bring Linda onboard – one of the region’s most active community members and an AWS Hero who also serves as the chairwoman of AWS Community DACH, bringing valuable expertise. Paula Kis, Oleksii Bebyc, Traian Ciobanu and Urban Jurca also happily accepted my invitation. Our community now includes six member countries: Austria , Croatia , Moldova , Romania , Slovenia , Slovakia , Hungary , and Ukraine .

Identity and Branding

Finding the right name proved challenging. I initially considered “AWS Community Danubian” but questioned whether we could effectively manage such a vast region, especially with potential overlaps with Adria and DACH. During the ExecLeaders dinner, I discussed this with Piotr Gralec, an AWS sales representative with extensive regional knowledge, who recommended sticking with “AWS Community CEE” – an advice I gladly accepted.

Inaugural Community Day Event

What better way to introduce our community than with a joint Community Day? My vision is to host AWS Community Day CEE in a different participating country each year. While I was open to any location, everyone suggested Budapest, Hungary for our inaugural event. Although organizing an event at this scale is a considerable challenge, I’m thankful that I can draw upon the experience and lessons learned from previous local Community Days to make it successful.

I am happy to announce that AWS Community Day CEE will take place in Budapest on Thursday, October 16. I’ve already secured an impressive lineup of speakers, including Massimo Re Ferre (Director of Product Management in Next Generation Developer Experience) and Maria Encinar (Global User Group Manager for AWS). This promises to be an exceptional event, and we welcome everyone to participate. Visit awscommunity.eu for more information.

I’m delighted to see this regional community come to life. I’ve always believed in the power of collaboration and am thankful to the regional User Group Leaders supporting this initiative.

A AWS Community CEE: A Regional Collaboration Takes Shape bejegyzés először Road to AWS-én jelent meg.

For those of you attending re:Invent for the first time, as I am, navigating a conference of this scale can be overwhelming. After extensive research and valuable advice from experienced Community Builders like Pubudu Jayawardana and Niklas Westerstråhle, I’ve put together this guide to help fellow attendees make the most of their re:Invent experience.

Registration

It all starts with registering for the conference. The earlier you do it, the more options you have. Registration typically opens around June, giving you ample time to book airfare and accommodations. One tip I learned the hard way: exhibitors at the expo may scan your badge, which can lead to a flood of newsletters. To avoid this, I recommend registering with a dedicated email or tagging your re:Invent emails. For example, if you use Google, registering with something like “misi+reinvent2024@roadtoaws.com” will apply a “reinvent2024” tag to all relevant messages.

Stay

Before booking your flight and accommodation, decide how long you plan to stay. Although re:Invent spans the entire week, most major sessions happen between Tuesday and Thursday, with Friday primarily reserved for repeats. If you stay until Friday, you may have better luck getting into reserved sessions as many attendees head home. However, if your schedule is tight, a two- to three-day stay will cover the key events and announcements.

Flights

After registration, you may find discounted airfare. This year, AWS is partnering with Delta Airlines for exclusive discounts, but I’ve found using flight comparison tools like Momondo offers the best deals. Having tracked flights from Budapest to Las Vegas since June, I noticed prices stay stable through September, with a noticeable increase in October. Be mindful of time differences—Budapest is nine hours ahead of Las Vegas, so jet lag can be intense. Avoid booking any sessions immediately after landing, as adjusting to the time zone takes a while.

Accommodation

AWS partners with several hotels near the conference venues offering discounts, though note that these bookings often don’t allow free cancellations. If flexibility is important, booking through platforms like Booking.com or Expedia can provide more options, including free cancellation periods.
The Venetian serves as the conference’s hub, hosting key events and the expo, while the nearby Wynn and Encore hotels are also popular options ($269 and $279 per night, respectively). For a more affordable alternative, I recommend Treasure Island, which is only half the price ($133/night) and located conveniently close to The Venetian. Keep in mind that navigating from one hotel to another can take longer than expected due to the sheer size of the event and the Strip—be prepared for a lot of walking!

Weather

Las Vegas in December has a daily temperature range from 4°C (39°F) to 15°C (58°F). Mornings and evenings can be cold, sometimes dropping to freezing, while afternoons are relatively mild. As Las Vegas is a desert city, staying hydrated is essential. Bring plenty of water and comfortable layers.

Local Transport

Getting from the airport to your hotel or the event can be done by bus, carpool, or taxi. If you’re staying near the south end of the Strip, ridesharing services are often the cheapest and quickest option, though traffic can sometimes be a problem. Taxis from the airport have a fixed rate to the Strip, and be prepared to pay a $3 surcharge if paying by card. Lines for rideshares like Uber or Lyft can also be long, so sometimes taxis are faster. Budget-conscious attendees can opt for buses, but note that routes can change—such as the CX bus now stopping at Flamingo rather than New York New York.

Re:Invent spans multiple venues along the Strip, so travel time between sessions can add up. re:Invent shuttle buses run frequently, but they can be delayed by traffic. For faster options, consider using the Las Vegas Monorail, which connects key venues, including Harrah’s, The LINQ, MGM Grand, and the SAHARA (re:Play party). For sessions at Mandalay Bay, the free tram from Excalibur is a convenient option.

Food at re:Invent

Complimentary breakfast is served daily from Monday to Friday between 6:30 AM and 8:30 AM, with Friday’s breakfast located at Caesars Forum and The Venetian. Free lunch is available from Monday to Thursday between 11:00 AM and 1:00 PM. Based on my experience at the Stockholm Summit, I recommend grabbing lunch early, as food can run out if attendees take extra portions. If you want to dine well, heading to a restaurant or one of the partner-organized events is a better option.

Expo

The Expo Hall opens Monday afternoon and runs through Thursday, offering opportunities to network with partners and pick up some swag. If you want to avoid the crowds, try going in the early mornings. The Expo is also where you’ll find Lightning talks, which offer quick 20-minute presentations on customer stories and product demos.

Sessions

Organizing your session schedule is critical, especially if you’re trying to make the most of the week. For this task, I recommend my fellow speaker, Raphael Manke’s Unofficial AWS re:Invent Session Planner 2024. Reserved seating opens on October 8, and you’ll need to act fast. Here’s a quick breakdown of the session types:

• Keynote: Major announcements happen here, but it’s challenging to secure a good seat. Many veterans leave 15 minutes early to avoid the post-event rush.
• Breakout sessions: These are 1-hour, non-interactive presentations that are recorded. While interesting, many attendees skip them to focus on live sessions.
• Builders’ sessions: Hands-on sessions in small groups. These are repeated throughout the week, so staying until Friday can increase your chances of participating.
• Chalk talks: Highly interactive 1-hour discussions that begin with a lecture and conclude with Q&A. These are not recorded, making them popular among experienced attendees.
• Code talks: Technical sessions at level 300 and above, focused on deep coding topics. Attendees are encouraged to ask questions.
• Lightning talks: Short, 20-minute presentations held in the Expo Hall.
• Workshops: Guided, hands-on labs to build solutions. Time constraints often limit how deeply you can explore the topics.

Health & Safety

With thousands of people attending re:Invent from all over the world, the chances of catching a virus increase. Bring hand sanitizer, consider wearing a mask, and wash your hands regularly to stay healthy during and after the event.

Key Takeaways

• Register with a dedicated or tagged email to manage incoming messages
• Bring hand sanitizer and a mask to reduce the risk of illness
• Avoid scheduling back-to-back sessions at different venues—travel time can be significant
• Pack comfortable shoes; you’ll be doing a lot of walking
• Carry a battery pack as outlets are hard to come by. Wi-Fi can be unreliable, so consider getting a good data plan
• Have cash on hand, as taxis prefer it, and withdrawing from casino ATMs can be expensive

Enjoy your stay at re:Invent and don’t forget to say hello!

A Navigating AWS re:Invent 2024: A First-Time Speaker’s Guide bejegyzés először Road to AWS-én jelent meg.

Amazon Bedrock is available in 13 AWS regions:

• US East (N. Virginia)
• US West (Oregon)
• Asia Pacific (Tokyo)
• Asia Pacific (Singapore – limited access)
• Asia Pacific (Sydney)
• Asia Pacific (Mumbai)
• Canada (Central)
• Europe (London)
• Europe (Frankfurt)
• Europe (Paris)
• Europe (Ireland – limited access)
• South America (São Paulo)
• AWS GovCloud (US-West)

Note: Due to limited access in Ireland, Singapore and GovCloud, these regions are excluded from my analysis, leaving us with 10 regions for comparison.

Anthropic uses "Haiku" for its smallest model, "Sonnet" for the mid-range option, and "Opus" for its top-tier model.

On June 21, 2024, Anthropic introduced Claude 3.5 Sonnet, claiming it can match or exceed OpenAI's GPT-4o or Google's Gemini across numerous tasks. This new model is exclusively available through the Anthropic API, Amazon Bedrock, and Google Cloud's Vertex AI. Since this is a new model, it is currently only available from us-east-1 at the time of this blog post.

When it comes to Amazon Bedrock, the rule of thumb you've come to know about AWS pricing and service availability no longer applies. If you are based in Europe, you have learned that the region with the most services is Ireland (eu-west-1) and that the cheapest option is usually Stockholm (eu-north-1).
With Bedrock, this all changes; the region that offer the most Anthropic FM's for Europe is Frankfurt (eu-central-1). If you're developing with Generative AI in Europe, Frankfurt is now your best choice.
In the US, your rule of thumb remains the same, with us-east-1 being the region that provides the most functionality, but there is a catch: the highest-end model, Claude 3 Opus is only available in Oregon.

Amazon Bedrock's on-demand and batch pricing is consistent across regions (e.g., you pay the same for Claude 3 Haiku in Oregon and Canada). In fact, Claude Sonnet 3 and 3.5 cost the same. This uniform pricing strategy underscores AWS's commitment to making advanced Generative AI models accessible and affordable for developers.

Provisioned Throughput pricing

When we look at the provisioned throughput pricing, we see fewer choices. We are limited to Claude Instant and Claude 2.0/2.1 models and with only 4 regions. Frankfurt is right behind the top US regions in terms of prices, with Tokyo being the most expensive.

Summary

AWS demonstrates its strong commitment to Generative AI through multiple actions. It offers competitive pricing for Anthropic's foundation models, continually expands Bedrock's availability to new regions, and promptly makes the latest foundation models accessible to its users.

These efforts highlight AWS's dedication to advancing and supporting Generative AI, providing developers with the latest tools at affordable prices.

A Amazon Bedrock – Consistent Anthropic FM pricing across regions bejegyzés először Road to AWS-én jelent meg.

One of the biggest disadvantages of Lightsail over EC2 is that you cannot easily change your instance type. Currently, there is no one-click option to switch from a 512 MB memory bundle to a 1 GB memory bundle. AWS is aware of this issue and is working on a solution that will allow you to upgrade to a larger bundle in the future. Until then, we have to do it the hard way.

How do I get 1 vCPU for free?

Previously, the cheaper Lightsail bundles only offered 1 vCPU. This was because the underlying t2 instances had 1 vCPU options. Now that AWS Lightsail has moved to the new t3 instance family, there are no 1 vCPU options, only 2 vCPU’s. While there has been a change under the hood, AWS has maintained its Lightsail pricing, so you get an additional free vCPU when you move to the t3 instance family.

Upgrading a Lightsail instance

To upgrade your Lightsail instance, you must create a manual snapshot. Under Snapshots, click Create Snapshot and give your snapshot a name. Creating a snapshot takes time, so be patient while your snapshot is being created.

While the snapshot is being created, go to the Networking tab, and if you have an IPv4 address, be sure to click Create static IP. This will allow you to keep your current public IPv4 address. Unfortunately, there is no option to keep your IPv6 address, so you will need to update your DNS settings in the future.

Under IPv4 firewall, make a note or a screenshot of your firewall rules, as they won’t be migrated either. If you have IPv6 networking, do the same for these rules as well, since you may have different IPv4 and IPv6 firewall rules.

By now, your snapshot has probably been created. Select Snapshots from the left menu and you will see your newly created snapshot. Click on the three dots and select Create New Instance. Here you can select an IPv6 bundle if you don’t need a public IPv4 address or the new 2vCPU options. There is only one restriction. You cannot select a lower bundle that you already have.

Note that Lightsail instance names are unique, so you cannot name your new instance the same as your previous instance (and there is no option to change the instance name in the future). I added www. in front of my instance.

Now that your new instance is up and running, first detach your IPv4 address from your old instance and attach it to your new. Also, enter your firewall rules that you saved earlier.

Do not forget to update your DNS settings with your new IPv6 public address. Stop your old instance and test your new instance.

Cleanup

Once you have verified that the new instance is fully functional, you can perform a manual cleanup. First, go to Snapshots and delete the snapshot you created for the upgrade. AWS charges $0.05 USD GB/mo for snapshots, so if you don’t need it, just delete it. You will also need to manually delete the old instance.

Amazon Lightsail is the easiest way to get started with AWS, upgrading your instance is not. While AWS implements this feature, you must manually upgrade your Lightsail instance.

A Upgrading Amazon Lightsail instance bundles – get an additional vCPU for free bejegyzés először Road to AWS-én jelent meg.

I saw a video on YouTube about how to make your business card smart with a simple NFC sticker. The problem is that while you can program a vCard into a sticker, iOS devices don’t support them yet. The only way to get an iPhone to read an NFC vCard is to host the vCard file on the web. Then it hit me. Why not host the vCard on AWS using only free tier resources.

The obvious solution was Lambda and Lambda Function URLs since they are completely free. Plus, you can be sure that AWS will still be around in 5 or 10 years, so your digital business card will still be running.
Also, it’s very easy to update your information if something changes, you don’t have to buy a new one. Which is good for the environment too!

During development I ran into issues that required creating extra policies to make it work. Since I wanted to make it as simple as possible for everyone to use it I created a CloudFormation template that creates all the resources for you.
And when you no longer need it, CloudFormation can delete all the used resources. But why would you do that when it’s completely free.

The code is written in Node.js 18.x and produces a v. 3.0 vCard. You might ask why not v. 4.0 and the answer is simple. Apple doesn’t support it and I wanted to make it as compatible as possible.
The other problem I faced is that according to the vCard specifications you can link an image URL as your photo, but Apple devices don’t support that either. The photo should be Base64 encoded in your vCard.
That is why CloudFormation creates an S3 bucket where you can store your photo (avatar.jpeg) and the Lambda function will convert it to Base64 and include it in your card.

Not just Apple, AWS has some weird things too. For example, when you create a FunctionURL for your Lambda function, this URL is not defined in your Lambda environment variable. To get the FunctionURL, you need to grant the GetFunctionUrlConfig role to read your function URL. Since a vCard allows you to define the source of the vCard where you can always get the latest version, I had to create a policy and attach it to the Lambda role to include the FunctionURL in the vCard.

The other issue I faced is that while you can include your Lambda code in CloudFormation, it creates an index.js file instead of an index.mjs which is required for Node.js 18.x. There is a solution to include the code in an S3 bucket and CloudFormation will retrieve the code from there, but then you are stuck with the region where your S3 bucket is. So I created two CloudFormation templates.
If you want the easiest installation and don’t want to change your region, use the default template. This will run in US East (N. Virginia). If you want to host your business card in another region, use the template-with-code.yaml instead, but you will need to rename index.js to index.mjs for the code to work.

All the source code is available on GitHub under the Apache 2.0 license. See the GitHub page for detailed installation information.
Use template.yaml if you want the simplest installation.
If you want to specify the region in which the resources are created, use the template-with-code.yaml stack instead and rename the index.js source file to index.mjs.

I hope this little code is as useful as it was fun to write it.

A Free and easy DIY digital business card bejegyzés először Road to AWS-én jelent meg.

I chose Mastodon as my primary platform because it is the most popular of all. You may choose otherwise, as these networks can communicate seamlessly with each other no matter what server you are running.

Twitter (now: X) as a commercial company has the right to restrict or commercialize its API, which can be a struggle for startups or small developers. Mastodon is not only free and open source, but also much more developer friendly. One such feature is the support of bot accounts. You are not limited at these accounts, in fact you are encouraged to use them. In Mastodon, you can specifically mark if an account is a bot, making it more transparent to everyone.

The first step is always the hardest, choosing your Mastodon server. There are many to choose from, some are for specific communities, some are geographically restricted. If you are unsure, just stick with the oldest: mastodon.social.

Create an account here and check the This is an automated account box under your profile. This will let others know that this is a bot account. Under Development, create a new application and select the appropriate permissions. Since my bot will only publish, I only selected write:statuses.

In a previous blog post I created a website for Hungarian tech conferences. I will use this as my input source. Currently this site doesn’t offer an easy way to export information, so I modified the Jekyll code to generate a CSV file for the upcoming events. This way I can parse the data more easily.

The Serverless Approach

From the title of this post, you have probably guessed that I am going to take a serverless approach. I don’t want to deal with security updates and patches. I just want this bot to work with very little maintenance.

Tip: Choose arm64 as your Lambda architecture because it is cheaper to run.

There are a handful of API clients for Mastodon to choose from. Since I will be using Node.js 18.x for the runtime, I wanted to find one that was compatible with it. My choice was Masto.js, which is maintained quite frequently and supports most of the Mastodon API features.

To download CSV data from techconf.hu, I will use Axios as in my previous projects. As for parsing CSV data my choice was csv-parse (watch out there are multiple CSV parsers out there, some names may only be different with a hyphen). I then created separate Layers for each function and attached it to my Lambda function.

Making it all work

The code is pretty simple. First I download the CSV file and parse it with csv-parse. Then I set up the Toot (Mastodon’s phrase for Tweet) and publish it with Masto.js.

One problem I faced is that in Mastodon every Toot has a language variable. If you don’t set it specifically, it defaults to the one set in your Mastodon account.

Tip: Since the Fediverse is so decentralized, it is a good idea to tag all your posts.

import { parse } from 'csv-parse';
import { login } from 'masto';
import axios from 'axios';

export const handler = async(event) => {
    var tweet = "Upcoming Hungarian Tech Conferences 🇭🇺\n\n";
    var conferencesThisWeek = false;
    const currentDate = new Date();
    const endOfWeek = new Date(new Date().setDate(new Date().getDate() + 7));
    currentDate.setHours(0,0,0,0);
    endOfWeek.setHours(0,0,0,0);
    var conferenceDate;
    var csv;
    
    await axios({
        url: 'https://techconf.hu/conferences.csv',
        method: 'GET',
        responseType: 'blob'
    }).then((response) => {
        csv = response.data;
    });
    
    const parser = parse(csv, {
        delimiter: ",",
        from_line: 2
    });
    
    for await (const record of parser) {
        conferenceDate = new Date(record[3]);
        if (currentDate <= conferenceDate && conferenceDate <= endOfWeek) {
            tweet += '👉 ' +record[0] + ' (' + record[2] + ')\n📅 ' + record[3] + ' - ' + record[4] + '\n🔗 ' + record[1] + '\n\n';
            conferencesThisWeek = true;
        }
    }
    
    if (conferencesThisWeek) {
        tweet += '#Hungary #Technology #Conference';
        
        const masto = await login({
            url: 'https://mastodon.social/api/v1/',
            accessToken: ''
        });
    
        await masto.v1.statuses.create({
            status: tweet,
            visibility: 'public',
            language: 'en'
        });
    }
    
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Scheduling

The easiest way to schedule a Lambda function is to use the Amazon EventBridge Scheduler. Simply select your schedule pattern and the Lambda function as the target, and it will execute your code at the given time.

Final Thoughts

Did I mention the best part? This is all free. The services I used are all covered by the AWS Free Tier (as of this writing).

Feel free to create similar bots or improve my code or just follow my bot at: https://mastodon.social/@techconf

A Creating a Serverless Mastodon Bot bejegyzés először Road to AWS-én jelent meg.

I was looking for a solution that was open source and that anyone could contribute to it. While discussing this issue with María Encinar (EMEA Community Programs Manager
– AWS), it turned out that other European countries are facing similar problems and there is also a trend on these conference websites. She recommended me this GitHub repository.
As far as I could track it down it all started with Android Study Group, which created a GitHub Page for Android conferences. Spain, Portugal, Italy and even Canada soon followed. I realized right away that I am on the right track. The source code is open source, hosted on GitHub and anyone can contribute to it with a simple Pull request. This was a great foundation, but I knew I wanted more.

Hungarian translation

The main problem we face here in Hungary is that while there are a lot of events happening here, some are primarily in English. For someone who is just starting with AWS, this could be an extra challenge that they might not take. That is why my first improvement was to translate the interface into Hungarian. I didn’t want to exclude English speakers as well, so I made the interface bilingual. This way everyone can feel comfortable on the website.

The other improvement I made is that I clearly highlighted the language of the conference. This way I can help people who prefer content in their native language.

Deployment on AWS

I cannot ignore the fact that I am an AWS Community Builder, so it was a no-brainer that I would implement this on AWS. Registering a domain and setting it up on Route 53 was the first step. Then I looked at the possibilities of hosting. The site is written in Jeklly and each page is generated separately. Using GitHub Actions, I can regenerate the static pages every time there is a new commit.
Hosting a static website on AWS isn’t rocket science. S3 static file hosting is a cheap and easy way. I just needed to find a way how to publish my files to S3. Jake Jarvis created a GitHub Action that can sync your files to S3. All you have to do is to create the appropriate IAM permissions and your files will be pushed to the S3 bucket of your choice. From there, AWS will do the rest. I have created a CloudFront distribution to get HTTPS and fast access from Hungary. Currently, there is no AWS region in Hungary, but there is an edge location in Budapest, so serving the site from there gives fast access to Hungarian users.

The outcome

The result is techconf.hu, a community-curated list of tech conferences around Hungary. I sincerely hope that this project will benefit the Hungarian AWS community, and perhaps other countries facing similar issues will follow. Happy Conferencing!

A Bringing together Hungarian technology conferences bejegyzés először Road to AWS-én jelent meg.