Bridging the EV Charging Divide: Architecting a Scalable OCPP Integration on AWS

Introduction

How intelligent architecture and cloud-native design transform fragmented EV charging networks into connected, resilient ecosystems.

Electric mobility is no longer a niche segment, it’s reshaping global energy infrastructure. With governments setting zero-emission targets and automotive OEMs accelerating electrification, the number of public and private chargers is growing exponentially.

In the U.S. alone, meeting projected EV demand will require over 500,000 public chargers by 2030. Globally, millions more are being deployed by utilities, fleet operators, and municipalities, but building physical chargers is only half the equation.

The real challenge lies in connecting and managing them, ensuring thousands of devices, built by different manufacturers and speaking slightly different “languages,” can communicate reliably, securely, and at scale.

The Interoperability Challenge

At the center of this communication puzzle is the Open Charge Point Protocol (OCPP), the global standard enabling bidirectional communication between chargers and charge point operator (CPO) platforms.

In theory, OCPP promises plug-and-play interoperability. In practice, each charger vendor interprets the protocol slightly differently. Some implement OCPP 1.6, others OCPP 2.0 or 2.0.1. Even small variations in payload formatting or session handling can break compatibility.

For CPOs, this creates operational complexity:

• Multiple integrations for different vendors
• Duplicated maintenance and monitoring systems
  
• Higher risk of communication failures under load

Compounding the challenge, OCPP relies on long-lived WebSocket sessions, while modern IoT systems, including those built on AWS, favor publish-subscribe patterns like MQTT. Bridging these two paradigms at scale required rethinking the architecture from the ground up.

From Protocol to Platform

To close this gap, our engineers at Klika Tech designed a cloud-native adapter layer, a system capable of maintaining persistent WebSocket connections with thousands of OCPP chargers while translating those communications into MQTT events for downstream cloud services.

Each charger is treated as an IoT “thing” with unique MQTT topics such as:

ocpp/{charger_id}/status  
ocpp/{charger_id}/meter_values  
ocpp/{charger_id}/transactions 

This transformation unlocks the power of event-driven architecture: every charging event, firmware update, or diagnostic report becomes a discrete message that can be processed, stored, and analyzed through AWS-native tools.

The result is a vendor-agnostic, fully scalable foundation for EV charging management, one that preserves OCPP compliance while enabling real-time analytics, smart-energy scheduling, and cross-fleet visibility.

Architected for Scale and Resilience on AWS

Building the OCPP integration layer required balancing two non-negotiables: reliability and elastic scalability. The architecture was therefore designed entirely around AWS services that enable horizontal scaling, high availability, and real-time communication continuity.

The OCPP Adapter is deployed as a containerized application on Amazon Elastic Container Service (ECS), running on Amazon Elastic Compute Cloud (EC2) instances.

Each container maintains long-lived WebSocket connections with multiple charge points (CPs) handling bidirectional OCPP messaging. ECS tasks are designed for sustained uptime, allowing these WebSocket sessions to persist for extended periods without interruption, minimizing reconnection overhead and reducing network churn.

To distribute incoming connections, a Network Load Balancer (NLB) fronts multiple adapter containers. The NLB provides a single, fully qualified domain name (FQDN) that serves as the OCPP endpoint. When a new charge point initiates a WebSocket handshake, the NLB routes it to one of the available ECS tasks, which then establishes and maintains the session.

Once connected, each ECS task sets up an MQTT client with AWS IoT Core, using the charge point’s unique identifier as its Thing ID. This creates a one-to-one mapping between the WebSocket session and the MQTT topic hierarchy for that charger. The adapter subscribes to MQTT topics associated with each CP as follows:

$aws/things/{thingName}/shadow/update
/devices/lifecycle/+
req/v1/+/DEFAULT/+/energy-session-schedule-request

This design makes the MQTT client socket-aware: messages initiated from the CPO backend are automatically published to the correct MQTT topic, routed through AWS IoT Core, and forwarded back through the WebSocket to the corresponding charge point. This one-to-one mapping between WebSocket sessions and MQTT topics preserves OCPP request/response correlation and timing across the entire path.

