A public-works team needs containerized model inference that requires GPU instance types. Managed Rekognition does not cover their custom model. Which compute placement meets the special-hardware need?

Custom model inference that requires GPUs cannot run on services that do not expose GPU hardware. When managed Amazon Rekognition does not cover the public-works model, place containerized inference on Amazon ECS backed by EC2 GPU-capable instance types so the containers can access the accelerators they need. That special-hardware placement is the correct Task 3.2 pattern: prefer purpose-built AI services when they fit, otherwise select EC2 instance families that provide GPUs for DIY inference. Lambda with 128 MB memory as a substitute for GPU inference fails because default Lambda configurations do not provide GPU acceleration for custom heavy inference workloads, and starving memory makes the mismatch worse. S3 Transfer Acceleration endpoints acting as GPU accelerators fail conceptually: Transfer Acceleration optimizes long-distance object uploads via edge paths; it does not perform model inference or attach GPUs. ElastiCache Redis nodes with GPU flags enabled in the parameter group fail because ElastiCache is an in-memory data store, not an inference accelerator fabric, and parameter groups cannot invent GPUs. Exam caveat: GPU EC2 capacity has cost, driver, and AMI/container image considerations; also re-check whether a managed AI service or SageMaker-style option could meet the requirement before standing up a fleet. Operational check: register GPU instance types with the ECS cluster, confirm the inference container sees the GPU, run a representative public-works model batch, and monitor utilization and queue depth so capacity matches demand.