Author: Renato Losio

Cloudflare recently published an article detailing their upgrade of developer documentation by migrating from Hugo to the Astro ecosystem. All Cloudflare documentation is open source on GitHub, with opportunities for community contributions.

The developers.cloudflare.com site was previously consolidated from a collection of Workers Sites into a single Cloudflare Pages instance. The process used tools like Hugo and Gatsby to convert thousands of Markdown pages into HTML, CSS, and JavaScript. Kim Jeske, head of product content at Cloudflare, Kian Newman-Hazel, document platform engineer at Cloudflare, and Kody Jackson, technical writing manager at Cloudflare, explain the reasons behind the change in the web framework:

While the Cloudflare content team has scaled to deliver documentation alongside product launches, the open source documentation site itself was not scaling well. developers.cloudflare.com had outgrown the workflow for contributors, plus we were missing out on all the neat stuff created by developers in the community.

In 2021, Cloudflare adopted a “content like a product” strategy, emphasizing the need for world-class content that anticipates user needs and supports the creation of accessible products. Jeske, Newman-Hazel, and Jackson write:

Open source documentation empowers the developer community because it allows anyone, anywhere, to contribute content. By making both the content and the framework of the documentation site publicly accessible, we provide developers with the opportunity to not only improve the material itself but also understand and engage with the processes that govern how the documentation is built, approved, and maintained.

According to the team, Astro’s documentation theme, Starlight, was a key factor in the decision to migrate the documentation site: the theme offers powerful component overrides and a plugin system to utilize built-in components and base styling. Jeremy Daly, director of research at CloudZero, comments:

Cloudflare has open sourced all their developer documentation and migrated from Hugo to the Astro, with the JavaScript ecosystem claiming another victim. No matter how good your documentation is, user feedback is essential to keeping it up-to-date and accessible to all.

According to the Cloudflare team, keeping all documentation open source allows the company to stay connected with the community and quickly implement feedback, a strategy not commonly shared by other hyperscalers. As previously reported on InfoQ, AWS shifted its approach after maintaining most of its documentation as open source for five years. In 2023, the cloud provider retired all public GitHub documentation, citing the challenge of keeping it aligned with internal versions and the manual effort required to sync with GitHub repositories. Jeff Barr, chief evangelist at AWS, wrote at the time:

The overhead was very high and actually consumed precious time that could have been put to use in ways that more directly improved the quality of the documentation.

Gianluca Arbezzano, software engineer at Mathi, highlights the significance of the topic:

If you are thinking: “it is just documentation”, I think you should care a bit more! We deserve only the best! Nice article from Cloudflare about their migration from Hugo to Astro.

Commenting on the Cloudflare article on Hacker News, Alex Hovhannisyan cautions:

I’m sorry but I have to be honest as someone who recently migrated from Netlify (and is considering moving back): the documentation is not very good, and your tech stack has nothing to do with it. End users don’t care what tech stack you use for your docs.

All Cloudflare documentation is available at developers.cloudflare.com.

At the latest re:Invent conference in Las Vegas, Amazon announced the general availability of AWS Glue 5.0, designed to accelerate ETL jobs powered by Apache Spark. The latest release of the serverless data integration service introduces upgraded runtimes, including Spark 3.5.2, Python 3.11, and Java 17, along with enhancements in performance and security.

Designed to develop, run, and scale data integration workloads while getting faster insights, AWS Glue is a serverless data integration service that simplifies the process of preparing and integrating data from multiple sources. The 5.0 release supports advanced features for open table formats, including Apache Iceberg, Delta Lake, and Apache Hudi. It also promises faster job start times, automatic partition pruning, and native access to Amazon S3.

Spark 3.5.2 brings significant improvements to Glue 5.0, including support for Arrow-optimized Python UDFs, Python user-defined table functions, and the RocksDB state store provider as a built-in state store implementation. It also includes numerous improvements related to Spark structured streaming. Additionally, AWS Glue 5.0 updates support for open table format libraries, supporting Apache Hudi 0.15.0, Apache Iceberg 1.6.1, and Delta Lake 3.2.1.