Operational telemetry and communication metadata are stored in a dedicated MongoDB instance, allowing the platform to retain session history, credentials, and configuration states for each CP.

System health, connection counts, and latency metrics are continuously monitored via Amazon CloudWatch, while Auto Scaling Groups dynamically adjust ECS capacity based on demand. This ensures the platform can automatically scale up during peak traffic and scale down during idle periods, maintaining both high availability and cost efficiency.

This design makes the MQTT client socket-aware: messages initiated from the CPO backend are automatically published to the correct MQTT topic, routed through AWS IoT Core, and forwarded back through the WebSocket to the corresponding charge point. This one-to-one mapping between WebSocket sessions and MQTT topics preserves OCPP request/response correlation and timing across the entire path.

Operational telemetry and communication metadata are stored in a dedicated MongoDB instance, allowing the platform to retain session history, credentials, and configuration states for each CP.

System health, connection counts, and latency metrics are continuously monitored via Amazon CloudWatch, while Auto Scaling Groups dynamically adjust ECS capacity based on demand. This ensures the platform can automatically scale up during peak traffic and scale down during idle periods, maintaining both high availability and cost efficiency.

At the code and deployment level, the system is built using Spring Boot with the Java-OCA-OCPP library. Each adapter instance operates as a WebSocket handler and MQTT client simultaneously, ensuring one-to-one message mapping between the cloud and the charger.

Containerized deployment on ECS/EC2 provides the long-running stability needed for persistent sessions, while keeping operational overhead minimal. Horizontal scaling policies are tied to CloudWatch metrics such as CPU utilization, connection count, and average response latency, ensuring adaptive scaling under real-world load.The result: stable operation exceeding 10,000+ concurrent charger connections and 99.9% uptime, verified under stress-test conditions.

SmartCharging: Making Infrastructure Intelligent

Once connectivity was stable, attention turned to intelligence. The adapter architecture implements OCPP SmartCharging profiles, enabling dynamic energy scheduling across distributed stations.

Default offline limits are set first. When a device is connected, the system applies short-lived temporary profiles (for example, 60-second expiration) with the desired current/power limits and refreshes them in a loop; when a device disconnects, temporary profiles expire and the defaults automatically take over.

When the grid is under pressure, charging current limits can be reduced in real time. When renewable production peaks, stations can automatically increase throughput. If a charger goes offline, default energy profiles ensure safe fallback behavior. Temporary “live” profiles expire gracefully, reverting to predefined limits until the charger reconnects, preventing uncontrolled consumption or stranded sessions.

This balance between automation and safety transforms ordinary chargers into active participants in the smart-grid ecosystem.

Extending Intelligence to the Edge

As networks grow, energy management can no longer be handled exclusively in the cloud. Localized decision-making, or edge logic, plays an essential role in balancing site-level energy demand and grid capacity. A controller positioned at the site can coordinate multiple chargers, ensuring that total load stays within local constraints while still delivering the fastest possible charging experience.

Managing and updating this edge software traditionally required bespoke, hardware-specific development. Today, solutions such as AWS IoT Greengrass simplify this challenge by providing secure, modular deployment of logic to on-premise gateways or charger controllers. Greengrass enables local data processing, message routing, and machine-learning inference while synchronizing with the cloud whenever connectivity is available.

This hybrid architecture, intelligence at the edge combined with orchestration in the cloud, allows charge-point operators to deploy advanced features like real-time load distribution, fault isolation, and local fallback behavior even in disconnected conditions. It represents the next stage of smart-charging evolution: an ecosystem that is both distributed and deeply connected.

At Klika Tech, these architectural principles guide how we design scalable IoT systems across industries, ensuring that intelligence, reliability, and sustainability extend seamlessly from the edge to the cloud.

The AWS reference architecture below illustrates how the same OCPP integration can be realized using fully managed container services. While our production environment runs the adapter on Amazon ECS with EC2 instances, the AWS implementation shown here uses AWS Fargate to demonstrate an equivalent, serverless realization of the same concept.

