[Webinar] Docs-as-code without the complexity.→ Save your seat
<- Back to main blog

Exploring AWS: cloud software system deployment options

Knowledge ManagementUpdated: May 26, 2026
Dragos
Dragos
Founder, robot with feelings. From planet Aiur.

Discover how Archbee Wiki enhances software development across various cloud providers with efficient deployment options on AWS.

Exploring AWS: cloud software system deployment options

Let's explore our cloud software system deployment options.

We've got the big 3: AWS, Google Cloud Platform and Azure. Maybe 5 if we include IBM Cloud and Oracle Cloud which are catching up rapidly. Then we've got the small&medium ones in Heroku, Digital Ocean, Linode, Vultr and more.

One good mental model on how to categorize them is to separate them by if they provide hosted services.

Most of the big ones offer hosted app environments, hosted databases, email services, hosted queues, machine learning as a service, functions as a service, computer vision, data warehouseing, hosted cache, etc.

From the small&medium ones only Heroku offers hosted services, and they are for the most part limited to app servers and databases.

Digital Ocean seems to be trying to get more service oriented with Spaces & Kubernetes (coming soon). The rest focus mostly on giving us barebones machines that we need to install and manage whatever services we want on them, but they do provide very good value for the money.

AWS was the first platform to arrive in this space and is offering the most comprehensive set of cloud tools out of all the other cloud providers. In this article we're going to explore everything it has to offer.

Barebone machines - EC2/Lightsail#

Like every other cloud provider mentioned above, this is the basic thing it offers. If your designed software architecture requires it and you've got yourself a strong devops and ops team, might be the way to go. Its advantage is the configurability.

You can do whatever you want, install and configure services with whatever parameters. AWS is particularly good in this regard because it allows us to choose from a wide range of available machine configurations.

One of the complaints we've heard over the years are that you cannot choose the ratio of RAM/CPU. You can only pick from the predefined ones. Another one is that sometimes they are a bit more expensive than other cloud counterparts.

A lower-cost alternative from AWS is Lightsail, meant to compete with smaller vendors like Digital Ocean.

Application engines#

Elastic Beanstalk#

This is a service where they host your applications without you having to configure the machine yourself. You can pick your programming language environment from a set of predefined ones like: Java, .NET, Node.js, PHP, Go, Python, Ruby, and Docker.

The Docker option is particularly interesting because this way you can deploy any of the not-mainstream programming languages for backend development, like: Erlang/Elixir, Haskell, Crystal, Rust, OCaml.

The advantages of Elastic Beanstalk are obvious: you don't need to install packages on servers, keep the OS updated, apply security patches, worry about being hacked other than what's going on in your own code. On top of that, you can setup an auto-scaling system with Elastic Load Balancing so you can sleep at night when you know this part of your system auto-scales with load.

Keep in mind that Elastic Beanstalk still works on top of EC2, so sometimes you might still need to get your hands dirty and SSH into one of those machines to see what's happening.

AWS Lambda#

Runtimes for functions as a service are getting better and better. You can now run your .NET, Java, Node.js, Go or Python application without actually having a server reserved just for you.

The runtime just quickly spawns your instance as it receives events and shuts it down after a while. This way, Lambda can actually be alot less expensive than renting an EC2 instance in some cases. It also scales by itself so basically this part of your system will never go down because of traffic spikes.

The only major downside of FaaS are startup times. They can be anything from 500ms for Go to 6s for Node.js and Python. Imagine what startup time for a Java based Spring application will be as it has to instantiate the dependency injection container.

The user experience will certainly be lesser, even if you keep functions warm by pinging them, because having a traffic spike, the system will have to spawn other instances on the fly. Basically it's another case of reliability versus performance.

Containers - ECS/EKS#

Containers are awesome. Why? Read about how the invention of shipping containers revolutionised worldwide transportation and global trade.

If you make the analogy and see how until 2015 software deployment has been all over the place, with pieces not fitting together, you quickly understand containers are the future. You get a nice abstraction of software, OS, and hardware configuration for free.

As opposed to FaaS which might also seem like the future, it doesn't actually present any downsides for user experience.

AWS was also one of the first movers to provide services in this space, even though Google was using containers internally long before.

What AWS provides for you here is a way to deploy and run containers with their own system, or Kubernetes. One key technology from AWS you should actually keep an eye on is Fargate. It allows you to run containers without having to manage servers or clusters.

Database services#

Hosted databases have lots of advantages: automatic backups, redundancy, optional automatic scaling, logging, zero-configs and easy config options. It's a crucial part of most systems, so never go cheap or neglect this one. AWS provides:

RDS#

RDS is AWS's hosted relational database service. Just a couple of clicks and you've got yourself a ready to rumble hosted database system.

Options include MySQL/MariaDB, PostgreSQL, Oracle, SQL Server, or Aurora. Aurora is AWS's own flavor of MySQL/PostgreSQL and promises lower costs and greater scalability.

