Deploying Event-Driven EV Depot Infrastructure with AWS CDK, EventBridge, and DynamoDB
How we architected a resilient, event-driven cloud infrastructure using AWS CDK, Amazon EventBridge, and DynamoDB to orchestrate a 40-van commercial EV depot under a strict 250 kW transformer ceiling avoiding multi-year utility upgrade delays and cutting carbon emissions by 40.3%.
Deploying Event-Driven EV Depot
Infrastructure with AWS CDK,
EventBridge, and DynamoDB
Electric last-mile delivery fleets are at the forefront of corporate decarbonization goals and Amazon’s Climate Pledge. However, as commercial operators rapidly deploy electric delivery vans, depot managers encounter a physical reality: the electrical grid.
When 40 delivery vans return to a logistics station after their evening shifts (18:00–21:00) with depleted batteries and connect to 10 DC fast-charging bays simultaneously, depot demand can spike to 482.6 kW. That is nearly double the site’s physical 250 kW substation transformer capacity.
Left unmanaged, this can overload electrical infrastructure, incur significant peak-hour electricity costs, and increase emissions when charging coincides with carbon-intensive grid periods. Furthermore, utility upgrades can involve 6–18 months of interconnection study delays and hundreds of thousands of dollars in capital expenditure for infrastructure that may remain underutilized for much of the day.
In this article, I’ll share how our team, AWSome Builds, engineered an event-driven operations platform using AWS CDK for Python, Amazon EventBridge, Amazon DynamoDB, and Amazon CloudWatch to orchestrate physical charging constraints in real time. By combining mathematical optimization, deterministic safety validation, and AI-assisted decision-making, our solution demonstrates how existing grid infrastructure may support fleet electrification while reducing carbon emissions and electricity costs.
Architecture Overview: The Decoupled Event Pipeline
In industrial fleet depots, unexpected disruptions are inevitable:
- Charging hardware trips offline, such as an inverter fault on Bay C04 at 21:15.
- Grid utilities impose emergency capacity curtailments, reducing the available power ceiling from 250 kW to 180 kW.
- Traffic delays cause delivery vans to arrive late with critically low State of Charge (SOC).
- Changes in grid carbon intensity make previously optimal charging schedules less environmentally efficient.
To handle these disruptions without tightly coupling telemetry ingestion to scheduling logic, we designed an asynchronous, event-driven architecture.
Amazon EventBridge decouples event producers from downstream processing. Amazon Bedrock assists with incident interpretation and operational recommendations, while Google OR-Tools CP-SAT handles mathematical scheduling and an independent deterministic validator checks the resulting plan before it is authorized. Amazon DynamoDB persists operational state, and CloudWatch provides visibility into system performance and infrastructure limits.
1. Infrastructure as Code: Defining the Stack with AWS CDK
Instead of maintaining manually configured resources or brittle infrastructure templates, we defined our cloud infrastructure programmatically using AWS CDK v2 for Python in
cdk/ev_depot_stack.py .This approach allows us to version-control infrastructure, reproduce deployments, and maintain application and infrastructure definitions in the same development environment.
Provisioning DynamoDB Tables with On-Demand Billing
Depot telemetry is bursty. Read and write activity increases during evening vehicle arrivals and morning departures, while demand can be significantly lower during the middle of the day. We therefore designed four dedicated DynamoDB tables using on-demand billing.
The following CDK excerpt illustrates the fleet-state table:
Plain text
from aws_cdk import (Stack,Duration,RemovalPolicy,aws_dynamodb as dynamodb,aws_events as events,aws_iam as iam,aws_cloudwatch as cloudwatch,)from constructs import Constructclass EVDepotStack(Stack):def __init__(self, scope, construct_id, **kwargs):super().__init__(scope, construct_id, **kwargs)# Real-time vehicle stateself.fleet_table = dynamodb.Table(self,"EVDepotFleetTable",table_name="EVDepotFleetState",partition_key=dynamodb.Attribute(name="VehicleId",type=dynamodb.AttributeType.STRING,),billing_mode=dynamodb.BillingMode.PAY_PER_REQUEST,point_in_time_recovery=True,removal_policy=RemovalPolicy.DESTROY,)
The complete architecture uses four logical tables:
-
EVDepotFleetState: Stores vehicle identifiers, battery SOC, arrival windows, and charging requirements.
-
EVDepotChargerState: Tracks charger availability, hardware faults, and charging-bay status.
-
EVDepotActiveSchedules: Stores authorized charging schedules and interval-based power allocations.
-
EVDepotDisruptions: Records operational incidents and operator approval information.
On-demand billing accommodates variable request volumes without requiring manually provisioned throughput. Point-in-time recovery is enabled for the fleet-state table. For production deployments, retention policies should be selected carefully;
RemovalPolicy.DESTROY is appropriate only when the associated data can safely be discarded during stack deletion.2. Event-Driven Disruption Routing with Amazon EventBridge
Point-to-point integrations between telemetry producers and scheduling components can become difficult to maintain as the system grows. We addressed this by provisioning a custom EventBridge bus named
ev-depot-bus .Plain text
# Custom EventBridge bus for depot telemetryself.event_bus = events.EventBus(self,"EVDepotEventBus",event_bus_name="ev-depot-bus",)
In our Python backend,
backend/aws_client.py publishes structured event payloads when operational conditions change.Plain text
import jsonimport logginglogger = logging.getLogger(__name__)def publish_disruption_event(self,event_type: str,payload: dict,) -> bool:"""Publish operational telemetry to Amazon EventBridge."""if not self.is_connected or not self.eventbridge:return Falsetry:response = self.eventbridge.put_events(Entries=[{"Source": "ev.depot.iot","DetailType": event_type,"Detail": json.dumps(payload),"EventBusName": self.eventbridge_bus,}])return response.get("FailedEntryCount", 0) == 0except Exception:logger.exception("EventBridge publication error")return False
This method checks the response for failed entries and logs publication exceptions. In production, the caller should also handle unsuccessful responses, implement retries with backoff where appropriate, and use idempotent event processing to prevent duplicate events from triggering conflicting schedule updates.
Standardized Event Schemas
We established four event contracts to represent the most important depot disruptions:
-
InverterFaultEvent: Contains the charger ID, fault code, and time the charger became unavailable.
-
UtilityCurtailmentEvent: Communicates changes to the permitted grid power ceiling, such as a reduction to 180 kW.
-
CarbonSpikeAlert: Signals an increase in marginal grid emissions that may justify shifting flexible charging sessions.
-
VehicleArrivalTelemetry: Includes the vehicle ID, battery capacity, arrival SOC, and required departure deadline.
These structured events allow the platform to respond to changing operating conditions without requiring every telemetry source to understand the internal implementation of the scheduling engine.
3. Mission-Critical Observability with Amazon CloudWatch
Transformer overload is a physical infrastructure risk, so the system needs clear operational visibility and timely alerts.
We used AWS CDK to define a CloudWatch dashboard named
EVDepot-Operational-Orchestration and a metric-based alarm for transformer overload risk.Plain text
# Operational dashboardself.dashboard = cloudwatch.Dashboard(self,"EVDepotDashboard",dashboard_name="EVDepot-Operational-Orchestration",)# Depot peak-demand metricpeak_metric = cloudwatch.Metric(namespace="EVDepot/Orchestration",metric_name="DepotPeakDemandKW",statistic="Maximum",period=Duration.minutes(5),label="Peak Transformer Load (kW)",)# Transformer overload alarmself.overload_alarm = cloudwatch.Alarm(self,"TransformerOverloadAlarm",alarm_name="EVDepot-TransformerOverloadRisk",metric=peak_metric,threshold=250.0,evaluation_periods=1,comparison_operator=(cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD),alarm_description=("Critical: Depot power demand exceeded ""the configured 250 kW transformer limit."),)
The dashboard is designed to surface key metrics, including:
-
DepotPeakDemandKW: Maximum observed depot power demand.
-
CarbonAvoidedKG: Estimated carbon emissions avoided through optimized charging.
-
CostSavingsINR: Estimated electricity cost savings.
-
DepartureReadinessPercent: Percentage of vehicles meeting their required departure SOC.
The overload alarm detects when the reported peak-demand metric exceeds the configured threshold. Because this example uses a five-minute metric period, it should not be interpreted as a guaranteed instantaneous protection mechanism. A production deployment should also incorporate appropriate telemetry frequency, alert delivery, safety margins, and independent local power-control mechanisms. Cloud monitoring complements rather than replaces electrical protection systems.
4. Key Lessons Learned and Architectural Patterns
The Dual-Mode Resilient Fallback Pattern
Industrial IoT systems must account for intermittent network connectivity and unavailable cloud services. We designed our AWS integration layer to support a local simulation fallback when AWS credentials or connectivity are unavailable.
In fallback mode, the platform can continue testing and executing supported local simulation workflows without making every operation dependent on cloud connectivity. When connectivity returns, synchronization can restore cloud-side state.
A production implementation must distinguish simulation from live depot control. Local fallback should not be treated as proof that real-world charging can safely continue without verified telemetry, and synchronization should include conflict resolution, idempotency, and recovery checks.
IAM Least-Privilege Security
Rather than granting broad administrative permissions to application components, we used resource-specific CDK permission grants where possible.
Plain text
self.fleet_table.grant_read_write_data(self.agent_role)self.event_bus.grant_put_events_to(self.agent_role)
These grants illustrate how the application role can be restricted to the resources and operations it needs. Additional permissions should be granted only where required, such as invoking an approved Bedrock model or writing to the remaining DynamoDB tables. On EC2, instance-profile roles allow the application to obtain temporary AWS credentials without embedding long-lived access keys in source code.
Keeping Generative AI Outside the Safety-Critical Boundary
Amazon Bedrock adds value by interpreting disruptions, summarizing operational trade-offs, and generating human-readable instructions for yard supervisors. However, a language model should not independently determine whether a charging schedule satisfies electrical or departure constraints.
Our architecture therefore separates the AI-assisted orchestration layer from deterministic scheduling and validation. Google OR-Tools CP-SAT computes charging allocations, the independent validator checks physical limits and vehicle requirements, and the operator reviews proposed actions where approval is required.
This separation is essential when applying generative AI to systems that interact with physical infrastructure.
Results and Impact
Against our modeled unmanaged charging baseline, the platform reports the following results:
- Carbon emissions: A 40.3% reduction, corresponding to approximately 610.9 kg of CO₂e avoided per night and more than 222 metric tonnes annually per depot if the modeled performance is sustained.
- Electricity costs: A 59.8% reduction, corresponding to approximately ₹11,910 in savings per depot per night.
- Transformer demand: A reported 48.2% reduction in peak demand, with the schedule designed to remain within the configured power ceiling.
- Departure readiness: All 40 modeled vehicles meet their required departure SOC and scheduled departure deadlines in the evaluated scenarios.
- Infrastructure utilization: The 60-night benchmark indicates that a 200 kW interconnect may be sufficient for the modeled fleet, potentially avoiding an expensive utility upgrade.
These figures describe the results of our modeled evaluation and should be interpreted in the context of its assumptions, charging profiles, tariff data, carbon-intensity inputs, and simulated disruptions. They are not a universal guarantee that every 40-vehicle depot can operate on a 200 kW connection.
Conclusion
The Carbon-Aware EV Depot Orchestrator & Utility Sizer demonstrates how AWS cloud services can support a more resilient and sustainable approach to electric fleet operations. AWS CDK makes the infrastructure reproducible, EventBridge decouples operational events from downstream processing, DynamoDB maintains fleet and schedule state, and CloudWatch provides operational visibility and threshold-based alerts. Amazon Bedrock adds AI-assisted incident interpretation without replacing deterministic scheduling or independent safety validation.
By combining event-driven architecture, mathematical optimization, and human-supervised AI, our team, AWSome Builds, aims to reduce charging costs and emissions while helping fleet operators make better use of existing electrical infrastructure. The broader lesson is that fleet electrification is not solely a hardware challenge: intelligent coordination of charging demand can be an important part of making the transition more economical, reliable, and scalable.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article