A few years ago, attending AWS re:Invent felt like a distant dream - something only the “real pros” got to experience. I remember seeing posts online, watching keynotes late at night, thinking: Maybe one day, maybe…

Well, that day finally arrived. In 2025, I found myself in Las Vegas, badge around my neck, surrounded by tens of thousands of builders, creators, architects, and dreamers. My first re:Invent wasn’t just a tech conference - it was an emotional, inspiring journey that exceeded everything I imagined.

This article is a reflection of that week. The learning. The energy. The people. The fun.

Key Notes

The Opening Keynote with Matt Garman: AI Everywhere

My re:Invent journey truly kicked off with the Opening Keynote, delivered by Matt Garman, the CEO of AWS. This was my first-ever live keynote at re:Invent, and I have to say, it was massive. The energy in the arena was electric, the room filled with tens of thousands of people, and the production itself felt almost cinematic.

What surprised me most was just how deeply AI was woven into nearly every announcement. Sure, I expected AI to be mentioned - it’s 2025, after all, but this wasn’t subtle. Nearly every new service, enhancement, or capability was either powered by, accelerated by, or tightly integrated with AI. It felt like a clear statement from AWS: AI isn’t a feature anymore. It’s the foundation.

A Special Closing Keynote with Dr. Werner Vogels

The second one - delivered by the legendary Dr. Werner Vogels - was something I’ll never forget. Not only because of the content, but because it was announced as his final re:Invent keynote after 14 years.

Werner has a unique way of speaking directly to the engineer inside you, not just your job title. His keynote wasn’t about features or announcements. It was about who we are as builders, and who we need to become.

The Renaissance Developer (Engineer): Why Now Is Our Renaissance

One of the big messages Werner emphasized is that we’re living in a new Renaissance - a time where multiple technological golden ages overlap: AI, robotics, space, medicine, cloud.

Progress in one field accelerates progress in the others. This creates a cycle where innovation compounds, and developers stand right in the center of it. Just like during the historical Renaissance, what drives this era is curiosity and the willingness to explore across disciplines.

Werner calls this new breed of builder the Renaissance Developer.

Qualities of Renaissance Developer (Engineer):

• Curiosity
• Thinking in Systems
• Communication
• Ownership
• Polymath

Curiosity

Curiosity, Werner says, is the foundation of great engineering. Everything changes all the time. Tools evolve. Paradigms shift. Assumptions break. Curiosity is the only constant that makes us effective.

He described curiosity as the engineer’s instinct to break things apart, understand how they work, challenge assumptions, and never accept the obvious answer.

We are not what we know, but what we are willing to learn. - Walt Whitman

I felt this deeply. re:Invent taught me that being curious is not an optional skill - it’s the heart of being a builder.

Werner spent time reminding us that:

An experiment is not an experiment if you already know the outcome.

Failure isn’t just acceptable - it’s essential.

Whether learning a language, building systems, or using new AI tools:

• Failure teaches behavior.
• Failure reveals assumptions.
• Failure is feedback.
• Failure is how systems expose their truth.

Experimentation drives learning. And learning drives innovation.

Thinking in Systems

Werner explained systems-thinking principles and how small changes ripple through entire architectures.

Systems have lives of their own, shaped by:

• positive feedback loops
• negative feedback loops
• changing structures
• evolving boundaries

Great engineers think beyond a single service or API - they see the larger whole. It’s a mindset shift from my component works to my component influences everything.

Communication

Werner argued that communication is just as important as technical skill.

We must be able to:

• explain our systems
• reduce ambiguity
• speak a shared language with the business
• write specifications
• guide AI tools with clarity

In an age of AI-assisted coding, how we communicate with machines becomes a core skill. And yes - he reminded us that strong communication prevents ambiguity, bugs, and misaligned systems.

Ownership

Werner’s famous principle lives on. And he made it clear: AI doesn’t reduce responsibility. It increases it.

Because:

• AI generates code faster than we can understand it
• hallucinations are real
• design mistakes slip through easily
• verification becomes harder and more critical

Human-in-the-loop review is a non-negotiable mechanism. Tools help, but accountability is ours.

