Here is the set of technical interview flashcards for .NET applications on AWS (EC2 vs. Fargate), structured progressively from foundational concepts to production troubleshooting:
Q: What is the fundamental difference between running a containerized .NET application on Amazon ECS with the EC2 launch type versus Fargate?
Answer
ECS on EC2: You provision, configure, patch, and manage the underlying EC2 virtual machine instances (the cluster hosts). You have full root-level control over the OS, instance types, and storage, but you carry the operational overhead of capacity planning and OS security patching.
ECS on Fargate: This is a fully serverless container platform. You do not manage or see any virtual machines. You simply define your container’s CPU and memory requirements in a Task Definition, and AWS provisions and isolates the compute capacity dynamically.
Common Pitfall
Assuming Fargate eliminates all infrastructure responsibilities. While it removes OS patching, you are still responsible for network security groups, IAM execution roles, container image vulnerabilities, and resource right-sizing.
Q: What are the key elements required in a Dockerfile to containerize a modern .NET application efficiently for AWS ECS?
A production-ready Dockerfile for .NET should leverage multi-stage builds to keep the final image lightweight:
Build Stage: Uses the .NET SDK image (
[mcr.microsoft.com/dotnet/sdk](https://mcr.microsoft.com/dotnet/sdk)) to restore dependencies and rundotnet publish -c Release.Runtime Stage: Uses the lean ASP.NET Core runtime-only image (
[mcr.microsoft.com/dotnet/aspnet](https://mcr.microsoft.com/dotnet/aspnet)) copying over only the published artifacts.Exposed Port: Explicitly exposes port 8080 (the modern default for non-root ASP.NET containers).
Non-Root User: Runs the app under a non-privileged user for security compliance.
Q: When making architectural trade-offs, when should a .NET system choose ECS on EC2 over Fargate?
Answer
You should choose ECS on EC2 when:
High 24/7 Utilization: Your instances run at a steady, high utilization rate (>60–70%), making EC2 Reserved Instances or Savings Plans significantly cheaper than Fargate’s pay-as-you-go per-second pricing.
Specialized Hardware: You require custom instance types like GPUs (for ML workloads), local NVMe storage, or specific kernel tuning.
Host-Level Agents: You need to install custom third-party monitoring or security agents directly onto the host operating system.
Mnemonic / Tip
“Bursty goes Fargate, Stable goes EC2.” If workloads are spiky or unpredictable, Fargate saves ops hours. If compute is dense, predictable, and fully utilized 24/7, EC2 wins on raw cost.
Q: What are the common production pitfalls and performance considerations when running high-throughput .NET APIs on AWS Fargate?
Answer
Cold Starts: Fargate tasks can take 25 to 60 seconds to provision from scratch during sudden scale-out events, unlike warm EC2 auto-scaling pools.
.NET Thread Pool & CPU Throttling: Fargate enforces strict CPU limits. If you configure a fractional vCPU (e.g., 0.5 vCPU), the container is hard-throttled using CFS quotas when it bursts, which can suddenly spike your ASP.NET Core request latency and cause thread pool starvation.
Memory Overhead: .NET’s Garbage Collector (GC) dynamically sizes heaps based on available host memory. On Fargate, ensure you configure server GC limits (
COMPlus_GCServer=1and memory limits viaDOTNET_GC_HeapHardLimitPercent) so the runtime doesn’t exceed your task container’s rigid memory boundary and trigger an OOM (Out Of Memory) kill.Common Pitfall
Undersizing memory or using default container GC settings on Fargate. Because Fargate tasks are terminated instantly when they breach their memory limit, an unconstrained .NET memory spike will lead to silent, hard container crashes.
Watch this comprehensive guide on ECS Fargate vs EC2 Launch Types to visually compare the cost models, performance overhead, and operational differences between running containers on AWS EC2 versus Fargate.