A serverless application is not simply a Lambda function behind an API. It is a system of components with separate responsibilities for user interaction, business logic, storage, identity and background work. AWS operates many of the underlying services, but the application owner still decides what a request means, when data becomes durable, which failures can be retried and who is allowed to access a record. Understanding these boundaries matters more than assembling the largest possible list of AWS products.<\/p>\n
Consider an equipment-maintenance portal. A field technician signs in, enters an inspection, uploads a photograph and receives a receipt. A supervisor later reviews the finding, and a notification is sent if a machine needs attention. Saving the inspection requires an immediate response; processing a photograph or sending a message does not. This example shows how presentation, API, compute, persistence and events fit together without forcing every operation through one long-running request.<\/p>\n
The presentation layer collects actions and displays results. It might be a browser-based single-page application, a mobile app or another HTTPS client. Static files can live in Amazon S3 and be distributed through Amazon CloudFront<\/a>, while application requests go to a separate API. Delivering cached JavaScript and images efficiently does not authorize anyone to read equipment records; identity and data permissions remain a backend responsibility.<\/p>\n The logic layer validates a request, evaluates business rules and coordinates service calls. Amazon API Gateway commonly exposes routes such as POST \/inspections and GET \/inspections\/{id}, with AWS Lambda handling the requested operations. A Lambda function is a unit of compute, not a permanent place to store the application’s truth. Its execution environment can be reused or replaced, so application state that matters must be written to durable storage.<\/p>\n The data layer must match what users need to ask. The portal could use DynamoDB for inspection metadata and indexed status queries, Amazon S3 for photographs and reports, and a relational database if its domain requires complex transactions or joins. Keeping storage separate from business logic is not only a diagramming convention: it lets the team define consistency, retention and access rules without assuming the lifetime of one function invocation.<\/p>\n These layers resemble a conventional three-tier system, but serverless does not imply that every responsibility needs a separate cloud product. A small application may use a few cohesive functions and one primary data model. Splitting every action into its own independently deployed microservice adds interfaces and operational cost without automatically increasing reliability.<\/p>\n When a technician opens the portal, the web client loads and begins a sign-in flow. Amazon Cognito<\/a> or another identity provider may issue the appropriate token after successful authentication. The client includes that token when calling the inspection API. API Gateway must apply the configured authorization mechanism, and the application must still check whether the authenticated person is allowed to work on the particular asset. A signed-in screen alone does not secure an API.<\/p>\n API Gateway HTTP APIs and REST APIs are related but not interchangeable. An HTTP API may suit straightforward routing, Lambda integration and JWT authorizers with lower operational overhead. REST APIs provide additional API-management capabilities, including usage plans and certain caching and request-validation features. Choose the type that supports the required authorizer, request contract and controls. The deeper implementation relationship between API Gateway and Lambda<\/a> follows from that decision, not from a generic rule that one option is always more secure.<\/p>\n The create-inspection handler validates the payload, confirms asset ownership and creates an inspection identifier. A conditional database write can prevent a duplicate or unauthorized state transition. Only after the intended write has succeeded should the handler return a receipt saying the inspection was saved. Authentication establishes who the caller is; resource-level authorization determines what that caller may change. Those checks should be separate enough to test and audit.<\/p>\n Uploading a photograph deserves a different path from sending a small JSON inspection record. The backend may generate a short-lived S3 presigned upload URL scoped to the intended object, allowing the client to send the file without receiving broad bucket permissions. The application must later associate the object with the inspection and verify its ownership, expected format and lifecycle. A presigned URL solves the upload permission problem, not the entire file-validation problem.<\/p>\n The API response should also distinguish completed work from accepted future work. If the database commit succeeded but the alert has only entered a queue, tell the client that the inspection was recorded, not that every supervisor notification was delivered. Clear response semantics keep eventual consistency from turning into a misleading user experience.<\/p>\n Synchronous calls are appropriate for checking permissions, returning a record and confirming a required write. Tasks such as image analysis, notification delivery and secondary search-index updates often do not need to hold the user’s connection open. A queue lets producers submit work while consumers process it at an appropriate rate, so a temporary downstream failure does not make every inspection submission fail.<\/p>\n Amazon SQS<\/a> buffers messages and can trigger Lambda through an event source mapping. The consumer may receive a message more than once. Design operations around stable IDs and idempotent effects rather than assuming exactly-once processing. Partial-batch responses can prevent valid records in a failed batch from being unnecessarily retried, and a dead-letter queue provides a place to inspect persistent failures. Those settings do not replace application-level deduplication.<\/p>\n Amazon EventBridge is suited to distributing events to interested consumers according to rules. An inspection-created event might feed an operational dashboard and an alerting workflow without forcing the writer to know each recipient. An event bus distributes changes; a queue protects a work backlog. An architecture can combine them, with EventBridge routing a domain event to an SQS queue when the consumer needs buffering and separate retry control.<\/p>\n Where an activity requires a sequence of decisions, AWS Step Functions<\/a> can coordinate tasks, waits, retries and failure branches. A severe-fault report might need manager review, a replacement-parts request and confirmation from a vendor. Those states should be explicit rather than hidden inside a function that waits and sleeps. Each individual step still needs safe retry behavior and a clear rule for what happens when a later activity fails.<\/p>\n DynamoDB works well when key-based access and predictable query patterns dominate. For the maintenance portal, the team should know how to retrieve recent reports for an asset, list unresolved faults and locate one inspection by ID. Partition keys, indexes and conditional updates affect whether those queries remain efficient as usage grows. Choosing a NoSQL service is not a substitute for data modeling or an excuse to scan entire tables for every screen.<\/p>\n Amazon S3 is suited to durable objects such as photographs, exports and archived reports, not as a substitute for a transactional record model. Store the object’s identifier in the application metadata and explicitly handle an interrupted upload. A database row that says an image exists when the upload failed is a consistency error. State transitions such as awaiting-upload, ready-for-review and rejected allow support teams to understand and repair partial workflows.<\/p>\n A relational service, including Aurora Serverless where suitable, may be preferable for multi-record transactional rules or complex joins. The team still needs to assess connections, capacity behavior, cost and operational characteristics. Legacy product lists should not be treated as current architecture recommendations: Amazon QLDB, sometimes named in older serverless material, reached end of support in 2025 and is not a new-project choice. The correct data model comes from business requirements and supported service capabilities.<\/p>\n API authorization governs incoming callers. Lambda execution roles<\/a> govern what a function itself may do in AWS. A handler that writes inspections should receive only the specific database and storage permissions it needs, not administrator access. Domain checks are still required: granting a function permission to read a table does not mean every authenticated technician should see every row.<\/p>\nTrace a user request through API Gateway and Lambda<\/h2>\n
Move nonurgent work into event-driven components<\/h2>\n
Choose data storage around access patterns and consistency<\/h2>\n
Enforce security across identities, functions and networking<\/h2>\n