AWS Summit Madrid 2026: What We Brought Back as a Team

The AWS Summit, Madrid 2026, was a chance to step outside our normal project rhythm, spend time together as a technical team, and look at the AWS ecosystem from a wider angle.

The event took place on June 4 at IFEMA Madrid, and we approached it with a clear intention: not just to attend sessions, but to identify ideas, tools, and conversations that could help us think more clearly about our current and future work.

One of the strongest impressions we took away was the scale and variety of the AWS ecosystem. For several attendees, including people experiencing their first AWS Summit, the event offered a broad view of how AWS services connect to real-world applications. This was especially valuable for those with less day-to-day exposure to AWS infrastructure. The sessions helped build a mental map of concepts such as Lambda functions, VPC networks, EC2 storage, DynamoDB, and the way different services can fit together in production systems.

The booths were one of the clearest highlights. We saw practical demonstrations that made the technology easier to understand: a robotic hand that could follow instructions, a 3D visualization tool for clothing designs, and a game designed for helping understand the different AWS services, among others. These demos were useful because they did not just show a finished product; many also presented the architecture behind the project. Seeing the logic behind the application made the tools feel less abstract and helped connect AWS services to concrete use cases.

Security and compliance were among the most useful topics. Conversations with AWS experts led to concrete recommendations, including Security Hub, GuardDuty, VPC Flow Logs, and centralized firewall architecture. For our team, that kind of practical guidance is especially valuable because it connects event learning directly to the way we manage risk, monitoring, and compliance in real systems.

Observability and monitoring were another major thread. The ‘Datadog’ booth generated interest and a healthy debate. Some of us saw strong potential: better bug detection and resolution cycles, improved tracking of AI-related costs, and opportunities to optimize AWS and operational expenses. Others felt that, given our current context, CloudWatch may still offer the better cost-benefit balance. That difference of opinion is useful rather than contradictory. It shows that the value of a tool depends on scale, timing, and fit.

There was also interest in open-source monitoring and compliance tooling, including conversations around how such tools are expanding beyond cloud environments into areas such as ‘Docker’. The discussion covered pricing, execution models, environments, and report visualization. The takeaway was not that every question had been answered, especially around how to connect monitoring logic with compliance rationales, but that the conversation provided useful pieces of information to continue evaluating.

Artificial intelligence was clearly the dominant theme of the summit. AWS is positioning AI deeply inside its development and infrastructure products, and that was visible across talks, demos, and messaging. 

Within that AI-heavy context, Claude Code on AWS Bedrock stood out. The talk connected to productivity, development process, and the practical impact of AI on engineering teams. What made it memorable was not only the technology itself, but the way the speaker described changes in company workflows and developer collaboration after adopting the tool. The discussion around pros, cons, correct usage, and good practices felt relevant to us. It also raised an important question: how can we use AI more globally across teams while keeping quality, security, and review discipline at the center?

Kiro, an advanced AI-powered Integrated Development Environment (IDE) launched by AWS and designed to act as an autonomous coding agent, received a more cautious reaction. The sessions were useful for understanding concepts, especially when paired with topics like PostgreSQL or CLI-based workflows. However, there were concerns around agentic AI coding workflows, especially when edge cases appear, schemas must remain consistent, or decision-making is still relatively rudimentary. For our current type of projects, the cost and complexity of fine-tuning or implementing such systems may not always be justified. They may become more relevant at larger scales or in environments with many teams working across the same codebase.

The central expert area also helped us think about architecture for current work. Discussions around deployment options, especially when future client volume is unpredictable, opened useful lines of investigation. AWS Lambda and Amazon Fargate came up as options to compare in terms of cost and scalability. Event-driven architecture was another area worth exploring, particularly for data synchronization. These conversations were valuable because they turned general AWS capabilities into possible next steps for real project decisions. 

Another session that stayed with the team focused on code quality metrics. Traditional metrics such as latency, availability, and response time remain important, but AI-enabled systems introduce new questions. If AI becomes part of our solutions or development workflows, we need to think about metrics that were previously less central or did not exist in the same form. That is a practical challenge for teams adopting AI seriously: we need to measure not only whether systems are running, but whether AI-supported outcomes are reliable, useful, and safe.

The summit also reminded us that different levels of experience bring different value to the same event. For first-time attendees, it was a positive introduction to AWS and a way to see the ecosystem more clearly. For people already working with AWS-related services, the strongest value came from expert conversations, tool comparisons, and applied architecture discussions.

Overall, the AWS Summit Madrid 2026, gave us a mix of inspiration and realism. We saw impressive demos, learned about services and patterns that deserve further study, and came back with stronger opinions about what may or may not fit our work. The event was enjoyable, interesting, and useful, but its real value depends on what we do next.

The clearest next step is to turn the summit into decisions. We should continue evaluating AWS security tooling, revisit observability options with a cost-benefit lens, explore how AI solutions could support development practices responsibly, and keep investigating architecture options for scalable deployments and event-driven systems.