1C-Bitrix Deployment on AWS: Architecture and Optimization Turnkey

Deploying 1C-Bitrix on AWS: where the project breaks

Deploying 1C-Bitrix on AWS most often stumbles not at the migration stage, but two to three weeks after launch, when the site reaches real traffic.

The classic scenario: the file cache sits on the instance's local disk, and when scaling under load a second node is spun up — and half of the visitors get pages assembled from stale data.

Components tied to bitrix/cache start serving different content depending on which instance the request landed on, while hit-bound agents duplicate tasks on every node.

The second source of failures is sessions and file uploads. If sessions are stored locally, a load balancer without sticky sessions scatters the user across different servers, and the cart "gets lost" at checkout.

Files uploaded via web forms settle on the disk of a single instance and disappear when it is replaced in the autoscaling group — and along with them, email attachments and documents in deals.

Peak requests finish off what's left: without offloaded cache and queues, PHP-FPM hits the worker limit, and heavy database queries block the rest.

The site doesn't "go down" entirely — it degrades: response time grows from tenths of a second to several seconds, and some requests drop off by timeout.

To the business this looks like "the site is slow at peak hours," even though the cause is architecture, not hardware capacity.

Fault tolerance in the cloud doesn't appear just because an instance is deployed across multiple availability zones.

You need a shared cache layer, offloaded sessions, object storage for media, and a database replica with automatic failover — otherwise restarting a single node turns into downtime. Below we break down how this is addressed at the architecture level, not with workarounds.

What a well-designed cloud architecture delivers

Response time under control

Application-level caching and serving static assets via CDN remove most repeat requests from the server — dynamic processing is reserved only for authenticated scenarios and the shopping cart.

In practice, catalog page response time is reduced severalfold, and the database stops being a bottleneck: heavy queries move to a separate node with a read replica. The client gets predictable speed across all traffic, not just on a test environment.

Resilience to peaks

Autoscaling based on load metrics adds application instances as traffic grows and removes the excess ones once the peak has passed. Load balancing between nodes and health checks remove a failed instance from rotation without manual intervention.

Sales, seasonal spikes, and ad campaigns go off without "the site is down" — the system scales up capacity on its own.

Fewer manual operations

Building and deploying releases follows a single scenario: database migrations, cache warming, switching traffic to the new version, and rollback with a single command.

Backups are taken on schedule and verified for restoration, rather than "when we remember." This eliminates an entire class of failures — from a forgotten backup to a manual edit in production.

The class of failures that goes away

A dedicated database node with a replica survives the failure of a single application instance, and data resides in fault-tolerant storage with versioning. Monitoring catches degradation by metrics before the user notices it.

Instead of emergency calls, the team gets planned maintenance and a clear recovery procedure — downtime is measured in minutes, not hours.

Deployment options: comparing approaches

Deploying 1C-Bitrix on AWS is not a matter of choosing "one right" option, but of matching a scheme to the load, fault-tolerance requirements, and operating budget.

Below are three approaches that teams realistically choose between at the start, along with the limitations they most often stumble over.

Amazon Web Services provides all three options out of the box: the only difference is how much managed infrastructure you are prepared to pay for and maintain.

Fault tolerance is not a binary flag but a set of solutions: redundancy across availability zones, a database replica with automatic failover, health checks on the load balancer, moving sessions and uploaded files to shared storage.

Each item adds cost and complexity, so a cluster is assembled for a specific target availability level, not "just in case."

In practice, most projects start with a single server and, as they grow, move production to a cluster, leaving the hybrid where data is required to remain in its own environment.

We analyze the load and downtime requirements, then propose a scheme with an estimate and a migration plan.

Implementation stages: from audit to handover

Deploying 1C-Bitrix on AWS is not "spin up a server and upload the code," but a sequence of engineering decisions, each of which affects delivery speed and total cost of ownership.

Below is how we run a project: from the initial audit to handing the infrastructure over to your team.