According to the team behind the project, the performance improvements will help reduce costs for data integration workloads:

AWS Glue 5.0 improves the price-performance of your AWS Glue jobs. (…) The TPC-DS dataset is located in an S3 bucket in Parquet format, and we used 30 G.2X workers in AWS Glue. We observed that our AWS Glue 5.0 TPC-DS tests on Amazon S3 were 58% faster than that on AWS Glue 4.0 while reducing cost by 36%.

Within the AWS ecosystem, Glue 5.0 supports native integration with SageMaker Lakehouse, enabling unified access across Amazon Redshift data warehouses and S3 data lakes. Additionally, SageMaker Unified Studio supports Glue 5.0 for compute runtime of unified notebooks and the visual ETL flow editor. The team has also published an article explaining how to enforce fine-grained access control (FGAC) on data lake tables using Glue 5.0 integrated with Lake Formation. They write:

FGAC enables you to granularly control access to your data lake resources at the table, column, and row levels. (…) Using AWS Glue 5.0 with Lake Formation lets you enforce a layer of permissions on each Spark job to apply Lake Formation permissions control when AWS Glue runs jobs (…) This feature can save you effort and encourage portability while migrating Spark scripts to different serverless environments such as AWS Glue and Amazon EMR.

Adriano Nicolucci, principal consultant at Slalom, published a video about Glue 5.0 and comments:

If you’re running ETL workflows, these enhancements will boost performance, cut costs, and streamline operations.

Glue 5.0 is now generally available in all AWS regions where Glue is supported.

Google recently announced support for third-party tools in Gemini Code Assist, including Atlassian Rovo, GitHub, GitLab, Google Docs, Sentry, and Snyk. The private preview enables developers to test the integration of widely-used software tools with the personal AI assistant directly within the IDE.

Offering similar functionalities to the market leader GitHub Copilot, Gemini Code Assist provides AI-assisted application development with AI code assistance, natural language chat, code transformation, and local codebase awareness. Launching these tools in private preview integrates real-time data and external application access directly into the coding environment, enhancing functionality while reducing distractions. Ryan J. Salva, senior director at Google, and Prithpal Bhogill, group product manager at Google, write:

Recognizing the diverse tools developers use, we’re collaborating with many partners to integrate their technologies directly into Gemini Code Assist for a more comprehensive and streamlined development experience. These partners, and more, help developers stay in their coding flow while accessing information through tools that enhance the SDLC.

According to the documentation, the supported third-party tools can convert any natural language command into a parameterized API call, based on the OpenAPI standard or a YAML file provided by the user. GitHub Copilot Enterprise also includes extensions to reduce context switching. Richard Seroter, senior director and chief evangelist at Google Cloud, comments:

Google often isn’t first. There were search engines, web email, online media, and LLM-based chats before we really got in the game. But we seem to earn our way to the leaderboard over time. The latest? Gemini Code Assist isn’t the first AI-assisted IDE tool. But it’s getting pretty good!

With coding assistance being one of the most promising areas for generative AI, Salva and Bhogill add:

Code Assist currently provides developers with a natural language interface to both traditional APIs and AI Agent APIs. Partners can quickly and easily integrate to Code Assist by onboarding to our partner program. The onboarding process is as simple as providing an OpenAPI schema, a Tool config definition file, and a set of quality evals prompts used to validate and tune the integration.

This is not the only recent announcement impacting Code Assist, with support for Gemini 2.0 Flash being a significant announcement. Powered by Gemini 2.0, Code Assist now offers a larger context window, enabling it to understand more extensive enterprise codebases. According to Google, this new LLM aims to enhance productivity by providing higher-quality responses and lower latency, allowing users to “stay in an uninterrupted flow state for longer.” In the “The 70% problem: Hard truths about AI-assisted coding” article, Addy Osmani warns:

