For operators deploying AI and cloud capacity in Indonesia, location is rarely a choice between one building and another. The real question is how to distribute a portfolio between metropolitan Jakarta and a large-scale campus. Inference serving users in Indonesia and training clusters processing datasets for days operate under very different constraints, and they are rarely optimized in the same location.
Those differences shape network, power, capacity, and operational-access requirements. Applying one placement criterion across an entire portfolio usually creates two problems at once: expensive metro capacity is consumed by workloads that are not latency-sensitive, while user-facing workloads are stranded in locations with longer network paths than necessary.
Digital Edge Indonesia operates two distinct location profiles. Its Jakarta CBD facilities are located downtown and prioritize proximity to Indonesia’s interconnection ecosystem. CGK Campus in Cikarang, Bekasi is designed as an AI-ready campus with room for large-scale power requirements and expansion.
Placement decisions should therefore begin with the requirements of each system, not with a preferred location. Network-bound workloads need to be close to interconnection points. Power- and compute-bound workloads need a campus with a confirmed growth path.
Factors That Determine Workload Placement
Four factors drive most placement decisions. Their relative importance differs by workload, and that order of priority is what distinguishes one placement from another.
Latency and connectivity
User-facing applications and transaction systems are measured by response time, so capacity savings become irrelevant if response-time targets are missed. Analytics and training jobs that run for hours have far more tolerance; a few milliseconds of network-path difference generally has no business impact.
Latency must also be measured against the correct destination. For consumer services, that destination is the user’s access network. For financial applications, it is the transaction partner’s system. For distributed training, inter-node communication within the cluster matters far more than distance to internet users.
Power requirements and capacity for growth
Power requirements should account for both day-one capacity and the growth path across the contract term. For megawatt-scale deployments, the critical question is not how much capacity is available today, but whether additional capacity can be delivered on your ramp schedule without splitting the cluster across locations.
Total cost
A cost comparison based only on space or power per kW will be misleading. Connectivity, inter-site data transfer, operational support, and expansion requirements all contribute to the cost of running an application. A location with lower capacity pricing may not produce a lower total cost if it requires additional connectivity or increases operational overhead.
Physical and operational access
Physical access matters when teams regularly replace equipment, deliver racks, conduct inspections, or perform technical interventions. A deployment with frequent hardware changes has different requirements from one that needs only a few scheduled visits per year.
Remote-hands coverage determines how dependent an operator is on on-site access. The more work the facility team can handle, the less often the operator’s own staff must be present—an increasingly important consideration for teams that are not based in Indonesia.
Beyond these four factors, the physical conditions of any prospective site require separate evaluation, including Jakarta data center site risks related to environmental exposure and the readiness of supporting infrastructure.
Once the minimum requirements for each factor are defined, locations can be compared based on technical needs and total cost over the contract term.
Workloads Better Suited to Jakarta CBD
Digital Edge Indonesia’s Jakarta CBD facilities provide approximately 29 MW of combined capacity downtown, including its Kuningan facility, which combines interconnection access with greater production-scale capacity.
The primary advantage of the CBD is proximity to Jakarta’s interconnection ecosystem, including IIX and OpenIXP. This is most relevant for connectivity-dependent workloads that need to exchange data quickly with systems outside their internal environment.
Network-Sensitive Workloads
Network-edge infrastructure, peering routers, and CDN points of presence are examples of workloads that benefit from a CBD location. Placing them near traffic-exchange points shortens some network paths to users.
The value of that proximity ultimately depends on how many destination networks can be reached directly—and that is where Jakarta’s peering density matters. IIX-Jakarta’s PeeringDB entry lists more than 800 networks present at the exchange. The more networks that can be reached through a single exchange point, the shorter the path to many users in Indonesia, provided your peering arrangements and port capacity make effective use of that access.
In a CDN architecture, for example, caches can be placed close to traffic-exchange points so content is distributed nearer to user networks, while high-capacity origin storage remains at the campus. This separates the need for fast content delivery from the need to store the full catalog.
Transaction Applications and Financial Services
A CBD location is also relevant for response-time-sensitive systems, particularly transaction APIs connecting platforms with domestic financial-service providers. Components that communicate synchronously with partner systems should be positioned close to the required connectivity paths, including transaction APIs, fraud checks, and frequently queried databases.
Historical reporting and batch analytics, by contrast, do not need to occupy the same location and can be placed in a facility with greater compute capacity.
Proximity Does Not Automatically Guarantee Lower Latency
Geographic proximity creates the potential for lower latency, but distance is not the only factor. Fiber routes, peering configurations, carrier selection, port capacity, and traffic congestion all affect the result. Proximity to IIX and OpenIXP does not mean every destination network will automatically be reached over the fastest path.
Performance should therefore be tested against the actual destination networks during peak periods. Use p95 or p99—the response time under which 95% or 99% of requests complete—rather than relying on averages alone. Averages hide the spikes users feel most, and in production traffic, the tail of the distribution determines whether response-time targets are truly being met.
In general, Jakarta CBD is better suited to workloads that gain measurable value from proximity to the network ecosystem: network edge, CDN, transaction APIs, and interactive inference.
When Is Cikarang the Better Location?
CGK Campus in Cikarang, Bekasi, is planned as an AI-ready hyperscale campus with capacity of up to 500 MW. That scale is intended for power, compute, and expansion requirements that cannot be accommodated in dense urban facilities.
The campus becomes the better choice when the main constraint is not proximity to user networks, but the availability of power, space, and a long-term growth path.
Power- and Compute-Intensive Workloads
AI training, bulk compute, batch processing, and large-scale storage are primary candidates. These workloads are evaluated by compute capacity, throughput, hardware utilization, and time to completion—not response time to users. A few milliseconds of difference on the user network path is irrelevant to a process that runs for hours.
For training, inter-node communication within the cluster and the availability of GPU power are far more important than distance to end users. Technical facility assessments should follow AI-ready colocation criteria, particularly around delivered rack power density and liquid-cooling readiness.
The IEA’s Energy and AI report projects that electricity consumption from accelerated servers will grow by around 30% per year from 2024 to 2030 in its base case, while energy infrastructure is built on much longer cycles. The implication is direct: when power-demand growth outpaces the expansion capacity of urban sites, large-scale capacity is more realistically placed at a campus with confirmed power supply.
Room for Long-Term Expansion
The advantage of the campus model is the ability to add power, racks, and compute capacity in phases without splitting a cluster across multiple locations. For operators whose requirements grow by megawatts per phase, this capability is often more important than the price per kW.
For planning context, the Uptime Institute Global Data Center Survey 2025 highlights cost pressure and power constraints as major industry challenges. Capacity assessments should therefore include growth projections from the outset, not only requirements on the implementation date.
Planned Capacity Must Be Distinguished from Available Capacity
The 500 MW figure describes the planned scale of CGK Campus, not the capacity available at every stage of development. This distinction is critical for deployments that depend on a specific ramp schedule.
Before selecting a location, verify that your power, space, and implementation schedule align with the capacity that will actually be available during the required period, and confirm the readiness stage with the Digital Edge Indonesia team.
A Campus Location Does Not Automatically Mean Lower Cost
Campus scale creates opportunities for efficiency, but Cikarang does not automatically deliver a lower final cost. Contract volume, utilization, connectivity requirements, data transfer, and supporting services still matter. Workloads that exchange large amounts of data with systems in Jakarta must include the cost and capacity of inter-site connections in the comparison.
Why Can Training and Inference Be Located in Different Places?
Training requires intensive inter-node communication and repeated access to datasets, so a training cluster and its active storage are more efficient when kept within one environment. Splitting a tightly coupled cluster across two locations adds synchronization time, even when the sites are connected with high bandwidth.
Interactive inference has different priorities. For AI conversations, real-time recommendations, or application responses, response time to the user is decisive, and a location closer to user networks can provide a measurable benefit. A common pattern is to train the model at the campus and then move the production-ready version to an inference environment in Jakarta CBD.
Batch inference behaves more like training than interactive inference. Because no user is waiting for a response, the critical metrics are throughput and cost per unit of work—not response time. Labeling millions of documents or processing a large dataset is therefore better placed at the campus alongside other compute capacity than in the CBD.
For interactive inference, the evaluation should include every component of response time: network transit, GPU queueing, model-processing time, and data retrieval. Comparing those components determines the next step. If GPU queueing contributes 300 ms while the network contributes only 15 ms, moving the deployment closer to users can, at best, shave a few milliseconds from that 15 ms and will not address the actual source of delay. In that case, adding GPU capacity or optimizing model serving will deliver far greater gains than changing locations.
Mapping Workloads Across the Two Locations
Use the following table as a starting point. Final placement should still be determined by measurement results and application dependencies.
| Workload group | Primary factor | Initial placement | What to validate |
|---|---|---|---|
| Transaction APIs and financial services | Latency to partners, p99 | Jakarta CBD | Paths to partners and databases meet response-time targets |
| Network edge and CDN PoP | Peering, proximity to users | Jakarta CBD | Network reach and port capacity are sufficient |
| Interactive inference | End-to-end response time | Jakarta CBD | Network latency materially affects the response-time target |
| AI training and bulk compute | Power and cluster throughput | CGK Campus | Capacity is available on the required ramp schedule |
| Batch inference and large-scale storage | Capacity cost and processing time | CGK Campus | Data transfer can be completed within the processing window |
Conclusion
No single location is optimal for an entire portfolio. Jakarta CBD facilities are more relevant for applications that benefit directly from proximity to Indonesia’s interconnection ecosystem—transaction APIs, network edge, CDN, and interactive inference. CGK Campus is more relevant for large-scale compute, storage, and power requirements, including AI training, bulk compute, and batch inference.
The final decision depends on the requirements of each workload, the relationships among components, performance targets, and the capacity actually available at the time of implementation. For many operators, the answer is not one location or the other, but both: network-bound components in Jakarta CBD and large-scale compute capacity at the campus, with the inter-site connection planned from the start.
Discuss your colocation design with Digital Edge Indonesia. Bring your workload inventory, latency targets, application dependencies, and power-ramp projections to determine the right allocation between Jakarta CBD and CGK Campus.