1. Audit of the current environment. We look at how the site behaves under load: where the bottleneck is — database queries, cache, static file delivery, cron jobs. We record the traffic profile and peak windows so we can design for real load rather than guesswork.
2. Architecture design. We break the application down into the web layer, database, and file storage, define availability zones, the autoscaling scheme, and failure points. At this step we decide what to move to managed services and what to keep on your own instances.
3. Environment setup. We deploy the servers, configure the web server and PHP for Bitrix, connect the database, object storage for static files and media, the load balancer, and the CDN. We describe the configuration as code — the environment is reproduced with a single command.
4. Performance optimization. We set up caching at all levels, composite cache, database indexes, and move heavy tasks to background processing. We measure response time before and after — the effect is visible in numbers, not in words.
5. Testing and fault-tolerance verification. We run load scenarios, check behavior when a node goes down, and verify the correctness of backup and recovery. We make sure that rollback to the previous version works.
6. Documentation. We hand over the architecture diagram, configuration description, backup policies, and instructions for typical operations — so that your team understands the system without us.
7. Handover and support. We carry out the handover of access and knowledge, and stay on for support: monitoring, updates, incident response.

Each stage ends with a verifiable result, so the project does not drag on and risks are visible at the early steps. Describe your task — we will come back with an estimate and a plan for your environment.

What the client receives

A cloud deployment does not end with a working website — it ends with a complete set of materials your team can use to operate, scale, and restore that website without us. Everything we configure is captured as files and documents, not left in the engineers' heads.

• Infrastructure configuration as code — descriptions of all environments (production, test, recovery rehearsal) in a repository: the same set is deployed repeatedly without manual edits, and drift between environments is eliminated.
• Architecture diagram — what lives where: load balancer, web nodes, database, cache, queues, user file storage, external backup points. With notes on which nodes scale horizontally and which remain a single point.
• Access policies — roles and permissions for developers, administrators, and contractors, network restriction rules, the procedure for granting and revoking temporary access, and separation of permissions between production and test.
• Backup and recovery policy — what is backed up, how often, where it is stored, and how long it is retained; separately, a step-by-step recovery scenario with a target downtime.
• Update policy — how a new version of the core and modules is rolled out, in what order, how it is tested on the test environment, and how it is rolled back if a release goes wrong.
• Monitoring and alerts — the set of tracked metrics, trigger thresholds, and notification routes: who receives a signal and in which channel when the website starts to degrade.
• Instructions for the team — short scenarios for typical operations: add a website or domain, connect a new module, grant access, bring up an environment from scratch, perform a recovery.
• Handover and training — a walkthrough of the artifacts with your engineers and a support period during which we answer operational questions.

Such a set removes the main risk of cloud deployment — dependence on a single person who "remembers how everything works here." Describe your task — we will get back to you with an estimate and a work plan.

Case study: how we cut response time by 3x

The client is an online store on «1C-Bitrix»: a catalog with tens of thousands of items, exchange with «1С» every few minutes, peak load during promotions. Before us, the site ran on a single server: the web server, database, and file cache shared the same resources.

During a sale, response time stretched into several seconds, the cart fell over at the checkout stage, and the «1С» exchange locked the database and brought down the storefront.

What we changed

We split the roles across separate nodes: web servers behind a load balancer, the database on a dedicated instance with a read replica, file storage and cache on a shared network disk.

The Bitrix cache was moved to an external in-memory store so it wouldn't be rebuilt on every node. The «1С» exchange was moved into a separate queue: it no longer competes with customer requests for the database.

We added autoscaling under load: as the number of requests grows, new web nodes spin up, and as it drops, they shut down. Static assets and media were offloaded to a CDN, and heavy catalog pages are generated on a schedule rather than on every request.

What the result was

We also set up monitoring separately: alerts for rising response time, database errors, and the exchange queue — problems become visible before a customer notices them. Backups and snapshots are verified by restoration, not by the fact that they were created.

The project was led by our engineer, who has worked with 1C-Bitrix and cloud infrastructure. If you're seeing a similar picture, describe your task and we'll get back to you with an estimate and a plan.