AI isn’t making our software dramatically better because software quality was (perhaps) never primarily limited by coding speed (…) What AI does do is let us iterate and experiment faster, potentially leading to better solutions through more rapid exploration (…) The goal isn’t to write more code faster. It’s to build better software. Used wisely, AI can help us do that. But it’s still up to us to know what “better” means and how to achieve it.

Code Assist currently supports authentication to partner APIs via the OAuth 2.0 Authorization Code grant type, with Google planning to add support for API key authentication in the future. Pricing is based on per-user, per-month licenses, with monthly or annual commitments. Licenses range from $19 USD to $54 USD per user per month. A Google form is available to request access to the private preview of Code Assist tools.

The PostgreSQL Global Development Group recently announced the general availability of PostgreSQL 17, the latest version of the popular open-source database. This release focuses on performance improvements, including a new memory management implementation for vacuum, storage access optimizations, and enhancements for high-concurrency workloads.

While the latest GA release includes general improvements to query performance and adds more flexibility to partition management, many database administrators have highlighted the updates to vacuuming, which reduce memory usage, improve vacuuming time, and display the progress of vacuuming indexes. Vacuuming is an operation aimed at reclaiming storage space occupied by data that is no longer needed. The more efficient VACUUM operations in PostgreSQL 17 have been made possible by the new data structure, TidStore, which stores tuple IDs during VACUUM operations. The team explains:

The PostgreSQL vacuum process is critical for healthy operations, requiring server instance resources to operate. PostgreSQL 17 introduces a new internal memory structure for vacuum that consumes up to 20x less memory. This improves vacuum speed and also reduces the use of shared resources, making more available for your workload.

PostgreSQL 17 introduces enhancements to logical replication, simplifying the management of high-availability workloads and major engine version upgrades by eliminating the need to drop logical replication slots. Other recent improvements include enhanced I/O performance for workloads that read multiple consecutive blocks, improved EXPLAIN support, and better handling of IS [NOT] NULL conditions.

While the list of improvements is substantial, the release may lack a standout new feature. Laurenz Albe, senior consultant and support engineer at CYBERTEC, writes:

That’s not because PostgreSQL has lost its momentum: in fact, there are more contributors today than ever before (…) Many smart people have contributed many great things over the years. Most of the easy, obvious improvements (and some difficult ones!) have already been made. The remaining missing features are the really hard ones.

The new version supports the JSON_TABLE option, which enables handling JSON data alongside regular SQL data. Similar to MySQL, JSON_TABLE() is an SQL/JSON function that queries JSON data and presents the results as a relational view.

SELECT *
FROM json_table(
  '[
	{"name": "Alice", "salary": 50000},
	{"name": "Bob", "salary": 60000}
   ]',
  '$[*]'
  COLUMNS (
	name TEXT PATH '$.name',
	salary INT PATH '$.salary'
  )
) AS employee;

Source: Google blog

Dave Stokes, technology evangelist at Percona and author of MySQL & JSON, writes:

JSON_TABLE() is a great addition to PostgreSQL 17. Those of us who deal with lots of JSON-formatted data will make heavy use of it.

Mehdi Ouazza, data engineer and developer advocate at MotherDuck, notes:

The last release of PostgreSQL 17 silently killed NoSQL, aka document store databases. Document store DBs were popular a couple of years ago with the explosion of web applications and APIs (thanks to REST) and the JSON format usage.

The MERGE command is another addition, enabling developers to perform conditional updates, inserts, or deletes in a single SQL statement. This simplifies data manipulation and improves performance by reducing the number of queries. On a popular Reddit thread, user Goodie__ comments:

Postgres manages to straddle the line of doing a little bit of everything, and somehow always falls on the side of doing it awesomely, which is exceedingly rare.

Cloud providers have already begun supporting the latest version of the popular open-source relational database. Amazon RDS has had it available in the preview environment since last May, and Cloud SQL, the managed service on Google Cloud, recently announced full support for all PostgreSQL 17 features.

All bug fixes and improvements in PostgreSQL 17 are detailed in the release notes.

