Cloud Service Selection

Cloud service selection is the disciplined process of choosing, for each capability a system needs, the cloud service or combination of services that best satisfies its drivers, rather than defaulting to what the team knows or what is fashionable. AWS alone offers several ways to run compute, store data and move messages, each with different limits, pricing dimensions and operational models. Selection starts from the workload's characteristics, such as traffic shape, access patterns, state, latency and growth, then evaluates candidates against weighted criteria, validates critical assumptions with proofs of concept, and records the decision and exit path in an ADR. Done well, it prevents expensive redesigns once the system is in production.

Functional fit comes first: does the service support the features you need, such as transactions, ordering or your query patterns? Then limits and quotas, including item sizes, throughput, connections and timeouts, because hard limits force redesigns. Quality covers latency, availability SLA, durability and multi-AZ or multi-region options. The operational model asks who patches, scales and backs it up. Cost means the pricing dimensions applied to your workload profile at expected scale. Security and compliance cover encryption, IAM, audit, certifications and data residency. Ecosystem means the Java SDK, IaC provider and observability integration. Skills means team experience and hiring. Exit means data export, open protocols and alternatives. Weight these per decision.

Pick DynamoDB when access patterns are known in advance and key-based, scale is very large or very spiky, and you need predictable single-digit-millisecond latency without managing capacity or connections. Shopping carts, sessions, inventory reservations and idempotency records fit well: you design the table and keys around the queries, and the service scales almost without limit. Choose Aurora PostgreSQL when you need joins, multi-row transactions, ad-hoc queries, reporting or a data model that will keep evolving. The classic mistake is using DynamoDB for complex relational reporting, which leads to expensive scans and secondary indexes; ShopNow moved such reporting to Athena on S3 and cut its cost by 70%. Many systems use both.

Pick Lambda when work is event-driven, short-lived and spiky, with low steady utilisation: S3 upload processing, queue consumers with bursty traffic, webhook fan-out, scheduled glue and small APIs with modest traffic. You pay per invocation, scale to zero and manage no capacity. Choose EKS when traffic is steady and high, latency must be consistently low, processes run for a long time, or you already run many services on a shared platform with a service mesh and common tooling. Cost often decides it. ShopNow assumed Lambda would be cheapest for a new pricing API, but a proof of concept showed that steady 2,000 requests per second made EKS on Graviton three times cheaper.

Because the decisions that hurt most rest on assumptions that documentation and feature lists cannot confirm. A proof of concept validates the critical ones with your own workload, data and code: latency at target load, such as DynamoDB conditional writes at 50,000 per second with a p99 of 8 milliseconds; limits, like MSK partitions per broker at the planned throughput; cost at projected traffic, for instance Lambda against Fargate; integration with the Java SDK, IAM authentication and observability; and failure behaviour, such as failover time through the JDBC wrapper. Keep it narrow and time-boxed, with pass criteria agreed before starting. The results become evidence in the ADR and sometimes reverse the expected choice.

Match the service to the interaction pattern. SQS is a work queue: point-to-point decoupling, buffering and retries with dead-letter queues, where each message is handled by one consumer. SNS is pub/sub fan-out, pushing each message to many subscribers such as SQS queues, Lambda functions or HTTP endpoints. EventBridge is an event bus with content-based routing rules, schema discovery, archive and replay, and native integration with AWS and SaaS event sources. MSK is managed Kafka, for high-throughput streams ordered per partition key, long retention, replay by consumer groups and the Kafka ecosystem, at the cost of more operations. Avoid overkill: ShopNow rejected MSK for a simple notification queue and chose SQS.

A paved road is a curated, supported catalogue of services and patterns that teams can use with minimal friction, because the platform team has already done the hard work. Each service on it comes with IaC modules containing secure defaults, observability integration, runbooks, cost tagging and support, so a team creating an SQS queue gets encryption, a dead-letter queue and alarms automatically. It is the easy path, not the only path. The benefits are consistency, faster delivery, a smaller security surface and less operational sprawl; the risk is slowing innovation if it becomes rigid. ShopNow's paved road holds about 35 services, with six exceptions approved through its trail process.

Through a lightweight but explicit trail process, rather than either free choice or a blanket ban. The team writes an ADR explaining the need, which paved-road options were considered and why they do not fit, the evaluation results and the exit plan. A security review covers IAM, encryption, data classification and compliance. Before production, the service gets a named owning team that will operate it, an IaC module with secure defaults and tagging, observability integration and runbooks. If the service proves widely useful, the platform team may adopt it into the paved road. This leaves teams room to innovate while keeping every new service supportable, secure and visible to the organisation.

Pricing models favour different services at different volumes, so the best choice at launch may be the wrong one at ten times the traffic. Per-request pricing, as with Lambda and API Gateway, is cheap at low volume and expensive under high, steady load, where provisioned capacity on EKS or an ALB costs far less. DynamoDB on-demand suits unpredictable traffic, while provisioned capacity with autoscaling is cheaper for steady patterns. Scale also reaches limits, such as partition throughput, connection counts or account quotas. So model cost at current, expected and peak volume during selection, identify the crossover points, and set re-selection triggers such as cost growth or limits being approached.

Because lock-in is cheapest to reduce before data, integrations and team habits are built around a service. At selection time you can prefer open protocols or compatible APIs, such as PostgreSQL-compatible Aurora or Kafka-compatible MSK, put repository or adapter layers around proprietary APIs, and confirm that data can be exported in usable formats, for example DynamoDB export to S3. Two years later the same change costs a migration project. Assessing exit does not mean avoiding managed services; it means knowing the cost and path of leaving and accepting lock-in deliberately where the benefit is worth it. Record the exit path in the ADR and test the export at least once.