Turning Data into Insight

Once charger data begins streaming through AWS IoT Core, it becomes more than just telemetry, it becomes intelligence.

Each charger’s MQTT topics feed an event-driven pipeline that captures status updates, energy metrics, and session details in real time. The AWS reference diagram focuses on data ingestion and telemetry flow. Additional analytics services (Amazon Kinesis, AWS Glue and Athena) are part of the extended implementation used for insight generation; operators can aggregate and analyze this information to uncover patterns in charger utilization, session duration, or fault frequency.

Building on this foundation, Amazon SageMaker enables predictive analytics, detecting anomalies, forecasting demand, and optimizing energy pricing based on live conditions. What started as a communication bridge between chargers and the cloud evolves into a full insight engine, transforming operational data into decisions that enhance reliability, efficiency, and network performance.

Engineering Collaboration Behind the Scenes

Delivering this architecture required collaboration across multiple domains. Our Embedded specialists mapped OCPP message flows and edge behaviors, our Cloud architects designed the container and network topology and our QA engineers built test harnesses simulating thousands of concurrent charger connections.

The result was a rigorous validation pipeline that validates message integrity, reconnection logic, and SmartCharging scheduling under simulated and live conditions.This cross-functional synergy reflects a broader engineering philosophy long championed at Klika Tech: blending embedded expertise, cloud scalability, and data intelligence into cohesive, production-ready ecosystems.

Key Outcomes

The solution’s impact was measurable across every operational dimension. By combining protocol interoperability, elastic scaling, and data-driven intelligence, the platform delivered tangible performance and efficiency gains for large-scale EV charging management.

Capability	Outcome
Interoperability	Supported OCPP 1.6, 2.0, 2.0.1 out of the box
Scalability	Stable performance beyond 10,000+ concurrent chargers
Reliability	99.9% uptime with auto-reconnect and fallback logic
Efficiency	25% improvement in energy utilization via SmartCharging
Onboarding Speed	40% faster integration for new charger models

These outcomes validate the architectural approach, proving that cloud-native design can bring order and efficiency to one of the most fragmented areas in clean-energy infrastructure.

Lessons from the Field

Building and scaling an OCPP integration of this size surfaced valuable lessons for future IoT and mobility projects:

• Elastic by default. Systems that can auto-scale outperform those optimized for fixed capacity.
  
• Protocol fidelity matters. Even minor translation errors between OCPP and MQTT can ripple across entire fleets.
  
• Observability is non-negotiable. Real-time monitoring through CloudWatch and tracing tools ensures resilience.
  
• Test at scale. Simulating thousands of chargers in pre-production reveals edge cases before they reach the field.

These principles now guide how high-throughput, cloud-connected systems are designed, whether in industrial automation, connected healthcare, or electric mobility.

Toward a Connected Energy Future

The electrification of transport is reshaping how infrastructure is designed and operated. What once relied purely on physical assets, transformers, cables, and fixed-capacity chargers, is now governed by data, automation, and real-time decision making.

The OCPP integration architecture built on AWS demonstrates how modern cloud and IoT technologies can transform distributed charging assets into a coordinated, intelligent network. By connecting thousands of devices to a unified data layer, operators gain visibility, interoperability, and the agility to introduce new business models, from predictive maintenance and adaptive load balancing to dynamic, grid-aware pricing.

This approach establishes a scalable foundation for the next generation of energy ecosystems, where vehicles, chargers, and distribution grids continuously exchange information and adjust in real time to support sustainability goals.

Resources

To explore more on OCPP integrations, IoT-based EV management, and AWS IoT architecture:

• AWS Blog: Building a Charging Station Management System with AWS
• AWS Architecture: Electric Vehicle Charging OCPP Handler
• AWS Blog: Building an OCPP-Compliant Electric Vehicle Charge Point Operator Solution Using AWS IoT Core
• Open Charge Alliance (OCA): OCPP Specification Portal
• Klika Tech Blog, Insights into IoT, cloud architecture, and mobility solutions

By Mohammad Shirazi, Portfolio Manager, Klika Tech