Amazon has recently announced that AWS CodeBuild, its managed build service, now supports building applications on macOS. However, due to Apple’s licensing requirements, developers must still reserve a dedicated macOS fleet to utilize this new option.

Building, testing, signing, and distributing applications for Apple systems (iOS, iPadOS, watchOS, tvOS, and macOS) require the use of Xcode, which runs exclusively on macOS. Although running CI/CD pipelines on Mac instances has always been possible, managing and automating macOS machines has presented various challenges in the fast. Sébastien Stormacq, Principal Developer Advocate at AWS, writes:

The first is to prepare the Amazon Machine Image (AMI) with all the required tools for the build. A minimum build environment requires Xcode, but it is very common to install Fastlane (and Ruby), as well as other build or development tools and libraries. Most organizations require multiple build environments for multiple combinations of macOS and Xcode versions.

AWS CodeBuild is a continuous integration service that provides prepackaged build environments for popular programming languages and tools like Apache Maven and Gradle. It compiles source code, runs unit tests, and produces artifacts. The new CodeBuild images for Mac builds come with macOS and Xcode pre-installed and support a variety of tools and frameworks, including Java, Kotlin, Node.js, Python, Ruby, Rust, and Swift.

CodeBuild for macOS utilizes reserved fleets, leveraging the reserved capacity feature introduced earlier this year, which is designed for building and testing in latency-sensitive scenarios. The service builds artifacts on Apple M2 instances running macOS 14 Sonoma. Stormacq explains the second major challenge that Mac builds on AWS CodeBuild addresses:

Large organizations typically have hundreds or thousands of builds per day, requiring dozens of build machines. Scaling in and out of that fleet helps to save on costs. EC2 Mac instances are reserved for your dedicated use. One instance is allocated to one dedicated host. Scaling a fleet of dedicated hosts requires a specific configuration.

Unlike on-demand fleets, where customers pay per minute of build time, reserved fleets are charged for the entire duration that the build machines are reserved for exclusive use, even when no builds are running. The capacity reservation adheres to Amazon EC2 Mac’s 24-hour minimum allocation period, as required by the SLA for macOS. Piero Bozzolo, cloud engineer and serverless developer at Claranet, comments:

For teams or developers with low build frequency (just a few dozen builds a month), this might not be cost-effective. I sincerely hope that Apple will consider and remove the 24-hour minimum lease for their OSs.

According to the AWS documentation, preparing an EC2 Mac instance takes 8-10 minutes. While this isn’t specific to CodeBuild, any builds submitted during this preparation time are queued and will be run in order as soon as the machine becomes available.

Mac builds are currently available in only five regions: Ohio, Northern Virginia, Oregon, Frankfurt, and Sydney.

In a surprising move for both the open-source and Elastic communities, Shay Banon, founder and CEO of Elastic, recently announced that Elasticsearch and Kibana will once again be open source. The two products will soon be licensed under the AGPL, an OSI-approved license.

Just over three years ago, Elastic relicensed their main products from Apache 2.0 to a dual-license model under the Server Side Public License (SSPL) and the new Elastic License, neither of which are OSI-compliant open-source licenses. This change prompted AWS to fork Elasticsearch, leading to the creation of OpenSearch, which continues to operate under the Apache 2.0 license. Banon explains the goal of this latest change:

We never stopped believing and behaving like an open-source community after we changed the license. But being able to use the term Open Source, by using AGPL, an OSI-approved license, removes any questions, or fud, people might have.

Sometimes referred to as the “server-side GPL,” the AGPL was approved by OSI in 2008. It requires that the source code of all modified versions of the software be made available to all users who interact with it over a network, offering protection against challenges by cloud service providers. Banon adds:

We have people that really like ELv2 (a BSD-inspired license). We have people that have SSPL approved (through MongoDB using it). Which is why we are simply adding another option, and not removing anything. (…) We chose AGPL, vs another license, because we hope our work with OSI will help to have more options in the Open Source licensing world.

While Luc van Donkersgoed, principal engineer at PostNL, described this as one of the weirdest press releases ever, Peter Zaitsev, open-source advocate, writes:

