AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
10 business days
To start an AWS engagement
Scoping through first sprint
100%
Senior engineers, US-based
No offshore handoff on production infrastructure
Every sprint
Working software on a preview URL
Not a status deck between milestones
100%
Infrastructure you own
In your own AWS account, from the first commit
Where AWS actually fits
Six categories of AWS service, and the decision inside each one
AWS's catalog is wide enough that naming a service isn't the same as making a decision. Here's how we actually choose within each category, for the workload in front of us rather than the one in a case study.
Compute
EC2 for anything that needs a persistent, fully controlled OS. ECS or Fargate for containerized services that don't need Kubernetes's flexibility. EKS when you're already committed to Kubernetes or need real multi-cloud portability. Lambda for short, event-triggered work — a webhook, a nightly job — where paying per invocation beats a server that's idle most of the day.
Storage
S3 for object storage — the default for anything that isn't a filesystem or a database, designed for eleven nines of durability by storing objects redundantly across facilities. EBS for block storage attached to a single EC2 instance. EFS when multiple instances need to share the same filesystem concurrently.
Database
RDS for a managed relational database (Postgres, MySQL, SQL Server) when you want AWS handling backups, patching, and failover. Aurora when you need RDS's management plus higher throughput and faster failover, at a real premium over standard RDS. DynamoDB when the access pattern is key-value or wide-column at a scale where a relational engine would need constant tuning to keep up.
Networking
VPC design — public and private subnets, NAT gateways, security groups — is the layer most teams get wrong first, usually by leaving a database in a publicly routable subnet. CloudFront for content delivery and edge caching. Route 53 for DNS and, less obviously, for health-check-driven failover between regions.
Messaging and events
SQS for a durable queue between services that shouldn't block on each other. SNS for fan-out notification to multiple subscribers. EventBridge when the real need is routing events between decoupled services by rule rather than by a hardcoded subscriber list. Getting this layer right is most of what makes a microservice architecture resilient instead of just distributed.
Infrastructure as code
Terraform, the AWS CDK, or CloudFormation — the tool matters less than committing to one of them for everything, including the resources a teammate might otherwise create by hand in the console during an incident. A single undocumented click-ops change is usually where the next migration's surprises come from.
Architecture decisions
What's expensive to unwind after an AWS account is live
None of the following is hard to do correctly from day one. All of it is materially harder to retrofit once applications, pipelines, and habits have formed around the gaps.
IAM least privilege
AWS's default is deny — a new IAM identity can do nothing until a policy grants it — but the common failure runs the other way: broad managed policies attached early because a deadline was close, then never narrowed once the deadline passed. Scoping policies to what a role actually needs, and reviewing them as the system grows, is far cheaper before dozens of services depend on the wide version.
Multi-account structure
AWS Organizations lets you split production, staging, and sandbox into separate accounts with their own billing and blast radius, rather than separating them by tags inside one account. Retrofitting this after a year of shared-account sprawl means untangling resources and IAM policies that were never designed to be split apart.
The Well-Architected pillars
Security, reliability, performance efficiency, cost optimization, operational excellence, and sustainability are AWS's own framework for a reason — most production incidents trace back to a gap in one of the first two, and most runaway bills trace back to a gap in the fourth. Reviewing an architecture against all six before launch catches what a feature-by-feature review misses.
Tagging and cost visibility
A resource with no cost-allocation tag is a line item nobody can attribute to a team or a feature later. Enforcing a tagging policy from the first Terraform module is trivial; reconstructing ownership across thousands of untagged resources during a cost review is not.
Data transfer and egress
AWS makes data transfer between its own services in the same region cheap or free, and charges more deliberately for egress to the public internet and transfer between regions. An architecture that ignores this early tends to concentrate traffic in a way that's expensive to redesign once the topology is load-bearing.
Backups that are actually tested
RDS automated backups and S3 versioning are easy to enable and easy to assume are working. The gap that actually costs a company data is never having restored from one — a quarterly restore drill costs an afternoon and is the only way to know a backup strategy works before an incident forces the question.
What's involved
AWS engagement types
What moves the scope here is not service count — it's how much of the current environment was built by hand in the console and has to be reverse-engineered before it can be described as code, plus how many outside systems a migration has to reconcile against.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Cloud readiness audit | Fixed scope | 1 – 3 weeks | Architecture review against the Well-Architected pillars, IAM and network security review, and a prioritized list of what has to change before a migration or build starts. |
| Migration engagement | Fixed scope | 6 – 16 weeks | Workload-by-workload migration planning, database cutover, and validation, sized to how much of the estate is rehost versus refactor. |
| Greenfield architecture and build | Fixed scope | 8 – 20 weeks | New system designed and built directly on AWS — compute, data layer, and networking chosen for the workload, with infrastructure as code from the first commit. |
| Cost and security optimization | Fixed scope | 2 – 6 weeks | Rightsizing, orphaned-resource cleanup, IAM policy tightening, and a tagging strategy that makes the next review faster than this one. |
| Ongoing AWS support | Ongoing retainer | Ongoing | Standing ownership of infrastructure, deploys, and incident response through the next service launch, security patch, and audit. |
Ranges assume US-based senior engineers and include the security review a cheaper quote often strips out. The audit exists as its own first step because it's the fastest way to find out how much of an environment is undocumented before anyone commits to the rest.
Migration
The six ways to move a workload to AWS, and why the label matters
AWS's own migration framework names six strategies, often shortened to "the 6 Rs." The label a workload gets decided early is most of what sets the real timeline — treating a refactor as a rehost is the single most common way an AWS migration runs over budget.
Rehost
Moving a workload to AWS with minimal change — the classic "lift and shift." Fastest to execute, and it carries forward whatever inefficiencies the workload already had, which is fine for a deadline-driven move and a poor long-term architecture on its own.
Replatform
Moving to AWS with targeted changes that don't touch the core architecture — swapping a self-managed database for RDS, for instance. Captures real operational savings without a full rebuild.
Refactor
Re-architecting to take advantage of cloud-native patterns — breaking a monolith apart, moving to managed services, adopting serverless where it fits. The slowest and most expensive of the six, and the one that actually changes the application's shape, not just its address.
Repurchase
Replacing a system with a SaaS or managed equivalent rather than migrating it at all — moving a self-hosted CRM to a hosted one, for example. Sometimes the honest answer is that the workload shouldn't move to AWS as code; it should stop being self-hosted.
Retire
Decommissioning a workload nobody actually uses. Every migration audit turns up at least one system that costs more to move than to shut off, and finding it is worth the audit by itself.
Retain
Leaving a workload where it is, for now — a dependency that isn't ready to move, or a system whose migration cost doesn't clear the bar yet. A migration plan that pretends everything moves on the same timeline is usually wrong about at least one workload.
Database migration is usually the part that actually sets the cutover date, not the application code. AWS's Database Migration Service handles ongoing replication for a cutover with minimal downtime, but the schema and data-type differences between engines still have to be resolved by hand before DMS can do that job safely.
AWS vs. the alternatives
When AWS is the right cloud, and when the honest answer is different
AWS's breadth is real, and it's also not automatically the right choice for every workload. The decision is about your team and your workload, not about which provider has the biggest catalog.
Where AWS's breadth actually matters
Teams with varied workloads — some serverless, some containerized, some on managed databases with very different access patterns — get real value from having every option under one account, one IAM model, and one billing relationship, instead of stitching services across providers.
Where a narrower platform is the better call
A team already deep in the Microsoft ecosystem — Active Directory, .NET, Office 365 — often gets more out of Azure's native integration than out of AWS's broader catalog. The right platform is the one that fits the team and the existing stack, not the one with more services listed.
Vendor lock-in is real, and it's uneven across services
A container running on EKS or Fargate is close to portable to another cloud with modest rework. A system built deeply around DynamoDB's data model, Step Functions' state machine syntax, or Lambda-specific event structures is a much larger rewrite to move. Knowing which parts of an architecture are portable and which aren't is a decision to make deliberately, not discover during a renegotiation.
Multi-cloud is usually not the free insurance policy it sounds like
Running the same workload actively on two providers roughly doubles the operational surface for a redundancy benefit most teams never actually need. It earns its cost at specific thresholds — real regulatory requirements or genuine negotiating leverage at scale — and is a poor default for a team that hasn't hit either.
Hybrid and on-premises aren't going away
AWS Outposts and Direct Connect exist because plenty of real workloads have to stay partly on-premises — data-residency rules, latency-sensitive equipment, or hardware that isn't moving. A migration plan that assumes 100% cloud from day one sometimes has to walk that back once the actual constraints surface.
Hiring
What to look for when hiring an AWS developer
A certification proves someone studied for an exam. It doesn't prove they've made the tradeoffs above under a real deadline with real production traffic on the line.
Production incident experience
Ask about a specific outage they've handled on AWS, not a general description of their experience. The answer that mentions what they changed afterward is worth more than the one that just describes the fix.
Cost-consciousness as a habit, not an audit event
A developer who tags resources and rightsizes instances as a matter of course, without being told to, saves more over a year than an annual cost-optimization pass recovers in one sitting.
IAM and security literacy
Someone who defaults to the narrowest policy that works, and can explain why a resource shouldn't be publicly routable, is the difference between an architecture that's secure by default and one that's secure because nobody's found the gap yet.
Infrastructure-as-code fluency, not just familiarity
Having used Terraform is different from being able to structure modules so a team can extend them without stepping on each other. Ask to see a module they've written, not just a list of tools on a resume.
Certifications are a signal, not a substitute
AWS Certified Solutions Architect and similar credentials show someone studied the service catalog. They don't show judgment about when not to use a service — that only shows up in how someone talks through a real architecture decision.
Comfort saying no to a service
The engineers worth hiring are the ones who'll tell you a simpler service solves your problem instead of steering you toward the one with the more interesting job posting. That instinct is worth more than another certification badge.
Related
Related services
What AWS builds usually connect to.
Questions
Common questions about AWS development
What teams ask before a first call.
It depends heavily on scope — a cloud readiness audit is a small, fixed engagement; a full migration or greenfield build is a larger one, and an ongoing support retainer is priced to the environment rather than sold as a fixed headcount.
What moves the number most is how much of the current environment was built by hand in the console and has to be reverse-engineered before it can be described as code, plus how many workloads a migration actually has to touch. The audit exists to answer that before the rest gets quoted.
Designs and builds the compute, storage, database, and networking layers a system runs on — choosing EC2 versus Fargate versus Lambda for a given workload, RDS versus DynamoDB for a given data shape, and writing the Terraform or CDK that defines all of it as code rather than console clicks.
A good AWS developer also owns the parts that don't show up in a feature list: IAM policy scope, cost visibility, and backup strategy that's actually been tested, not just enabled.
It depends on the workload, not a blanket policy for the whole estate. A lift-and-shift (rehost) is fastest and carries forward existing inefficiencies; a refactor is slower and more expensive but actually changes the architecture to use cloud-native patterns.
Most real migrations mix strategies — some workloads rehosted to hit a deadline, others refactored because the current architecture is the actual bottleneck, and a few retired outright because nobody's using them. Treating every workload the same way is the most common source of a migration running over budget.
AWS's breadth is a real advantage for teams with varied workloads under one account and one IAM model. A team already deep in the Microsoft ecosystem — Active Directory, .NET, Office 365 — often gets more out of Azure's native integration than out of AWS's larger service catalog.
The right platform is the one that fits your team's existing stack and expertise, not the one with the most services listed. We'll tell you honestly if what you're describing is a better fit elsewhere.
For most workloads, ECS or Fargate runs containers reliably without the operational overhead of a Kubernetes control plane, and it's the cheaper and simpler choice for a team running a few dozen services or fewer.
EKS earns its cost at specific thresholds — real multi-cloud portability, genuinely heterogeneous workloads, or a platform team whose job is operating the cluster. We cover this decision in more depth on our DevOps page, since it applies beyond AWS specifically.
Rightsizing instances, cleaning up orphaned resources — unattached EBS volumes, idle load balancers, forgotten snapshots — and enforcing a tagging policy so spend can be attributed to a team or feature. This is usually the fastest-paying-back engagement we run, often covering its own cost within the first billing cycle.
Committed-use discounts like Reserved Instances or Savings Plans should come after that cleanup, not before it — locking in a multi-year commitment against an over-provisioned footprint just makes the waste contractual for another year.
AWS's default IAM posture is deny-by-default, which is a good starting point, but the common failure is a broad managed policy attached under deadline pressure and never narrowed afterward. Security groups and subnet routing are the other place we see the most real exposure — a database left reachable from the public internet because a subnet was never actually private.
A security review as part of the initial audit catches both before they're load-bearing, which is far cheaper than discovering them during an incident.
Yes — database migration is usually what actually sets a cutover date, more than the application code around it. AWS's Database Migration Service handles ongoing replication to keep downtime minimal, but the schema and data-type differences between source and target engines have to be resolved by hand first, and that work is where most of the real timeline risk lives.
We scope this separately from the application migration because it genuinely runs on a different critical path.