Summary
- AS208355 proves that the exact Turkish company YAM DIGITAL ALTYAPI VE VERI HIZMETLERI A.S. has a registered autonomous-system identity, a valid route-origin authorisation and a provider-assigned IPv4 /24; it does not prove ownership of the address block, data centres, fibres or scrubbing capacity.
- The strongest observed operating evidence is narrow but real:
95.133.139.0/24was broadly visible in May and June 2026, and a June 25 routing snapshot exposed AS5405 and AS44901 as its immediate adjacent networks. At the July 18 snapshot, RIPE collectors saw no route from AS208355. - YAM Network’s public offer spans edge facilities, DDoS protection, disaster routing, managed Redis and managed Kafka. Those are company claims whose production scope is blurred by a website that simultaneously marks parts of the platform “available”, “operational”, “under deployment” and “under construction”.
- A credible purchase therefore begins with a staged proof: identify every facility and subcontractor, validate routing and physical diversity, run destructive failover and restore tests, document locality and support responsibilities, and prove that the customer can leave without losing data, service continuity or address portability.
At midnight, the network disappeared from view
At 00:00 UTC on July 18, 2026, a query for AS208355 returned an austere result: no BGP routes. The RIPEstat point-in-time BGP response contained zero entries, while the companion routing-status summary reported no announced IPv4 or IPv6 space and no observed neighbours. For a business that presents itself as a network-infrastructure operator, that is the sort of fact that can dominate a superficial assessment.
It should not. Three weeks earlier, the same measurement system told a very different story. At noon UTC on June 25, the historical BGP-state response contained 362 collector views of one prefix, 95.133.139.0/24. Across those paths, the autonomous system immediately before AS208355 was either AS5405 or AS44901. The routing-history series shows that the /24 became broadly visible after the current Turkish holder received the number in spring 2026, before visibility collapsed in July.
That sequence is more useful than either snapshot alone. It proves that YAM’s current routing identity was not merely a dormant registry entry: the company-originated prefix reached a wide set of collectors through at least two logical adjacencies. It also proves that visibility was not stable through the publication date. It does not reveal why. A withdrawal can be planned, experimental, operational, contractual or accidental. The prefix may have supported a build rather than customers. Services may use addresses originated by a supplier. A collector can only report what reaches its vantage points. RIPE’s own routing-status methodology warns that an autonomous system can have neighbours its collectors do not see.
The opening fact is therefore not “YAM’s network was down”. The defensible fact is narrower: public global routing visibility went from broad to absent in the examined snapshots, and no public status notice or postmortem in the frozen evidence explains the transition. For a prospective customer, that is not a verdict. It is the first acceptance test.
It also captures the central difficulty in assessing YAM Digital. An autonomous-system number is unusually crisp evidence. Product words such as “sovereign”, “resilient”, “terabit”, “edge” and “available” are not. The former can anchor identity and show reachability. The latter require named facilities, architecture, operating records, legal terms and tests. YAM is visible first through the cleanest part of its evidence—a single ASN—and the temptation is to let that precision spill over into claims the route cannot substantiate.
The legal company and the public brand do connect
The identity question can be answered with substantially greater confidence than the capacity question. The RIPE Database query currently names AS208355 yamnet and associates it with YAM DIGITAL ALTYAPI VE VERI HIZMETLERI A.S. The authoritative RIPE organisation response gives the exact company name, Turkey as country, registration number 539562, an address at Oran Mahallesi, Kudüs Caddesi No. 6/1, internal door 15, Çankaya, Ankara, and the email [email protected].
The YAM Network website uses that domain and email and gives the same One Tower Business Club address. Its public operating name is YAM Network. The company’s LinkedIn page links back to yam.net.tr, locates the business in Ankara and describes the same combination of edge facilities, DDoS protection, disaster routing and private cloud. Those repeated contact points form a strong bridge between the assigned legal company, the YAM Network brand and AS208355.
There is also independent, if lower-grade, corroboration. A Turkish company-data page reports the legal company as an Ankara corporation formed on January 12, 2026, with activity classified under data processing, hosting and related services. That page warns that its information is assembled automatically and may be incomplete or wrong, so it cannot carry the bridge by itself. The RIPE email-domain-address match is the decisive connection; the company-data page merely makes the corporate story more coherent.
Dates need care. YAM’s website says the operating business was founded in December 2025. The secondary company page gives a January 2026 incorporation date. RIPE created the current organisation entry on April 20 and the current AS record on April 22. These statements can all be true: a venture can begin operating before incorporation and receive Internet resources later. But “founded in 2025” is a company continuity claim, not evidence that the present legal company had facilities or customers in that year.
There is a second historical trap. RIPEstat retains traffic history for AS208355 from years before YAM held it. Autonomous-system numbers can be returned and reassigned. The earlier routes in the historical response must not be credited to YAM, because the current YAM record begins in April 2026. This matters for any automated longevity score: a six-year graph attached to the number would manufacture operating history the company did not have.
The conclusion is exact. YAM Network is not an unrelated brand accidentally sharing a similar name with the Turkish company. The public domain, email, address, service language and current Internet-resource records align. That identity bridge is strong enough for a company article. It is not a bridge to every facility symbol on the website, every capacity statement or every regional service claim. Those require separate proof.
One ASN proves control of policy, not ownership of the stack
BGP’s purpose is to exchange reachability information between autonomous systems. RFC 4271 defines an autonomous system as a network under a technical administration that presents a coherent routing picture to other networks. In practical terms, AS208355 gives YAM a public policy identity: it can originate authorised prefixes, establish sessions with other networks and decide how reachability is announced.
The address evidence is more constrained than the phrase “YAM’s IP space” suggests. The RIPE address hierarchy shows that 95.133.136.0/22 is allocated to the Turkish local Internet registry 3C1B. Within it, 95.133.139.0/24 is assigned to YAM with status ASSIGNED PA. The AS record is sponsored and maintained through the same 3C1B context, and the RIPE record for the sponsoring organisation identifies 3C1B as an Ankara-based local Internet registry.
“Assigned” is not “owned”, and “provider aggregatable” is not “portable”. RIPE’s explanation of ASSIGNED PA space says such addresses generally cannot be taken to another provider; the user must renumber. That distinction has direct commercial consequences. If a YAM customer receives addresses from this /24, its exit cost may include firewall changes, DNS updates, allow-list changes, certificate work, partner notifications and reputation warm-up. If the customer brings independent address space and its own ASN, the dependency changes.
The origin-security signal is positive and narrow. The RIPEstat RPKI validator finds a valid route-origin authorisation permitting AS208355 to originate the /24. That reduces one class of origin error and lets networks performing route-origin validation recognise the intended pairing. It does not certify the path after origin, stop every route leak, encrypt traffic, prove customer isolation or show where a server sits.
The current routing-policy record lists more relationships than the June observation. It declares imports from AS6823, AS214941, AS5405, AS174, AS6204, AS44901 and AS42914, among other export statements. A registry policy expresses intention and supports filtering; it does not establish that seven paid, physically independent circuits were live. The June collector paths establish two immediate logical adjacencies, not seven. Public aggregators preserve further, time-sensitive views: bgp.tools showed no currently originated prefixes while retaining recent peer information; Hurricane Electric’s toolkit showed a recent one-prefix snapshot; Cloudflare Radar mapped the network and its routing telemetry; and IPinfo associated the ASN with the legal company, yam.net.tr, the /24 and several adjacent networks.
Those differences are not necessarily errors. Routing is time-dependent, and each platform observes or refreshes differently. Together they make a procurement rule: date every route claim, distinguish declared policy from observed propagation, and never translate a list of ASNs into a list of independent fibres without documentation.
The facility map is an invitation, not an inventory
YAM’s website tells an expansive geographical story. It describes edge data centres across Turkey, Iraq, Azerbaijan, Georgia, Kazakhstan and Uzbekistan. Its network display names an Ankara hub, Frankfurt point of presence, Athens node, Baku edge, Tbilisi branch, Iraq point of presence and a “Silk Road” transit node. It calls Ankara the primary hub and places the company at the intersection of Europe, the Caucasus, the Middle East and Central Asia. This is a coherent strategy: serve routes and workloads in a corridor where global platforms, national carriers and local operators do not always align neatly.
The same page also demonstrates why a map cannot be read as a live-facility list. It labels the Ankara “Master Hub” operational and advertises a 99.999% resilience SLA. A few lines later, it says all nodes and transit links are under construction with a target of Q2 2026. The DDoS centre is “under deployment”. Managed Redis and Kafka are marked “available”. By July 18, Q2 had ended. The page may combine a live control function, planned physical nodes, third-party reach and launch copy from different dates. Without versioned status, a buyer cannot tell.
The headquarters address does not solve the puzzle. The official One Tower Business Club site markets flexible workspace, shared areas, private desks and virtual memberships that include address use and mail reception at the same street location. That does not establish which arrangement YAM occupies. It does show that the registered address, by itself, is not proof of a data hall, redundant utility feeds, scrubbing appliances or carrier entrances. A “command hub” can be an operations office supervising equipment elsewhere; that may be entirely legitimate. It must not be confused with owning the building or the equipment.
Nor does a public interconnection directory currently fill the gap. The PeeringDB API query returned no network record at the research cut-off. PeeringDB is voluntary, so absence proves neither lack of peering nor lack of facility presence. It means a buyer cannot use that common directory to verify YAM’s exchanges, facilities, ports, traffic policy or NOC details.
A proper facility schedule would answer five distinct questions for each dot on the map. First, what is the site: a data centre, telecom exchange, office, cloud region or remote logical connection? Second, who operates the building and who owns the servers, routers and mitigation equipment? Third, how is YAM present: owned equipment, leased rack, bare-metal rental, virtual network function, reseller agreement or remote connection? Fourth, which carriers, power domains and physical paths are independent? Fifth, what is live today, what is in pilot and what is planned?
Those distinctions do not diminish a capital-light operator. Leasing excellent facilities and combining carrier services can be more sensible than owning concrete. Resale can widen reach. The risk arises only when a buyer prices a reseller as an owner, counts one supplier’s two labels as two independent routes, or treats a roadmap node as an operational recovery site. YAM’s public map supplies a direction of travel. It does not yet supply the evidence needed to calculate control, concentration or recovery.
The DDoS proposition has a test result and a much larger claim
YAM’s most differentiated promise is not generic hosting. It is sovereign network defence. The website says the company built its own mitigation technology, detects attacks in under a second, handles Layer 3/4 and Layer 7 attacks, and is deploying a national carrier-grade scrubbing centre with terabit-scale capacity. It presents the service as both a security product and a continuity route: malicious traffic is cleaned before it reaches customer infrastructure, while legitimate traffic continues.
The company’s social posts add useful timing and one quantitative claim. On its public LinkedIn page, YAM said a first multi-vector test processed 100 million packets per second and 85 Gbps while using 30% CPU. It said full-capacity operation with international peering was planned for August, and direct Layer 2 delivery for on-demand or always-on protection was being prepared in Istanbul and Ankara. Another post invited companies to test before the August start.
That is more informative than an unqualified “terabit” badge, but it remains company-reported test evidence. The relationship between 85 Gbps at 30% CPU and terabit production capacity is not linear by default. Packet size changes the limiting resource. A flood of small packets can exhaust packet processing before bandwidth; application requests can exhaust state, inspection or origin capacity at much lower line rates. Encrypted traffic adds key and termination questions. Multi-vector protection depends on simultaneous rule behaviour, not a succession of isolated tests.
Production also adds telemetry, logging, customer policy, clean-traffic forwarding and failure handling.
A buyer should first determine what “mitigation” means in the contract. RFC 5635 describes remote-triggered blackholing: selected traffic is directed to a discard route at the edge. That can protect the surrounding network, but it completes a denial of service for the target. It is not scrubbing. RFC 8955 describes BGP FlowSpec, which can distribute detailed traffic filters and is useful against denial-of-service traffic, while warning that faulty automation can distribute unintended rules. YAM has not publicly disclosed whether it uses either technique. The point is to prevent a procurement document from treating blackholing, filtering, rate-limiting, in-line inspection and clean-pipe scrubbing as synonyms.
Next comes diversion and return. For an always-on service, the customer needs to know whether traffic is permanently routed through YAM, where inspection occurs, how asymmetric routing is handled and what baseline latency is added. For on-demand service, it needs trigger authority, detection thresholds, route-propagation time, minimum prefix sizes, tunnel or Layer 2 return design and a manual fallback. If the customer brings its own ASN and prefixes, route-origin authorisations and registry records must be prepared before an emergency. If it uses YAM addresses, exit and renumbering become part of incident planning.
Then comes capacity provenance. “Terabit” should be decomposed into owned appliance capacity, committed upstream scrubbing capacity, burst capacity and shared regional capacity. A reseller can deliver excellent protection, but the contract should name the upstream, state whether capacity is dedicated or shared, describe oversubscription, and say who controls filters during an attack. The six-country map must not be counted as six scrubbing locations unless each location has traffic intake, cleaning and return capability.
The acceptance test should be adversarial and observable. Run permitted traffic mixes across packet sizes and protocols, with the customer’s production-like rules. Measure detection time, diversion time, packet loss, clean throughput, latency, jitter, false positives, origin load and withdrawal time. Force a mitigation node or upstream path to fail during the test. Verify that the customer can see sampled traffic, actions and rule changes in real time. Confirm what happens above the contracted ceiling: continued cleaning, rate limit, blackhole or best effort. Repeat through both logical adjacencies and from multiple source regions.
A single successful 85 Gbps exercise can establish that engineering exists. It cannot establish the service YAM’s website sells. Only a repeatable report, a production architecture, an escalation path and contractual remedies can do that.
Disaster routing is valuable only when the failure domains are named
YAM describes itself as a boutique network-disaster-recovery operator. The proposition is attractive: add geographically diverse transit paths, remote exchange access and BGP-based failover so a customer is not trapped behind one carrier or one damaged corridor. For organisations between Turkey, the Caucasus, Central Asia and the Middle East, route diversity can be economically and strategically valuable.
The June routing evidence supports a modest foundation. AS208355’s /24 propagated with AS5405 and AS44901 immediately adjacent in RIS collector paths. That shows two logical exits at that time. It does not show two fibre entrances, two metro providers, two buildings, two countries or two independent long-haul systems. Both sessions could converge on one location or one physical route; conversely, YAM could have private or unobserved diversity the collectors cannot see.
Sub-second failover is a particularly testable claim. Standard BGP reachability does not, by itself, disclose failure-detection timers, convergence behaviour or application recovery. Faster mechanisms may sit around it, but YAM’s public material does not name them. The customer should receive a topology annotated with every failure domain: router, line card, cross-connect, meet-me room, building, metro fibre, long-haul cable, carrier, upstream ASN, power feed, control system and operator. Diversity should be priced only where those domains genuinely separate.
Routing security deserves the same layered treatment. A valid ROA is a good first control, not a complete programme. The MANRS implementation guide organises network hygiene around filtering, anti-spoofing, coordination and global validation. A buyer can ask YAM to show customer-prefix filters, maximum-prefix limits, route-leak prevention, source-address validation, current NOC contacts, registry maintenance and emergency route-change procedures. The test is not whether a logo appears on a membership page; it is whether the controls work on the customer’s routes.
Finally, a disaster route should be tested as a business service, not a diagram. Pull the primary circuit. Withdraw a route. Break the return tunnel. Remove one upstream. Measure packet loss and application recovery, then fail back. A route that exists but is cold, mis-filtered, capacity-limited or dependent on the same building is not the recovery product the customer thought it bought.
Managed Redis and Kafka shift the diligence from routes to state
The private-cloud offer broadens YAM beyond connectivity. The website advertises managed Redis and managed Kafka on redundant infrastructure in Turkey, with self-service provisioning, high availability, an API, 24/7 operations support and no vendor lock-in for Redis. That combination could be commercially sharp. A Turkish organisation might want local data handling and low-latency support without running distributed data systems itself. A network operator able to connect the platform directly to customer sites could offer a useful alternative to a distant cloud region or self-managed cluster.
The public description is not yet sufficient to evaluate the service. “Redis as a Service” can mean a disposable cache, a durable primary store, a clustered service, a single primary with a replica, or a compatibility layer with restricted commands. Those uses have very different economics and risk. Official Redis persistence documentation lists snapshots, append-only logging, both together and no persistence, each with different performance and data-loss trade-offs. The Redis replication guide explains that replication is asynchronous by default and that careless persistence and restart choices can propagate data loss.
YAM should therefore specify, per plan, the engine and version, supported commands and extensions, clustering behaviour, maximum data size, eviction policy, persistence mode, backup interval, backup location, encryption, restore procedure, maintenance process and failover semantics. “Redundant” must say whether primary and replica occupy different hosts, racks, power zones and buildings. “High availability” must be paired with a measured recovery-time objective and a data-loss objective. A customer should test acknowledged writes during primary loss, not merely watch a replica become reachable.
Kafka has an equally large gap between “multi-broker” and a dependable service. The Apache Kafka introduction notes that replication occurs at the topic-partition level and that a replication factor of three is common in production. That does not say whether three replicas sit in three failure zones, whether producers require sufficient in-sync replicas, how consumer offsets are protected, or how quickly an under-replicated partition is repaired. The KRaft operating guide recommends separating controller and broker roles for critical deployments and explains why three or five controllers are typical for quorum availability.
A useful YAM specification would disclose Kafka version, controller design, broker count, rack awareness, default and maximum replication factors, acknowledgement settings, minimum in-sync replicas, partition limits, retention, compaction, storage performance, quotas, upgrade windows and cross-site recovery. It would distinguish a broker restart from loss of a rack, building or region. It would show how the customer exports topics and offsets during exit.
Security cannot be reduced to a private endpoint. Kafka’s authorisation documentation supports principals, operations, hosts and resource-level access rules. A managed offer should state how customers authenticate, who can administer clusters, how privileged access is approved and logged, how tenant boundaries are enforced, how secrets are rotated, and whether network and application administrators are separated. Redis needs comparable answers for transport encryption, access lists, dangerous commands and administrative actions.
The “no lock-in” claim is best treated as a promised test. Can a customer restore a standard Redis snapshot into a clean installation? Can it export append-only data? Can a Kafka customer mirror or copy topics, retain timestamps and keys, recreate access rules, and reconcile offsets? Are export bandwidth and engineering support charged? Does the service use standard protocols without proprietary extensions? Portability is not a sentence on a product page. It is a successful exit rehearsal.
Sovereignty is a chain of custody, not a country field
YAM says its managed services keep all data in Turkey and comply with KVKK and GDPR. Locality can be a genuine advantage, particularly when a customer needs predictable jurisdiction, lower latency or a simpler story for regulated data. But neither a Turkish company address nor a country: TR line in an Internet registry proves where application data, backups, logs or administrative access reside.
A locality schedule should follow each category of data. Primary Redis or Kafka data may sit in Turkey while backups copy abroad. Metrics may flow to a foreign monitoring service. Support personnel may connect from another country. Email, ticketing, threat intelligence, source-code hosting, key management and the web control system may involve separate providers. During DDoS mitigation, traffic may be diverted through a foreign scrubbing site even if storage remains domestic. Each flow needs a purpose, location, recipient, retention period and deletion process.
The Turkish data-protection authority’s controller-and-processor guide uses a cloud-storage example to show that the customer can remain the controller while the cloud provider acts as processor when it stores data under customer instructions. That allocation must be reflected in instructions, security obligations, incident notification, deletion, audit rights and subcontracting terms. A provider’s compliance claim does not transfer the customer’s responsibility.
Cross-border handling requires more than geographic reassurance. The authority’s international-transfer guidance describes mechanisms involving adequacy, appropriate safeguards and limited exceptions. The correct route depends on the parties and processing. YAM should supply a data-processing agreement, a current subcontractor list, a transfer map and the safeguards used for any foreign access or movement. A buyer should obtain legal advice for its own data rather than ask a network engineer to certify compliance in a sales call.
Sovereignty also includes operational control. Who holds encryption keys? Can a foreign supplier disable a service? Which company answers a lawful request? Does YAM control the hypervisor and storage, or buy managed capacity from another provider? Can it restore the service without that provider’s control system? Local servers can still carry external concentration risk; foreign components can sometimes be managed with clear safeguards. The decisive quality is a documented chain of custody and authority.
YAM’s public materials do not provide that chain. They provide a direction: Turkish infrastructure and local operations. That can justify a pilot. It cannot yet justify marking a compliance requirement complete.
The customer journey currently begins with a conversation
The website invites a prospective customer to request a briefing. It also describes instant self-service provisioning for Redis and Kafka, yet the frozen public page exposes no price card, plan table, service terms or visible portal entry. The likely buying motion is therefore consultative even if provisioning later becomes automated.
That can suit a boutique operator. The customer’s problem may cross network, security and data layers: a direct circuit into a Turkish service, a backup route, DDoS protection for owned prefixes, or a managed data system with particular recovery requirements. A capable engineering-led seller can design around those constraints better than a generic checkout page.
It also creates information asymmetry. Before the first paid commitment, the customer should ask YAM to identify the contracting company, every service provider in the delivery chain, each live location, the launch status of each component, and the named person accountable during an incident. The answer should separate owned equipment, leased equipment, third-party capacity and resold service. “Our infrastructure” is too broad for procurement.
Onboarding should then split into two tracks. The network track covers addresses, ASN ownership, route-origin authorisations, filtering, handoff, tunnels, traffic baselines and failover. The data-service track covers engine version, migration, capacity, encryption, access, backups, restore, monitoring and deletion. Combining both in one order form can hide responsibility gaps; joining them in one tested runbook can create real value.
The final step is operational handover. A customer needs a service inventory, support contacts, escalation timers, change windows, dashboards, emergency authority, maintenance notifications and an exit procedure. Self-service deployment is useful only after these human responsibilities are explicit.
The economics hide in redundancy, traffic and support
YAM publishes no stable public pricing in the frozen evidence. That prevents a like-for-like cost comparison, but the architecture reveals where a quote can become expensive.
For network service, likely cost drivers include port speed, committed bandwidth, burst traffic, cross-connects, remote exchange access, address use, BGP support, route monitoring and geography. DDoS protection adds normal clean traffic, attack traffic, protected prefixes, always-on versus on-demand operation, inspection depth, retention of attack data and incident engineering. The commercial danger is an inexpensive base fee attached to undefined overage or a mitigation ceiling that converts to blackholing when the customer needs cleaning most.
Redis economics concentrate in reserved memory, replicas, persistence, storage, backup retention, cross-zone traffic, high-availability tier and support. Memory billed for a primary and replica can double the apparent dataset footprint before headroom and fragmentation. Persistence changes storage and input/output demand. A low entry price can become poor value if the service requires large fixed sizes or charges heavily for export.
Kafka economics are usually less intuitive. Broker count, storage, throughput, partitions, replication, retention, inter-site replication, network egress and operations all matter. A customer with modest average traffic but many partitions or long retention can be expensive in a different way from a high-throughput transient stream. A quote should state which dimension triggers the next tier and whether under-replicated recovery consumes billable bandwidth.
Support is part of the product, not overhead. The website claims 24/7 NOC support for Kafka, but it does not publish response targets, languages, channels, severity definitions or escalation. If YAM’s advantage is expert local intervention, the contract should price and measure it. If support is best effort by email, the service should not be compared with a staffed, financially backed enterprise tier.
The buyer should request a twelve-month scenario, not a monthly unit price: ordinary load, one growth step, one restore, one DDoS episode, one data export and one exit. It should include taxes, setup, cross-connects, third-party circuits and professional services. It should also show what the provider pays through rather than controls. This turns hosting economics from a discount discussion into a risk-adjusted cost.
YAM could still be compelling. A smaller operator may combine direct engineering access, Turkish locality and network customisation at a price a global platform cannot match. But boutique economics work only if the customer knows which resilience is included, which is shared, and which must be purchased separately.
Support evidence and incident evidence are still thin
Publicly, YAM offers an email address, a briefing request and a claim of 24/7 NOC backing. The frozen sources do not expose a status page, a history of maintenance notices, a postmortem archive, a public support policy or customer case studies. The July route withdrawal has no public explanation in those sources. That is an evidence gap, not proof of poor support or a production incident.
Young infrastructure providers often have little public operating history. The sensible response is not to demand a decade they cannot have; it is to demand richer real-time evidence. During a pilot, the customer can open tickets at different severities, time acknowledgement and resolution, test after-hours escalation, request a route change, restore data and observe how ownership passes between network and platform staff.
Incident terms should be unusually explicit because YAM spans layers. If Kafka is unreachable because a carrier path failed, one team cannot bounce the customer between “cloud” and “network”. The contract should identify one incident commander, one clock and one communication channel. It should define notification time for security issues, locality breaches, route leaks, capacity exhaustion and data loss. It should require a written cause analysis for severe failures and track corrective actions.
A 99.999% website claim permits roughly five minutes and fifteen seconds of downtime in a 365-day year before exclusions. The real contract must define the measurement point, maintenance treatment, partial degradation, regional scope and service credits. A network port, Redis endpoint, Kafka cluster and DDoS system cannot all share one vague percentage.
Customer references would help, but reference calls should match the service being purchased. A successful network test does not validate managed Kafka; an office workload does not validate terabit mitigation. Until YAM can show longer production history, a reversible pilot and strong termination rights are more valuable than a polished testimonial.
Security and regulatory proof should match the service boundary
The website makes broad compliance and security statements but does not publish the supporting control set. A buyer needs to know where YAM’s responsibility starts and ends: building, hardware, virtualisation, network, managed engine, customer configuration and application.
NIST’s public-cloud security guidance frames cloud use as outsourcing that brings governance, security, privacy and dependency questions. The Cloud Security Alliance’s CCM and CAIQ v4.1 turns that problem into 207 controls across 17 domains and a structured provider questionnaire. A full questionnaire may be heavy for a young operator, but a scoped version covering data-centre security, encryption, identity, logging, vulnerability handling, continuity, subcontractors, data handling and exit is proportionate.
Evidence should include current certificates with scope and issuing body, penetration-test summaries, vulnerability and patch targets, privileged-access controls, employee access termination, log retention, backup protection, key custody and incident exercises. Certification is not a substitute for architecture; an architecture claim is not a substitute for an independent assessment. Both are more useful when their scope names the exact service and facility.
Network regulation also needs a bounded answer. Turkey’s BTK authorisation guidance says companies intending to provide electronic-communications services or operate networks and infrastructure must assess notification and, where applicable, usage-right requirements before starting. That does not establish whether a particular YAM product requires authorisation, is covered by YAM, is delivered through an authorised partner or falls outside the relevant scope. Procurement should ask YAM to identify the legal basis and authorisation chain for the exact connectivity service being sold, then verify it independently.
The right conclusion is not that missing public documents equal missing controls. It is that the customer currently carries the cost of discovering them. YAM can reduce sales friction by publishing a security overview, service boundaries, subcontractor categories, certificate scopes, a responsible disclosure route and a concise reliability history.
YAM’s niche sits between a carrier, a cloud and a specialist
YAM is not most interesting as a miniature general-purpose cloud. Its potential advantage is the combination: routing identity, local handoff, DDoS protection, disaster paths and managed stateful services. A customer might buy one accountable Turkish engineering relationship instead of coordinating a carrier, a scrubbing provider, a data-centre operator and a managed-service vendor.
The competitive test is nevertheless becoming harder. AWS opened an Istanbul Local Zone in May 2026 with local compute, networking, storage, S3 and EBS snapshot capabilities. That is not a like-for-like replacement for YAM’s claimed managed Redis, Kafka, DDoS and regional routing. It gives customers another way to keep important infrastructure in country while using a mature control environment. An engineering team can also run open-source Redis or Kafka there, accepting more operational work in exchange for greater direct control.
Established domestic providers offer another benchmark. Turkcell’s virtual data-centre service advertises self-service infrastructure and regulated Turkish cloud options. Again, it is not the same product. It demonstrates what YAM must beat: documented facilities, support depth, procurement familiarity and financial durability.
Global managed data-service companies compete on automation, ecosystem and operating history, but may not satisfy a strict Turkish locality requirement. Local data centres and carriers compete on facilities and circuits, but may lack a focused managed Kafka or Redis experience. Security specialists compete on mitigation depth, but may not integrate recovery routes and local platform services. YAM’s opening lies in the seams.
That position also compounds dependency. Buying multiple layers from one provider simplifies accountability during normal operation but creates a larger blast radius if that provider fails commercially or technically. A backup route supplied by the same company that hosts the application may not be organisationally independent. A DDoS control failure can affect both connectivity and managed services. The customer should decide where integration is valuable and where a second provider is essential.
YAM does not need to match a hyperscaler feature for feature. It needs to prove a narrower promise: better local engineering, clear custody, credible route diversity and recoverable managed services along a difficult regional corridor. The ASN is a credible opening credential. The procurement evidence must finish the argument.
Switching costs begin with the /24 and end with the data
The simplest exit risk is written into the registry. YAM’s visible /24 is provider-aggregatable space under 3C1B’s allocation. A customer numbered from it may need to renumber when the underlying service ends. That makes address allocation a contract question on day one, not a clean-up task on the last day.
The network exit plan should state whether the customer brings addresses, receives YAM addresses or uses addresses from another supplier. It should cover route-origin records, DNS, reverse DNS, filtering, reputation, firewall rules and transition overlap. A serious plan permits both old and new paths during migration where technically possible.
The Redis exit plan needs a standard export, integrity check, documented restore and deletion certificate. The Kafka plan needs topic data, keys, timestamps, access rules, consumer position and enough overlap for producers and consumers to move safely. Backups should be readable without YAM’s control environment. Encryption keys should not make the export useless.
Commercial terms matter as much as format. Egress charges, professional-service fees, notice periods and minimum commitments can create lock-in even where protocols are standard. The customer should cap exit charges, reserve assistance hours and require an export within a fixed time. It should rehearse the process before production volume makes it painful.
The best proof of YAM’s “no vendor lock-in” claim would be a completed migration from YAM to a clean environment during the pilot, followed by a return migration. That test simultaneously checks compatibility, documentation, support and data custody. It also gives the customer a recovery option if the young service changes direction.
A procurement test that converts claims into evidence
The decision need not be binary. YAM can be evaluated through a gated pilot in which each stage answers a different uncertainty and no stage relies on a marketing label.
Gate one: identity and contracting. The contract must name YAM DIGITAL ALTYAPI VE VERI HIZMETLERI A.S. exactly, match the registration and invoicing details, identify signatory authority, and list every subcontractor or reseller that touches the purchased service. For connectivity, it should identify the relevant BTK basis or authorised delivery partner. For data services, it should attach processing and locality terms. Failure at this gate is not a technical failure; it is an inability to know who owes the service.
Gate two: facility schedule. YAM should provide a confidential table for every live or proposed location: street address, facility operator, YAM presence type, equipment owner, rack and power separation, carrier entrances, cross-connects, upstreams, certifications, launch date and supported products. The customer should visit the principal Turkish site or obtain independent remote evidence. Any resold capacity should be labelled as such. Planned nodes should not contribute to an availability calculation.
Gate three: route proof. Using the customer’s test prefix where possible, announce through each contracted path and observe propagation from multiple independent collectors and customer locations. Verify RPKI, registry filters, maximum-prefix controls and emergency contacts. Record baseline paths and latency. Then fail each session and physical handoff separately. Confirm that two logical upstream ASNs remain diverse at the building, metro and long-haul levels. Repeat because the July evidence shows that a one-day snapshot is not enough.
Gate four: DDoS proof. Agree in writing on permitted test traffic and safety limits. Exercise always-on and on-demand modes, multiple packet sizes, protocol floods and application traffic. Measure detection, diversion, clean delivery, false positives, origin load and recovery. Remove a mitigation node or upstream during the exercise. Confirm whether excess traffic is cleaned, limited or blackholed. Require the report to separate YAM-owned capacity, committed supplier capacity and shared capacity.
Gate five: Redis proof. Load production-shaped data, enable the proposed persistence setting, and record write acknowledgements. Kill the primary host, isolate a rack or zone, fill storage within safe limits, restore an older backup and rotate credentials. Measure data loss and recovery against contractual objectives. Export to a standard Redis installation and compare keys, expirations and application behaviour. The customer should reject “HA” as an answer unless these outcomes are stated.
Gate six: Kafka proof. Inspect broker and controller placement, replication, in-sync settings, storage and access policy. Produce under load while removing a broker, controller and site connection. Measure unavailable partitions, write failures, duplicates, consumer lag and recovery. Restore from backup or mirror to a clean cluster. Recreate access rules and move consumer positions. Confirm that the service remains secure when customer administrators make mistakes.
Gate seven: locality and security. Trace primary data, replicas, backups, logs, monitoring, support access and deletion. Review the subcontractor list and cross-border safeguards. Complete a scoped CAIQ, inspect certificate scope and recent security-test evidence, and validate privileged-access logging. Simulate a security notification and a customer data request. The desired result is not paperwork volume; it is agreement about responsibility.
Gate eight: support and economics. Open test incidents after hours. Escalate one across the network and managed-service teams. Verify acknowledgement, ownership, technical depth and communication cadence. Price a year containing growth, one serious attack, a restore and an exit. Attach service credits to the component actually measured. A quote that cannot survive those scenarios is not predictable enough for production.
Gate nine: exit. Move the workload and routes away. Measure the time, fees and help required. Verify deletion and return of customer material. If addresses must change, complete the renumbering plan. Only after a successful exit rehearsal should the customer treat portability as established.
A pilot can pass selectively. YAM might prove an excellent DDoS service before its managed Kafka offer is mature, or a strong Turkish Redis service before the regional edge map is live. Procurement should allow those outcomes. Buying the verified component is more rational than accepting or rejecting the whole narrative.
What to watch after July 18
AS208355 should be monitored as a moving signal, not a one-time score. The first watchpoint is whether 95.133.139.0/24 returns to broad, stable visibility and whether more than one adjacent path remains observable. The second is IPv6: the examined current record showed no visible IPv6 announcement, a gap worth resolving for a next-generation operator. The third is whether YAM publishes a PeeringDB entry or another verifiable facility and exchange inventory.
The August DDoS milestone is more consequential than another capacity slogan. Buyers should look for a named production launch, supported handoff locations, a service description, a status surface, a test method and evidence that the 85 Gbps exercise scales safely. Any claim of terabit capacity should say where that capacity exists and under whose control.
The managed-service watchpoints are quieter but equally important: public plan definitions, engine versions, recovery objectives, security boundaries, pricing, data-processing terms, subcontractors and an export procedure. A real customer reference for Redis should not be used to validate Kafka, and neither should be used to validate a regional disaster route.
YAM Digital’s opportunity is credible because the underlying need is real. Customers operating between Turkey and neighbouring corridors can value local custody, direct engineering, route alternatives and managed data systems. Its legal and routing identity is also real. AS208355, the assigned /24 and the valid origin authorisation establish that much.
But the ASN is a coordinate, not a conclusion. It tells the Internet who may announce one route. It does not tell a customer who owns a rack, where a replica lives, how an attack is cleaned, whether two fibres share a trench, who answers at 03:00, how an SLA is measured or how data comes home. Those questions are not reasons to dismiss a young infrastructure company. They are the work required to rely on one.
YAM should be judged neither by the smallness of its visible address footprint nor by the size of its website claims. It should be judged by how quickly it can turn the gap between them into named facilities, stable routes, repeatable tests, clear custody and a clean exit. That is what AS208355 proves most usefully today: there is a real operator to test, and still a great deal that only the test can prove.