I wonder though if community trust can be repaired as quickly? Can we count on Elastic to stick to Open Source this time or is the license likely to be changed to serve the need of the moment?

On HackerNews, Adrian Cockcroft, tech advisor and formerly VP at AWS, references an article he wrote in 2018 about the Open Distro for Elasticsearch and comments:

At the time we didn’t think a new license made sense, as AGPL is sufficient to block AWS from using the code, but the core of the issue was that AWS wanted to contribute security features to the open source project and Elastic wanted to keep security as an enterprise feature, so rejected all the approaches AWS made at the time.

Lars Larsson, field CTO at Elastisys, comments:

I find it hard to believe that the community will flock back to Elasticsearch: When Elastic closed the source, a lot of companies and individuals saw their contributions to the Apache 2 codebase all of a sudden locked into only creating value for Elastic. This burns the community, just like when Hashicorp took all their previously-open products and closed them up.

Guido Iaquinti, CTO and co-founder at SafetyClerk, agrees:

Trust is something that takes a long time to build but can be shattered in an instant. Only time will tell, but for now, I see no reason why people shouldn’t continue to stick with OpenSearch.

In the article, Banon acknowledges that the community might experience confusion and surprise and attempts to address the main questions. He denies that the 2021 license change was a mistake and wants to dispel concerns that the AGPL is not a true open-source license.

The inaugural European InfoQ Dev Summit is set to take place in less than a month at the Hilton Munich Park Hotel. Following the successful format of the recent InfoQ Dev Summit Boston, the two-day conference for senior software engineers, architects, and team leaders will be held in the Bavarian capital on September 26th and 27th.

Security standards and site reliability engineering will be two of the major themes at the conference, which coincides with the first week of the Oktoberfest festival. Mykhailo Brodskyi, principal software architect at PagoNxt, will discuss comprehensive approaches to software supply chain security:

Developing software in the highly regulated FinTech industry presents unique challenges due to the complexity and risks involved. Regulatory frameworks significantly impact architecture decisions, requiring attention to compliance and data security standards.

Kennedy Torkura, CTO and co-founder at Mitigant, will explain cloud attack emulation, a novel approach for continuously validating security posture by proactively testing the people, processes, and technology aspects of enterprise security strategies:

With cloud security mechanisms increasingly overwhelmed by the fast-evolving cyberattacks, organizations must adopt practical cyber resilience to move from preventing attacks to quick detection, response, and recovery.

Join us in Munich to learn how cloud configuration visibility can enhance an organization’s security posture. Danielle Sudai, security operations lead at Deliveroo, will explore the often-overlooked complexities of cloud configurations. Sudai explains:

Companies are heavily invested in CSPM and CNAPP solutions, revealing misconfiguration in their cloud-based infrastructure. My session will explain how those are identified and what the profit is in understanding our organizational threats to fine-tune detection rules and selecting SaaS/cloud-native tooling.

Michael Friedrich from GitLab will lead a session on building efficient AI workflows, focusing on practical prompts and advanced practices with custom LLMs, retrieval-augmented generation (RAG), and AI agents.

Local speakers from Munich, including practitioners from Nvidia and Siemens, will deliver various talks. In the two keynotes, Teena Idnani and Nischal HP will respectively delve into the dawn of quantum computing and AI in the age of climate change. Nischal HP explains:

I will be taking us on a journey to understanding climate change, what are the main contributors to it, focusing on agriculture and AI, and how this holds the key to changing for human kind.

Thanks to over 20 technical talks from senior software practitioners, the first InfoQ Dev Summit in Munich will offer actionable insights and practical advice on today’s developer priorities. As the chair of the InfoQ Dev Summit, I look forward to meeting you and your fellow senior software practitioners in Munich next month!

At the recent Cloud Next conference in Tokyo, Google announced Spanner Graph, a managed feature that integrates graph, relational, search, and AI capabilities within Spanner. This new database supports a graph query interface compatible with ISO GQL (Graph Query Language) standards while avoiding the need for a standalone graph database.

