AWS re:Invent 2025: insights and key takeways

07/12/2025 · 34 min read · aws re:invent conference cybersecurity cloud ai agentic quantum-computing networking computing storage serverless  ·
Share on:

Overview

In this article, I take you with me to the AWS re:Invent 2025 conference I attended in Las Vegas. You’ll see an overview of the sessions I attended along with the key takeaways from this intense week of learning, practising and connecting.

Introduction

I was lucky enough to attend the Amazon Web Services (AWS) re:Invent 2025 conference in Las Vegas, NV. This huge event gathers nearly 60,000 people from all around the world with more than 2,000 sessions across 5 different hotel locations. It’s a great opportunity to acknowledge latest AWS cutting-edge announcements and innovations, learn new technical concepts, ask questions, practise over labs and connect with peers.
I will share here the outcome of sessions I have been able to attend. For each session, you’ll find a summary along with my raw notes and the replay when available. Of course, this is a very limited overview of what you can expect at re:Invent with my own interests, but still I hope you’ll learn some interesting stuff.

AWS re:Invent 2025 opening keynote

Attended sessions

🔒 Protect privacy in GenAI applications using AWS Confidential computing (CMP338)

This session focused on securing GenAI applications by addressing the “multi-party collaboration” challenge, where Large Language Model (LLM) owners want to protect their intellectual property (model weights) and consumers seek to protect sensitive data during processing. The solution leverages AWS Confidential Computing to protect data in use via EC2 Instance Attestation, which cryptographically verifies that only trusted software and boot processes are running on an instance to allow decryption of encrypted LLM.
By using the AWS Nitro System and NitroTPM to store system measurements in Platform Configuration Registers (PCRs), the architecture integrates with AWS Key Management Service (KMS) to strictly condition key access; encrypted model weights are only decrypted if the instance state matches the cryptographic hash of a trusted “Attestable AMI” ensuring a Zero Trust environment where secrets never persist in plaintext.

Attack surfaces in GenAI apps: multi-party collaboration problem (relying on LLM built by 3rd party), consumer <--> owner
Owner of the LLM wants to protect model the consumer
Consumer wants to protect their sensitive data from leaving the boundaries

Confidential Computing: protecting code and data while being operated (at rest or in transit).
--> no unauthorized access, isolation, trusted code execution
Need to consider what to protect and who to protect from (cloud and internal operators)

AWS example: Manage KMS policies conditional with PCR4/PCR7 (platform configuration registers) to manage AWS KMS storing a key used to encrypt a data key used to encrypt LLM Model weights.
Model wieghts: numerical values learned during the training process that encode all of the model's knowledge, language structure, and reasoning ability, determining the strength of connections between its artificial neurons.

Objective: bring attestation --> cryptographic proof (EC2 instance attestation)
Attestation: cryptographically prove to any party that only trusted software, drivers, and boot processes are running on an EC2 instance. Instance attestation is powered by the Nitro Trusted Platform Module (NitroTPM) and Attestable AMIs.
Attestable AMIs: AMIs with a corresponding cryptographic hash that represents all of its contents. Hash is generated during the AMI creation, and calculated based on the entire contents of it, including the applications, code and boot process.
Using Nitro Trusted Platform Module (NitroTPM), customers can verify whether a target instance has the same measurement as the reference measurement generated by the AMI. Instance attestation integrates with KMS, allowing customers to restrict key operations to instances that pass specific attestation conditions.
NitroTPM is a virtual device that is provided by the AWS Nitro System and conforms to the TPM 2.0 specification. It securely stores artifacts (passwords, certificates, or encryption keys) that are used to authenticate the instance. NitroTPM can generate keys and use them for cryptographic functions.
Process:
1. bootstrap then fetch encrypted LLM model weights and datakey from S3
2. then attested decrypted model using KMS (containing a model KMS key managed by policy with PCR conditionals)
3. then locally decrypt model weights and run LLM