Even though we experienced lots of marketing for the newer database systems in the last couple of years, relational databases haven't fallen out of favor.

They're 30-40 year old technology that's battle tested and powers 90% of our systems. You can't go wrong picking relational, though sometimes they're not the complete best option.

DynamoDB#

DynamoDB is AWS's hosted document database. If you want to avoid any maintenance or scaling work, it's an excellent choice. As with any option, it does have some downsides.

First, the development experience is not as good as you would get with MongoDB or a RDBMS.

Second, it's inexpensive when your system is small/medium. Once you cross a certain threshold, it might be a lot more expensive than anything else.

Third, it's not good for everything. Some times you resort to use Elasticsearch for what might've been a simple query in other database systems. AWS has a great document explaining when to use/when not to use DynamoDB. It's certainly not very general purpose, but extraordinary for some use cases.

As a designer/architect, always use the best tools for the job, do a good analysis of requirements beforehand. When not sure, go back to choosing RDBMS.

Neptune#

This is a 2018 development. We should be praising AWS for making this step.

If you've ever used Neo4j, you know how good graph databases can be.

Development experience is great.

Performance is very very good when you're dealing with deep relations. Consider that in RDBMS a join can be anything from O(1) to O(n*m). In graph databases it's always O(1), or it should be from a theoretical standpoint.

Let's keep our eye on Neptune, because it's never been a better time to have graph databases at our disposal.

Elasticache#

It's all about scale. Choose between Memcached and Redis as a backend, and you're good to save database hits and scale effortlessly.

Redshift#

It's again all about scale. This time scale of data. If you have so much data you need to warehouse, AWS has got your back. 100% hosted, Redshift can handle any amount of data you throw at it.

File/Blob Storage#

S3#

S3 is internet's darling. If S3 crashes, a big percentage of the internet will be down. It stores everything from websites, images, videos, database files, etc.

It's a very reliable service, auto-scales, and gets lots of love from developers all over the world.

Glacier#

Glacier is a low-cost solution for long-term storage of files/data.

Application Integration#

Amazon MQ (ActiveMQ) and SQS are two services that you can use for your integration patterns. You'll be able to scale some parts of your system easier, and queue stuff wherever you need to.

As Apache Kafka is blowing up in popularity, Kafka as a service from AWS would be one nice thing to have, because ActiveMQ is antiquated and SQS is proprietary.

AppSync#

With Google launching Firebase a couple of years ago, AWS finally decided to offer their counterpart. Backed by Lambda and DynamoDB, they made the commitment to offer HTTP data interaction with GraphQL.

It seems most platforms are pushing 'serverless' / FaaS + Managed Databases, but don't commit in standardizing stuff or open sourcing anything. As developers are skeptical people in general, we can see why this kind of service hasn't taken off.

Vendor lock-in is a very serious problem.

Honorable mentions#

API Gateway is another AWS service which aims to mediate between external network requests and your internal infrastructure. It's highly configurable, but other than AWS's CloudFormation files which are a mess to work with, there's no way to express your intent as code.

Route 53 is great for purchasing domains and routing them to your AWS resources like S3, Elastic Beanstalk, API Gateways, Load Balancers, etc.

Certificate Manager is one of the niftiest services from AWS. You can generate SSL certificates for your domains and and assign them easily to your resources. The certificates can be auto-renewable, so you can rest assured you won't need to mess with Letsencrypt stuff.

Cloudwatch is AWS's cloud service for logs/events/metrics. Works well, and it's well integrated with most other AWS services.

How to write code for a good deployment experience?

Here's a diagram showing off our extensive library for AWS Services:

TURN STATIC DOCS INTO INSTANT ANSWERS

Build beautiful knowledge portals that are easy to navigate, search and share

SPRING 2026Easiest SetupENTERPRISE
SPRING 2026Easiest To UseENTERPRISE
SPRING 2026Best UsabilityENTERPRISE
SPRING 2026High PerformerENTERPRISE
UsersLove UsMILESTONE

How can Archbee help with your AWS based system?#

Archbee Wiki provides an easy to adopt solution for documentation & knowledge sharing that is specifically tailored to software development teams. We've studied many teams and their workflows, we've identified common usecases and coded them into our software's DNA. When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.

Frequently Asked Questions

The “big three” are AWS, Google Cloud Platform (GCP), and Microsoft Azure. A fast, practical way to size any cloud up is to look at the breadth and maturity of its managed (hosted) services—and how well those services fit your use cases.

  • Major clouds (AWS, GCP, Azure): Broad catalogs of managed services—hosted runtimes, databases, serverless, queues, ML/AI, data warehousing, caching, observability, and more. You ship faster by offloading ops to the provider.
  • Fast followers: IBM Cloud and Oracle Cloud are adding managed services and narrowing gaps.
  • Smaller/medium providers: Heroku (managed apps and databases) and VM-focused options like DigitalOcean, Linode, and Vultr where you mostly manage servers yourself.