Spanner Graph now combines graph database capabilities with Cloud Spanner, Google Cloud’s globally distributed and scalable database service that provides horizontal scaling and RDBMS features without the need for sharding or clustering. One of the goals of the project is the full interoperability between GQL and SQL to break down data silos and lets developers choose the tool for the specific use case, without extracting or transforming data. Bei Li, senior staff software engineer at Google, and Chris Taylor, Google fellow, explain:

Tables can be declaratively mapped to graphs without migrating the data, which brings the power of graph to tabular datasets. With this capability, you can late-bind (i.e., postpone) data model choices and use the best query language for each job to be done.

While graphs provide a natural mechanism for representing relationships in data, Google suggests that adopting standalone graph databases leads to fragmentation, operational overhead, and scalability and availability bottlenecks, especially since organizations have substantial investments in SQL expertise and infrastructure. Taylor comments on LinkedIn:

Interconnected data is everywhere, and graph query languages are a fantastic way to understand and gain value from it. With Spanner Graph, you can have the expressive power and performance of native graph queries, backed by the reliability and scale of Spanner.

A highly anticipated feature in the community, Spanner Graph offers vector search and full-text search, allowing developers to traverse relationships within graph structures using GQL while leveraging search to find graph content. Li and Taylor add:

You can leverage vector search to discover nodes or edges based on semantic meaning, or use full-text search to pinpoint nodes or edges that contain specific keywords. From these starting points, you can then seamlessly explore the rest of the graph using GQL. By integrating these complementary techniques, this unified capability lets you uncover hidden connections, patterns, and insights that would be difficult to discover using any single method.

Among the use cases suggested for the new Spanner Graph, the cloud provider highlights fraud detection, recommendation engines, network security, knowledge graphs, route planning, data cataloging, and data lineage tracing. Eric Zhang, software engineer at Modal, comments:

Google’s new Spanner Graph DB looks pretty awesome and hints at a world where multi-model databases are the norm.

Rick Greenwald, independent industry analyst, adds:

By having graph, as well as structured data, search operations and vector operations all accessible within the same SQL interface, Spanner essentially removes the need for users to understand what database technology they need and implement it before they can get started solving problems. The range of options to derive value from your data expands, without undue overhead.

Previously, Neo4J was the recommended deployment option on Google Cloud for many use cases now covered by Spanner Graph. Google is not the only cloud provider offering a managed graph database: Microsoft offers Azure Cosmos DB for Apache Gremlin, while AWS introduced Amazon Neptune years ago, a service distinct from NoSQL Amazon DynamoDB, which was previously recommended for similar scenarios.

A codelab is now available to get started with Spanner Graph. During the conference, Google also announced new pricing models and GoogleSQL functions for Bigtable, the NoSQL database for unstructured data, and latency-sensitive workloads.

For the first time in its history, AWS has discontinued several managed services within a matter of days. Among the affected services are the source control AWS CodeCommit, the cloud-based IDE AWS Cloud9, and the time-series forecasting service Amazon Forecast. The wave of deprecations has led to concerns within the community due to the lack of clear communication.

After deprecating the ledger database Amazon QLDB, as separately reported on InfoQ, AWS began posting articles to document how to replace CodeCommit with other Git providers, CloudSearch with OpenSearch, and Cloud9 with AWS IDE Toolkits. While the technical articles provided useful information, they did not initially clarify whether the existing services had been discontinued, leaving the community in a state of uncertainty.

None of the retirements — S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline, and CodeCommit — appeared on the announcement page and feeds, a practice that other providers usually follow. While existing customers might have received emails clarifying the status of the affected services, others were left wondering if the services were still supported or if AWS was changing its philosophy. To clarify the status of the affected services—a small percentage of the over 200 available—Jeff Barr, vice president and chief evangelist at AWS, confirmed:

After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit. While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today, including keeping them secure and reliable. We also support migrations to other AWS or third-party solutions better aligned with your evolving needs. Keep the feedback coming. We’re always listening.

