Марія Бровінська Work 18 June 2026, 15:20

Rife transformed Cloud Governance into a Developer Experience for 370+ engineers. How the bank taught the platform to make the right engineering decisions

Today, Raiffeisen Bank’s cloud environment includes over 100 AWS accounts, over 40 teams, and over 370 engineers who work with the cloud infrastructure every day.

On this scale, the main challenge is no longer creating infrastructure.

The challenge is the organization’s ability to maintain speed, transparency, and manageability without turning every change into a bureaucratic process and creating dependence on a narrow circle of experts.

This is precisely the problem that Raiffeisen Bank has been solving in recent years, gradually transforming Cloud Governance from a control system into an element of Developer Experience.

Landing Zone doesn’t solve all problems

Like most large organizations, Raiffeisen Bank started its cloud transformation with a Landing Zone .

Landing Zone provided each team with standardized AWS accounts, network architecture, centralized access control, logging, and basic security mechanisms. This foundation became an important starting point for further development of the cloud platform.

However, as the number of teams grew, it became apparent that Landing Zone standardizes the environment, but does not standardize the way of working within it.

In fact, Landing Zone answers the question «where to work», but does not answer the question «how to work».

Different teams organized their Terraform code differently, used different approaches to IAM, and had their own naming conventions and tagging standards. Some changes were made through the AWS Console or local terraform apply. The Code Review process also differed between teams.

When CloudOps engineers analyzed infrastructure code from different teams, they often saw multiple ways to solve the same problem. Each solution was technically correct, but at the organizational level, this diversity gradually made it difficult to maintain, audit, and transfer knowledge between teams. At the individual team level, this looked like flexibility, but at the organizational level, this diversity gradually created operational risk.

From experts to a knowledge platform

It is important that the current model is not the result of the work of one team.

It has been shaped over the years by the contributions of architects, IT security specialists, platform and product teams, CloudOps engineers and a large number of enthusiasts from different areas of the bank. The key factor is that the CloudOps team itself can build, but cannot design, a mechanism that takes into account the needs of the entire IT Bank. This mechanism can only be the result of fruitful cooperation between its users and its developers.

As a result, an engineering community was formed, which gradually accumulated practices, standards and approaches, which later became part of the platform. At some point, it became clear that it was not the infrastructure that needed to be scaled, but the accumulated knowledge of the organization. After that, any problem began to go through the path: description → standardization → automation.

Architectural decisions, IT security requirements, infrastructure standards, and change management rules began to be transferred directly to the platform — into the repository structure, Terraform modules, automated policies, and change processes.

This is how the set of tools used on top of Landing Zone gradually turned into an additional operational layer that unified not only the infrastructure environment, but also the way it was managed.

His goal was to create a system that would allow hundreds of engineers to work according to the same rules, but without constant appeals to specialized specialists. Everything that previously had to be agreed upon in correspondence could now be checked automatically.

«We tried to make the right solution the simplest solution. If an engineer has to remember dozens of local rules, then the system is not mature enough,» explains Pavlo Klets.

Pavlo Klets, Head of Cloud Solutions Implementation at Raiffeisen Bank

Single framework: Terragrunt as a Don’t Repeat Yourself framework for Terraform

At a scale of over 6,500 Terraform plans, the main challenge was not developing new configurations, but their support, reuse, and manageability. That is why the Bank switched to a model where engineers work primarily with ready-made Terraform modules, and Terragrunt is used as a mechanism for building a unified structure and managing dependencies.

Today, the bank’s cloud infrastructure contains over 1,000,000 lines of cloud service configurations in AWS and OCI (Oracle Cloud Infrastructure). A separate Git repository with Terragrunt code was built for each cloud provider. This allowed us to fully transition to Terraform modules. In fact, Terraform modules have become an internal catalog of proven engineering solutions.

Now, the structure of these Terragrunt repositories reflects both the boundaries of team responsibility and the real-world resource ownership model. Thanks to this, engineers can quickly find the necessary configurations, understand the context of changes, and determine who is responsible for any infrastructure component. In effect, this set of Git repositories has become the operational point of truth for the entire cloud platform.

A single process: Atlantis, the tool that transformed a complex banking change process into ChatOps

