AWS: Complete Developer Learning Guide

Amazon Web Services (AWS): Complete Developer Learning Guide

A practical, developer-focused guide to understanding cloud computing and building, deploying, securing and operating modern applications on AWS. Learn the services and architecture decisions that matter, with examples connected to ASP.NET Core, C#, Angular and SQL Server workloads.

1. Introduction

Amazon Web Services (AWS) is a cloud platform that provides on-demand infrastructure, managed services, databases, networking, security, analytics and application-development capabilities. Instead of purchasing and maintaining every server in your own data centre, you can provision cloud resources when needed and manage them through the AWS Management Console, command-line tools, APIs or infrastructure-as-code.

For a .NET developer, AWS can host an Angular frontend, ASP.NET Core Web API, background workers, relational databases, file storage, queues and monitoring infrastructure. The important skill is not memorising every AWS product. It is understanding the problem each service solves and selecting an appropriate combination.

Learning approach: Start with cloud and networking fundamentals, then learn identity, compute, storage, databases and integration. After that, explore containers, serverless, automation, observability, security and architecture trade-offs.

Learning Roadmap

1. 2. Cloud Computing Foundations
2. 3. AWS Global Infrastructure
3. 4. Accounts and Governance
4. 5. IAM and Identity Security
5. 6. Networking and VPC
6. 7. Compute Services
7. 8. Storage Services
8. 9. Database Services
9. 10. API and Application Integration
10. 11. Serverless Architecture
11. 12. Containers and Kubernetes
12. 13. Hosting Frontend Applications
13. 14. AWS for .NET Developers
14. 15. Messaging and Event-Driven Systems
15. 16. Application and Platform Security
16. 17. Monitoring and Observability
17. 18. Infrastructure as Code
18. 19. CI/CD and Deployment
19. 20. Modern Cloud Architecture
20. 21. Reliability and Disaster Recovery
21. 22. Cost Management and FinOps
22. 23. AI and Machine Learning on AWS
23. 24. Migration and Modernisation
24. 25. End-to-End .NET Application on AWS
25. 26. Choosing the Right AWS Service
26. 27. Common Mistakes and Best Practices
27. 28. Developer Checklist
28. 29. Interview Questions
29. 30. Official Learning Resources

2. Cloud Computing Foundations

Cloud computing is the delivery of computing resources over a network on demand. These resources can include virtual machines, storage, databases, networking, application platforms and managed software services.

Key cloud characteristics

• On-demand access: Provision resources when required through a console, API or automation.
• Elasticity: Increase or decrease capacity as workload demand changes.
• Measured usage: Track consumption and pay according to the pricing model of each service.
• Managed infrastructure: Delegate selected operational tasks to the cloud provider.
• Global reach: Deploy workloads in supported geographic regions and serve users through edge locations.

Cloud service models

Model	What it provides	Example	Developer responsibility
IaaS	Virtualised infrastructure such as compute, network and disks.	Amazon EC2	More responsibility for OS, runtime, patching and application operations.
PaaS / managed platform	A managed environment for deploying applications or using a platform capability.	AWS Elastic Beanstalk, Amazon RDS	Focus more on application, configuration and data; exact responsibility varies by service.
SaaS	Ready-to-use software delivered as a service.	Amazon QuickSight (business intelligence service)	Configure and use the application rather than manage its underlying platform.
Serverless	Managed execution or service capabilities without provisioning the underlying servers.	AWS Lambda, Amazon SQS	Design around events, limits, permissions, scaling and service behaviour.

Important distinction: Serverless does not mean that servers do not exist. It means the provider manages the server infrastructure and capacity model for you.

Shared responsibility model

AWS is responsible for security of the cloud, such as the physical facilities and underlying infrastructure. Customers remain responsible for security in the cloud, such as identity permissions, data classification, application code and configurations. The exact split changes by service: using a managed database reduces some infrastructure work but does not remove the need to secure accounts, data and access.

3. AWS Global Infrastructure

AWS infrastructure is organised into Regions, Availability Zones and edge locations. Understanding these building blocks helps with latency, resilience, data residency and disaster-recovery decisions.

AWS Global Infrastructure
│
├── Region (geographic area)
│   ├── Availability Zone A
│   │   └── One or more data centres
│   ├── Availability Zone B
│   │   └── One or more data centres
│   └── Availability Zone C
│       └── One or more data centres
│
└── Edge locations / points of presence
    └── Content delivery and edge services

• Region: A separate geographic area where AWS offers services.
• Availability Zone (AZ): An isolated location within a Region, designed to support fault isolation.
• Edge location: A point of presence used by services such as Amazon CloudFront to deliver content closer to users.

Deploying across multiple Availability Zones can improve availability, but it does not automatically create a complete disaster-recovery plan. Backups, data replication, recovery procedures and tested failover are still required.

4. AWS Accounts and Governance

An AWS account is a fundamental boundary for resource ownership, billing and access control. For learning, a single account may be sufficient. Larger organisations commonly use multiple accounts to separate production, development, security, logging and shared infrastructure.

