Cloud Infrastructure Setup on Google Cloud Platform

GCP setup: where infrastructure breaks first

Cloud infrastructure breaks not on service selection, but in operations.

GCP setup starts with the project, network, and access rights, but the first failures come from elsewhere: someone changed a firewall rule in the console "for a minute," and six months later no one can explain why traffic between services flows exactly that way. There is no way to roll back such a change — no one saved the original state.

The second typical failure point is shared accounts and one project for all environments. Development, the test environment, and production live in one space, so a test run can affect production data, and from access logs it is impossible to understand who changed what. An environment without isolation turns any configuration error into a shared outage.

The third is the absence of a repeatable deployment scheme. Cloud setup is rarely a one-time job: while infrastructure is assembled by hand, it can neither be reproduced from scratch nor can two environments be compared.

Discrepancies accumulate silently and surface during an incident, when a fast rollback to a known-working state is needed.

Infrastructure under load tests all of this at once. Configuration errors that are invisible on test traffic manifest at peak: reserved capacity is insufficient, health checks are set incorrectly, autoscaling hits project limits.

We examine how this is addressed — from environment and role isolation to describing the cloud in code.

What a managed cloud environment provides: measurable effects

Managed infrastructure is not "cloud instead of servers," but rules by which the environment is described declaratively and reproduced from a single source.

In Google Cloud Platform, this approach relies on network policies, access roles, and resource lifecycle rules defined by description rather than manually in the control panel. Below are effects that are visible in operations, not in a work report.

Release frequency grows without a rise in failures

The environment description lives in a repository: a change is first tested in an isolated environment and only then applied to production.

This makes it possible to release updates several times a week instead of one large quarterly release — each release is smaller, and the cost of an error is visible immediately.

Recovery time is measured in minutes

Returning to the previous state is one pass through the same description, not hours of manual reconstruction. Backup and snapshot retention rules are checked regularly, so recovery does not depend on whether someone remembers the sequence of actions.

The class of failures "it worked in test, not in production" disappears along with environment drift.

Availability and predictability instead of manual decisions

Scaling, health checks, and zone failover are defined by policies: the service survives the failure of an individual node without an on-call engineer's intervention.

Access is granted through roles with the minimum required permissions, not a shared administrator key — this closes a common source of incidents.

Load grows according to clear rules, not a phone call: resources are added automatically, and the environment's behavior remains predictable.

Cloud deployment modes: comparison of options

The deployment mode defines the main thing: how separated production and test environments are and what happens if test load or a failed rollout reaches customers.

Environment isolation is built not only on separate clusters — it is determined by projects and accounts, quotas, network policies, and service account permissions. Where these boundaries are drawn determines release speed and the cost of an error.

Below are three schemes that are actually chosen between when setting up GCP. There is no universally best one among them: each breaks in its own load mode.

Limitations do not appear immediately, so the scheme is chosen for a horizon: a single environment is convenient at the start, separated environments when releases happen more than once a week, and hybrid when data or equipment must remain on their own site.

We transition between options in stages: first we move out the test environment, then migrate services one by one, keeping the production link available.

GCP setup stages: from audit to handover

The work proceeds sequentially, and each stage ends with an artifact that is accepted before the next one starts. This way, decisions on access, networks, and backup are recorded once, and the result is verified by reproducible scenarios, not words.

1. Infrastructure audit. We inventory what already runs in GCP, build a dependency map between services, and record target availability and the load profile. The output is a list of bottlenecks and a prioritized change plan.
2. Network and access scheme. We divide the environment into subnets and describe routing, firewall rules, and egress points. We separate roles and service accounts according to the principle of least privilege — compromise of one key does not open the entire project.
3. Environment assembly. Infrastructure is described as code and deployed identically in development, acceptance, and production environments — the "it worked locally" class of errors goes away.
4. Observability. Metrics, logs, and alerts with thresholds for key indicators, so the on-call engineer sees the cause of a failure, not just the fact of it.
5. Fault tolerance testing. We deliberately take nodes and entire zones down in a drill, test automatic failover, and measure the service's actual recovery time.
6. Project handover. We hand over access, diagrams, configurations, and response procedures, and train the team using walkthroughs of typical incidents. After that, the infrastructure runs without us.

What remains with you: configurations, diagrams, procedures

Everything we deploy in the cloud, you receive as working artifacts, not verbal agreements. The environment can be reproduced from scratch, an access rule can be changed, or traffic routes can be understood without contacting us.