Key PCR Registers:
    - PCR0: Contains measurements of the boot process and firmware
    - PCR4: Typically used for boot loader measurements
    - PCR7: Used for secure boot policy measurements
    - PCR12: Used for kernel command line override measurements
    - PCR15: Available for custom application use (used by the sample app for model measurements)
    - PCR16: Available for custom application use (we'll use this for our demonstration)

Critical security features integrated:
- Attestation-Based Access Control: model decryption only succeeds when PCR measurements match policy conditions, cryptographic proof that the EC2 instance is in the expected state
- Zero-Trust Architecture: no permanent secrets stored on the instance, all access decisions based on real-time attestation
- Cryptographic Binding: model weights cryptographically bound to specific PCR measurements, prevents decryption in compromised or different environments
- Defense in Depth: multiple layers (S3 encryption, KMS policies, TPM attestation, local decryption)
- Ephemeral Key Management: RSA keys generated fresh for each decryption operation, data keys never persist in plaintext outside the instance

Build attestable AMI with kiwi-ng
https://osinside.github.io/kiwi/

🛡️ Winning the DDoS Battle with AWS WAF (NET306)

This workshop detailed a comprehensive strategy across three pillars to defend Web applications on AWS: resilient design, layered security, and proactive response. The core defense utilizes Amazon CloudFront as the exclusive, highly scalable entry point, implementing origin access control to prevent direct attacks on the resources. Security is layered using AWS Web Application Firewall (WAF), featuring Anti-DDoS AWS Managed Rules (AMR), custom rate-based rules (e.g. blocking excessive POSTs or geo-limited requests) and Bot Control (including JavaScript challenges to verify browsers). The lab culminated in DDoS attack simulation and monitoring via CloudWatch.

CloudFront: CDN to deliver content globally with low latency and high speed
AWS WAF: monitor HTTP(S) requests  forwarded by protected web application resources
Anti-DDoS AWS Managed Rules (AMR: faster detection and mitigation, improved accuracy, granular control, simplified setup)

Best practices:

- Using AWS Edge locations for scale, for example by using Amazon CloudFront as the entry point to your web applications.
- Implementing application layer defenses, for example by adding a WAF.
- Reducing attack surface, for example by implementing origin cloaking techniques.
- Scaling, for example by using Load Balancers and Autoscaling groups.

Origin cloaking is a set of techniques aiming at reducing the attack surface of web applications. It's a best practice to use CloudFront as a single-entry point to web applications, where security controls, such as protections against DDoS attacks and undesired bots, are applied. Origin cloaking stops malicious actors from by-passing CloudFront and its security controls to attack the origin directly, using firewall rules to block any traffic not coming from the CloudFront entry point. Origin cloaking can be achieved at multiple layers of the OSI model.

LAB
Step 1: removing public exposure of internal backend
Created a target group
Created a ALB
Created a cloudfront origin and associated the ALB to it
Removed old public LB and as origin of Cloudfront distribution

Step 2: removing exposure of public app
Created custom WAF rule to block HTTP DELETE methods
Created custom WAF rule to block HTTP POST >1kB

Step 3: understanding baseline of the traffic
Enable WAF logging with CloudWatch
Ran CloudWatch queries to understand better the incoming traffic
Created CloudFront Alarm for 5xx error rate

Step 4: defend against DDoS
Created a simulation of DDoS attack from 3 AWS regions
Created custom WAF rate-based rule to block traffic with >1000 req / 5 mn
Created custom WAF rate-based rule to block traffic not from the US with >100 req / 1 mn
Created custom WAF rate-based rule to block HTTP POST traffic with >20 req / 1 mn
Created AWS managed WAF rule to return a CAPTCHA for anonymizing proxies
Created AWS managed WAF rule to block traffic identified as coming from AWSManagedIPReputationList, AWSManagedReconnaissanceList or AWSManagedIPDDoSList
--> relies on MadPot: AWS Honeypot used to gather Tactics, Technics and Procedures (TTPs)

Step 5: add managed DDoS protections
Created an Anti-DDoS managed WAF rule for Layer 7 attacks
Created custom WAF rate-based rule to harden the DDoS mitigation for traffic not from the US

Step 6: protect against bots
Created an Bot Control managed WAF rule to block bot traffic (many categories available, including AI)
Interesting: it blocks curl based requests, doesn't block curl based requests performing HTTP user-agent spoofing except after a few consecutive requests!

Javascript challenge: ensures traffic originates from a browser by challenging the client with a computationally expensive task
![[Pasted image 20251201222612.png]]

Step 7: respond to DDoS attacks
Created custom WAF IP-based rule to block traffic from preconfigured IP address sets

Shield Advanced: subscription based service, that gives you the following capabilities in your battle against DDoS attacks:

- 24/7 support from the AWS Shield Response Team (SRT) during DDoS attacks. The SRT assists you during DDoS attacks that were not automatically mitigated by CloudFront and AWS WAF. For example, they can manually write WAF rules on your behalf to mitigate the attack.
- Financial benefits. When enabled on a resource, the price of Shield Advanced includes the basic WAF costs, and protects you against DDoS-related spikes in your EC2, ELB, Global Accelerator, and Route 53 costs.

In this workshop --> 3 pillars for winning the DDoS battle using AWS:

1. Building a resilient web application, for example by using the distributed network of CloudFront as the exclusive entry point to the backend, and scaling the backend automatically.
2. Adding security controls, using multiple layers of AWS WAF rules, such as IP reputation based rules, rate limits, advanced bot detections, and Shield Advanced layer 7 auto mitigation.
3. Monitoring and responding to DDoS attacks. For example, create alarms using appropriate CloudWatch metrics, and when the attack is not mitigated automatically, follow your run books to triage attack traffic using observability tools like CloudWatch Logs Insights, or escalate to the AWS Shield Response Team.

☁️ Powering your success through AWS Infrastructure innovations (NET402)

This session detailed major advancements across AWS infrastructure: networking, security, and high-performance computing. Key takeaways include significant enhancements to CloudFront (supporting HTTP/3, HTTPS DNS and Post-Quantum Cryptography) and new tools for VPC security (VPC Block Public Access, Encryption Controls, and advanced Bot/AntiDDoS management). Furthermore, the speakers highlighted the foundation of its global scale with th newe FastNet 320 Tbps subsea cable and infrastructure techniques like Precast Fiber Duct Banks and SRLG-aware routing for superior resilience. Finally, the session talked about the extension of AWS Private Links to cross-region, then covered the bleeding edge of AI/HPC and then the tightly integrated UltraServer (single high-performance logical computing node) and UltraCluster (cluster of EC2 Accelerated Computing instances) systems, supported by the next generation of load-balancing and adaptive routing and UltraSwitch networking fabrics that utilize dynamic, intent-based routing to ensure petabit-scale and low-latency performance.

Latest AWS Infrastructure innovations reviewed

CloudFront maintain TCP connection opened with the server, only handshake is between client and CloudFront.
New HTTP/3 support even if the server does not support it in the backend
Support HTTPS DNS records: allows clients to discover information about the supported HTTP protocols (e.g. HTTP/3!) and port numbers for a CloudFront distribution during the initial DNS lookup, before attempting an HTTP connection
Post-Quantum Cryptography ready in CloudFront, ALB and NLB
Private Front-End VPC accessible only through AWS HyperPlane
VPC Block Public Access: restrict backend VPC
VPC Encryption Controls: enforce encryption for traffic within and across VPCs
Bot Control with computationally expensive challenge
AntiDDoS with AWS Managed rules (AMR)
FastNet 320 Tbps (enough to stream 12.5 million HD films simultaneously) transatlantic subsea fiber optic cable between Ireland and the US
Nitro card
Traffic engineering (explained last year) to allow to serve traffic from another city with a better capacity
Direct-to-EC2 Traffic
Automatic Network Traffic Engineering

AZ Redundancy: multiple connection across the buildings (sort of mesh)
Inter-DC redundancy
Geographic Information Systems (GIS) to take into account geography (example with highways) in fiber deployments
GIS are software systems that create, manage, analyze, and map all data types. They combine location data with information about how things are in that location. GIS applies geographic science with tools for understanding and collaboration. Additionally, GIS can analyze changes in regions over time, such as population density or changes to land use.

PreCast Fiber Duct Banks: modern, modular system to create protected, organized, underground pathways for cables
Shared Risk Link Groups (SRLG): set of links (network connections) sharing a common physical resource and therefore having the same risk of failure from a single event
Backbone tunnels: pre-provision ip based bypass tunnels, segments are independent (physically also). Recalculate paths upon failures

Cross Region PrivateLink: connect VPCs from different regions together
Cross Region Private Link for AWS Services: connect VPCs service endpoints across different regions
AWS UltraClusters: high-density, tightly coupled cluster of EC2 Accelerated Computing instances specifically engineered to deliver supercomputing-class performance, 8ms latency, 50k 800G GPUs. For GenAI, HPC..
AWS UltraServers: single high-performance logical computing node created by physically interconnecting multiple standard EC2 accelerated instances, uses high-bandwidth, low-latency interconnect (such as NeuronLink for AWS Trainium)
firefly, loki (validate cables), reduction of 36% of link level failures, 76% of reduction in time to cable
Initially on access / fabric network: Usage of ECMP, may still cause network contention --> solution is to incorporate dynamic load balancing / adaptive routing
AWS UltraSwitch: choose the behavior that matches the workload, Virtual Rails, Cost to workload, Availability, Agility (example: split storage traffic)
Intent-based Fabric Controller

💡 Opening Keynote with Matt Garman (KEY001)

The opening keynote showcased the recent AWS announcements that represent a significant push into AI and Agentic services, alongside key security and performance upgrades. Matt Garman introduced the Nova suite of AI tools, including Nova Forge for building large models, Nova Act for UI automation, and Nova 2 Sonic for conversational AI, complemented by AWS Lambda Durable Functions for complex AI workflows and AWS Transform Custom for AI-driven code modernization to crush technical debt. Simultaneously, AWS enhanced compute with new EC2 X8aedz instances (powered by AMD EPYC) for memory-intensive tasks and strengthened security with a new AWS Security Agent, GuardDuty Extended Threat Detection and the AWS DevOps Agent for better autonomous incident response.
You may find more information here.

🤖 Accelerating incident response through AIOps (COP334)

This session on accelerating incident response through AIOps first highlighted the massive scale of CloudWatch, which now ingests vast amounts of operational data for Amazon itself, and its evolution into a unified AIOps platform. The key focus is leveraging AI and ML to dramatically reduce incident resolution time, moving from hours to seconds, as demonstrated with analogies like predicting Formula 1 pit stop durations. New features include a unified data management approach for operational, security, and compliance data, a natural language query generator, and the Model Context Protocol (MCP)—an open standard allowing AI assistants (like those in IDEs) to integrate with and query CloudWatch, Application Signals, and CloudTrail data. This culminates in CloudWatch Investigations, an AI-powered tool that automatically scans telemetry, suggests solutions, generates detailed reports (saving Amazon 80% of incident resolution time), and the new AWS DevOps Agent, which is designed for autonomous, always-on incident prevention and resolution.

CloudWatch evolution
Now ingests 17 exabytes of logs, 32 quadrillion of metrics for Amazon on CloudWatch
Example of pit stops at Formula1 with predictions for pit stop duration made from real-time telemetry
Unscheduled pit stops compared to incidents: reduce duration from hours to seconds with AIOps
AIOps: use AO a,d ML to enhance, accelerate and automate operations processes
Unified Data management for CloudWatch: across operational, security and compliance use cases. Goal: put the data in one place.
Automatic collection of vended logs, pre-built connectors for 3rd party sources
Demo with data sources aggregation from VCP flow logs, Route53 logs, CloudTrail events, CloudFront, API Gateway, can ingest integrated 3rd parties
Query generator in natural langage available in CloudWatch
MCP: Model Context Protocol, open standard to enable AI assistant to integrate with products. MCP allows here to integrate CloudWatch into IDEs
3 MCP servers: CloudWatch, Application Signals, CloudTrail
Demo with KIRO IDE using AWS MCP servers (sending requests in natural language, recommendations were returned that you can apply directly)
Reality of operations: is a mess with many steps --> CloudWatch Investigations: helps respond to incidents, uses AI to scan telemetry and surface suggestions, can be done across accounts, generate incident reports with 5 whys. In Amazon: 80% time saved to solve incidents.
Able to provide a topology map of the application being troubleshooted
AWS DevOps agent: frontier agent that resolves and proactively prevents incidents. Always on autonomous incident response.

🕵️ Robust network security with perimeter protection and zero trust (NET326)

This session detailed a multi-layered approach to robust network security using AWS services, encompassing perimeter defense and Zero Trust principles. The perimeter security strategy starts at the edge with CloudFront, leveraging AWS Shield for high-volume DDoS mitigation followed by AWS WAF for deeper content inspection, rate limiting, and bot prevention. Origin access controls with VPC Origins in CloudFront secure connections to internal resources. For network-level control to, from and within the VPC, AWS Network Firewall provides stateful inspection, blocking, and filtering based on the open-source Suricata IDS/IPS engine, managing both north-south and east-west traffic and integrating with AWS Firewall Manager for centralized policy management. Finally, the move towards Zero Trust is facilitated by AWS Verified Access (AVA), which acts as a Zero Trust Network Access (ZTNA) reverse proxy performing continuous, multi-source verification, complementing traditional remote access methods like Client VPN, which also supports enhanced security via device posture checks using Lambda functions.

Public and private resources
Network security needs: protect public apps from external threats, inspect and authorize outbound connections, prevent lateral movement by inspecting east-west requests, allow only authorized employees to access private resources
Edge security in CloudFront: 750 PoPs in 50+ countries, protected by AWS WAF + AWS Shield
AWS Shield first: L3/4 and L7 security: list of known offenders IP addresses, event monitoring and detection, HTTP/2 rapid reset, mTLS supported
AWS WAF then: inspecting inner content, rate-limiting, bot prevention, AWS WAF Anti-DDoS managed rule: advanced and faster mitigation, improved accuracy, granular control
Origin access controls in CloudFront to secure what can access the resources with VPC Origins
Demo to deploy CloudFront and WAF with KIRO IDE
AWS Network Firewall: policy, block and filter, monitor. Based on Suricata so integrate IDS/IPS. All incoming / outgoing traffic from a VPC can be routed to AWS Network Firewall. Endpoints can be used to inspect traffic within a VPC. Integrated with AWS Firewall Manager for management. Managed rules: from AWS honeypot (MadPot), create rules for the customer
Remote access: AWS Site-to-Site VPN / Client VPN / Verified Access (ZTNA)
Client VPN: certificate authentication + AD or SAML based. Device posture with device connection handler (in a Lambda)
AWS Verified Access (AVA): reverse proxy, use additional sources to verify access, continuous verification

🛡️ Innovations in Infrastructure Protection to strengthen your network (SEC310)

The session focused on AWS’s multi-layered strategy for infrastructure protection to address modern challenges like hybrid connectivity, evolving threat landscape, and compliance needs. AWS reinforces its defense-in-depth model across three layers:

  • Application Level: Using AWS WAF (with new simplified onboarding, reduced CloudWatch logging costs, and enhanced Anti-DDoS L7 protection via AMR) and AWS Shield for ingress protection.
  • Network Level: Using AWS Network Firewall and Route 53 DNS Firewall* for egress and east-west inspection.
  • Visibility and control: with new dashboard for the firewall and new AWS Shield network security director The key recent innovations include:
  • Advanced firewall capabilities: The AWS Network Firewall now includes an explicit proxy function, enabling features like TLS decryption, anti-SNI spoofing, granular URL/header/content filtering, and flexible cost allocation. It continues to provide stateful inspection and IDS/IPS based on Suricata. Also, AWS deception technologies around MadPot are now integrated into managed rules and 3rd-party threat intelligence can now be shared as indicators to the firewall.
  • Active Threat Intelligence: The Active Threat Defense system integrates proprietary threat intelligence from AWS’s MadPot deception technologies into managed rules for both WAF and Network Firewall. Third-party partner managed rules are also available via the Marketplace.
  • Enhanced Visibility: The AWS Shield Network Security Director provides network topology mapping and posture assessments via a new dashboard experience, complementing native dashboards in Network Firewall.
Customer challenges: hybrid connectivity, compliance regulations, availability and maximum performance, visibility, evolving threat landscape, internal expertise
Layered defense in depth:
- Application level security: AWS WAF & AWS Shield --> protect ingress flows
- Network level security: AWS Network Firewall, Route53 DNS Firewall --> egress + east-west
- Visibility & control: AWS Firewall, AWS Shield network security director
Deception technologies: MadPot (threat research project), set (tens of thousands) of decoys across the AWS infra and emulating hundreds of services
New in network security visibility:
- AWS Shield network security director: builds a network topology, posture assessment
- New dashboard experience
- Reduced pricing for WAF logs in CloudWatch
- Network firewall native dashboard
- Simplified onboarding with AWS WAF (recommended set of rules based on application type)
- AWS WAF Anti-DDoS L7 protection with Anti-DDoS AMR
Route53 DNS Firewall: prevent DNS attacks via custom lists or AWS provided lists
AWS Network Firewall: stateful inspection, IDS/IPS, TLS decryption
AWS Network Firewall proxy: explicit proxy within AWS Network firewall --> domain filtering, header/URL/IP filtering, anti-SNI spoofing, content-type controls. attached to nat gateway with PrivateLink support for overlapping VPC CIDRs with transit gateway and CloudWAN compatibility
Introducing Network Firewall flexible cost allocation
Active Threat Defense: powered by MadPot (threats detected by AWS Threat Intelligence are added to the managed rules)
Partner Managed Rules from AWS Marketplace for AWS Network Firewall: get some 3rd party threat intelligence integrated into AWS Network Firewall

⚛️ Get hands-on with quantum computing (CMP202)

This workshop session provided an overview of quantum computing fundamentals, including the concepts of qubits, superposition, entanglement, and quantum gates, and demonstrated its application using Amazon Braket SDK. The core of the workshop was a hands-on lab showing how to build, run, and manage quantum circuits (specifically a Bell state and Deutsch’s algorithm) across various targets: a local simulator, a managed simulator (SV1), and a real Quantum Processing Unit (QPU) from a provider like Rigetti (Ankaa-3). The demonstration included essential workflow tasks such as monitoring the device queue depth, recovering a quantum task using its ARN, analyzing measurement counts, and confirming that Deutsch’s algorithm correctly distinguishes between constant and balanced functions (resulting in measurements of ‘0’ and ‘1’ respectively) using a single quantum evaluation.
In case you want to learn more on quantum computing, feel free to read my related blog article.

Quantum computing: new paradigm for computation leveraging law of quantum physics
Applications: physics and chemistry, material science, optimization
Amazon Bracket: enabling quantum computing research, on-demand & dedicated access to hardware from various providers, more and more quantum hardware integrated over the past 5 years
Simulators available to mimic behaviors of quantum computers
qubit: states represented by a Bloch sphere, superposition of basis states as a vector on the sphere, measure given by a probability distribution
Quantum computers apply quantum gates to qubits
Quantum circuits: string gates together to implement a quantum algorithm, the final measurement is the bit representation of the solution
Quantum entanglement: special type of correlation between multiple qubits
Deutsch's algorithm: function mapping bits (0 or 1) either constant or balanced, with classical computing we need to evaluate the function twice, with quantum computing we can evaluate both at the same time (applying Hadamard Gates)
Lab: jupyter notebook to learn how to use the Amazon Braket Python SDK
Created a quantum circuit to create a Bell state and executed the circuit on a local simulator, then printed and visualized the count of binary strings for the measurements

import string
import matplotlib.pyplot as plt
from braket.circuits import Circuit, Gate
from braket.devices import LocalSimulator
bell = Circuit()
bell.h(0)
bell.cnot(control=0, target=1)
print(bell)
device = LocalSimulator()
task = device.run(bell, shots=100)
print(task, task.state())
LocalQuantumTask('id':39898a73-e3d7-4a61-8958-978565ebf4da) COMPLETED
result = task.result()
print(result)

counts = result.measurement_counts
print(counts)
plt.bar(counts.keys(), counts.values())
plt.xlabel("bitstrings")
plt.ylabel("counts")
plt.show()

Now run it on a device:
from braket.devices import Devices
device = AwsDevice('arn:aws:braket:::device/quantum-simulator/amazon/sv1') 
task = device.run(bell, shots=100)
print(task, task.state())
AwsQuantumTask('id/taskArn':'arn:aws:braket:us-east-1:135808919586:quantum-task/55525059-5822-43ce-bac3-ca2d33436c25') QUEUED
task_metadata = task.metadata()
print(f"https://s3.console.aws.amazon.com/s3/buckets/{task_metadata['outputS3Bucket']}/{task_metadata['outputS3Directory']}/")
result = task.result()
print(result)

Now run it on a real QPU:
device = AwsDevice('arn:aws:braket:us-west-1::device/qpu/rigetti/Ankaa-3') 
task = device.run(bell, shots=100)
print(task, task.state())
result = task.result()
print(result)

View how many other quantum tasks are already in front of you by checking device queue depth
device.queue_depth()
QueueDepthInfo(quantum_tasks={<QueueType.NORMAL: 'Normal'>: '0', <QueueType.PRIORITY: 'Priority'>: '0'}, jobs='0')

view the current position of your quantum task within a respective device queue
task.queue_position()
QuantumTaskQueueInfo(queue_type=<QueueType.NORMAL: 'Normal'>, queue_position=None, message='Task is in COMPLETED status. AmazonBraket does not show queue position for this status.')

print(task.id, task.state())
arn:aws:braket:us-west-1:135808919586:quantum-task/3f36d5cb-4e08-4b59-ba03-60d5587203c1 COMPLETED

from braket.aws import AwsQuantumTask

Task recovery
recovered_task = AwsQuantumTask(arn='arn:aws:braket:us-east-1:135808919586:quantum-task/55525059-5822-43ce-bac3-ca2d33436c25')
print('Status of (reconstructed) task:', recovered_task.state())
Status of (reconstructed) task: COMPLETED
if recovered_task.state() == "COMPLETED":
    # get metadata
    metadata = recovered_task.metadata()
    shots = metadata["shots"]
    deviceArn = metadata["deviceArn"]
    print(f"{shots} shots taken on device {deviceArn}.\n")

    # get task result
    result = recovered_task.result()

    # get measurement counts
    counts = result.measurement_counts
    print("Measurement counts:", counts)

    # plot result
    plt.bar(counts.keys(), counts.values())
    plt.xlabel('bitstrings')
    plt.ylabel('counts')
    plt.tight_layout()

else:
    # print current status
    print(f'Your task has not been completed. Its current status is {recovered_task.state()}')

Implemented Deutsch's algorithm:
Constant function:
constant_circuit = Circuit()
constant_circuit.x(1)
constant_circuit.h(0)
constant_circuit.h(1)
constant_circuit.x(1)
constant_circuit.h(0)
constant_circuit.measure(0)
print(constant_circuit)

balanced_circuit = Circuit()

Balanced function:
balanced_circuit.x(1)
balanced_circuit.h(0)
balanced_circuit.h(1)
balanced_circuit.cnot(0,1)
balanced_circuit.h(0)
balanced_circuit.measure(0)
print(balanced_circuit)

Run the circuits
device = LocalSimulator()
constant_result = device.run(constant_circuit, shots=100).result()
constant_counts = constant_result.measurement_counts
balanced_result = device.run(balanced_circuit, shots=100).result()
balanced_counts = balanced_result.measurement_counts
print("Constant function results:", constant_counts)
print("Balanced function results:", balanced_counts)
Constant function results: Counter({'0': 100})
Balanced function results: Counter({'1': 100})

Run the circuits on a QPU
from braket.aws import AwsDevice
from braket.devices import Devices
device = AwsDevice(Devices.Rigetti.Ankaa3)

constant_task = device.run(constant_circuit(), shots=100)
balanced_task = device.run(balanced_circuit(), shots=100)

if constant_task.state() == "COMPLETED" and balanced_task.state() == "COMPLETED":
    constant_counts = constant_task.result().measurement_counts
    balanced_counts = balanced_task.result().measurement_counts
    print("Constant function results:", constant_counts)
    print("Balanced function results:", balanced_counts)
else:
    # print current status
    print(f'Your tasks have not been completed. The current status:')
    print(f'Constant task: {constant_task.state()}')
    print(f'Balanced task: {balanced_task.state()}')


What was done here:
- build a circuit
- run a circuit as a task on the local simulator, a managed on-demand simulator and a real QPU on Amazon Braket
- build a quantum algorithm from scratch and run it on a QPU
- import and use pre-built quantum algorithms

🪣 What’s new with Amazon S3 (STG206)

This session highlighted major advancements in S3 aimed at improving security, performance, cost, and data utility. For security, AWS introduced a simplified tag-based access control for easier S3 access policy management and support of centralized features like Block Public Access and Post-Quantum TLS encryption at the Organization level. Performance was significantly boosted for S3 Express with a price reduction, support for 2 million requests/second, and the addition of object rename and Access Point support. Data management features included support for objects up to 50TB, new Conditional Copy/Delete requests, and 35% cost reductions for object tags. S3 is also expanding its data utility with S3 Tables for managed tabular data (including Iceberg catalog support and replication), new automatic S3 Metadata generation (journal/inventory tables), and the powerful new S3 Vectors capability, which allows for semantic search and finding meaning in unstructured data using numerical vector representations generated by ML models.

S3 Security:
Access control policies can be hard to manage --> tag-based access control (tag the bucket and reuse the tags in policies), available via API
Useful existing features brought at Organization level: block public access, enhanced 403 messages
Post-Quantum TLS encryption
99.999999999% data durability: end-to-end integrity checking of requests, data always stored on redundant devices, periodic durability auditing data at rest
S3 Express: price reductions, support of 2M req / s, object rename, access point support
New conditions:
- Conditional Copy: verifies existence match on COPY request
- Conditional Delete: verify match on DELETE request
Managing large objects: support up to 50TB objects
Reduction of cost of object tags by 35%
Enhancements on S3 batch operations: no-manifest batch operations, automatic IAM roles, 20B objects, 10x performance
S3 Tables (storing tabular data): Iceberg REST catalog, table limit raise, sort compaction, compaction price cut, set schema on create, table replication (read-only replicas)
Intelligent tiering: cost optimization
S3 Metadata (automatically generate object metadata): journal tables (records of the changes down to an iceberg table), live inventory tables
S3 Vectors: finding meaning in data (semantic search), long list of numerical values generated by models, the values represent the characteristics of an image to mathematically quantify similarity, etc. --> can arrange images in categories for instance

🌐 Advanced VPC design and new capabilities (NET340)

This session outlines AWS’s new networking capabilities released over the past year, that are rapidly evolving beyond foundational elements like VPCs, Transit Gateway (TGW), CloudWAN and PrivateLink, focusing heavily on scale, security, and simplified application connectivity. Recent innovations emphasize centralized and improved network security with features like native TGW attachment for AWS Network Firewall, its new explicit proxy capabilities, or Encryption control for flows within a VPC. Service-to-service connectivity is streamlined through VPC Lattice’s cross-region and custom DNS features, while the network backbone improves with IPv6 support across a growing number of services, the introduction of the VPC Route Server for dynamic BGP routing at instance level, and significant performance boosts for Site-to-Site VPN and DirectConnect. These updates collectively enable enterprises to manage large, complex, and secure cloud networks with greater automation and cost-efficiency.

Foundations:
- VPC: hosting compute, workloads, instances, subnets (AZ level constructs), NACL (subnet level stateless filtering) & security groups (stateful filtering), can add AWS Network Firewall, Internet Gateway for Internet access
- Elastic Load Balancer: ALB, NLB, GWLB
- AWS PrivateLink: connect to AWS services via endpoints: Gateway endpoints (no interfaces in VPC) to connect to S3 and DynamoDB, or Interface endpoints (interfaces in VPC).
- AWS Lattice: connect applications (service-to-service)
- VPC Peering: intra-region and cross region
- Transit Gateway (TGW): regional routing hub to connect 5,000 VPC, can peer TGW together, relies a lot on static routing
- AWS CloudWAN: fully managed service to allow dynamic connectivity across segments, while TGW is more DIY.
- Site-to-site VPN & DirectConnect (private virtual interface, transit virtual interface, public virtual interface)
- Remote access VPN: AWS Verified Access (device posture, identity management)
Innovations over the past year (150+ new features & integrations):
- NAT Gateway in regional availability mode: from one NAT Gateway per AZ to region wide, automatically update availability zones
- AWS Network Firewall:
	- Native attachment to TGW to avoid having a dedicated inspection VPC
	- Multiple VPC endpoints for AWS Network Firewall, can use endpoint ID in the policies to create per VPC policies but in a centralized manner
	- Active Thread defense enabled by default in alert mode, partner (3rd-party) managed rules, enhanced console, monitoring
	- Explicit proxy available: Proxy Endpoint so the client can use it without modifying the routing table, pre (upon HTTP CONNECT) & post (inner HTTP methods inspection) request inspection, TLS decryption
- Amazon VPC Route server: allows instance within VPCs to make BGP routing updates to VPC routing table, use cases: anycast, failover in active/passive EC2 instance deployments.
- Flexible cost allocation for TGW
- Amazon VPC Encryption controls: monitor mode or enforcement mode (ensure everything flowing in a VPC is encrypted)
- AWS PrivateLink now works across regions, supports IPv6.
- Amazon VPC Lattice: custom DNS for Resources to simplify DNS management (can now define a custom DNS for a resource), configurable IP addresses for resource gateways, Service Network Association (can't be accessed outside of the VPC) vs Service Network Endpoint (can be accessed outside of the VPC), on-prem & cross-region connectivity, traffic inspection is possible via AWS Network Firewall
- Application Load Balancer: target optimizer (load balancer based on the number of concurrent requests), health check logs, PQ-TLS
- Network Load Balancer: access logs, weighted target groups, PQ-TLS, support of QUIC
- Amazon API Gateway developer portal, response streaming, response timing extended to 15mn, support of direct private integration with ALB, MCP support
- CloudWAN: tunnel-less Connect (connect instance talking BGP), drop TGW and DirectConnect into CloudWAN segments, security group referencing, advanced routing controls (route filtering, summarization, RIB view)
- Site-to-site VPN: 5Gbps tunnels + ECMP on TGW / CloudWAN
- DirectConnect: AWS Interconnect Multicloud (partnership with Google, Azure coming in 2026)
- Amazon Route53: global resolver (public & private domain resolution), anycast support, encrypted DNS (DoH/T) support, DNS firewall
- Amazon CloudFront: mTLS support, flat rate pricing
- Amazon VPC IP Address Manager: public IPv4 allocation policies (integrate with prefix lists)
- 75% of AWS services support IPv6, 100+ AWS services launched with IPv6 this year

🚀 Infrastructure Innovations (KEY004-OF4)

The keynote on Infrastructure innovations showcased significant advancements across the core compute stack, focusing on performance, efficiency, and AI integration. The foundation remains the Nitro System, which uses dedicated hardware to eliminate hypervisor-related jitter. A major highlight was the introduction of the Graviton5 processor, featuring 192 cores, a five-fold increase in L3 cache (one of the pieces of memory incorporated directly on the chip), and 25% higher performance than its predecessor, available first in M9g EC2 instances. This focus on specialized hardware extended to AI with the announcement of Trainium3 UltraServers, a massive supercomputer setup utilizing 144 chips and Neuron switches to achieve 4.4x higher compute performance for training the largest AI models. Complementary announcements included the General Availability of S3 Vectors to enable semantic search on object data and the launch of AWS Lambda Managed Instances, which merges the serverless simplicity of Lambda with the specialized hardware flexibility of EC2. Also, a focus was made on one year of experience with the Swift SDK, which allows developpers to easily consume AWS services.

Example shown on jitter issues observed on EC2 due to hypervisor layer --> Nitro system to solve such issues: dedicated hardware for virtualization, networking and storage
Built own chip with custom silicon: Graviton. Direct to silicon cooling system allows heat to move more efficiently (fan power drops by 33%).
Use of caches to avoid going to DRAM, with Graviton doubling of the cache of L2 cache up to 2MB
Graviton4: increased again cache, added a coherent link between CPUs
Graviton5 introduced today: 192 cores in one package, 5 times of the L3 cache of previous generation, 2.6 times more L3 cache, available in M9g EC2 instance, 25% higher performance
AWS Swift SDK (build apps, call AWS services), available on Linux, Windows, Android, etc
Introduced AWS Lambda Managed instances: use a Lambda on an EC2
Announcing GA of S3 vectors: turns every S3 buckets into a potential search image engine!
AWS Trainium3 UltraServers: AI supercomputer based on Trainium3 chips (144 chips across 2 racks), in the middle there are Neuron switches. 4.4x higher computer performance, 3.9x more bandwidth than last Trainium UltraServer. Can run very largest AI models.
Gravition processor, Nitro card (networking)

⚙️ Building the future with AWS Serverless (CNS211)

The session on the future around AWS Serverless showcased major innovations that expand Lambda’s capabilities. A core theme was balancing high-burst elasticity with cost-optimized steady-state performance through Lambda Managed Instances (LMI), which enables running Lambda on customer-configured EC2 (like Graviton4) with full AWS management and multi-concurrency, bringing cost reduction. Complexity in workflows was simplified with Lambda Durable Functions, allowing developers to write reliable, long-running, multi-step business logic as sequential code. Finally, the introduction of Lambda Tenant Isolation Mode addresses SaaS multi-tenancy concerns by guaranteeing isolated execution environments per customer, thus reducing operational overhead while maintaining security and performance.

Architecting for evolution: no right architecture, just the right tradeoffs, evolution feature of the architecture, embrace change not only technology but also in people and processes too
Biggest secret of Serverless: hundreds of thousands of EC2 instances under-the-hood
Why Serverless? Speed! (fast time to market)
Example demo on building a note taking app with Kiro (AI coding assistant):
- Foundations: build CRUD API with MCP servers (GA Q2 2025). Give prompts to install MCP servers, and the REST API (API Gateway, Lambda functions, DynamoDB, CloudWatch, SAM templates..)
- Handling sudden traffic burst: hands-free scaling, seamless support for needle point traffic
- Optimizing steady state traffic: Lambda Managed Instances (LMI) --> run Lambda within EC2, access to latest CPUs like Graviton4, still fully managed, multi-concurrency available (deal with parallel requests), memory to CPU ratio can be chosen. LMI efficiency was shown within the demo: cost reduction!
- Build workflow-based architectures: multi)steps business logic --> Lambda durable functions: write reliable business logic as sequential code (Python supported for now), suspend and resume long-running operations
Concern of segregation for Lambda: to avoid creates several functions per tenants, Lambda Tenant Isolation Mode was introduced (isolate customer's requests execution)
Future upcoming in Serverless Compute: enhanced observability (monitoring, tracing, debugging with logs in the right format), more runtimes (e.g. Rust was added), optimized price-performance, deeper integration with 3rd-party tools

☁️ Multicloud networking best practices (HMC321)

This chat talk session on multicloud networking best practices highlightes key drivers of using multicloud like mergers and acquisitions, services availability or regulatory and compliance, stressing the need to balance performance, security, and cost across connectivity options. Traditional public options include VPNs (limited to 5 Gbps) and GRE-based or tunnel-less SD-WAN connectivity, contrasted with high-speed private options like dedicated Direct Connect (DX), which scales up to 400 Gbps with high SLA support. The most notable recent innovation is the new AWS Interconnect Multicloud service, a fully managed, high-bandwidth (up to 400 Gbps) cloud-to-cloud solution leveraging the Direct Connect Gateway. This service simplifies creating robust backbones between AWS and other providers, with initial support for Google Cloud Platform (GCP) and planned support for Azure.

Multicloud drivers: mergers and acquisitions, services availability, regulatory and compliance.
AWS follows cloud maturity model: multicloud approach
Connectivity considerations: performance (speed & latency), security, reliability and SLA, cost
Connectivity options:
- Public peering (over Internet):
	- direct internet peering (via Internet Gateway)
	- VPNs: 5Gbps IPsec tunnel
		- via Virtual Private Gateway: only 1 tunnel active & no ECMP, IPv5 or acceleration support)
		- via Transit Gateway / CloudWAN: 2 active tunnels ECMP supported
	- SD-WAN: SD-WAN virtual appliance in a VPC with VPC attachment to Transit Gateway / CloudWAN
		- GRE-based: 5Gbps per tunnel, ECMP supported
		- CloudWAN Connect: 100Gbps par AZ, tunnel-less
- Private direct connections: AWS DirectConnect (via on-prem, colocation facilities or 3rd-party)
	- DirectConnect:
		- Co-location facilities to connect both clouds via Customer DC (with physical routers)
		- 3rd-party Interconnect services
		- Dedicated direct connect (up to 400 Gbps, TLS/VPN/MACsec, 99.99% SLA)
		- DirectConnect through 3rd-party (up to 25Gbps, TLS / VPN, no SLA)
		- AWS Interconnect Multicloud just announced: fully managed cloud-to-cloud connectivity (up to 400Gbps) via DirectConnect gateway, GCP supported, Azure next year. 1,000 prefixes can be advertised with GCP
- Managed network services: 3rd-party virtual network solutions

🛡️ Network security architecture: Deployment patterns for firewalls in AWS (NET325)

This chat talk focused on strategic deployment patterns for network firewalls in AWS to secure East-West (within/cross-VPC), North-South (ingress/egress), and Hybrid traffic flows. The architecture choices generally fall into three patterns: distributed (firewall endpoint in every VPC), centralized (inspection VPC shared via Transit Gateway), or a combined hybrid approach. For multi-region architectures, inspecting traffic in both the source and destination regions is recommended for operational simplicity. When integrating third-party firewalls requiring high availability (HA) and autoscaling, the Gateway Load Balancer (GWLB) is typically the preferred as a more native solution over using Transit Gateway (TGW) with TGW Connect and GRE tunneling. Moreover, AWS plans to support firewall endpoints for 3rd-party firewall vendors directly into the Transit Gateway (TGW) in the future, a capability currently reserved for the native AWS Network Firewall. Ultimately, network firewalls and WAF are considered complementary and sometimes both required for regulatory reasons. A firewall might bring additional features and can handle generalized non-web traffic flows that WAF does not cover.

Types of flows:
	East-west: within VPC, cross VPC, cross region
	North-south: egress to the Internet, ingress from the Internet
	Hybrid: between AWS and on-prem
Firewall deployment patterns:
- Distributed: deploy firewall into each VPC with a firewall endpoint. A firewall manager is required to manage the different policies.
- Centralized : share central firewall with an inspection VPC reachable via Transit Gateway.
- Combined: mix of distributed and centralized
In multi-region deployment with Transit Gateway and centralized pattern: general recommendation to keep TGW architecture the same across the regions and for cross region traffic inspect traffic in both regions for simplicity (avoid NAT)
Question on recommended network deployment for 3rd-party firewalls with Ha: Gateway LoadBalancer (GWLB) vs TGW with TGW Connect + GRE to connect with 3rd-party. GWLB generally preferred as more native, can scale better..
Question on WAF vs network firewall: complementary (feature wise), firewalls deals with non-Web flows..
Question on integrating firewall endpoints in TGW (as available already for AWS Network Firewall) for 3rd-party firewalls? Yes planned in the future.

Conclusion

The re:Invent was an amazing and intense experience in Las Vegas. I really wish you to be able to attend this conference one day if you have the opportunity. This year, amongst the various sessions I’ve attended, I mainly retain the following.

  • An impressive amount of annoucements around the development of AI and more specifically Agentic: the journey towards autonomous intelligent systems is definetely launched!
  • The continuous progress of cutting-edge technologies for high performance computing, networking and storage to sustain AI development.
  • More and more flexibility for developers with things like AI assistants, SDK, durable Serverless functions or extension of Serverless power to EC2 instances.
  • The wish to have AWS networking service with advanced network and security features, be more easily manageable, extensible and compatible with non-AWS environments.
  • Security is the top priority for AWS.
  • The incredible opportunity I had to play with confidential computing and quantum computing.

Last, I would like to thank my colleague Anthony who gave me a lot of useful advices from his own experience, that I share here as well for future attendees:

  • Book your sessions in advance as soon as you can.
  • Try to book sessions at the same location on a given day (even if it can be sometimes difficult): dimensions go crazy in Vegas.
  • Wear comfy and solid shoes: be ready to walk a lot.
  • Be in advance to your sessions: reserved seating slots are released 10 minutes prior the start time, and given to walk-up.
  • Be well in advance to the keynote sessions if you want to have a chance to get a seat.
  • Try to attend to diverse types of sessions: lectures, chat talks, guided labs…
  • Plan to book half a day to walk around at the Expo in order to connect and discover new solutions

Sources