Governance services and concepts

• AWS Organizations: Centrally manage multiple AWS accounts and apply organisation-level policies.
• Organizational Units (OUs): Group accounts by purpose, department or environment.
• Service Control Policies (SCPs): Set permission guardrails for accounts in an organisation. SCPs do not grant permissions by themselves.
• AWS Control Tower: Helps establish and govern a multi-account landing zone using recommended controls.
• AWS CloudTrail: Records account activity and API events for auditing and investigation.
• AWS Config: Tracks resource configuration and evaluates it against rules.

AWS Organization
├── Security OU
│   ├── Log Archive Account
│   └── Security Tooling Account
├── Workloads OU
│   ├── Development Account
│   ├── Testing Account
│   └── Production Account
└── Sandbox OU
    └── Learning Account

Account safety: Enable MFA for privileged identities, protect the root user, configure billing alerts and avoid experimenting with expensive services without a budget. Remove unused resources after labs.

5. IAM and Identity Security

AWS Identity and Access Management (IAM) controls who or what can access AWS resources and which actions are permitted. It is one of the most important AWS foundations.

Core IAM concepts

• Principal: An identity that can make a request, such as a user, role or AWS service.
• Policy: A JSON document describing allowed or denied actions on resources, optionally under conditions.
• IAM user: A long-lived identity; prefer federation and roles for workforce and workload access where appropriate.
• IAM role: An identity with permissions that can be assumed by trusted principals, including applications and AWS services.
• Temporary credentials: Short-lived credentials issued through AWS Security Token Service (STS).
• Least privilege: Grant only the permissions needed for a task.

