AWS re:Invent 2026 · Las Vegas · November 30 – December 4

Every year I watch the same thing happen. Thousands of people fly into Las Vegas, badge up, and sprint between keynotes and sessions with a notebook full of service names they've never heard of, absorbing announcements against a mental model of their own environment that's six months stale. They come home with a list of things that "sounded cool" and no clear sense of which ones actually solve a problem they have.

This is my tenth consecutive re:Invent, and I've learned that the single highest-leverage thing you can do happens before you get on the plane: take an honest inventory of your own AWS estate. Do that, and the firehose of announcements stops being noise. Every launch, hands-on lab, builder talk, and hallway conversation lands against a real gap you already know you have: "that fixes our cross-region recovery problem" instead of "that looks interesting."

So before you build your session agenda, work through these six checks. I've mapped the most relevant ones to real sessions in the live 2026 catalog so you can turn "I should look into that" into a seat on your calendar.

A 2026 logistics note before we start: The reservation system changed this year. Reserved seating opened October 6, and in 2026 only interactive sessions take reservations: workshops, chalk talks, builders' sessions, and code talks. Keynotes and lecture-style breakouts are walk-up. So the sessions you'll want to reserve off this list are the chalk talks and workshops; for the big breakout rooms, just show up early.

1. Resource inventory: know what you're running

You can't assess an estate you can't see. Before anything else, generate a current, authoritative inventory of what exists across every account and region. Most teams are surprised by the orphaned resources, forgotten test environments, and "temporary" infrastructure that's been running longer than intended.

What to check: A complete resource list across all accounts/regions, owners mapped to each workload, and anything you can't explain. If you find resources nobody can account for, that's your first finding.

2. Backup and disaster recovery gaps: how much confidence do you have in recovery?

This is the one most teams quietly skip, and it's the one that ends careers when it goes wrong. Before re:Invent, pressure-test your real recovery posture: not the runbook you wrote, but the one you've actually tested. Do you have defined RTO and RPO targets per workload? Have you tested failover this year? Where are the single points of failure you've been meaning to address?

DR and resilience get strong coverage every year, and the 2026 catalog is no exception.

Sessions to put on your list:

• DAT409, Building globally distributed applications with DynamoDB global tables (Mon Nov 30). Directly addresses architecting for availability across failure modes from single-AZ to full-region, composing global tables, multi-region strong consistency, and backup/restore into patterns that meet strict RTO/RPO objectives, drawn from recent large-scale events.
• Search the catalog for ARC (architecture) and resilience-tagged sessions to round out your DR track.

What to check: Documented RTO/RPO per critical workload, date of your last tested failover, backup coverage and restore validation, and your single points of failure.

3. Security and compliance exposure: what would an auditor find today?

You don't need a full audit before re:Invent, but you should know your exposure: public-facing resources you didn't intend, over-permissioned IAM roles, unencrypted data stores, and where you stand against the frameworks you're held to (SOC 2, PCI DSS, etc.). The gap between "the scanner passed" and "the auditor is satisfied" is exactly where a lot of real risk hides.

Sessions to put on your list:

• COM302, The judgment gap: when Terraform scans clean but fails the audit (Mon Nov 30, community track). A genuinely useful framing of where automated scanners stop and human judgment has to take over on controls like SOC 2 CC6.1.
• SEC430, Multi-tenant isolation with IAM: ABAC, session tags, and token vending machines (Thu Dec 3) if you run multi-tenant SaaS.

What to check: Public exposure, IAM over-permissioning, encryption at rest/in transit, and your standing against required compliance frameworks.

4. Governance at scale: can you enforce standards across the whole estate?

This is where the operational discipline lives, the altitude a cloud leader should fly at before re:Invent. Governance at scale is only as good as the metadata it runs on: you can't allocate a cost, scope a permission, or automate a guardrail against resources you can't reliably identify, so consistent, enforced tagging is the substrate everything below depends on. The mature teams I work with treat that as table stakes; for everyone else, the real question is whether your standards are enforced (through SCPs, Config rules, and tag policies) or merely documented. Three things to assess against that bar:

