When we talk about cloud-native applications, we are simply defining them as applications that are built to run on the cloud and have the ability to access the cloud environment they are running on in one way or another. This capability can allow an application to be self-managed and, among other factors, can allow it to do any or all of the following:

• Provision its own resources, such as instances, databases, storage, and networks
• Access services in the cloud, such as monitoring and enumerating services to determine its own state
• Have the ability to scale itself according to events or metrics that are retrieved from the cloud
• Manage other applications running in the cloud

On the other hand, applications that have been designed with a server less approach in mind are designed in a way that they consume no visible server instance resources, and all of their processing, data storage, databases, and other features are delivered from environments managed by AWS delivered completely transparently to us. This can be achieved with any application that has very spiky, short bursts of processing activity and mostly delivers a static web page to users. A static web page can be simply deployed in AWS S3 and served by a CloudFront distribution, which will make the static website accessible and highly available by design. Any kind of request that requires processing can be forwarded in one way or another to one or multiple AWS Lambda functions, which can then run that query on predefined processing functions that have been stored in S3 with the static content itself. Outputs of Lambda can be stored in DynamoDB, the contents of which can also be viewed from JavaScript, and embedded within the static website hosted on S3:

This is just one example of a serverless application. Not one server instance needs to be running for this website to function, but it can still provide both static and dynamic content. It can also be integrated with other services to provide authentication, access from mobile applications, monitoring and advanced triggering through SQS queues, SNS notifications or AWS SWF, and so on.