COST06-BP04 - Consider using shared resources
Implementation guidance
Where workloads or components have compatible requirements, share resources instead of provisioning dedicated capacity for each one. Sharing increases aggregate utilization, smooths out per-workload peaks and troughs, and lowers the total resource type, size, and number needed to meet your cost targets.
Identify sharing opportunities
Group compatible workloads: Look for workloads with complementary demand profiles (for example, batch jobs that run overnight alongside interactive workloads that peak during the day) that can safely share the same underlying capacity.
Use multi-tenant and managed services: Prefer services that pool capacity across tenants — for example, container platforms (Amazon ECS/EKS) bin-packing multiple tasks onto shared compute, serverless services that share the underlying fleet, or shared databases and clusters — rather than standing up isolated infrastructure per workload.
Manage shared resources safely
Right-size the shared pool: Size shared capacity to the aggregate demand of the tenants, taking advantage of statistical multiplexing rather than summing each workload’s individual peak.
Isolate and attribute: Apply appropriate isolation (namespaces, quotas, limits) so one tenant cannot starve another, and use split cost allocation data and tagging so shared cost is attributed fairly back to each consumer.
Validate against requirements: Confirm that sharing does not violate performance, security, or compliance requirements before consolidating workloads onto shared resources.
AWS Services to Consider
Amazon ECS / Amazon EKS
Bin-pack multiple tasks or pods onto shared compute to raise utilization and reduce the number of instances required.
AWS Lambda & serverless services
Share an underlying managed fleet across many workloads, paying only for what each invocation consumes.
Split cost allocation data
Attribute the cost of shared container and other resources back to individual workloads for fair chargeback.