All-in-one serverless DevOps platform.
Full-stack visibility across the entire stack.
Detect and resolve incidents in record time.
Conform to industry best practices.
Dashbird continuously monitors and analyses your serverless applications to ensure reliability, cost and performance optimisation and alignment with the Well Architected Framework.
What defines a serverless system, main characteristics and how it operates
What are the types of serverless systems for computing, storage, queue processing, etc.
What are the challenges of serverless infrastructures and how to overcome them?
How systems can be reliable and the importance to cloud applications
What is a scalable system and how to handle increasing loads
Making systems easy to operate, manage and evolve
Learn the three basic concepts to build scalable and maintainable applications on serverless backends
The pros and cons of each architecture and insights to choose the best option for your projects
Battle-tested serverless patterns to make sure your cloud architecture is ready to production use
Strategies to compose functions into flexible, scalable and maintainable systems
Achieving loosely-coupled architectures with the asynchronous messaging pattern
Using message queues to manage task processing asynchronously
Asynchronous message and task processing with Pub/Sub
A software pattern to control workflows and state transitions on complex processes
The strategy and practical considerations about AWS physical infrastructure
How cloud resources are identified across the AWS stack
What makes up a Lambda function?
What is AWS Lambda and how it works
Suitable use cases and advantages of using AWS Lambda
How much AWS Lambda costs, pricing model structure and how to save money on Lambda workloads
Learn the main pros/cons of AWS Lambda, and how to solve the FaaS development challenges
Main aspects of the Lambda architecture that impact application development
Quick guide for Lambda applications in Nodejs, Python, Ruby, Java, Go, C# / .NET
Different ways of invoking a Lambda function and integrating to other services
Building fault-tolerant serverless functions with AWS Lambda
Understand how Lambda scales and deals with concurrency
How to use Provisioned Concurrency to reduce function latency and improve overall performance
What are Lambda Layers and how to use them
What are cold starts, why they happen and what to do about them
Understand the Lambda retry mechanism and how functions should be designed
Managing AWS Lambda versions and aliases
How to best allocate resources and improve Lambda performance
What is DynamoDB, how it works and the main concepts of its data model
How much DynamoDB costs and its different pricing models
Query and Scan operations and how to access data on DynamoDB
Alternative indexing methods for flexible data access patterns
How to organize information and leverage DynamoDB features for advanced ways of accessing data
Different models for throughput capacity allocation and optimization in DynamoDB
Comparing NoSQL databases: DynamoDB and Mongo
Comparing managed database services: DynamoDB vs. Mongo Atlas
How does an API gateway work and what are some of the most common usecases
Learn what are the benefits or drawbacks of using APIGateway
Picking the correct one API Gateway service provider can be difficult
Types of possible errors in an AWS Lambda function and how to handle them
Best practices for what to log in an AWS Lambda function
How to log objects and classes from the Lambda application code
Program a proactive alerting system to stay on top of the serverless stack
DynamoDB has two basic types of pricing models, based on capacity modes:
As the name suggest, on-demand will allocate resources as the application needs them, without any pre-provisioning. All costs are charged on a per-usage basis.
In povisioned capacity mode, developers can choose how many resources each database table will receive. They may also choose whether DynamoDB can auto-scale up resources if needed, or whether the database should start throttling requests once the provisioned capacity is reached.
For more details, read our article about the two different capacity modes.
Read Operation: an API call to read data from a DynamoDB table.
Write Operation: an API call to insert, modify or delete an item in a DynamoDB table.
Each Read Operation can read up to 4 KB of data. If the item is larger, DynamoDB will charge multiple Read Operation, rounded to the next multiple of 4 KB. Eventual consistent reads are charged only a half operation. Read operations inside transactions are charged double the normal price.
Each Write Operation can write up to 1 KB of data. For larger items, DynamoDB will charge multiple Write Operations, rounded to the next multiple of 1 KB. Write operations inside transactions cost double the normal price.
Bear in mind that, when using secondary indexes, DynamoDB needs to replicate all changes from the main table in the indexes. One extra Write Operation will be counted for each index associated.
Write operation costs $1.25 per million requests.
Read operation costs $0.25 per million requests.
Capacity usage is charged by units. If the database doesn’t reach a million operations, it’s not rounded up to the nearest million, but charged only for the requests actually used.
It is not possible to buy reserved capacity at discounted prices in On-Demand mode.
Dynamo also charges the amount of data stored at the price of $0.25 per GB-month.
Backups are chaged as per follows:
DynamoDB offers Global Tables, an automated multi-region replication system. It is charged at $1.875 per million write operations replicated.
DynamoDB Streams are charged at $0.02 per 100,000 read operations.
Data requested by requesters outside the AWS region where the DynamoDB table is deployed is charged at $0.09 per GB.
AWS provides a free tier with the following resources:
Write operation is charged at $0.00065 per capacity unit per hour.
Read operation is charged at $0.00013 per capacity unit per hour.
In provisioned mode, DynamoDB will provision the capacity and charge by the time it’s available. Observe that it’s a different model in comparison to On-Demand, which charges per request.
In provisioned mode, the application can issue several Read queries, for example, and get charged only one capacity unit. If all requests are sequential, they consume the same read capacity allocated.
It is possible to reserve capacity in advance with a monthly commitment in chunks of 100 capacity units (Read or Write). The price is as follows:
Reserved capacity can dramatically decrease costs with DynamoDB. If they are not used, though, no credit remains for the next billing cycle.
Global Tables (multi-region replication) is charged at $0.000975 per Read Capacity consumed.
Backup, DynamoDB Streams and data transfer have the same pricing as the On-Demand mode.
AWS provides a free tier with the following resources included:
No results found
End-to-end observability and real-time error tracking for AWS applications.