Cost and rightsizing posture. Don't walk into the FinOps sessions cold. Know your top cost drivers, your Savings Plan / Reserved Instance coverage and expirations, and your most obviously oversized or idle resources. The cost sessions land far harder when you're pattern-matching against a bill you've already studied.

Account and region sprawl. Each extra account and active region widens your security surface, cost footprint, and operational overhead. Know your account count and structure, which regions you're genuinely active in, and whether guardrails (SCPs, baseline Config) are consistent across all of them.

Legacy and licensing debt. The commercial database licenses you could migrate off, the VMware-era workloads waiting to be modernized, the EOL operating systems, slow-burn costs that are exactly what re:Invent announcements tend to address. Know what you're still paying for and what's flagged for modernization.

What to check: Your top cost drivers and Savings Plan / RI coverage and expiration dates, your account count and active region list, whether guardrails are consistent across all of them, and what legacy licensing and EOL workloads you're still paying for.

5. Observability and operational readiness: can you see inside what you run?

When something breaks at 2 a.m., what's your actual visibility? Before re:Invent, assess whether your monitoring, logging, and alerting would actually let you diagnose a real incident, or whether you'd be flying blind. This matters more than ever as teams add AI agents and distributed systems whose failures don't show up as clean exceptions.

Sessions to put on your list:

• COM304, Hidden trade-offs in distributed architectures (Wed Dec 2, community track). A real-world case study on the consistency, latency, and failure-handling trade-offs that diagrams never show you.

What to check: Alerting coverage for critical paths, log retention and searchability, dashboard coverage, and your mean-time-to-diagnose on recent incidents.

6. AI and data readiness: is your house ready for what's coming?

It's safe to predict that AI agents and the data/governance substrate underneath them will dominate re:Invent 2026: in the catalog, nearly every other session title contains the word "agent". The question to answer before you go isn't "should we do AI"; it's "is our data governed, our access controlled, and our platform ready to support agentic workloads safely?" Know where you stand so the agent-heavy agenda maps onto a real readiness gap rather than hype.

Sessions to put on your list:

• DAT443, Context engineering for agents: memory, SQL, knowledge graphs & skills (Mon Nov 30).
• SEC407, Implement governance guardrails for autonomous AI agents at scale (Tue Dec 1): scoped IAM roles, Guardrails enforcement, and Cedar-based policy for agent workloads.

What to check: Data governance and catalog maturity, access controls on sensitive data, and whether you have a point of view on where agents fit in your environment.

Arrive with a plan for the conversations worth having

Do these six checks and something changes about how the week feels. You stop reacting to announcements and start hunting for the specific ones that close gaps you've already named. You walk the expo hall, sit down in chalk talks, and corner the AWS service teams with sharper questions, because you're carrying real context, not a blank page.

Do the assessment, and you flip the dynamic. Instead of every announcement arriving as a hammer in search of a nail, you show up knowing exactly which nails you came to drive, and you go find the right hammer for each one.

That's the real payoff: you arrive with an informed list of conversations to have, with the AWS service teams who build what you're evaluating, and with partners like us who help you put it into practice. Not a wish list of things that sounded interesting, but a short, specific set of problems you already understand and are ready to solve.

Ten years in, that's the difference I see between people who come home energized and people who come home exhausted. The exhausted ones tried to drink from the firehose. The energized ones showed up knowing exactly what they came to figure out.

See you in Vegas.

Sources

1. AWS re:Invent 2026 booking helper: session reservation changes for 2026 (interactive sessions reservable; keynotes and lecture-style breakouts walk-up). https://github.com/gmmurugan/aws-reinvent-booking

2. AWS re:Invent 2026 session catalog: session codes, titles, tracks, and dates (verify current scheduling in the live catalog). https://catalog.awsevents.com/widget/awsevents/reinvent2026/