In addition to the code structure, Raiffeisen Bank has also unified the process of making changes.

All infrastructure changes go through a single process built around Pull Requests. The engineer sees upcoming changes before they are applied, automatically passes policy checks, and involves responsible resource owners in the review. This has made control part of the usual development process, rather than a separate bureaucratic procedure.

Atlantis became a key element of the process, which allowed us to make the above process a mandatory part of every Pull Request.

To quickly find the owners of resources that will be involved in the Pull Request review, the GitHub Code Owners mechanism is used. A similar approach is also supported in GitLab and other systems and allows you to determine who is responsible for certain directories with code.

Open Policy Agent (OPA) is integrated into Atlantis Workflows and performs automatic compliance checks against internal policies and IT security requirements. This allows control and audit teams to manage automated checks, quickly adding all new requirements to the Git policy repository. Now all regulatory requirements are reflected in the code and versioned, which simplifies monitoring their implementation.

Manual changes via the AWS Console are of course also possible, but are only allowed as an exception during critical incidents and have a separate mechanism for controlling the actions of incident participants. However, changes that are part of daily workflows are made only through Pull Requests with Atlantis, which minimizes the possibility of human error, even if the executor does not fully understand all the requirements.

Today, each change has a defined owner and a recorded history of decision-making by all process participants, available for audit and compliance analysis.

Over the past year, the platform has handled over 5,400 Pull Requests for infrastructure changes. The full change cycle — from creating a Pull Request to deploying it to the infrastructure — takes 26 minutes (median over the past year). All this allows us to maintain a balance between the speed of change delivery and the manageability of their quality on a scale of hundreds of engineers.

A single repository of knowledge: Open Policy Agent and Terraform modules

One goal was to make sure that domain experts were no longer required to be on board with every change. Architects, IT security specialists, and platform engineers no longer had to manually review every solution. They were tasked with transferring their requirements and approaches into Terraform modules and Git repositories with policies.

Any requirement that regularly arose during reviews, consultations, or audits went through the same path: description — standardization — automation.

As a result, a significant part of the requirements for the structure of the infrastructure code, access settings, encryption and tagging of resources is now implemented directly in Terraform modules and OPA policies. For the engineer, this means that he receives a significant part of the checks even before other teams are involved. The platform itself signals deviations from standards and allows you to fix most problems at the Pull Request stage.

This is how the checks for the content of VPC Security Groups and IAM Policies are implemented. If the Terraform plan does not contradict the defined policies, the check is automatically considered passed and does not require additional involvement of specialized specialists.

If a conflict with policies or standards is identified, relevant experts are automatically involved in the Pull Request through comments and can assess the appropriateness of the exclusion or provide the necessary approval. As a result, much of the process is automated, but the same level of control and expert oversight is maintained.

As a result, knowledge ceases to exist only in the heads of individual experts. It becomes part of the platform and automatically scales to hundreds of engineers at the same time.

Previously, a typical infrastructure change might require 3-5 separate approvals via Jira and email. Today, the entire process is reduced to a single Pull Request on GitHub, which automatically engages the necessary experts and performs most of the reviews without human intervention.

This allowed us to simultaneously improve the quality of the infrastructure, reduce the number of manual approvals, and reduce the time-to-market for business features by several times. Both the Bank’s teams and its clients benefited from this.

Cloud Governance as a Developer Experience

Raiffeisen Bank is convinced that at a certain scale, Cloud Governance ceases to be exclusively a question of quality control. It becomes part of the Developer Experience. The task is not to limit the work of the engineer, but to provide comfortable tools for self-testing. It is the possibility of self-testing that significantly reduces the number of questions that people did not dare to ask, or did not find the time. And this is the key to the quality of technical solutions.

«On a scale of hundreds of engineers, Cloud Governance is now becoming an element of the Developer Experience. Its task is not to limit engineers, but to reduce cognitive load and help make the right decisions quickly and independently. All this forced us to create a framework in which you don’t need to schedule a meeting to be sure that your technical solution will satisfy everyone,» says Pavlo Klets.

The more standard solutions, proven practices, and automated controls the platform takes on, the lower the pressure on the engineer becomes and the better he can focus on creating value for the business.

