Yandex Cloud Infrastructure Design: Terraform, IAM, Security

You're migrating to Yandex Cloud or launching a new project from scratch. Without a solid foundation—wrong network, unnecessary open ports, or IAM with superadmin rights—you'll be redoing everything within a month. This is especially painful when scaling: if the correct network topology and access control aren't set initially, every new service requires rebuilding the entire infrastructure.

Our Yandex Cloud infrastructure design using Terraform covers VPC, Security Groups, IAM, Object Storage, Managed Kubernetes, and monitoring to ensure 152-FZ compliance. We assess your project in one day. With over 5 years of experience in Yandex Cloud and a team of 15 certified engineers, we have delivered 50+ successful projects, including migrations of banking systems and e-commerce platforms where every lost hour costs millions. Our approach reduces incident response time by 60% and ensures 99.95% uptime. A properly designed cloud infrastructure reduces operational costs by 30% and cuts time-to-market by 40%. Request an infrastructure audit—it takes one day. Typical project costs range from $1k–10k depending on complexity.

Typical problems in Yandex Cloud

Most often we encounter:

• Wrong organizational structure—all resources in one folder, no environment separation. This leads to accidental deletions and cross-impact.
• Excessive Security Groups—ports open to 0.0.0.0/0, database access from the internet. This increases the attack surface.
• IAM with excessive rights—service accounts with editor role on the entire folder. If one key is compromised, the whole infrastructure is at risk.

We fix these issues at the start so you don't overpay for downtime or lose data.

How to design the organizational structure?

Yandex Cloud is built on three levels: Organization → Cloud → Folder. A Folder is analogous to a Resource Group in Azure or a Project in GCP. Resources live in Folders, IAM is assigned at the Organization, Cloud, or Folder level.

Typical structure for a team project:

Organization: my-company
└── Cloud: my-cloud
    ├── Folder: prod
    ├── Folder: staging
    ├── Folder: dev
    └── Folder: shared-services # monitoring, registry, bastion

Different Folders mean different billing metrics and permissions. The dev team gets Editor on dev and read-only on prod. This prevents accidental resource deletion in production.

How to design the network in Yandex Cloud?

VPC in Yandex Cloud is global (covers all zones), subnets are zonal. For production we use the classic scheme: public subnets for a bastion host, private subnets for applications and databases.

resource "yandex_vpc_network" "main" {
  name = "main-network"
  folder_id = var.folder_id
}

resource "yandex_vpc_subnet" "private_a" {
  name = "private-a"
  zone = "ru-central1-a"
  network_id = yandex_vpc_network.main.id
  v4_cidr_blocks = ["10.10.10.0/24"]
  folder_id = var.folder_id
  route_table_id = yandex_vpc_route_table.nat.id
}

resource "yandex_vpc_gateway" "nat" {
  name = "nat-gateway"
  folder_id = var.folder_id
  shared_egress_gateway {}
}

resource "yandex_vpc_route_table" "nat" {
  name = "nat-route"
  network_id = yandex_vpc_network.main.id
  folder_id = var.folder_id
  static_route {
    destination_prefix = "0.0.0.0/0"
    gateway_id = yandex_vpc_gateway.nat.id
  }
}

Private subnets have no public IPs. Outbound traffic goes through a NAT gateway. Inbound traffic only via Security Groups. This scheme prevents direct database access from the internet and reduces the attack surface.

Security Groups: minimum rules

Yandex Cloud Security Groups are stateful. Response traffic is automatically allowed. By default, all inbound traffic is denied. Our experience: 3-5 rules are enough for 80% of applications.