Becoming a Polymath

Werner ended with the idea that the best engineers:

• go deep in their domain
• but are also broad across disciplines

Not everyone needs to be Da Vinci, but everyone should strive to understand the bigger picture.

The balance of depth and breadth makes us flexible, creative, and better system thinkers.

Technical Sessions

Networking and Observability Strategies for Kubernetes (CNS417)

This session immediately caught my attention because it addressed a real challenge I’ve personally struggled with in production environments: unclear or invisible communication paths between pods inside an EKS cluster.

During the talk, the presenters introduced a new EKS feature designed specifically to improve network visibility and traffic observability inside Kubernetes workloads. And honestly - this was exactly the feature I felt was missing.

With this new capability, you can now see:

• How pods communicate with each other
• Traffic flow patterns inside the cluster
• Performance characteristics of workload-to-workload communication

Hassle-Free Multicloud Connectivity with AWS Interconnect (NET205)

Another standout moment for me at re:Invent was attending the NET205 session, where AWS announced one of the most impactful new networking features in years: AWS Interconnect.

This was a huge announcement.

Interconnect introduces a fully managed, extremely simple way to connect AWS with other cloud providers - starting with Google Cloud Platform (and with Azure support planned for 2026). And when I say simple, I mean shockingly simple: with just a few clicks, you can establish a private, secure, high-performance connection between clouds.

The best part? It behaves with the same simplicity and clarity as VPC Peering, but across cloud providers.

No more:

• negotiating with 3rd-party network vendors
• stitching together complex VPN topologies
• maintaining separate connectivity stacks for each cloud

Interconnect abstracts all of that away.

This launch opens the door to real multicloud architectures - not in the marketing sense, but in the operational sense. It suddenly becomes much more feasible to:

• build services across clouds
• replicate workloads for disaster recovery
• migrate or burst capacity between providers
• design architectures where each cloud does what it does best

Deep dive on AWS hybrid and edge networking architectures (HMC315)

One of the more unique sessions I attended was HMC315 – a chalk-talk on AWS hybrid and edge networking architectures. Unlike the larger breakout sessions, this one was much more intimate: no video recording - just architects, a whiteboard, and a room full of engineers asking real-world questions.

Hybrid and edge networking architectures are far from straightforward. Unlike standard VPC or cloud-only networking, the edge brings a completely different set of challenges - latency constraints, limited connectivity, on-prem dependencies, hardware variability, security considerations, and a long list of architectural “gotchas” that you simply don’t experience in pure cloud environments.

The presenters clearly lived and breathed this stuff. They were incredibly knowledgeable, walking us through scenarios that ranged from outposts to local zones architectures.

It felt like sitting in a room with the people who design the systems we rely on. It was only 60 minutes, and honestly, this could have gone on for hours. There was so much value in the Q&A and the shared problem-solving that I would gladly attend a half-day workshop on this topic.

The Art of Managing Trade-Offs for Your AWS Network Design (NET315)

Another session that really stood out for me, and one I personally valued the most, was the NET315 chalk-talk on managing trade-offs in AWS network design. This session dove deep into one of the most fundamental realities of engineering: everything is a trade-off. Performance vs. cost, complexity vs. flexibility, security vs. usability, real-world architectures always come down to choosing the right balance for your specific needs.

What made this talk especially engaging was the interactive format. The audience brought real challenges from real environments, and the discussion quickly became a collaborative exploration of how different teams approach the same problems in completely different ways.

Hearing how other engineers tackle issues like network segmentation, scaling patterns, redundancy models, and traffic visibility provided a whole new perspective. It reminded me that even though we all work with the same AWS building blocks, the solutions can vary widely depending on constraints, business priorities, and organizational maturity.

The presenters were excellent deeply knowledgeable, practical, and able to answer every single question thrown their way. You could tell they had years of hands-on experience and had seen almost every possible design scenario.

Advanced VPC Design and New Capabilities (NET340)

For anyone working with cloud networking, NET340 was essentially a must-attend session. In many ways, it felt like a networking-focused keynote-packed with updates, architectural patterns, design considerations, and a look back at everything AWS Networking introduced or evolved over the past year.