At the same time, Developer Experience is not about implementing the latest tools or popular technologies. The real value comes when the tools reflect the way an organization works: its processes, team structure, accountability models, information security requirements, and change management practices.

In other words, the Platform should adapt to the Organization, not the Organization to the Platform.

It is when the tools that make up the platform begin to reflect the real processes of the company that they accelerate work and help scale the organization’s accumulated experience. And only then does the platform reduce the initial requirements for the engineer, accelerate his involvement in a new project and allow him to concentrate on business tasks. And the predictability of quality ceases to be the task of the performer — it becomes the task of the platform. And this is important for both development teams and teams that manage the infrastructure, because in the world of cloud technologies their work is no longer at all different from classic development.

Hryhoriy Tatsy, Director of the IT Technology Development Department of Raiffeisen Bank

Raiffeisen Bank views this approach not only as a technical initiative, but as part of an overall IT strategy.

«It is important for us that engineering teams can move quickly without sacrificing security, transparency, and manageability. That is why standardization, test automation, and Developer Experience are interconnected elements of one system,» notes Grigoriy Tatsy, Director of the IT Technology Development Department at Raiffeisen Bank.

According to him, a modern platform should not only provide access to technology, but also scale an organization’s best practices through tools and processes.

One of the best indicators of platform maturity in a bank is the speed of onboarding, both of new people and new systems. A new engineer already spends months learning internal rules and processes — in 2026, Raiffeisen Bank’s Time To 1st Pull Request metric reached an average of 11 days and 40 days for Time to 10th Pull Request. Because between his code changes and his actual deployment in the cloud, there is an entire Cloud Governance platform that embodies the experience of hundreds of his colleagues.

If you start today

It’s important to understand that most organizations don’t need to build a complex platform with dozens of tools right away. Almost everything described in this article starts with fairly simple things.

First, you need to agree on a single way to make changes. If one team works via Pull Request, another via AWS Console, and a third via local terraform apply, then no Cloud Governance model will work.

After that, it’s worth getting the Terraform code structure in order and defining who is responsible for each part of it. This is what usually gives the greatest effect in the early stages.

The next step is to start looking closely at the comments from architects, IT security, and platform teams. If the same requirement is repeated for the tenth time in a row, it’s a good candidate for automation. If it can be checked automatically, it shouldn’t be checked by a human.

This is how the platform is gradually formed. Not through the implementation of fashionable tools, but through the transfer of the organization’s accumulated experience into code, Terraform modules and automatic checks. Almost five years of development of Cloud Governance at Raiffeisen Bank led to a simple conclusion: it is not the infrastructure that needs to be scaled. It is the organization’s accumulated experience that needs to be scaled.

Cloud Governance as a Foundation for AI

Additionally, it is worth noting that modern AI assistants work best in environments where the structure, processes, and rules of the organization are described in code. Terraform modules, Open Policy Agent policies, standardized repository structure, and processes for making changes through Pull Requests have effectively become a formalized description of the Bank’s engineering practices.

This gives AI access not only to the infrastructure code, but also to the organization’s accumulated knowledge about security, architecture, change management, and development standards. In a sense, AI has become another engineer working inside the Bank, and it also needs a clear context to make the right decisions.

That is why investments in Cloud Governance today simultaneously become investments in an organization’s ability to effectively use AI, because modern language models can only scale knowledge that has already been formalized and transferred from engineers' heads into code, policies, and automated processes.

Resume

Raiffeisen Bank’s experience shows that on a large scale, Cloud Governance platform ceases to be a set of technical limitations. It improves the daily experience of engineers, makes their difficult work more comfortable and creates conditions for initiative.

The goal of such a platform is to create an environment in which the right engineering decisions are made naturally, quickly, and predictably. It then becomes a mechanism for scaling knowledge, practices, and expertise across the organization.

As a result, the right decision no longer depends on whether the engineer has found the right expert, whether he remembers all the local rules, or whether he has enough experience in this particular subject area. The platform itself helps to move on the right path.

And that is why today Cloud Governance is not only an element of cloud management, but also one of the foundations of Developer Experience and the use of AI.

How Raiffeisen Bank transformed the sale of government bonds from a manual process to a digital scenario in MyRaif: BPM microservices and over 10 integrations