@VenkateshG8536

a practical way to measure and shrink your app’s footprint on Pega CS running on Pega Cloud (AWS). Use PDC to track app-level resource signals: CPU and memory usage, HTTP latency, queue processors/listeners health, and backing services like search/stream; these are your best proxies for energy use at runtime. For storage/traffic, monitor object count and attachment size trends, DB/stream throughput, and cache hit ratios via PDC and platform dashboards; higher I/O and cache misses usually mean higher energy. Optimization basics: cut chattiness (batch calls, cache read-heavy data), tune data pages (refresh strategies), paginate lists, archive/purge old work and attachments, right-size/auto-scale nodes, and keep queue processors lean; avoid heavy reports during peak hours. For storage, enforce retention and lifecycle rules for large files to lower S3/EBS footprints. On integration: AWS offers the Customer Carbon Footprint Tool (CCFT) with CSV export and APIs, but it reports per AWS account; since Pega Cloud runs in Pega-managed AWS accounts, you won’t see CCFT directly unless workloads run in your own account—ask Pega for org-level reporting or roadmap.  As a lightweight KPI set, track CPU-hours, GB-hours of memory, GB of storage, GB of egress, and transactions per case and per user session, and target steady declines over each release using PDC baselines.  Finally, document “green SLOs” (e.g., ≤X CPU-ms per API call, ≤Y MB per case) and make them part of performance gates in your CI/CD so efficiency improvements stick.