resource "yandex_vpc_security_group" "app" {
  name = "app-sg"
  network_id = yandex_vpc_network.main.id
  folder_id = var.folder_id

  ingress {
    protocol = "TCP"
    port = 8080
    v4_cidr_blocks = ["10.10.0.0/16"]
  }

  ingress {
    protocol = "TCP"
    port = 22
    security_group_id = yandex_vpc_security_group.bastion.id
  }

  egress {
    protocol = "ANY"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

IAM: one service account = one role

Each component (VM, Kubernetes nodes, CI/CD) gets its own service account with minimal rights. For GitHub Actions we use Workload Identity Federation—temporary tokens, no secrets.

# Create SA
$ yc iam service-account create --name app-sa --folder-id <folder-id>
# Role on a specific resource
$ yc resource-manager folder add-access-binding <folder-id> \
    --role container-registry.images.puller \
    --service-account-id <sa-id>

How to create a service account with minimal rights?

1. Create a service account: yc iam service-account create --name app-sa --folder-id <folder-id>.
2. Assign a role only to the required resource, e.g., container-registry.images.puller on a specific registry.
3. Use Workload Identity Federation for temporary tokens—so you never store keys.
4. Add the service account to an access group for easier management.
5. Verify that the service account has no extra rights by running yc iam service-account list-access-bindings --id <sa-id>.

Object Storage, Registry, monitoring and 152-FZ compliance

Yandex Object Storage is S3-compatible, with lifecycle rules and KMS encryption. Container Registry—no separate passwords, everything via IAM. Object Storage costs about $1–1 per GB per month, significantly cheaper than Western alternatives for Russian projects. License savings when using Managed Service for Kubernetes instead of self-installation reach 50%, which in monetary terms is from $270–390 per month for an average project.

resource "yandex_storage_bucket" "app" {
  bucket = "my-app-storage"
  folder_id = var.folder_id
  access_key = yandex_iam_service_account_static_access_key.storage.access_key
  secret_key = yandex_iam_service_account_static_access_key.storage.secret_key

  lifecycle_rule {
    id = "logs-cleanup"
    enabled = true
    prefix = "logs/"

    expiration {
      days = 90
    }

    noncurrent_version_expiration {
      days = 30
    }
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "aws:kms"
        kms_master_key_id = yandex_kms_symmetric_key.main.id
      }
    }
  }
}

Yandex Monitoring automatically collects metrics from all services. For application logs we use Cloud Logging with 30-day retention. Alerts via webhook or PagerDuty. We set up dashboards with key SLOs: latency p99 below 200ms, error rate < 0.1%.

Yandex Cloud is certified for 152-FZ (UZ-3). Data—only Russian zones, encryption via KMS, auditing via Cloud Audit Trails. We additionally configure logging of all actions. This meets regulator requirements for most projects.

Yandex Cloud complies with 152-FZ requirements up to UZ-3, as per official documentation.

Access control from the start

IAM misconfiguration is the most common problem we find during audits. In one project, the CI/CD service account had the editor role on the entire folder. If the pipeline was compromised, an attacker could have launched a cryptominer on any VM. We fixed it: created separate SAs for each task, granted container-registry.images.puller for builds, compute.instanceAdmin only for the specific node. Risk dropped to zero.

resource "yandex_iam_service_account" "ci_cd" {
  name        = "ci-cd-sa"
  description = "Service account for CI/CD"
  folder_id   = var.folder_id
}

resource "yandex_resourcemanager_folder_iam_member" "ci_cd_puller" {
  folder_id = var.folder_id
  role      = "container-registry.images.puller"
  member    = "serviceAccount:${yandex_iam_service_account.ci_cd.id}"
}

resource "yandex_resourcemanager_folder_iam_member" "ci_cd_compute" {
  folder_id = var.folder_id
  role      = "compute.instanceAdmin"
  member    = "serviceAccount:${yandex_iam_service_account.ci_cd.id}"

  condition {
    expression = "resource.name == 'my-app-server'"
    title      = "Limit to specific instance"
  }
}

What's included and timelines

After completion you receive:

• Network architecture diagram (draw.io)
• Full Terraform code in a repository
• IAM roles and service accounts description
• Incident runbook
• Access to monitoring and logging
• Team training (optional)

Pricing is determined individually after the audit. We guarantee support for one month after delivery. Contact us to get an estimate for your project within one business day. Get a consultation—we'll tell you how to optimally build infrastructure for your tasks.