Summary
- DRP Cloud México’s move to the Ebunti brand is supported by the company’s own announcement, current network registration data and recent third-party references. The public record nevertheless leaves an important contracting question: newer Ebunti legal pages use “Ebunti México, S.A.P.I. de C.V.” while network, university and business records continue to identify DRP CLOUD MEXICO SAPI DE CV.
- The operating evidence is more substantial than a typical reseller brochure. The company controls a Mexican autonomous system and address space, publishes service telemetry, holds a current Veeam partner distinction and exposes contractual terms for infrastructure, backup, recovery and Microsoft 365 protection. None of those facts, alone, proves a customer’s data location, recovery time or end-to-end availability.
- Public material associated with ARTEM does not establish that ARTEM is DRP Cloud México, Ebunti, a successor or an affiliate. ARTEM identifies a different company, while an Odoo directory entry merely identifies DRP Cloud México as an Odoo customer. ARTEM’s cloud catalogue and Odoo capabilities therefore cannot safely be attributed to this entity.
- A buyer can turn the uncertainty into a procurement advantage. The decisive test is a contract-backed proof covering the legal counterparty, workload and backup locations, network paths, restore and failover performance, support ownership, security scope, price escalation and a rehearsed exit—not a checklist of product logos.
At 2 a.m., the invoice name becomes infrastructure
Imagine the failure that matters. It is 2 a.m. on a Sunday. A ransomware event has made a customer’s production virtual machines suspect, the most recent replicas may have copied the damage and the finance team needs its Odoo environment before Monday. The customer calls the number in its runbook. A support engineer asks for the service identifier. The cloud portal bears one name, the tax invoice another, the reseller may own the commercial relationship and a third-party platform supplies the recovery machinery. At that moment, brand architecture stops being a marketing concern. It becomes part of the recovery architecture.
That is the right opening for DRP CLOUD MEXICO SAPI DE CV because the public evidence supports continuity while also exposing a gap a serious buyer should not ignore. In an official announcement hosted on the old DRP México domain, the company said its commercial brand would become Ebunti. It presented the move as an evolution of the same business, gave the Ebunti web address and retained DRP Cloud México SAPI de CV as the name for invoicing and contracts. The notice also described an expansion beyond Mexico into Panama and Colombia. That is unusually useful evidence: it states both the operating bridge and the distinction between a brand and the company behind it.
The live network record strengthens the bridge. LACNIC’s registration for AS265618 identifies DRP CLOUD MEXICO SAPI DE CV as the registrant, while its current technical contact uses an @ebunti.com address and its abuse contact is named for Ebunti. The related 45.190.180.0/22 allocation carries the same combination. This is not merely an old logo redirecting to a new website; current operational contact data links the DRP legal name to the Ebunti operating name on a real internet resource. A February 2026 report by the Universidad Politécnica de Chiapas’s innovation unit likewise describes a collaboration with “DRP Cloud México (EBUNTI)”. Together, those sources support the conclusion that Ebunti is the commercial continuation of DRP Cloud México.
They do not settle the legal picture. Ebunti’s current master agreement, updated in January 2026, identifies the Mexican contracting entity as “Ebunti México, S.A.P.I. de C.V.” Its Mexican privacy notice, updated in July 2026, uses that name and gives RFC DCM170329Q19. Meanwhile, the LACNIC resources still name DRP CLOUD MEXICO SAPI DE CV, the University of Guadalajara’s 2025 agreements list still lists DRP Cloud México SAPI DE CV, and a Dunsguide business entry retains that legal name. The addresses also differ across public pages: the agreement points to López Mateos Sur 7000, while the privacy notice points to an Avenida de las Américas address.
There are several innocent explanations. The company may have completed a formal name change; one document may be stale; one address may be an operating office and the other a registered or notification address. The public sources inspected do not prove which explanation is correct. The prudent conclusion is therefore narrower than either “only the logo changed” or “an entirely new company took over.” Commercial and operational continuity is well supported. The exact current corporate denomination, notice address, ownership of the network resources and responsibility for an existing DRP contract should be verified for each purchase.
A procurement file should contain the current constancia de situación fiscal, corporate name and RFC, the signed order, the entity shown on invoices, the entity named as data processor, the entity operating each data-centre service and a schedule of subcontractors. If the autonomous system and address space remain registered to DRP Cloud México while Ebunti México signs the order, the contract should state how the former makes those resources available to the latter and who is responsible for a routing or abuse incident. If the names refer to the same renamed corporation, the customer should retain the document that proves the change.
That paperwork is not bureaucracy around the cloud. It is the first dependency in the cloud.
The ARTEM shortcut fails the identity test
The most tempting error in researching a broad local cloud catalogue is to join businesses because their vocabulary overlaps. “DRP” is also a common abbreviation for disaster recovery planning. Odoo services, backup, cybersecurity, infrastructure and Mexican data-centre language occur across many unrelated providers. A search result can therefore make two catalogues look like one operating group even when no corporate bridge exists.
The public ARTEM material inspected for this article does not pass that bridge test. ARTEM’s about page presents Arquitectos de Tecnología Mouan as the company behind the brand, with its own history and team. Its site has used a different telephone number and Mexico City presence from the Ebunti material. No corporate notice, regulator record, customer announcement, partner page or authoritative network record found in the frozen evidence set says that ARTEM acquired DRP Cloud México, became Ebunti, operates for it or belongs to the same group. Overlapping references to cloud, disaster recovery, security or Odoo are not evidence of control.
The Odoo lead is even narrower. Odoo’s official customer directory has a page titled DRP CLOUD MEXICO. The page proves that Odoo listed the company as a customer. It provides no case narrative, implementation scope, partner status, certification, deployment architecture or support commitment. It cannot establish that DRP Cloud México implements Odoo for other companies, hosts production Odoo under a defined service, or supplies the integrations displayed by ARTEM.
This matters because an Odoo workload is an excellent resilience test. Its availability depends not only on virtual-machine power but also on PostgreSQL consistency, filestore synchronization, scheduled jobs, mail relays, DNS, certificates, identity, payment and tax integrations, and a recoverable set of custom modules. A provider that can restore a virtual disk has not necessarily restored the business process. Ebunti may be capable of doing more; the public Odoo entry simply does not prove it.
Accordingly, ARTEM’s catalogue is excluded from the assessment of DRP CLOUD MEXICO SAPI DE CV. A buyer approached under both names should ask the seller to document the relationship, identify the contracting entity and separate subcontracted work from Ebunti-operated services. Until that evidence exists, the safe boundary is clear: the verified DRP-to-Ebunti bridge can support procurement diligence; an ARTEM-to-DRP bridge cannot.
Ebunti’s catalogue describes components, not yet an operating system
Ebunti’s public offer has a coherent centre. Its current website groups Infrastructure as a Service, Backup as a Service, Disaster Recovery as a Service, Microsoft Protection as a Service and S3-compatible storage. Its master agreement defines the same families and adds managed services. The emphasis is continuity rather than general-purpose application development: run virtual machines, copy data, preserve Microsoft 365 content, keep recoverable replicas and have someone monitor the result.
That centre is reinforced by vendor evidence. Veeam named Ebunti its 2024 Latin American cloud and service provider partner of the year. In trade interviews, Ebunti executives describe the business as a service manufacturer for channel partners, packaging Veeam-backed backup and recovery with infrastructure and support. ITware Latam’s 2024 interview explicitly connects the former DRP México name to Ebunti and describes BaaS, DRaaS, S3, IaaS and Microsoft protection. ITseller’s account presents a similar partner-led design. These are interviews carrying company claims, not independent measurements, but the consistency and the Veeam recognition make the operating proposition credible.
A plausible customer workflow follows. The customer or its reseller defines protected workloads. Connectivity carries backup traffic to a provider repository or replication target. VMware supplies part of the virtualisation layer; Veeam supplies much of the policy, movement, catalogue and recovery machinery; Ebunti supplies infrastructure, capacity, monitoring, operational work and a support path. For Microsoft 365, the protected system, authentication and restore destinations are different, but the commercial idea is similar. S3 storage can be a destination or application service. The quote decides which pieces are actually present.
Veeam’s own documentation shows why this distinction matters. Cloud Connect architecture allows a service provider to expose its own compute, storage and networking resources for hosted repositories and replication. The Service Provider Console supports central monitoring and a hierarchy of providers, resellers and managed companies. These are useful capabilities, but a platform’s capability is not a statement of one provider’s deployment. The buyer still needs to know where the management server sits, which party holds administrative privileges, how tenants are separated, whether the repository is immutable, where configuration backups go, which networks carry management traffic and how a compromised customer identity is prevented from deleting the recovery copy.
The public success stories add scale signals without closing those gaps. Ebunti’s Softtek case study calls Ebunti the former DRP México and says its protection reaches 14,000 endpoints in 25 countries. It includes performance improvements and a customer quotation. It is provider-published material rather than an audited technical report, so it supports the existence of a substantial engagement, not universal performance for another customer. Named stories involving Softtek, Sí Vale, Carnes Viba and other partners show routes to market; they do not disclose failure domains, retention periods or contractual recovery objectives.
The difference between a catalogue and an operating system is the difference between nouns and verbs. “Backup,” “recovery,” “S3,” “security” and “24/7 support” are nouns. An operating system says who detects a failed job, who calls whom, how an immutable copy is selected, how identity is reconstructed, how long the restore takes, which application checks determine success and how the customer exits with usable data. Ebunti has enough visible infrastructure and partner evidence to justify testing those verbs. The website alone cannot answer them.
AS265618 is hard evidence—but only for one layer
Cloud procurement often treats network claims as invisible. DRP Cloud México offers an exception: it has an externally observable network identity. LACNIC records AS265618 to DRP CLOUD MEXICO SAPI DE CV, with an active status and an original registration date in December 2019. The registry also records the 45.190.180.0/22 allocation. Current operating contacts tie those resources to the Ebunti domain. That is stronger evidence than a generic claim to “world-class connectivity.”
Routing observers add a useful, though non-authoritative, view of the perimeter. bgp.tools shows five announced IPv4 prefixes, including the four /24s within the LACNIC allocation and a 38.58.140.0/22 route. It identifies Alestra and Cogent among the upstreams. IPinfo’s AS265618 page similarly reports five IPv4 prefixes, no observed IPv6 prefixes and a valid route-origin authorization for the 38.58.140.0/22 route. These snapshots can change, and routing collectors do not see every private connection, so they are evidence of public routing rather than a complete network diagram.
What does the autonomous system prove? It proves that the named company has a durable internet routing identity and that Ebunti-branded contacts operate it. It gives a buyer something concrete to monitor: origin changes, route validation, upstream diversity and prefix reachability. It may allow the provider to control routing policy more directly than a company that merely rents addresses behind one carrier.
What does it not prove? It does not locate a workload. An IP geolocation label is not a rack address. It does not show whether two upstreams enter a facility through diverse ducts, whether the border routers share power, whether distributed denial-of-service protection is inline, whether management traffic uses the same path, whether private circuits exist, or whether a disaster-recovery site has independent connectivity. It does not prove that a customer will receive portable addresses. It does not prove storage durability or virtualisation availability.
The absence of an observed IPv6 announcement also does not establish that no internal or private IPv6 exists, but it is a reasonable subject for a roadmap question.
A buyer should convert the network evidence into a live test. First, list every production and recovery prefix and verify the expected origin. Ask for the route-origin authorization status, letter-of-authorization process and notification rules for an origin or upstream change. Second, trace paths from the customer’s principal offices, remote users and key integration partners at several times of day. Third, force the agreed connectivity failure: disable the primary tunnel or circuit, measure reconvergence, confirm that monitoring notices the event and verify that restored workloads are reachable through the secondary path.
Fourth, distinguish public internet, private connectivity, replication and management networks. A provider can have two internet carriers while a customer still has one fragile recovery path.
The commercial demarcation matters as much as the topology. Ebunti’s SLA excludes failures beyond its demarcation and many third-party causes. If a reseller supplies the circuit, an office firewall terminates the tunnel and Ebunti supplies the virtual machine, a single outage can fall between three support queues. The order should name the demarcation point, responsible party, evidence source and clock for each layer. AS265618 is valuable precisely because it makes one portion of that chain observable. It should be the beginning of diligence, not the end.
Mexican data sovereignty is a map, not an address
Ebunti markets infrastructure in Mexico and Panama and speaks to customers seeking local service. That can be valuable. Local capacity can reduce latency, simplify site visits and invoicing, keep operational knowledge in the same time zone and give a customer a practical alternative to exporting every workload to a distant region. But “sovereign” and “local” are not binary attributes conferred by a Mexican office or IP address. They are properties of a particular data flow, legal arrangement and control design.
The first reason is visible in Ebunti’s own Mexican privacy notice. It lists technology providers including Microsoft, Google, AWS, Veeam and Wasabi, as well as Ebunti affiliates in Colombia, Panama and the United States, among possible recipients or processors. That is not evidence that customer workload content is routinely sent to all of them. Privacy notices usually cover a broad set of business processes, including sales, support, analytics and administration. It does show why a blanket promise that “the data stays in Mexico” must be decomposed.
For each service, the buyer needs a location matrix. Where are primary virtual disks? Where are backup blocks, replicas and archive copies? Where are encryption keys, management-plane databases, job catalogues, monitoring metrics, ticket attachments, support recordings and administrator logs? From which countries can privileged personnel connect? Does a vendor receive diagnostic bundles? Does a reseller see tenant metadata? If S3 replication is enabled, is the second physical location within Mexico or in another country? A workload can remain in Guadalajara while its support data, identity service or recovery metadata crosses a border.
Mexican privacy law makes controls and transparency consequential without turning every private-sector workload into a universal localisation mandate. The current Federal Law for the Protection of Personal Data Held by Private Parties, issued in 2025 and subsequently amended, requires responsible parties to maintain administrative, technical and physical security measures and to notify data subjects of materially significant breaches. It also regulates data transfers and the privacy notice. The exact duties depend on the roles, data and sector, so a buyer should obtain legal advice for its circumstances rather than rely on a cloud slogan. Mexico’s NMX-I-27018 cloud privacy standard offers an additional reference point for protection of personal data in public-cloud processing, but a standard’s existence is not evidence that Ebunti is certified to it.
The second reason is competition. Major global providers now offer Mexican regions. AWS opened its Mexico Central region in January 2025 with three availability zones. Microsoft announced the operation of its Mexico Central cloud region in 2024, and Google Cloud opened a Querétaro region later that year. Local substitution is no longer a simple choice between a Mexican provider and a foreign region thousands of kilometres away. It is a choice among local physical capacity, different control planes, different support structures and different contractual leverage.
Ebunti’s potential distinction is therefore not a flag planted over a server. It is the possibility of combining Mexican infrastructure, a visible local network, Veeam-centred continuity, Spanish-language operational help and channel relationships into a service that an SME can actually run. That may be more useful to a company with three administrators than a vast hyperscale catalogue. It may also introduce concentration: the same provider can operate the production environment, backup repository, recovery site and first-line support. A control failure or commercial dispute can then touch every copy.
The buyer’s solution is not to reject concentration automatically. It is to define sovereignty in testable statements. Production data will be stored at named Mexican sites. Backup data will remain within stated jurisdictions. Privileged access will be logged and limited to named support locations. Subprocessors will be listed, changes notified and cross-border transfers documented. Customer-held keys will be used where feasible. At least one recovery copy or export path will be outside the provider’s administrative failure domain. Those statements belong in the order and architecture schedule.
Without them, “Mexico cloud” describes a market position, not a control.
Recovery is a timed choreography, not a backup logo
Ebunti’s strongest commercial story is recovery, and recovery is where broad claims become measurable. Its Backup as a Service page describes Veeam-based automation, monitored jobs, encryption and restore options. Its Disaster Recovery as a Service page promotes failover, failback and automated testing, with recovery measured in minutes rather than hours. Its Microsoft protection page describes per-user protection for Microsoft 365. The S3 page promotes compatible storage, encryption and a very high durability claim. These are useful descriptions of intent. They are not a recovery design for a named customer.
The design begins with two clocks. Recovery point objective asks how much recent data can be lost; recovery time objective asks how long a defined service can remain unavailable. Both require a scope. A five-minute recovery point for a database is meaningless if its filestore is copied every four hours. A one-hour recovery time for virtual machines is not a one-hour recovery time for the order-to-cash process. The timer might start when the failure occurs, when monitoring detects it, when the customer opens a valid severity-one ticket or when the provider accepts a disaster declaration. Each interpretation produces a different service.
Veeam supplies credible building blocks, but its documentation also exposes design choices. A Cloud Connect provider can offer hosted repositories and replication resources from its own compute, storage and networking. Veeam’s guidance on cloud repositories describes logical tenant separation and repository options. Immutability is configured for a repository, with consequences for the tenants sharing it. Veeam’s Cloud Connect limitations identify restrictions around recovery operations, network appliances and protected workload types. Its entity-storage immutability guidance explains that, during the retention window, protected data cannot simply be deleted—even by support personnel with access.
Those capabilities create the right questions for Ebunti. Is the customer’s primary backup repository immutable, and for how long? Is immutability enforced at a storage layer outside the credentials used to administer production? Can a tenant administrator shorten retention? Are configuration backups and encryption keys protected separately? Is the recovery target already provisioned or assembled after declaration? How are overlapping customer disasters prioritised? Does capacity planning assume one tenant fails, one site fails or a regional event affects many tenants? Which workload types cannot use the advertised recovery path?
An Odoo environment demonstrates why the questions are practical. The test should begin with an application-consistent backup of PostgreSQL and the filestore, plus the exact custom code, configuration, secrets and integration endpoints required by that version. The team should record a transaction, introduce a controlled corruption event and restore into an isolated network. Users should log in, locate the transaction, create a new one, send a test message, render a report and exercise a critical tax or payment integration through a safe test endpoint. DNS, certificates and identity should then switch to the recovery environment.
Finally, the team should fail back without losing the transactions created during recovery.
That drill measures more than storage. It measures whether the service desk can identify the right restore point, whether network policy follows the workload, whether a database and filestore remain consistent, whether licensing survives changed hardware identifiers, whether third-party allowlists accept the recovery addresses and whether the customer has enough application knowledge to declare success. It also reveals responsibility gaps. If Ebunti restores virtual machines but the Odoo partner validates modules, the runbook must state when the recovery clock stops and which party owns coordination.
SMEs are particularly vulnerable to the distinction between “backup completed” and “business recovered.” They may have no second infrastructure team, no spare identity environment and no recent application map. Managed recovery can be valuable because it supplies repetition and expertise the customer cannot economically retain. That makes evidence of previous tests more important, not less. The buyer should ask for job-success reporting, restore-test frequency, exception handling, recovery evidence, named runbook ownership and a sample post-test report. A green backup dashboard is an input.
A successful, timed and application-validated exercise is the product.
The public language should also be separated into durability, availability and recoverability. Ebunti’s S3 page presents an “eleven nines” claim, a formulation commonly associated with annual entity durability. That is not eleven nines of service availability, does not guarantee that an application can list or retrieve an entity at every moment, and does not define the failure domains behind a particular bucket. The order should identify the applicable metric, measurement method, replication policy, versioning, immutability, delete protection and credit.
Similarly, a promise to recover in minutes needs a workload tier, data volume, starting condition and test result. Otherwise, the most compelling verbs on the website remain aspirations.
The public status page changes the diligence conversation
Many regional providers publish little operational evidence. Ebunti’s public status page is therefore a meaningful positive signal. It exposes monitors for Mexican and Panamanian infrastructure, a VMware portal and S3 service. A buyer can see that the company is willing to place at least some service health in public view.
The same page makes simplistic availability claims harder to accept. At the evidence freeze on July 18, 2026, the page said that some services were down. Across its displayed 90-day window, it showed approximately 99.587 per cent for Mexico POD-1, 96.804 per cent for Mexico POD-2, 98.477 per cent for Panama POD-1, 99.962 per cent for the VMware Mexico portal and 98.894 per cent for S3 Mexico. The page showed a multi-hour interruption for Mexico POD-2 on July 17 and several earlier S3 interruptions. Depending on the monitor interval, a 96.804 per cent result across 90 days corresponds to roughly 69 hours outside the monitor’s successful state.
Those figures should not be presented as customer SLA results. A public monitor can test one endpoint, be affected by maintenance, remain active after a service migration or fail while customer workloads continue. Conversely, a green endpoint can miss storage latency, partial tenant failure, packet loss, a failed backup job or an application outage. Ebunti’s public incident archive displayed no incident narratives for multiple periods in which the monitor history showed downtime. That may reflect the difference between monitor events and declared incidents, but the absence of explanations prevents an outside buyer from reconciling the two.
The contractual service-level agreement creates another layer. It states a monthly uptime objective of at least 99.5 per cent for covered services. Yet its credit table begins with a band below 99.9 per cent and at or above 99.0 per cent, an apparent mismatch that should be clarified in the order. It defines unavailability narrowly: all of a customer’s running instances or tasks must simultaneously lack external connectivity. A storage slowdown, one failed virtual machine, a management-portal failure, a missed backup or an application outage may not meet that definition.
Credits are applied to future payments rather than refunded, and the customer must submit a detailed claim through the support portal before the end of the second billing cycle after the event. The SLA excludes events beyond Ebunti’s reasonable control, internet conditions outside its demarcation, customer and third-party actions, some third-party technology, and suspensions permitted by the agreement. Credits are the stated sole remedy for failure to meet the service level. A customer that does not preserve timestamps, tickets and evidence could experience a real outage but receive no credit.
The arithmetic gives the contract practical meaning. A 99.5 per cent monthly target permits roughly three hours and 39 minutes of unavailability in an average month before the target is missed. Whether that is suitable depends on the application. A payroll archive may tolerate it. A point-of-sale or logistics control system may not. More importantly, the contractual definition may count fewer failures than the business experiences.
A capable buyer should not use the public page to condemn the provider, nor ignore it. It should ask Ebunti to map each monitor to a service and location, explain the July 2026 conditions, disclose scheduled maintenance treatment and provide customer-specific availability reports. The order should add component and workload measures where needed: backup job completion, restore-point age, storage latency, portal access, replication lag and recovery-test success. Incident reporting should state severity, affected service, timeline, cause, corrective action and whether the SLA clock ran. Publishing telemetry is the first half of transparency.
Explaining what it measures and what changed is the second.
Support is part of Ebunti’s control plane
For an SME, support may be the principal reason to choose Ebunti over self-managed infrastructure. A global cloud can provide deep automation and extensive documentation, but the customer still owns architecture, monitoring and much of incident coordination. Ebunti’s proposition is that a local specialist and its channel can absorb more of that operational burden. Its website repeatedly presents 24-hour coverage, and its partner interviews emphasise enablement of resellers that may not have their own backup or recovery platform.
The master agreement reveals the most important boundary. A direct customer contracts with Ebunti. A channel customer contracts with the authorised partner, and the agreement says Ebunti has no direct billing, warranty or support relationship with that end customer unless a separate written arrangement says otherwise. This can be a sensible distribution structure, but it changes the recovery chain. The end customer may believe Ebunti operates its service while the first contractual obligation rests with a reseller.
Every order should therefore name the support owner for each task. Who monitors failed jobs? Who receives an automated alert? Who can declare a disaster? Who has permission to start a failover? Who validates an application? Who coordinates Veeam or VMware? Who communicates with the business? A responsibility chart should include Ebunti, the reseller, the customer, the software implementer and any connectivity provider. It should identify a single incident commander for the combined service.
The service definition should make “24/7” measurable. Is a staffed operations function watching the environment continuously, or can a caller merely open a ticket at any hour? What are the response, engagement and update intervals for each severity? Is telephone escalation available? Are Spanish-speaking engineers available throughout the night? What conditions permit remote administrative access? How are emergency changes approved and recorded? When a problem belongs to a vendor, does Ebunti remain responsible for coordination or hand the customer a case number?
Implementation deserves equal specificity. The customer should receive a discovery output, dependency map, network and identity design, protection policy, initial full copy plan, bandwidth estimate, recovery runbook and acceptance test. Large initial backup transfers may require seeding; rapid restoration may require physical media or local capacity. Ebunti advertises such options, but the order must define logistics, custody, encryption and timing. A service that is well supported after activation can still fail because onboarding omitted one database, custom module or administrator credential.
The best evidence would be operational: anonymised sample reports, a ticket escalation demonstration, an observed recovery exercise and references from customers with comparable workloads. Headcount and office claims can indicate capacity but do not prove coverage. Support becomes a control plane only when responsibilities, authority and evidence span the provider, channel and customer. Otherwise, it is another catalogue entry.
The public price card is the beginning of cost, not the price
Ebunti’s website includes an unusually accessible calculator denominated in US dollars. At the evidence freeze, it showed indicative minimums of $99 a month for BaaS, $150 for IaaS, $30 for Microsoft protection and $25 for S3. The displayed unit values included $0.23 per gigabyte and $11 per virtual machine for BaaS; $16 per virtual CPU, $13 per gigabyte of memory, $0.12 per gigabyte of high-speed storage and $10 per public IP for IaaS; $2.90 per user for Microsoft protection; and $0.23 per gigabyte for S3. The calculator itself warns that final pricing varies with volume, term and requirements.
These figures are useful for orientation, but the signed quote governs. A buyer needs to know whether protected capacity is measured before or after compression and deduplication, whether the storage figure is monthly, which traffic and operations are charged, which licences are included, how many restore tests are covered and whether support, onboarding or professional services are separate. The public numbers can otherwise produce combinations that look precise while hiding the largest cost drivers.
The master agreement supplies the commercial gravity. It says the initial term is at least 12 months unless an order states otherwise. Services renew for equal periods unless notice is given at least 60 days before expiry. Ebunti may increase renewal prices by up to eight per cent with notice; a higher increase requires consent. During a term, a customer may reduce an individual resource by no more than 20 per cent, and a reduction does not lower the minimum commitment. Increases are allowed subject to availability.
Early exit is more consequential. If a customer terminates for convenience, the agreement makes the remaining fees for the term due. Ebunti can terminate for convenience with 30 days’ notice, while a customer’s termination for cause is tied to specified conditions and cure periods. Non-payment can lead to suspension after 15 days and acceleration of the remaining commitment after 30. Following termination, the customer has 30 days to download its content before the provider may delete it. For Mexican services, the general liability cap is the fees paid in the preceding three months, subject to the agreement’s details and applicable law.
These terms do not make the service uniquely unattractive; commitments, credit remedies and liability caps are common in cloud contracts. They do create an asymmetry that should be priced. A customer may owe nearly a year of remaining fees, have only a month to extract data and recover at most a small fraction of annual spend for many claims. Meanwhile, moving a large backup corpus or rebuilding a recovery environment can take longer than 30 days.
The relevant comparison is total continuity cost. It includes infrastructure, storage, licences, network transfer, public addresses, monitoring, support, initial seeding, periodic recovery exercises, emergency professional work and exit. It also includes customer labour. A managed service may remain cheaper than hiring enough people to run it well, even if its unit price exceeds raw hyperscale capacity. Conversely, a low storage rate can be expensive if restores, traffic and assistance are excluded.
Before signing, a buyer should negotiate a complete rate card and three scenarios: steady state, a declared disaster and exit. It should cap or define renewal increases, align the non-renewal window with budgeting, permit reduction when workloads disappear, extend the export period where data volume requires it and state formats, bandwidth and assistance. It should require continued read access during a good-faith billing dispute and protect recovery data from deletion while a dispute is being resolved. Price is not the number beside a gigabyte. It is the cost of retaining operational choice.
Security badges cannot substitute for a control schedule
Ebunti’s current site displays security and service-management signals, including a claim to ISO/IEC 20000-1:2018 and a Veeam Platinum relationship. The Veeam regional award is independently visible on the vendor’s site and indicates meaningful participation in that ecosystem. These are legitimate reasons to take the provider seriously. They answer narrower questions than a buyer may assume.
ISO’s description of ISO/IEC 20000-1:2018 concerns requirements for a service management system. It is not the same standard as ISO/IEC 27001, which addresses an information security management system. Good service management can improve incident, change and supplier processes, but a logo does not tell a buyer which legal entity and sites were certified, the scope of services, the certification body, the certificate’s current status or any exclusions. No public certificate carrying those details was located in the frozen sources. The buyer should request it and verify the issuer, accreditation, scope, holder, validity and most recent surveillance.
The control schedule should then address the customer’s actual threat paths. Administrative access needs phishing-resistant multi-factor authentication, role separation, time-limited privileges and logging. Provider personnel should not use the same identity domain or credentials that a ransomware event can compromise at the customer. Backup deletion, retention changes and key access should require stronger controls than routine restore work. Network management, virtualisation management, storage and backup orchestration should occupy separated trust zones.
Logs should leave the system they monitor and be retained long enough to investigate an intrusion.
Immutability deserves particular precision. A Veeam-compatible feature or S3 object lock can resist deletion only under its configured conditions. The buyer needs the retention window, clock source, governance or compliance setting, administrator capabilities, repository type and evidence from a deliberate deletion attempt. It should determine whether a storage administrator, cloud administrator and backup administrator can collude through one identity system. At least one copy should resist compromise of the production and ordinary backup administration paths.
The incident clause must connect technical operations to Mexican privacy duties and sector obligations. It should define when Ebunti notifies the customer, what information follows, how evidence is preserved and how subcontractors participate. The privacy notice promises reasonable measures and identifies broad processing purposes, but it does not provide a customer-specific security architecture. A regulated buyer may also need penetration-test summaries, vulnerability remediation windows, personnel screening, secure media disposal, business-continuity results and cyber-insurance evidence.
Cybersecurity services create a further boundary. A provider can resell or manage security products without assuming responsibility for the customer’s overall security. The order should separate the security of Ebunti’s cloud from optional security services supplied to the customer. It should state which alerts are monitored, who investigates, what response is included and where logs reside. Vague language such as “protected by leading technology” cannot define accountability.
The fair conclusion is not that Ebunti lacks controls. The public evidence is limited public evidence to assess them at the level needed for a critical workload. Partner standing, a registered network, published telemetry and an asserted service-management standard are credible starting points. A certificate pack, architecture workshop, control evidence and live recovery test must complete the picture.
Local substitution now competes with three Mexican hyperscale regions
The arrival of AWS, Microsoft and Google infrastructure in Mexico changes Ebunti’s competitive question. A buyer can seek local data residency from a global platform, often across multiple availability zones, while retaining access to extensive identity, security, analytics and automation services. Ebunti cannot win merely by saying that foreign cloud is remote.
It can compete on a different unit of value. A small company rarely wants an availability zone; it wants payroll to run after an attack. It may value a Spanish-language team that knows its VMware estate, a channel partner that already supports its offices, a predictable recovery package and the ability to speak with the people operating the platform. Ebunti’s visible ASN, Veeam specialisation and service mix can support that position. Its provider-led Softtek story also suggests experience operating through partners at meaningful scale.
The trade-off is breadth and concentration. A hyperscaler offers more regions, deeper automation, broader marketplace choice and large security investment, but can leave architecture and cost control to the customer. Ebunti can assemble and operate a narrower stack, but the customer may depend on one provider for infrastructure, backup, recovery, network and escalation. A hyperscaler’s local region can still rely on global management services; a regional provider can still use global vendors and cross-border support. Neither label answers sovereignty by itself.
A serious comparison should use the same workload and acceptance test. Price the production environment, immutable copy, second failure domain, monitoring, support and two annual recovery exercises on both paths. Measure latency from real users and integrations. Test recovery from compromised credentials. Identify the person who coordinates the whole incident. Map all data and management locations. Calculate exit time and fees. The winning design may be Ebunti, a hyperscaler with a managed partner, or a hybrid in which one holds production and another an independent copy.
That hybrid deserves attention. If Ebunti runs production and the only recovery repository is also under its administration, the customer has provider concentration. If production runs elsewhere and Ebunti holds a protected copy and recovery target, Ebunti becomes a local continuity alternative rather than a complete substitution. Conversely, a customer can use Ebunti infrastructure while exporting an independent recovery copy. The strongest local-cloud proposition may not be “replace everything.” It may be “create a recoverable Mexican operating path that does not share every failure with the incumbent.”
Switching costs hide in the recovery path
Cloud exit is often reduced to data egress. For an Ebunti customer, switching cost can accumulate in more places. Virtual machines may be shaped around VMware. Backup history, catalogues and retention chains may depend on Veeam. Firewall policy, public addresses, DNS and partner circuits may point to provider infrastructure. S3-compatible applications may rely on behaviour that differs at the edges between implementations. Microsoft 365 restore permissions and retention choices may live in a provider-managed console. Recovery runbooks may exist mainly in the heads of the people who operate them.
The customer does not own AS265618 merely because its service uses an address announced by that network. Moving can require new public addresses and updates to allowlists, DNS, certificates, partner systems and security rules. If an Odoo environment has custom modules, attachments and integrations, exporting its database alone is not enough. If encryption keys or backup metadata are inaccessible, a copy of storage blocks may not be readily recoverable elsewhere.
The agreement’s 30-day post-termination download period makes these dependencies concrete. A multi-terabyte corpus over a constrained link can consume much of that window. Restoring an entire retention history into another Veeam environment can require compatible versions, repository access and operational assistance. An immutable retention policy can complicate deletion timing even as the customer needs usable exports. The order should therefore specify what “download” means: native backup files, virtual disk images, database dumps, entity versions, configuration exports, logs, keys and documentation.
An exit test should happen before production and annually thereafter. Export one representative machine, one database, one S3 dataset and one Microsoft 365 item through the customer’s intended path. Import them into an environment not controlled by Ebunti. Measure time, fees and provider labour. Verify that the customer can obtain its configuration and recovery history. Confirm how data is securely destroyed after the retention and legal-hold periods, and request evidence of destruction.
Switching cost is not inherently bad. It can be the residue of valuable integration and managed expertise. It becomes dangerous when it is discovered during a dispute or outage. A buyer that prices and rehearses exit can accept a long commitment with open eyes. One that relies on generic portability language has transferred more control than the invoice reveals.
A 30-day proof can turn Ebunti’s claims into a service
The evidence supports a disciplined pilot rather than an immediate yes or no. Thirty days is enough to test the chain with one representative workload if the provider and customer prepare data, access and decision-makers in advance.
During days one through five, settle identity and scope. The seller should provide the current Mexican corporate document, RFC, notice and service addresses, proof of the DRP-to-Ebunti name relationship, and an explanation of which entity holds or operates AS265618. The draft order should identify the contracting, invoicing, data-processing, infrastructure-operating and support entities. If a reseller is involved, it should sign a responsibility schedule with Ebunti and the customer. ARTEM should not appear in the scope unless a documentary relationship and precise responsibility are supplied.
The same phase should freeze the workload definition. Select an application with a database, files, authentication, external integration and meaningful recovery objective. An Odoo deployment would be suitable if the customer actually uses it, but Odoo should not be included merely because the directory lists DRP Cloud México as a customer. Inventory data volume, daily change, peak transactions, dependencies, required ports, identities, certificates, software versions, licences and business validation steps.
Define the recovery point and recovery time from business event to accepted service, not merely from ticket acceptance to powered-on virtual machine.
During days six through ten, map architecture and sovereignty. Ebunti should provide a customer-specific diagram showing production, repositories, replication targets, management systems, networks, support paths and external providers. Every component should have a country, site or region, operator, legal controller, encryption state and failure domain. The diagram should distinguish customer, reseller, Ebunti and vendor privileges. The customer should compare it with the privacy notice’s provider list and document any data or support access outside Mexico.
Network testing should run in parallel. Verify the public route origin, route authorization, expected upstreams and customer endpoints. Measure latency, jitter, packet loss and throughput from real locations. Disable a primary tunnel or agreed circuit and observe failover, monitoring and ticket creation. Confirm whether recovery networking uses an independent path. If IPv6 matters to the application or procurement policy, obtain a supported design or a dated roadmap rather than assuming the public ASN observation tells the whole story.
During days eleven through twenty, attack the recovery assumptions. Seed the workload, record baseline backup duration and confirm that failures create actionable alerts. Attempt an unauthorised retention change and deletion using the roles most likely to be compromised. Create known transactions, corrupt or isolate production, and require the service team to select a clean restore point. Recover into a segregated network without trusting the failed production identity system. Test the application, integrations and reporting against a written acceptance script.
Then declare a recovery event. Measure detection, acknowledgement, engineer engagement, data restoration, network switch, application validation and business acceptance separately. Continue operating long enough to create new transactions in the recovery site. Fail back and prove that those transactions survive. Record the achieved recovery point and time, every manual dependency, capacity constraint and decision right. Repeat one failed step after changing a person on the support shift; a runbook that works only with its author is not resilient.
During days twenty-one through twenty-five, test support and security. Open low, high and critical tickets through the channels the contract actually covers. Escalate one after the promised interval. Ask the reseller and Ebunti separately who owns the next action and compare the answers. Inspect access logs for the recovery exercise, privileged role assignments, multi-factor controls, approval records and evidence that management and backup paths are separated.
Review the claimed ISO/IEC 20000-1 certificate rather than a logo: holder, scope, sites, issuer, accreditation, validity and surveillance. Obtain a security-control pack appropriate to the risk, including vulnerability management, incident notification, subcontractor governance, media disposal and continuity testing. Verify repository immutability with a technical result, not a product name. If a cybersecurity monitoring service is included, inject a safe test alert and follow it from detection to customer communication.
During days twenty-six through thirty, test economics and exit. Reconcile the public calculator with a signed quote for the pilot’s measured consumption. Add licences, transfer, support, recovery exercises, onboarding and professional work. Price a declared disaster and an early exit. Ask the provider to export a representative virtual machine, database, entity set, configuration and log package. Import them outside its administration. Measure the transfer rate and calculate whether the complete estate can leave within the contractual window.
The final acceptance sheet should be binary where possible. The legal identity reconciles or it does not. Data locations are named or they are not. A deletion attempt failed for the agreed immutable window or it did not. A recovery met the business clock or it did not. A second network path worked or it did not. The support chain reached an accountable engineer or it did not. The export was usable elsewhere or it was not. Residual uncertainty can then be priced, insured, mitigated with an independent copy or made a condition before production.
This proof is not hostile procurement. It gives Ebunti a chance to demonstrate the operating advantage its brand promises. A local managed provider should be able to outperform a generic catalogue in coordination, context and recovery practice. The pilot measures exactly those strengths.
The evidence falls into four different buckets
The verified facts are meaningful. DRP Cloud México officially announced the Ebunti brand. Current LACNIC records tie the DRP legal name and Ebunti contacts to AS265618 and a Mexican address allocation. Independent university material still uses DRP Cloud México alongside Ebunti. Veeam publicly recognised Ebunti as a leading Latin American service-provider partner. Ebunti publishes legal terms, an SLA, service telemetry and identifiable product pages. Those facts establish a real operating business with network resources and a continuity-focused proposition.
Company claims form a second bucket. Ebunti describes multiple Latin American locations, round-the-clock support, specific infrastructure characteristics, rapid recovery, high entity durability, security practices and customer outcomes. Its case studies and executive interviews add detail, and some carry named customer or vendor context. They remain statements that must be tested for the buyer’s service. A capability at one site or for one customer cannot be presumed across every quote.
Reasoned inferences form the third bucket. The combination of a registered network, Veeam standing, product structure and status monitors suggests that Ebunti operates more than a paper resale catalogue. Its channel approach could give SMEs a practical managed route to backup and recovery. Its control of several layers could speed incident coordination. The same combination could increase concentration and switching cost. These are conclusions drawn from the joined evidence, not direct statements from a regulator or customer contract.
The unknowns are the procurement agenda. Public evidence does not reconcile the latest legal denomination with all older and current records. It does not prove an ARTEM relationship. It does not show an Odoo implementation or hosting competency. It does not disclose named data-centre sites and failure domains for each service, customer-specific data locations, complete security certification, oversubscription policy, recovery capacity during correlated events, exact support staffing, root-cause narratives for the visible monitor history, or the portability of a full retention chain.
Keeping the buckets separate prevents two opposite errors. One is to dismiss a regional provider because it lacks the disclosure volume of a public hyperscaler. The other is to convert every partner badge and product page into an assumed control. Ebunti has supplied enough evidence to merit direct technical diligence. The buyer must supply the discipline to keep what is observed, asserted, inferred and unknown from collapsing into one sales story.
Watch the name, the monitors and the independence of the recovery copy
The first watchpoint is corporate identity. Future invoices, legal notices, LACNIC records and partner announcements should converge on a documented denomination. A formal update of the network registrant, or evidence that DRP Cloud México remains the asset holder while Ebunti México contracts, would change the risk analysis. Continued divergence is not proof of wrongdoing, but it raises the cost of enforcing responsibility.
The second is operational transparency. Ebunti’s status page should be observed over time. Buyers should look for improved availability, durable incident narratives and a clear mapping between monitors and contractual services. A quiet archive alongside visible red periods is less useful than a candid explanation. Changes to the SLA’s 99.5 per cent objective, 99.9 per cent credit threshold and narrow simultaneous-connectivity definition would also be material.
The third is network maturity. AS265618 provides a baseline for watching prefix origins, route authorization, upstream changes and IPv6 adoption. Growth in prefixes is not automatically improvement, and two visible upstreams are not automatically physical diversity. The relevant signal is whether the customer can verify independent paths and documented response to routing incidents.
The fourth is recovery independence. As ransomware increasingly targets backup administration, buyers should watch whether Ebunti publishes clearer evidence on immutability, isolated identity, cross-site capacity and recovery exercises. A copy stored in another rack but controlled by the same compromised credentials is not an independent recovery path. A regional provider that can demonstrate administrative and geographic separation will have a stronger answer than one that merely adds storage.
The fifth is competitive adaptation. Mexican hyperscale regions reduce the force of residency alone. Ebunti will need to show why its managed operating layer, support chain and recovery practice outperform a customer’s alternative. Clear service documentation, site-specific controls, transparent pricing and portable recovery could become more important than adding further logos to the catalogue.
Finally, watch for a documented ARTEM bridge. If a reliable corporate filing, acquisition notice, signed partnership or authoritative service statement eventually connects ARTEM to DRP Cloud México or Ebunti, its role can be assessed then. Until that point, importing ARTEM’s Odoo and cloud claims would weaken rather than enrich the evidence.
The contract is the sovereign-cloud product
DRP CLOUD MEXICO SAPI DE CV is not an empty name behind a website. The DRP-to-Ebunti transition is supported by an official announcement, live network contacts, third-party references and a consistent recovery business. AS265618, public service telemetry and Veeam recognition give buyers observable handles that many local providers do not expose.
The open questions are equally real. The precise current legal name is not consistent across public records. The SLA measures a narrower condition than most businesses mean by availability. The agreement gives the quote enormous importance and makes commitment, claims and exit consequential. The status page shows conditions that deserve explanation. Product pages describe rapid recovery, durable storage and security without disclosing the customer-specific architecture that makes those statements true. ARTEM and Odoo cannot be used to fill the gaps.
That combination produces a more useful verdict than a rating. Ebunti is credible enough to test and insufficiently transparent to buy on catalogue alone. For a Mexican SME, its greatest possible advantage is not cheaper virtual CPUs. It is a joined service in which local infrastructure, recoverable copies, network control and people who answer the phone reduce the work of surviving a disruption. Its greatest risk is that the same joined service concentrates technical and contractual control while leaving the boundaries implicit.
A buyer can resolve much of that tension before production. Reconcile the legal counterparty. Attach the architecture and data-location map. Turn recovery language into a timed application exercise. Map AS265618 to the actual customer path. Put the reseller and Ebunti in one responsibility schedule. Verify security scope and immutable separation. Reconcile public monitor history with the SLA. Price the disaster and rehearse the exit.
If Ebunti can pass those tests, the rebrand will represent more than a new commercial presentation. It will describe a Mexican continuity operator whose local network, recovery practice and support make cloud dependency more manageable. If it cannot, the buyer is left with a broad catalogue and a name change. In sovereign-cloud procurement, the difference is not decided by the homepage. It is written into the contract, demonstrated in the recovery room and preserved in the copy the customer can still restore after the provider is no longer there.