• Configuration descriptions. Projects, networks, services, and rights are recorded declaratively: the environment state is deployed from a repository, not assembled manually in the console.
• Network diagram. Address spaces, subnets, routes, internet egress points, and connections to your local sites — with an explanation of which segment is responsible for what.
• Access policies. Roles based on the principle of least privilege, separate accounts for services and people, rules for contractors and external integrations.
• Documentation. How the environment is structured, which services are used, what changes where for typical tasks — from adding a subnet to connecting a new domain.
• Operations procedures. The procedure for rolling out changes, planned maintenance, failure response, rollback to the previous version, and recovery from backups.
• Division of responsibility. A table with areas: what we maintain, what remains with your team, and what the platform covers — so that no "gray" areas arise.

We hand over artifacts as the work progresses, not as a single archive at the end: we accompany them with walkthroughs and answers to questions. Ultimately, support and development of the environment do not depend on who assembled it.

Moving workloads to the cloud: metrics before and after

The team came with a product on manual stands: a release was assembled according to a ten-step instruction, deployment took 4-6 hours, and it was covered by a night window.

The test environment and production diverged in details, so some failures were not reproduced before release, and rollback was performed manually and stretched over hours.

We moved the workload to Google Cloud Platform and described the infrastructure declaratively: the network, access rights, load balancer, database, and compute nodes are created from a single set of configurations.

Environments are no longer assembled "from memory" — the test environment is raised from the same descriptions as production, differing only in scale.

What changed in numbers

Deployment was reduced from hours to 10-15 minutes: build and checks run automatically for every code change. Recovery after a failure went from several hours to minutes, because a node is raised anew from the description, and state is taken from a database replica.

The share of incidents due to environment drift has almost completely disappeared. The remaining failures relate to code and load, not infrastructure — they are visible on graphs, not in emergency restarts.

Repeatability became measurable: versioned descriptions, the same set of configurations, rollback to the previous state in one operation. The team raises and deletes a copy of the environment to test a hypothesis without affecting production.

How does a managed environment differ from your own servers?

The difference is not in where the machines are located, but in who runs the operations cycle. In a managed environment, Google Cloud Platform covers hardware, disk replacement, and base layer updates, while the team is responsible for architecture, configuration, and data. On your own servers, this layer remains in-house — from firmware to night on-call duty.

Change control diverges the most. On your own hardware, a change goes through procurement, installation, and manual configuration — that takes weeks, and the actual state of the machines lives in notes.

In a managed environment, the configuration is described declaratively and stored in a repository: a change undergoes verification, and rollback is done by restoring the previous version.

The team's workload is redistributed, not eliminated. Your own servers require on-call duty, monitoring, and planned updates — this is a separate role that grows with the fleet.

In the cloud, the same engineers are occupied with fault tolerance, access, and release predictability.

The choice is rarely binary: a sensitive environment is left on your own equipment, and the rest is moved to a managed environment. We start with inventorying the load and data requirements — they determine which scheme will produce fewer failures with the same team.

Technical concerns: integrations, access, support

Technical concerns during GCP setup arise at three boundaries: compatibility with already running services, our engineers' rights inside your environment, and support after handover. We address them before the start — while redesigning the scheme is cheapest.

What access will your engineers receive?

Minimally necessary: separate service accounts instead of shared accounts, time-limited roles, and production access only through verifiable changes. Actions are recorded in the audit log, and access is revoked in one operation.

What about support after handover?

The infrastructure is handed over as code and configurations in your repository — you are not tied to us. After that, support with an incident response window and team training: usually after two to three months, your engineers run the system.

What are the data requirements?

The storage region, encryption, role-based access segregation, retention periods, and backups are recorded before work begins. Regulatory and internal security policy requirements become part of the scheme, not an add-on on top of it.

Let's discuss the task: what to prepare for the conversation

The accuracy of estimating the scope for cloud infrastructure depends on the inputs: the more specific the initial picture, the fewer assumptions in the work plan and the lower the risk that timelines slip at the stage of connecting networks and access.

Below is what is worth preparing for the conversation; if some points are not yet defined, that is also an input — we will examine the options together.

• Current scheme. What already runs in the cloud, what remains on your own infrastructure, and how these parts are connected — networks, data exchange, shared authentication.
• Environment requirements. How many environments are needed (development, test, production), whether isolation between them is required, and role-based access segregation.
• Load profile. Peak requests, data volume and nature, availability requirements, and acceptable recovery time after a failure.
• Constraints. Where data must physically be stored, what requirements apply to its protection, and in what windows work can be performed without stopping services.
• Access. Who is the owner of the cloud account and billing profile, who grants rights to read the current configuration and to create new resources.
• What is already automated. Infrastructure description as code, build and deployment pipelines, as well as manual operations that need to be removed first.
• Result and timelines. By what date the production environment is needed, what we consider readiness, and how you will verify the result.

Describe the task in free form — based on these points, we will return with a work plan, scope estimate, and timelines. It is enough to start with a review of the current scheme to outline the stages, control points, and roles on both sides.