AWS application development
We design and build applications on Amazon Web Services (AWS). The way an application runs depends on its load: AWS Lambda functions, containers on ECS Fargate or App Runner. Infrastructure is defined in AWS CDK or Terraform, so every environment can be recreated from the repository.
When an application is a good fit for AWS
-
Traffic changes during the day or the season
Lambda functions and Fargate containers add capacity as the number of users grows and scale back after the peak. You pay for actual use, with no server kept running just in case.
-
The process has many steps
Order, payment, document, notification: we model processes like these in AWS Step Functions. Each step handles its own errors and can be retried without repeating the rest.
-
The application processes files
An uploaded file lands in Amazon S3 and immediately triggers a function that reads it, converts it or saves the result to the database. Nobody has to do it by hand.
-
Nobody keeps track of your AWS costs
We review the application's services, define them as code, tag resources and set budgets with alerts. You can see what each environment costs.
AWS or another cloud
We recommend AWS when an application has uneven traffic, processes files or consists of many event-driven steps. It offers the widest choice of serverless services, and Lambda, Step Functions and DynamoDB work well together. AWS also makes sense when your company already runs other systems there.
We consider another cloud in three situations. If your company has a Microsoft Azure subscription and a .NET application, it is easier to stay on Azure (see Azure application development). If data has to stay physically in Poland, we choose Azure or Google Cloud, because both have regions in Warsaw and AWS has no region in Poland. For a small application with steady, predictable traffic, a single server can be cheaper than cloud services, and we tell you so when we quote.
Example architecture of an application on AWS
A typical web application we build on AWS has several layers:
- Static interface files are stored in Amazon S3 and delivered through CloudFront with an HTTPS certificate.
- Amazon API Gateway receives user requests and passes them to a Lambda function or to a container on ECS Fargate.
- Data is stored in DynamoDB or, when the application needs relations and reports, in Amazon RDS for PostgreSQL.
- User files go to a separate S3 bucket, and each new file triggers a function that processes it.
- AWS Step Functions runs longer processes, and EventBridge passes events between parts of the application.
- CloudWatch collects logs and alarms, and cost budgets warn you when the planned amount is exceeded.
After deployment we can maintain and develop an application built this way as part of application maintenance and development. If you are planning your own subscription product, see how we build SaaS platforms and MVPs. We cover deployment automation and containers in more detail on our DevOps for applications page, and an example of Amazon Bedrock in use on our AI integration page.
What we do
- Application architecture on AWS, with a monthly cost estimate in the AWS Pricing Calculator
- Serverless backends on AWS Lambda and Amazon API Gateway
- Next.js, .NET and Node.js applications in containers on Amazon ECS Fargate or AWS App Runner
- Database chosen for the way the data is used: Amazon DynamoDB or Amazon RDS for PostgreSQL
- Multi-step processes in AWS Step Functions, with events passed through Amazon EventBridge and SQS
- Files and interfaces served through Amazon S3 and CloudFront
- AI models in Amazon Bedrock, with data processed in an EU region
- Infrastructure defined in AWS CDK, AWS SAM or Terraform, with automated deployments
- IAM permissions, logs and alarms in Amazon CloudWatch, and cost budgets
Who it is for
- You are building a new application with traffic that is hard to predict
- Your company already has an AWS account and wants to run the application on it
- The application runs on a single server and you want to move it into containers in the cloud
- The application's process involves many steps, files or integrations
Serverless: Lambda, API Gateway and DynamoDB
Serverless means there is no server for us to maintain. A request from the application reaches Amazon API Gateway, which invokes a Lambda function. The function runs the logic and saves data in DynamoDB. AWS provides the computing power, system updates and availability across several Availability Zones in the region. We choose this model for applications with uneven traffic and for event-driven tasks.
- No charges while nobody is using the application
- Availability across several Availability Zones with no extra configuration
- Each function deployed and scaled separately
Containers on ECS Fargate and App Runner
The Next.js and .NET applications in our portfolio run in Docker containers. On AWS we run them on Amazon ECS Fargate, which adjusts capacity to the load. Smaller applications go to AWS App Runner, which provides an address with an HTTPS certificate and automatic scaling without network configuration. A new version goes live with no downtime, and if something goes wrong, we roll back to the previous one.
- The same Docker image on a developer's laptop and in production
- New versions deployed without downtime
- Quick rollback to the previous version
Infrastructure in AWS CDK and Terraform
Every AWS service, permission and alarm is defined in code. Our own tools are deployed with AWS CDK and SAM, and the infrastructure of the new Conetso Group websites is defined in Terraform. Test and production environments are built from the same files, and every change is reviewed before it is deployed.
- Environments recreated from the repository
- IAM permissions limited to what each service needs
- Cost budgets and alerts for every environment
How we work
-
Requirements review
We establish the expected traffic, the type of data and the region. If you have an AWS account, we check what already runs on it.
-
Architecture and cost
We set out the AWS services that will run the application and give you an estimated monthly cost for the expected traffic.
-
Build in a test environment
Infrastructure is created from code, and the application is deployed automatically with every change. You get a test version to try out.
-
Production deployment
We create the production environment from the same files, set up alarms, budgets and data backups, and then switch over the domain.
Experience
- Our own product, Savanna One, a system for manufacturing companies, is delivered to clients as a service on AWS.
- For a client, we built automated contract checking in Amazon Bedrock in Frankfurt. It handles around 20 contracts a month and saves about 10 hours of work each month.
- The new Conetso Group websites run on Amazon S3 and CloudFront, an AWS Lambda function handles the forms, and the whole infrastructure is defined in Terraform.
- Our internal tools run on AWS Lambda, ECS Fargate, App Runner, DynamoDB and Step Functions, and are deployed with AWS CDK and SAM.
Case studies
-
Savanna One
Savanna One is our own product: a system for manufacturers that brings the warehouse, production and documentation together. Food producers already use it.
Frequently asked questions
Which AWS region will our data be in?
For companies in Poland and elsewhere in Europe, we run applications in AWS regions in the European Union, most often Frankfurt. We choose the region with you before the project starts, and data backups are stored there too.
Who will own the AWS account?
The account can belong to your company, and we receive the permissions needed to build and maintain the application. AWS then bills you directly for cloud usage. We can agree a different arrangement in the contract.
How much does it cost to run an application on AWS?
It depends on the traffic, the volume of data and the services used. Before work starts, we calculate it in the AWS Pricing Calculator for the expected load. After deployment we set budgets and alerts that tell you when spending goes over budget.
Can you move an existing application to AWS?
Yes. We start with a review of the code and the way it is deployed. Usually we first put the application in a container and run it on ECS Fargate, and only later move selected functions to Lambda, if that saves money.
See also
-
SaaS platforms and MVPs for startups
We build first product versions (MVPs) and SaaS platforms with user accounts, subscriptions, payments, licences and APIs.
-
Web application maintenance and development
On a monthly plan, we add new features, install security patches and look after the server. Response times are set out in an SLA.
From our blog
AWS vs on-premises hosting for web applications
AWS vs on-premises hosting for web applications: we compare a Docker server, AWS Fargate and Lambda functions, and explain how we choose.