Alexandra and Andrew delivered a fantastic deep dive, walking through both foundational principles and the newest capabilities that are reshaping how we design VPC architectures. Their ability to connect high-level concepts with real operational insights made the session incredibly valuable. You could tell they weren’t just presenting features-they were explaining why these changes matter and how they impact real-world workloads.

Some sessions at re:Invent are optional. This one absolutely wasn’t.

From updated best practices to major service improvements, NET340 served as both a recap and a roadmap for where AWS networking is heading. It’s the kind of session that helps you re-evaluate your existing architectures, question your assumptions, and start planning upgrades or migrations with a deeper understanding of what’s now possible.

AWS KMS Over the Decade - How Architecture Evolved to Earn Customer Trust (SEC218)

Another fascinating session I attended was SEC218, which explored the history and architectural evolution of AWS Key Management Service (KMS) over the past decade. This talk focused less on new features and more on the story of KMS-how it grew, matured, and continuously adapted to meet ever-rising security expectations.

Accelerate Terraform Provider Development Workflows with Kiro (DVT216)

This session included a demo showing how*HashiCorp uses Kiro, AWS’s AI-assisted IDE, in Terraform provider development. Kiro was a recurring theme across many re:Invent sessions, and here the presenters demonstrated its role in automating tasks such as code generation and refactoring. The focus was on practical workflow examples and how Kiro reduces manual effort in provider development.

Networking - connecting with people

While re:Invent is packed with keynotes, sessions, and deep technical content, the most valuable part of the entire week was meeting people. The conference brings together experts, architects, builders, and leaders from all over the world, and the conversations that happen in hallways, lounges, or while waiting for sessions often provide insights you can’t get anywhere else.

Talking with others about their architectures, challenges, successes, and failures offered new perspectives and sparked ideas I wouldn’t have arrived at on my own. These discussions pushed me to think differently and question assumptions, something that s much harder to do when working in isolation.

Almost all of the sessions (with some exception like chalk-talks) eventually show up online, and you can watch the recordings from home. But what you can’t do from home is build real connections, exchange experiences, or learn directly from people facing similar issues in completely different environments. Networking at re:Invent isn’t a side benefit, it’s a core part of the experience. And for me, it’s what made the event truly worth attending in person.

re:Play party

re:Invent would be complete without re:Play, the legendary closing party that brings thousands of cloud professionals together for a night of music, lights, and high-energy celebration.

That Kaskade set was a perfect fit for re:Play’s vibe this year – huge energy, big-room melodic moments. It worked really well at the Las Vegas Festival Grounds layout too, with the visuals and lights making the whole thing feel more like a dedicated EDM festival than a corporate party.

Las Vegas: The Unexpected Bonus

I’ll be honest: I didn’t go to Vegas for Vegas. I went for re:Invent, but the city naturally becomes part of the whole experience.

Between sessions, I wandered around the Strip, grabbed late-night food with other attendees, and got lost inside the Venetian more times than I expected. Las Vegas added its own rhythm to the week.

It also happened to be the week of the National Finals Rodeo, so I took the opportunity to watch the event. I enjoyed the atmosphere and the culture around it, next time I’ll need to show up properly equipped with a hat and boots.

I also set aside time to visit the Grand Canyon, including the Skywalk. Standing on a glass bridge suspended over the canyon is a unique experience, you get a sense of the scale and depth that photos never fully capture. The views from the rim and the Skywalk were impressive, and it was a good break from the intensity of the conference.

Between Grand Canyon West and Hoover Dam, the road cuts through a sparse but beautiful Joshua tree forest, with these alien-looking desert trees scattered across the hillsides on both sides of the highway. It was a completely different vibe from the Strip and even from the canyon itself, and seeing those Joshua trees in the late afternoon light made the whole road trip feel like a classic Southwest adventure.

On the way back, I visited the Hoover Dam, which was equally interesting from an engineering perspective. Seeing the dam up close gives you a better understanding of the scale of the structure and the complexity behind its construction. It was a good complement to a week filled with technical sessions different type of engineering, but just as impressive.