Matthew Juliana, senior manager at Rackspace Technology, highlights how Barr’s message significantly differs from the “retiring services isn’t something we do at AWS” statement that Werner Vogels, CEO at Amazon, wrote just over a year ago. SimpleDB, a service superseded by DynamoDB over a decade ago, has often been used as an example of AWS not killing services like other providers do. In the article “The end of the Everything Cloud“, Forrest Brazeal comments:

This is not an indication that AWS is turning into GCP, who has inherited from broader Google a deserved reputation for pulling the rug out from under users by killing services with wide adoption (…) These services have been in maintenance-only mode for some time.

Andrew Brown, CEO of ExamPro, writes:

Whether this is a marketing blunder or not to me the idea of AWS cleaning up their catalog and killing off zombie AWS Services and Products is a good idea.

After suggesting that AWS should provide a deprecation page, Scott Piper, cloud security consultant, now maintains a list on GitHub of the services that have been deprecated. Scott writes:

I’d also like to hear the strategy moving forward around this in terms of whether this is a one-time event, or if we should expect more batches of deprecations (…) how should one be evaluating services now that a change in strategy has happened at AWS?

Since the original posts, various deprecation notes have been added to the articles documenting the migrations from the affected services, clarifying the status of each one.

Amazon recently released the AWS User Guide to the Digital Operational Resilience Act (DORA). The document details how AWS services support financial entities in complying with DORA’s requirements for operational resilience, including ICT risk management, incident reporting, testing, and third-party risk management.

Released over a year after submitting a response to the consultation on the second batch of DORA technical standards, the new guide offers a series of considerations for financial entities (FEs) seeking to meet the regulatory expectations set by DORA. It explains how FEs can utilize AWS services and documentation to help demonstrate their compliance with DORA requirements.

As the financial sector becomes increasingly dependent on technology and a few cloud companies to deliver financial services, DORA introduces new regulatory requirements to achieve a high common level of digital operational resilience. It entered into force on January 16, 2023, and will require compliance by January 17, 2025.

Stephen Martin, head of security and compliance for financial services industries at AWS, Akshay Dalal, EMEA regulatory risk and compliance at AWS, and Eduardo Vilela, Head FSI reg. enablement EMEA at AWS, explain:

This guide describes the roles that AWS and its customers play in managing operational resilience in and on AWS, describes the AWS Shared Responsibility Model, compliance frameworks, AWS services, and features, and measures that customers use to evaluate their compliance with sample DORA requirements when adopting AWS.

The new European regulation covers ICT risk management requirements, reporting major ICT-related incidents and cyber threats, digital operational resilience testing, and information sharing on cyber threats and vulnerabilities. It includes measures for managing ICT third-party risk across 20 different types of financial entities and ICT third-party service providers, including major cloud providers. Maria E. Tsani, head of financial services public policy EMEA at AWS, previously wrote:

Our lack of visibility into data uploaded into a customer’s AWS account is a fundamental part of the governance model that operates in a cloud environment (the AWS Shared Responsibility Model).

While the regulation does not set any restrictions on the adoption and use of cloud services, Martin, Dalal, and Vilela add:

The regulation promotes a principles-based approach to ICT risk management, giving FEs the flexibility to use different management models as long as they address key functions such as identification, protection, detection, response, recovery, and communications.

One of the debated topics is the reliance on a single cloud provider. András Gerlits, founder at omniledger.io, comments:

Confusingly, DORA says you are legally allowed to use your exclusive cloud provider, but disallows this technically. It does this by expecting banks to have a monitoring, a mitigation and a recovery strategy in place in case of a disruption event. So sure, use your AWS/Azure/GCP for everything, but you must also be able to shift immediately with no data loss.

AWS is not the only cloud provider recently outlining its steps towards DORA compliance. Google has simplified the process with Google Cloud’s updated contracts and Microsoft has explained how to strengthen operational resilience and reduce concentration risk in financial services. IBM and Oracle OCI also provide dedicated resources.