How is 1C-Bitrix different from Bitrix24 during deployment?

1C-Bitrix is a platform for deployment on your own infrastructure: you manage the server, database, file storage, and updates. Bitrix24 is a cloud service with a fixed architecture, where the vendor handles the infrastructure and the client works only in the web interface.

This is where the difference in requirements comes from: for 1C-Bitrix, we design an environment for load and fault tolerance; for Bitrix24, we mainly set up integrations and migrate data.

In the Bitrix24 cloud, there is no access to the server side: you cannot install your own module at the kernel level, change the configuration of the web server or database, or influence the caching policy.

In the on-premise version of 1C-Bitrix, all of this is the team's responsibility — we choose the web server, configure PHP, select the DBMS and its tuning parameters, and manage permissions and backups.

Therefore, architecture here is not an abstraction but a set of concrete decisions for the load profile: catalog, online store, portal, or high-load project.

Infrastructure requirements also diverge. For 1C-Bitrix, disk performance, the amount of RAM for cache and database connections, and a horizontal scaling scheme as traffic grows are critical.

For Bitrix24, these parameters are not important — what matters more is channel stability, correct access permission configuration, and synchronization with external systems via the software interface.

Migration between the products is a separate task: transferring data, modules, and logic requires a preliminary audit, because some on-premise capabilities are unavailable in the cloud, and some cloud scenarios do not transfer one-to-one.

In practice, the choice also determines the support model. We maintain on-premise 1C-Bitrix as an infrastructure project: kernel and module updates, monitoring, backups, incident response.

Bitrix24 in the cloud requires less server work but more attention to integrations and business logic. If you are planning to deploy 1C-Bitrix on AWS, describe the task — we will come back with an architecture assessment and a plan.

Common technical concerns

Deploying 1C-Bitrix in the cloud raises a predictable set of questions: will the product survive the migration, will search break, what about access rights, and what about migrating back. Below are answers to the point, without generalities.

How are security and access handled?

Everything that should be closed off lives in private subnets: the database and cache are not accessible from the internet. Only the load balancer with a certificate faces outward. Access to servers is via keys and through a jump host, and rights are separated by role. Backups are encrypted and stored in a separate region.

What about migration, and can we go back?

We migrate on a live site: first we deploy a copy, synchronize the database and files, test on a test domain, and only then switch the traffic. The downtime window is minutes, not hours.

We also rehearse the reverse scenario in advance: if something goes wrong, we return to the previous platform using the same plan.

Who is responsible for updates and failures after launch?

We stay on for support: we monitor the load, update the core and modules in agreed windows, and maintain monitoring and on-call duty. We first run updates on a copy — they appear on the production environment only once they have been verified.

If your question is not on the list — describe the task, and we will come back with an estimate and a plan.

Let's discuss your task

Describe the task — we'll come back with an estimate and a plan.

To keep the conversation concrete rather than "tell us about our project in general terms," a few inputs are enough: what load is expected, how many sites or portals, whether there's already infrastructure in the cloud, and what exactly hurts — response speed, growing storage costs, downtime during updates, or the lack of rollback.

From there we follow a clear route:

• A 30-40 minute call: we go over the current deployment scheme, peak loads, availability requirements, and growth plans.
• We define the target architecture: the distribution of roles between application servers, the database, and the cache, plus the replication and backup scheme.
• We calculate resources for your load profile — without a "just in case" buffer and without savings that break at the very first peak.
• We prepare a migration plan with maintenance windows, rollback points, and the order of traffic switching.
• We agree on areas of responsibility: what we do, what stays on your side, where access is needed.
• We deliver an estimate by stages with timelines and scope of work — no hidden items that surface along the way.
• After approval, we start: we deploy, migrate, test under load, and hand over with documentation.

If needed, on the first call we'll bring in an engineer who runs such deployments — he'll immediately say which solutions apply in your case and which will create unnecessary support complexity.

Write to us on your preferred channel: email, messenger, or the form on the website. Attach the current deployment scheme or just describe it in words — that's enough for us to come back with a first architecture option and an estimate.