The goal is not to memorize every AWS service. Start with workload, trust boundary, failure mode and operational responsibility.
Work through the path
Open a card when you need it. Marking a lesson complete is optional and stays only in this browser.
1Start with identity and least privilege
An AWS design is incomplete until it says which identity can do what, to which resource and under which conditions.
Prefer workload identities such as IAM roles over long-lived access keys in application configuration. Separate deploy permissions from runtime permissions.
Access denied errors are useful design feedback. Do not fix them by attaching administrator access to the application.
Try it
For one service, list the AWS actions it actually calls and turn that list into a small runtime policy.
// Application code requests the SDK client. // The runtime supplies credentials through its role. var client = new AmazonS3Client(); // Do not commit accessKey or secretKey values.
2Separate configuration from secrets
A .NET application should read environment-specific settings at runtime and retrieve secrets from a managed mechanism.
Use appsettings for safe defaults and non-secret behavior. Use environment variables, a parameter store or a secrets manager for controlled access and rotation.
Make the configuration contract explicit and fail at startup for required values rather than deep inside a request.
Try it
Mark settings as safe default, environment setting or secret. Move the last category out of the file.
builder.Services
.AddOptions<PaymentsOptions>()
.BindConfiguration("Payments")
.ValidateDataAnnotations()
.ValidateOnStart();3Choose compute by operational responsibility
The right AWS compute service depends on how much scheduling, patching, scaling and networking you want to own.
A containerized ASP.NET API may fit a managed container service when you want to ship an image without managing a cluster. A VM gives more control and more responsibility.
Start with request duration, traffic pattern, startup time, background work, networking and team operations.
Try it
Describe the service without naming AWS. Then map requirements to two candidate services and write the trade-off.
Workload: request / worker / scheduled State: stateless or durable Scale: steady, bursty or event-driven Network: public, private or hybrid Operations: who patches and observes it?
4Make a cloud service explain its failures
Logs, metrics and traces answer different questions; an incident needs all three connected by useful correlation context.
Metrics show a symptom changed, logs explain an event and traces show where time moved across boundaries. Emit structured fields such as operation name and dependency duration.
Set alarms on user impact and resource saturation, not only on whether a process is alive.
Try it
Pick one API request and list the metric, log fields and trace span needed to debug a slow response.
logger.LogWarning(
"Payment provider returned {StatusCode} in {ElapsedMs} ms",
response.StatusCode,
stopwatch.ElapsedMilliseconds);No lesson matches that phrase.
Related tools
Turn the concept into a working example with the browser-based tools.