Example IAM policy structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-documents/*"
    }
  ]
}

This illustrative policy allows reading objects from one named bucket. A real policy should be reviewed for required actions, resource scope, conditions and access paths.

Workforce and application identity

AWS IAM Identity Center can provide workforce access to multiple AWS accounts. For application workloads, use an IAM role or supported identity federation mechanism instead of embedding access keys in source code, appsettings files, container images or repositories.

.NET developer practice: Configure the AWS SDK to obtain credentials from its supported credential resolution mechanisms. In AWS-hosted workloads, attach an appropriately scoped role to the compute service rather than storing permanent access keys.

6. Networking and Amazon VPC

Amazon Virtual Private Cloud (VPC) lets you define a logically isolated network for AWS resources. Networking determines which resources can communicate, which can be reached from the internet and how traffic moves between environments.

Important networking components

Component	Purpose
VPC	Defines an isolated virtual network and IP address range.
Subnet	Creates a network segment within a VPC and an Availability Zone.
Route table	Controls where network traffic is directed.
Internet Gateway	Enables eligible resources in a VPC to communicate with the internet.
NAT Gateway	Allows resources in private subnets to initiate supported outbound internet traffic without accepting unsolicited inbound connections.
Security Group	Stateful virtual firewall attached to supported network interfaces/resources.
Network ACL	Stateless subnet-level traffic control.
VPC Endpoint	Provides private connectivity to supported AWS services without requiring internet routing.
Load Balancer	Distributes incoming traffic across registered targets.

Public and private subnet example

Internet
   │
Internet Gateway
   │
Public Subnet (Load Balancer / NAT Gateway)
   │
Private Application Subnets (EC2 / ECS tasks)
   │
Private Database Subnets (RDS)

Application tier → Database tier
Only required ports and paths are allowed

A subnet is not public merely because its name contains “public”. Its route table and the relevant resource configuration determine its connectivity. A database should normally not be directly exposed to the public internet.

Other networking services

• Route 53: DNS and domain-routing service.
• Elastic Load Balancing: Application, Network and Gateway Load Balancers for different traffic patterns.
• CloudFront: Content delivery network and edge delivery capabilities.
• AWS Direct Connect: Dedicated network connectivity between an organisation and AWS.
• Site-to-Site VPN: Encrypted connectivity between networks.

7. Compute Services

Compute services run application code, web servers, workers and other workloads. Select a compute option based on control, operational effort, runtime requirements, scaling behaviour and cost.

Service	What it does	Useful when
Amazon EC2	Resizable virtual machines.	You need OS-level control, custom software or traditional server hosting.
AWS Elastic Beanstalk	Managed application deployment and environment provisioning.	You want a guided platform for supported web application stacks.
AWS App Runner	Managed deployment for containerised web applications and APIs.	You want a simpler path for supported containerised web services.
AWS Lambda	Runs functions in response to events.	Event-driven tasks, automation, lightweight APIs and asynchronous processing.
Amazon ECS	Orchestrates containerised applications.	You want to run and manage container workloads.
AWS Fargate	Serverless compute engine for containers.	You want ECS or EKS containers without managing EC2 worker servers.
Amazon EKS	Managed Kubernetes control plane.	Your organisation needs Kubernetes APIs and ecosystem compatibility.

EC2 concepts

• AMI: Image used to launch an instance.
• Instance type: Defines compute, memory, storage and networking characteristics.
• EBS: Persistent block storage volumes for EC2.
• Key pair: Authentication mechanism for supported instance access methods.
• Auto Scaling: Adjusts instance capacity based on configured policies and demand.

EC2 is flexible, but you are responsible for more of the operating system and server lifecycle than with higher-level managed services.

8. Storage Services

Different storage services solve different problems. Object, block and file storage are not interchangeable.

Service	Storage type	Common use
Amazon S3	Object storage	Images, documents, backups, static assets, data lakes and application uploads.
Amazon EBS	Block storage	Disk volumes attached to EC2 instances.
Amazon EFS	Managed file storage	Shared file system access for supported Linux workloads.
Amazon FSx	Managed file systems	Workloads needing file systems such as Windows File Server or Lustre.
AWS Backup	Backup management	Centralised backup policies and protection for supported resources.

Amazon S3 concepts

• Bucket: Container for objects.
• Object: Data plus metadata and a key.
• Versioning: Keeps multiple versions of objects when enabled.
• Lifecycle rules: Transition or expire objects based on defined policies.
• Storage classes: Options with different access, retrieval and cost characteristics.
• Bucket policy: Resource-based permissions for a bucket and its objects.
• Presigned URL: Time-limited URL granting a defined operation to a recipient.

Upload a file to S3 from C#

using Amazon.S3;
using Amazon.S3.Model;

public sealed class DocumentStorage
{
    private readonly IAmazonS3 _s3;

    public DocumentStorage(IAmazonS3 s3)
    {
        _s3 = s3;
    }

    public async Task UploadAsync(
        Stream content,
        string bucket,
        string objectKey,
        CancellationToken cancellationToken)
    {
        var request = new PutObjectRequest
        {
            BucketName = bucket,
            Key = objectKey,
            InputStream = content
        };

        await _s3.PutObjectAsync(request, cancellationToken);
    }
}

Register the SDK client through dependency injection using the supported AWS SDK for .NET setup. The workload identity should have only the required S3 permissions. Validate file size and type, avoid public buckets by default, and use encryption and lifecycle policies appropriate to the data.

9. Database Services

AWS offers relational, key-value, document, in-memory, graph, time-series and other specialised data services. The right database depends on data shape, consistency, query patterns, transactions, scaling and operational requirements.

Service	Database model	Typical use
Amazon RDS	Managed relational database service	Relational workloads using supported engines such as SQL Server, PostgreSQL and MySQL.
Amazon Aurora	Cloud-optimised relational database compatible with PostgreSQL or MySQL	Relational workloads requiring Aurora architecture and features.
Amazon DynamoDB	Managed key-value and document database	High-scale access patterns with known partition and key design.
Amazon ElastiCache	Managed in-memory data store	Caching and supported low-latency data access patterns.
Amazon DocumentDB	Managed document database service	Document-oriented application workloads requiring its supported API compatibility.
Amazon Neptune	Graph database	Relationship-centric data and graph queries.

RDS and SQL Server

Amazon RDS for SQL Server provides managed SQL Server database instances. AWS manages many infrastructure and database administration tasks, but you still choose the edition and configuration, manage schema changes, secure access, plan backups and understand engine-specific feature limitations.

RDS versus DynamoDB

• Choose a relational database when relationships, joins, relational constraints and transactions are central to the application.
• Choose DynamoDB when access patterns can be modelled around partition and sort keys and the workload benefits from its managed key-value/document model.
• Do not select a NoSQL database only because it sounds more scalable. Data modelling and query patterns are essential.

10. API and Application Integration

AWS provides services for exposing APIs, routing traffic, connecting applications and coordinating workflows.

• Amazon API Gateway: Create, publish, secure, monitor and manage APIs.
• Elastic Load Balancing: Distribute application traffic across targets.
• AWS AppSync: Managed GraphQL API service with data-source integrations.
• AWS Step Functions: Coordinate multi-step workflows using state machines.
• Amazon EventBridge: Route events between AWS services, applications and supported SaaS integrations.

Example API request path

Browser / Angular Client
        │ HTTPS
        ▼
Amazon CloudFront (optional edge layer)
        │
        ▼
API Gateway or Application Load Balancer
        │
        ▼
ASP.NET Core API (ECS / App Runner / EC2)
        │
        ├── RDS / DynamoDB
        ├── S3
        └── SQS / EventBridge

API Gateway and a load balancer solve related but different problems. API Gateway provides API-management capabilities, while load balancers distribute network or application traffic to targets. Choose based on authentication, routing, protocol, integration and operational needs.

11. Serverless Architecture

Serverless architecture uses managed services so teams can focus on application behaviour rather than provisioning and maintaining the underlying servers. It is especially useful for event-driven workloads, variable traffic and asynchronous processing.

Common serverless building blocks

• Lambda: Execute code in response to events.
• API Gateway: Expose HTTP APIs and route requests.
• S3: Store objects and trigger events.
• DynamoDB: Managed key-value/document database.
• SQS and SNS: Queue and publish messages.
• EventBridge: Event routing and integration.
• Step Functions: Orchestrate workflows.

Example: file-processing workflow

User uploads file
      │
      ▼
Amazon S3 bucket
      │ Object-created event
      ▼
AWS Lambda function
      │
      ├── Validate file
      ├── Extract metadata
      └── Store processing result
              │
              ▼
        DynamoDB / RDS

Design considerations

• Functions should be stateless where practical; persist state in suitable services.
• Design handlers to tolerate retries and duplicate event delivery.
• Set timeouts, memory, concurrency and permissions deliberately.
• Use dead-letter queues or failure destinations where supported and appropriate.
• Monitor duration, errors, throttles and downstream dependencies.
• Consider cold starts, execution limits, networking and cost for the actual workload.

.NET on Lambda: AWS documents a managed .NET 10 Lambda runtime. ASP.NET Core applications can also be hosted using the Lambda ASP.NET Core server integration, subject to the supported deployment model and runtime requirements. Check the current runtime support page before choosing a target.

12. Containers and Kubernetes

Containers package an application and its dependencies into a portable image. They help standardise how software is built, tested and run across developer machines, CI pipelines and cloud environments.

Container services

• Amazon ECR: Managed container image registry.
• Amazon ECS: AWS container orchestration service.
• AWS Fargate: Serverless compute for supported ECS and EKS tasks/pods.
• Amazon EKS: Managed Kubernetes control plane.

Typical container deployment flow

ASP.NET Core source code
        │
        ▼
Build and test
        │
        ▼
Docker image
        │
        ▼
Amazon ECR
        │
        ▼
Amazon ECS service + Fargate
        │
        ▼
Application Load Balancer
        │
        ▼
Users

When to use ECS or EKS?

Amazon ECS	Amazon EKS
AWS-native orchestration with a simpler service model for many AWS container workloads.	Kubernetes API and ecosystem for teams that need Kubernetes portability, operators or platform conventions.
Often a good starting point for teams focused on running containers on AWS.	Can be appropriate when the organisation already operates Kubernetes or needs its capabilities.
Can use EC2 capacity or Fargate.	Can use managed node groups, self-managed nodes or Fargate for supported workloads.

Kubernetes is not automatically better than ECS. It adds a powerful abstraction and ecosystem, but also introduces operational concepts and complexity.

13. Hosting Frontend Applications

An Angular application is commonly built into static assets such as HTML, CSS and JavaScript. Those assets can be delivered through object storage and a content delivery network, while the API runs separately.

Common hosting approach

Angular build output
      │
      ▼
Amazon S3 bucket (private origin)
      │
      ▼
Amazon CloudFront
      │
      ▼
HTTPS + custom domain (Route 53 / ACM)
      │
      ▼
Browser users

Angular application ──HTTPS──> ASP.NET Core API

• Use S3 for static object storage and CloudFront for content delivery.
• Use AWS Certificate Manager (ACM) for supported TLS certificate workflows.
• Use Route 53 or another DNS provider to manage domain records.
• Configure cache behaviours and invalidation strategy for deployments.
• Keep API secrets out of frontend bundles. Browser code is public to its users.
• Configure CORS on the API only for the required origins and methods.

For a static Angular site, S3 plus CloudFront is a common architecture. It is not the same as running an Angular server-side rendering application; SSR requires an appropriate runtime and deployment design.

14. AWS for .NET Developers

AWS supports .NET applications through managed compute options, containers, virtual machines and the AWS SDK for .NET. The SDK provides .NET libraries for interacting with AWS services from C# applications.

Useful .NET integration options

• AWS SDK for .NET: Call AWS service APIs from C# using service clients.
• AWS Toolkit for Visual Studio: IDE integration for supported AWS development and deployment workflows.
• AWS Deploy Tool for .NET CLI: Helps package and deploy supported ASP.NET applications to selected AWS compute targets.
• Amazon.Lambda.Tools: CLI tooling for .NET Lambda projects.
• Docker: Package ASP.NET Core applications for container deployment.

Register an AWS SDK client in ASP.NET Core

// Program.cs
using Amazon.Extensions.NETCore.Setup;
using Amazon.S3;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAWSService<IAmazonS3>();

builder.Services.AddControllers();

var app = builder.Build();
app.MapControllers();
app.Run();

Install the relevant AWS SDK package and configure credentials through an appropriate provider. In AWS, use workload roles with least-privilege policies. For local development, use a secure developer credential mechanism supported by the SDK and AWS CLI.

Choosing a hosting option for ASP.NET Core

Option	Good fit	Trade-off
EC2	Custom OS configuration, legacy dependencies or server-level control.	You manage more of the operating system and deployment lifecycle.
Elastic Beanstalk	Managed environment for supported web application platforms.	Less low-level control than directly managing infrastructure.
App Runner	Simplified deployment of supported containerised web services.	Less infrastructure flexibility than a custom ECS platform.
ECS with Fargate	Containerised APIs and workers with control over task and service configuration.	Requires container and ECS concepts.
Lambda	Event handlers, asynchronous tasks and suitable HTTP workloads.	Requires designing for function execution model, limits and event behaviour.

Practical recommendation: For a conventional ASP.NET Core API, compare App Runner, ECS with Fargate and Elastic Beanstalk before choosing EC2. Use Lambda when the workload fits its event-driven execution model. There is no single best hosting service for every application.

15. Messaging and Event-Driven Systems

Messaging decouples application components. Instead of requiring one service to call another synchronously for every task, a producer can publish a message or event that another component processes independently.

Service	Pattern	Typical use
Amazon SQS	Message queue	Buffer work and decouple producers from consumers.
Amazon SNS	Publish/subscribe notifications	Fan out messages to multiple subscribers.
Amazon EventBridge	Event bus and routing	Route application, AWS service and supported SaaS events.
Amazon MQ	Managed message broker	Applications that need supported broker engines and protocols.

Queue-based order processing

Order API
   │ Send message
   ▼
Amazon SQS queue
   │ Poll / event source mapping
   ▼
Background worker (ECS or Lambda)
   │
   ├── Process order
   ├── Update database
   └── Publish completion event

Important messaging concepts

• Visibility timeout: Time during which a received SQS message is hidden from other consumers while being processed.
• Dead-letter queue: Captures messages that could not be processed successfully after configured receive attempts.
• Idempotency: Repeated processing of the same message should not cause unintended duplicate effects.
• At-least-once delivery: Some delivery modes can result in duplicate messages; consumers must be designed accordingly.
• Ordering: FIFO queues provide ordering and deduplication features within their documented constraints.

16. Application and Platform Security

Cloud security is a continuous engineering responsibility. Secure architecture combines identity, network boundaries, encryption, secrets management, vulnerability management, audit trails and application-level controls.

Core security services

• AWS KMS: Create and manage cryptographic keys and control their use.
• AWS Secrets Manager: Store, retrieve and rotate supported secrets.
• AWS Systems Manager Parameter Store: Store configuration data and supported secure string parameters.
• AWS WAF: Help protect web applications from common web exploits and unwanted traffic patterns.
• AWS Shield: DDoS protection capabilities.
• Amazon GuardDuty: Threat detection based on supported data sources.
• AWS Security Hub: Centralise security findings and posture management capabilities.
• Amazon Inspector: Assess supported workloads for vulnerabilities.
• CloudTrail: Audit API activity and account events.

Security practices

• Use MFA and federation for human access; use roles and temporary credentials for workloads.
• Apply least privilege and review permissions regularly.
• Encrypt data in transit and at rest where appropriate.
• Keep databases and internal services in private network paths when possible.
• Store secrets in a managed secret store; do not commit them to source control.
• Enable relevant audit and threat-detection services.
• Patch dependencies, scan images and protect CI/CD credentials.
• Test backups and incident-response procedures.

Never: Put AWS access keys in frontend JavaScript, public Git repositories, Docker images or application source code. Rotate exposed credentials immediately and investigate their use.

17. Monitoring and Observability

Observability helps teams understand the internal state of a system from its outputs. A production application needs more than a “server is running” check.

• Amazon CloudWatch: Metrics, logs, dashboards, alarms and related monitoring capabilities.
• AWS CloudTrail: Records account activity and API events for auditing.
• AWS X-Ray: Distributed tracing and service-map capabilities for supported integrations.
• Amazon OpenSearch Service: Managed search and analytics capabilities for supported use cases.
• OpenTelemetry: Vendor-neutral instrumentation framework that can export traces, metrics and logs through supported pipelines.

What should a .NET API monitor?

• Request rate, latency percentiles and HTTP error rates.
• Application exceptions and dependency failures.
• Database connection pool and query performance indicators.
• Queue depth, message age and failed processing.
• CPU, memory, container restarts and throttling.
• Business metrics such as completed orders or failed payments.

Use correlation IDs or trace context to follow a request across the Angular client, API, queue, worker and database. Avoid logging passwords, access tokens, personal data or other sensitive values.

18. Infrastructure as Code

Infrastructure as Code (IaC) describes infrastructure in version-controlled files so environments can be reviewed, reproduced and deployed consistently.

Common IaC tools

• AWS CloudFormation: AWS-native infrastructure provisioning using templates.
• AWS CDK: Define cloud infrastructure in supported programming languages and synthesize CloudFormation templates.
• Terraform: Declarative infrastructure provisioning tool commonly used across cloud providers.
• AWS SAM: Framework for defining and deploying serverless applications on AWS.

Why use IaC?

• Repeatable environments and controlled changes.
• Code review and change history.
• Reduced manual configuration drift.
• Reusable modules and deployment patterns.
• Integration with automated testing and CI/CD.

Good practice: Separate application configuration from infrastructure definitions, protect state and secrets, review planned changes, and avoid making untracked production changes through the console.

19. CI/CD and Deployment

CI/CD automates building, testing, packaging and deploying software. AWS workloads can be deployed using AWS-native services, third-party CI platforms or combinations of both.

Common tools

• AWS CodePipeline: Orchestrates release workflows.
• AWS CodeBuild: Builds and tests code in managed build environments.
• AWS CodeDeploy: Automates deployments to supported compute targets.
• GitHub Actions / GitLab CI / Jenkins: External CI/CD platforms that can deploy to AWS using appropriately scoped credentials or federation.
• Amazon ECR: Stores container images used by deployment workflows.

Example pipeline for Angular + ASP.NET Core

Git push / Pull request
        │
        ▼
Restore dependencies + build
        │
        ▼
Unit tests + security checks
        │
        ├── Angular build → S3 → CloudFront
        │
        └── .NET publish → Docker image → ECR
                                   │
                                   ▼
                              ECS / Fargate
                                   │
                                   ▼
                          Smoke tests + monitoring

Use separate environments, approvals where needed, deployment health checks and rollback procedures. Prefer short-lived credentials through supported federation (such as OIDC integration) over long-lived access keys stored in pipeline variables.

20. Modern Cloud Architecture

Modern cloud architecture is not simply a collection of managed services. It is the deliberate design of application boundaries, data flows, identity, deployment, resilience and operations.

Architecture approaches

• Monolith: One deployable application. It can be a sound choice for a small or evolving product.
• Modular monolith: One deployable application with explicit internal modules and boundaries.
• Microservices: Independently deployable services organised around business capabilities, with explicit communication and data ownership.
• Event-driven architecture: Components communicate through events and asynchronous reactions.
• Serverless architecture: Uses managed execution and integration services.
• Multi-account architecture: Separates workloads and governance boundaries across AWS accounts.
• Hybrid architecture: Connects cloud workloads with on-premises systems.

AWS Well-Architected Framework

The AWS Well-Architected Framework provides guidance for evaluating cloud workloads across six pillars:

1. Operational Excellence
2. Security
3. Reliability
4. Performance Efficiency
5. Cost Optimization
6. Sustainability

Use the framework to review trade-offs and identify improvements rather than treating it as a one-time certification checklist.

Modern design concepts worth learning

• Loose coupling: Reduce direct dependencies between components.
• Stateless compute: Keep durable state in suitable data services rather than local instance memory or disk.
• Immutable deployment: Replace application artifacts rather than manually modifying running servers.
• Zero-trust principles: Verify identity and authorise each access path; do not assume network location alone establishes trust.
• Policy as code: Automate checks for infrastructure and security requirements.
• Platform engineering: Provide reusable paved paths and self-service capabilities for development teams.

21. Reliability and Disaster Recovery

Reliability is the ability of a workload to perform correctly and recover from failures. High availability and disaster recovery are related but distinct concerns.

Resilience techniques

• Deploy critical components across multiple Availability Zones where the service and architecture support it.
• Use health checks and load balancing to route around unhealthy targets.
• Scale based on measured demand and safe capacity limits.
• Use queues to absorb bursts and isolate downstream failures.
• Set timeouts, bounded retries with backoff and jitter, and circuit-breaking behaviour where appropriate.
• Use backups, point-in-time recovery and replication according to business requirements.
• Test failover and recovery procedures regularly.

Disaster recovery terms

Term	Meaning
RTO	Recovery Time Objective: target time to restore a service after disruption.
RPO	Recovery Point Objective: acceptable amount of data loss measured in time.
Backup and restore	Recover data and infrastructure from backups after a failure.
Pilot light	Keep a minimal core environment ready and scale it during recovery.
Warm standby	Maintain a scaled-down but functional environment for faster recovery.
Multi-site active/active	Run workloads in multiple locations concurrently, with greater complexity and cost.

The right strategy depends on business impact, recovery targets, data consistency and budget. Multi-Region deployment is not automatically required for every application.

22. Cost Management and FinOps

Cloud cost is an architectural concern. Resource selection, data transfer, storage retention, idle capacity, observability volume and availability requirements all influence the bill.

Cost management tools and practices

• AWS Cost Explorer: Explore historical and forecasted cost and usage information.
• AWS Budgets: Set budget thresholds and alerts.
• AWS Pricing Calculator: Estimate expected costs before deployment.
• Cost allocation tags: Attribute eligible costs to teams, applications or environments.
• Compute optimisation: Right-size instances and choose suitable purchasing options.
• Storage lifecycle: Move or expire data according to access and retention needs.
• Data transfer: Review cross-AZ, cross-Region and internet egress patterns.

Billing reminder: Some AWS resources can continue generating charges even when you are not actively using them. Before ending a learning session, check running instances, databases, NAT Gateways, load balancers, snapshots, storage and other provisioned resources.

FinOps is a collaborative practice that brings engineering, finance and business teams together to understand and optimise cloud value—not merely to reduce every bill at any cost.

23. AI and Machine Learning on AWS

AWS provides managed AI services, machine-learning infrastructure and tools for building generative AI applications. Select a service based on whether you need a ready-made AI capability, a managed foundation-model platform or a custom ML lifecycle.

Service / capability	Purpose
Amazon Bedrock	Build generative AI applications using supported foundation models and managed capabilities.
Amazon SageMaker AI	Build, train, tune, deploy and manage machine-learning models.
Amazon Textract	Extract text and structured information from supported documents.
Amazon Rekognition	Image and video analysis capabilities.
Amazon Transcribe	Speech-to-text capabilities.
Amazon Comprehend	Natural-language processing capabilities.

Generative AI application pattern

Angular / Web Client
       │
       ▼
ASP.NET Core API
       │
       ├── Authentication + authorisation
       ├── Prompt / request validation
       ├── Retrieval from approved knowledge sources
       └── Amazon Bedrock model invocation
                    │
                    ▼
             Response validation
                    │
                    ▼
               Client response

For retrieval-augmented generation (RAG), a system retrieves relevant content from an authorised knowledge source and provides it as context to a model. You must design document permissions, chunking, indexing, retrieval quality, prompt-injection defences, data retention and evaluation. A model response should not be treated as inherently correct.

24. Migration and Modernisation

Moving an existing application to AWS is a planning exercise, not just copying files to a virtual machine. First understand dependencies, data, security, network connectivity, licensing, performance and recovery requirements.

Common migration strategies

• Rehost: Move an application with minimal changes.
• Replatform: Make limited changes to use managed services or improve operations.
• Refactor / re-architect: Change application design to use cloud-native capabilities.
• Repurchase: Replace an existing solution with a different product.
• Retire: Remove an application that is no longer needed.
• Retain: Keep an application where it is for a justified reason.

Example: modernising a .NET application

1. Inventory the ASP.NET application, SQL Server database, file storage, scheduled jobs and integrations.
2. Assess runtime compatibility, Windows dependencies, licensing and network requirements.
3. Choose an initial hosting model such as EC2, Elastic Beanstalk, App Runner or ECS.
4. Move file storage to S3 where object storage fits the access pattern.
5. Evaluate Amazon RDS for SQL Server or another database option against feature and licensing needs.
6. Externalise configuration and secrets; establish IAM roles and network boundaries.
7. Automate build, test, deployment, monitoring and recovery.
8. Validate performance, security, data integrity and operational readiness before cutover.

25. End-to-End .NET Application on AWS

Consider a business application with an Angular frontend, ASP.NET Core Web API, SQL Server database, document uploads and background processing. One possible architecture is shown below. It is an example design, not a universal blueprint.

                         Users
                           │
                           ▼
                 Route 53 + HTTPS
                           │
                           ▼
                     CloudFront
                      │       │
             Angular assets   API traffic
                  │              │
                  ▼              ▼
              Amazon S3     Application Load Balancer
                                 │
                                 ▼
                         ECS Service / Fargate
                           ASP.NET Core API
                           │       │       │
                           │       │       └── Secrets Manager
                           │       │
                           ▼       ▼
                      Amazon RDS  Amazon S3
                      SQL Server  Documents
                           │
                           ▼
                    SQS / EventBridge
                           │
                           ▼
                  Background worker / Lambda

          CloudWatch + CloudTrail + IAM + KMS
          CI/CD + ECR + Infrastructure as Code

How a request flows

1. A user opens the Angular application delivered through CloudFront.
2. The frontend sends an HTTPS request to the ASP.NET Core API endpoint.
3. The load balancer routes the request to a healthy application task.
4. The API authenticates and authorises the user, validates input and applies business rules.
5. The API reads or writes data in RDS and stores documents in S3 using its workload role.
6. Long-running work is placed on SQS or published as an event rather than blocking the user request.
7. A worker processes the message and records its outcome.
8. CloudWatch collects operational telemetry, while CloudTrail records account activity.

Important implementation decisions

• Use private subnets for application tasks and databases where appropriate; expose only the required entry points.
• Keep the database inaccessible from the public internet unless there is a carefully justified exception.
• Use IAM task roles and least-privilege access to S3, SQS and other services.
• Store secrets in Secrets Manager or an appropriate configuration service.
• Use database backups, deployment health checks and a tested rollback strategy.
• Define environment-specific configuration without copying production secrets into development.
• Choose a database engine only after validating compatibility, licensing, performance and operational requirements.

26. Choosing the Right AWS Service

Service selection should begin with requirements and constraints—not with a desire to use the newest service.

Requirement	Services to evaluate	Questions to ask
Host a .NET web API	App Runner, ECS/Fargate, Elastic Beanstalk, EC2	How much infrastructure control and operational ownership do you need?
Run event-triggered code	Lambda, ECS worker	Does the task fit function limits, or does it need a continuously running worker?
Store uploaded files	S3, EFS, FSx	Is the data object, shared file or block storage?
Relational database	RDS, Aurora	Which engine, features, licensing and compatibility are required?
Key-value/document access	DynamoDB	Can the data and access patterns be modelled around keys?
Queue background work	SQS, EventBridge, SNS	Do you need durable work buffering, event routing or fan-out?
Expose APIs	API Gateway, Application Load Balancer	Do you need API management features or primarily traffic distribution?
Static web hosting	S3 + CloudFront	Is the site static, or does it require server-side rendering?

27. Common Mistakes and Best Practices

Common mistakes

• Using the root account for routine administration.
• Giving broad administrator permissions to application workloads.
• Embedding access keys or secrets in source code.
• Making a database publicly accessible without a strong reason.
• Assuming a single Availability Zone deployment is highly available.
• Choosing microservices or Kubernetes before the complexity is justified.
• Using synchronous calls for every background task.
• Ignoring retries, duplicate messages and idempotency.
• Deploying infrastructure manually without repeatable definitions.
• Leaving test resources running and overlooking data-transfer costs.
• Assuming backups are useful without testing restoration.

Best practices

• Build a secure account foundation before deploying production workloads.
• Use roles, temporary credentials, MFA and least privilege.
• Design network boundaries deliberately and keep internal resources private.
• Automate infrastructure and application delivery.
• Monitor application-level and infrastructure-level health.
• Use managed services when their operational and feature trade-offs fit.
• Design for failure, retries, graceful degradation and recovery.
• Tag resources and review cost trends regularly.
• Document architecture decisions and revisit them as requirements change.

28. Developer Checklist

Before deploying a workload to AWS, verify:

• Account, Region and environment are selected correctly.
• Root account is protected and privileged access uses MFA.
• Workload identity uses a role and least-privilege permissions.
• VPC, subnet, route and security-group rules are reviewed.
• Secrets are stored outside source code and container images.
• Data encryption, backup and retention requirements are defined.
• Application health checks, logs, metrics and alerts are configured.
• Build, tests and deployment are automated.
• Rollback and disaster-recovery procedures are documented and tested.
• Budgets, cost alerts and resource tags are configured.
• Unused learning resources are removed after practice.

29. AWS Interview Questions

Fundamentals

1. What is AWS? A cloud platform offering infrastructure and managed services on demand.
2. What is a Region? A geographic area containing multiple isolated Availability Zones.
3. What is an Availability Zone? An isolated location within a Region used to support fault isolation and resilient designs.
4. What is the shared responsibility model? AWS secures the cloud infrastructure; customers secure their workloads and configurations according to the service model.
5. What is the difference between IaaS and PaaS? IaaS offers more infrastructure control and responsibility; PaaS/managed platforms reduce selected operational tasks.

Compute, storage and databases

6. What is EC2? A service for running virtual machine instances in AWS.
7. What is Lambda? An event-driven compute service that runs code without customers managing the underlying servers.
8. What is S3? An object storage service for storing and retrieving data.
9. What is the difference between EBS and S3? EBS provides block storage volumes; S3 stores objects in buckets.
10. RDS versus DynamoDB? RDS is a managed relational database service; DynamoDB is a managed key-value/document database.

Networking, security and architecture

11. What is a VPC? A logically isolated virtual network for AWS resources.
12. Security Group versus Network ACL? Security Groups are stateful controls associated with resources/network interfaces; Network ACLs are stateless subnet-level controls.
13. What is IAM? AWS identity and access management for controlling access to resources and actions.
14. Why use IAM roles for applications? Roles provide temporary credentials and avoid embedding long-lived access keys.
15. What is CloudFront? A content delivery network and edge service for delivering content with lower latency.
16. SQS versus SNS? SQS provides queue-based message buffering; SNS provides publish/subscribe message delivery.
17. What is EventBridge? An event bus service for routing events between applications, AWS services and supported SaaS sources.
18. What is IaC? Managing infrastructure through version-controlled definitions and automation.
19. What is the Well-Architected Framework? AWS guidance for evaluating workloads across six architecture pillars.
20. How would you deploy an ASP.NET Core API on AWS? Evaluate App Runner, ECS/Fargate, Elastic Beanstalk, EC2 or Lambda according to runtime, traffic, control and operational requirements.

30. Official Learning Resources

Use official documentation as the source of truth for service limits, supported Regions, pricing, runtime lifecycles, security configuration and current implementation steps.

• Getting Started with AWS – account setup, fundamentals and hands-on tutorials.
• AWS Documentation – product guides, API references and tutorials.
• AWS Well-Architected Framework – architecture principles and review guidance.
• AWS IAM User Guide – identities, roles and policies.
• Amazon VPC User Guide – networking and connectivity.
• AWS SDK for .NET V4 Developer Guide – use AWS services from .NET applications.
• Building Lambda Event Functions with C# – .NET Lambda development and runtime guidance.
• Overview of Amazon Web Services – broad service and platform overview.
• AWS Skill Builder and Training – learning plans and training resources.
• AWS Pricing Calculator – estimate service costs before deployment.

Version and lifecycle note: AWS services, supported runtimes, features and prices change over time. In particular, verify the currently supported .NET runtime and deployment tool versions in the official AWS documentation before starting a production project. This guide explains concepts and common patterns; it is not a substitute for service-specific implementation documentation.

Skills Tutorials

Learn • Build • Grow Together