Quick comparison checklist:

  • Managed services: Coverage, SLAs, and how opinionated they are
  • Regions and compliance: Data residency, latency, certifications
  • Pricing model: Transparency, egress costs, and predictability
  • Tooling and ecosystem: IaC support, SDKs, marketplace, community
  • Portability and lock‑in: Open standards, data export, container support

Rule of thumb: More mature managed services = less infrastructure to run and faster delivery, with trade‑offs in fine‑grained control and a higher risk of vendor lock‑in.

Both EC2 and Lightsail give you virtual machines you configure and operate. Choose based on how much control you need versus how quickly you want to get running.

Choose EC2 when you need:

  • Fine‑grained control over OS, networking, storage, and instance types
  • Advanced features (Auto Scaling Groups, Load Balancers, Spot, custom AMIs)
  • A wide range of instance families/sizes and accelerators (e.g., GPUs)
  • Tight integration with the full AWS ecosystem

Notes: You select from predefined CPU/RAM ratios, and EC2 can be pricier than some competitors.

Choose Lightsail when you want:

  • A simpler, lower‑cost VM experience with predictable pricing
  • Quick starts for straightforward workloads (blogs, small web apps, prototypes)
  • Bundled conveniences (static IPs, snapshots, basic load balancing) without deep AWS complexity

Shared responsibility with both:

  • You handle OS updates, security patches, runtime config, and monitoring.

Quick guide:

  • Pick EC2 for maximum flexibility and scale.
  • Pick Lightsail for simplicity, speed, and predictable costs.

Tip: You can start small on Lightsail and migrate to EC2 later as needs grow.

AWS Lambda runs your code in response to events—no servers to provision or manage. It supports Node.js, Python, Go, Java, and .NET, scales automatically, and you pay only for the compute you actually use.

Why it’s great:

  • Cost efficiency: Pay per invocation and duration—ideal for spiky or intermittent workloads
  • Autoscaling: Scales up and down with traffic without capacity planning
  • Deep integrations: Works seamlessly with API Gateway, S3, DynamoDB, EventBridge, and more

Trade‑offs to consider:

  • Cold starts: New instances can add latency during spikes or infrequent traffic (mitigate with provisioned concurrency)
  • Execution model: Stateless, ephemeral environments—not for long‑running or stateful tasks
  • Limits: Max execution duration and memory/CPU constraints apply

Good fits:

  • Event‑driven processing (file uploads, queue events, webhooks)
  • APIs and microservices (often behind API Gateway)
  • Scheduled jobs, lightweight ETL, and automation tasks

Not ideal for:

  • Constant, low‑latency workloads or long‑running processes
  • Workloads needing persistent connections or large, in‑memory state

Tip: If startup latency matters, design for brief warm‑up spikes, use provisioned concurrency, or consider containers (ECS/EKS/Fargate) for steady, always‑on traffic.

Match the database to your data model and query patterns.

  • RDS (Relational): Managed MySQL/MariaDB, PostgreSQL, Oracle, SQL Server, plus Aurora (MySQL/PostgreSQL‑compatible). Great general‑purpose default—familiar SQL, easier HA/backups, strong ecosystem.
  • DynamoDB (Document/Key‑Value): Fully managed, auto‑scaling, and zero‑maintenance. Excellent for well‑defined access patterns at massive throughput. Trade‑offs: a more constrained development model than RDBMS/MongoDB and costs that can climb at very high scale. For complex search‑style queries, pair with a search engine (e.g., OpenSearch).
  • Neptune (Graph): Optimized for deep relationship queries and fast traversals—ideal when your core model is entities and relationships (e.g., social graphs, recommendations, knowledge graphs).
  • ElastiCache (Redis/Memcached): In‑memory caching to reduce latency and offload reads/write bursts from primary stores.
  • Redshift (Data Warehouse): Columnar analytics warehouse for large‑scale BI, dashboards, and reporting.

Guideline: When in doubt, start with a relational database (RDS/Aurora) for transactional workloads and add specialized stores (DynamoDB, Neptune, ElastiCache, Redshift) as access patterns and scale requirements become clearer.

File/blob storage:

  • S3: Highly durable, massively scalable object storage for static websites, media, backups, logs, and more. Supports versioning, lifecycle policies (including archival), encryption, and cross‑region replication.
  • Glacier: Low‑cost archival tiers for long‑term retention with slower retrieval times—ideal for compliance and infrequently accessed data.

Application integration (messaging):

  • SQS: Fully managed message queues to decouple services, buffer workloads, smooth spikes, and handle retries. Supports DLQs and FIFO when ordered processing matters.
  • Amazon MQ (ActiveMQ): Managed brokers for traditional messaging patterns and protocol compatibility (AMQP, MQTT, STOMP, OpenWire)—useful for migrating or integrating with legacy systems.

Note: While Kafka is popular, in this context the native options highlighted are SQS and Amazon MQ.

Documentation, technical writing tips and trends Blog

Join 5000+ people from around the world that receive a monthly edition of the Archbee Blog Newsletter.