AWS Integration
Everything is available. That is the problem as well as the appeal.
What is AWS?
AWS integration means building on or connecting to Amazon Web Services, where the practical constraints are cost behaviour, the absence of a local region for Kenyan workloads, and the ease of building something more complicated than you need.
AWS offers a service for everything, which is genuinely useful and quietly dangerous. Architectures grow more elaborate than the problem requires because each additional service is easy to add and the bill arrives a month later.
Cost behaviour is the part people design around last. Charges for data leaving the platform and between availability zones accumulate in ways that do not appear in a proof of concept and become significant in production.
For Kenyan workloads there is also no local region, so latency to European or Middle Eastern regions is a real design input rather than a footnote. For most business applications it is acceptable and worth knowing before rather than after.
Why we price the month before the build
Duara builds on and integrates with AWS from Nairobi, and prefers boring architectures to impressive ones.
We size the monthly bill before building rather than after. An architecture that looks elegant and costs four times the estimate is a failure regardless of how well it runs, and clients rarely get that number from a supplier being paid to build it.
Who this is for
- You run workloads on AWS
- Your bill is larger than expected
- Latency from Kenya matters to your users
- An architecture has grown more complex than the problem
Industries we serve
- Technology companies
- Financial services
- Media and content
- Logistics technology
- Telecommunications
- Data heavy operations
Problems this solves
These are cost and complexity problems more often than capability problems.
- Architectures more complex than the problem. Each service is easy to add, so systems grow elaborate and the operational burden grows with them.
- Bills larger than expected. Data transfer and inter zone charges accumulate invisibly and appear a month after the decisions that caused them.
- Latency treated as a footnote. There is no local region, so round trip time from Kenya is a design input rather than something to discover in testing.
- Nobody owning the account. Resources are created for projects that ended and nothing removes them, which is a recurring cost with no owner.
What we deliver
Architecture kept as simple as the problem allows, monthly cost estimated before building, data transfer designed for rather than discovered, and unused resources identified and removed.
An architecture no more complex than needed
Monthly cost estimated before building
Data transfer patterns designed deliberately
Latency assessed for your actual users
Unused resources identified and removed
Documentation your team can operate from
Features
- Boring architectures preferred. Elaborate is easy to build and expensive to operate, and the operational burden lands on you rather than on us.
- Cost estimated before build. An architecture costing four times the estimate is a failure however well it runs, and clients rarely get that number from a supplier.
- Data transfer designed for. Charges for data leaving the platform and crossing zones accumulate invisibly and become significant at production volume.
- Latency stated honestly. No local region means round trip time from Kenya is real, acceptable for most business applications, and worth knowing beforehand.
- Unused resources found. Resources from finished projects are a recurring cost with no owner, and identifying them frequently pays for the engagement.
Benefits
- Predictable bills. Estimating before building turns cloud cost into a decision rather than a monthly discovery.
- Systems your team can operate. A simpler architecture is one your people can run without specialist knowledge you do not have.
- Latency expectations set correctly. Knowing round trip time upfront prevents a design that assumed a local region exists.
- Waste removed. Unused resources from old projects stop being billed monthly for nothing.
Technologies we use
- Architecture design. Choosing the smallest set of services that solves the problem rather than the most capable.
- Cost modelling. Estimating monthly running cost including transfer before anything is built.
- Data transfer planning. Designing where data moves, since crossing zones and leaving the platform both carry charges.
- Region and latency assessment. Choosing a region against real user location rather than by default.
- Resource audit. Identifying what is running, what it costs and what nobody needs any more.
The cost model rewards designing for it and punishes ignoring it. Data transfer is the charge that most often surprises, because it is invisible in a small test and material at production volume.
How the process works, step by step
AWS work usually takes three to eight weeks depending on scope, with the cost estimate produced before the build begins.
-
Step 1
Free account review
We look at what is running, what it costs and how much of it anybody still needs.
-
Step 2
Cost modelled first
Monthly running cost is estimated before building, since that figure should inform the design rather than follow it.
-
Step 3
Architecture kept small
The simplest design that solves the problem, because elaborate systems become your operational burden.
-
Step 4
Transfer and region decided
Where data moves and which region serves your users, both chosen deliberately rather than by default.
-
Step 5
Handover documented
Your team receives what they need to operate it without depending on us.
Quality assurance and how we work
The commitments attached to building something you will pay for monthly.
- We estimate monthly cost before building. An architecture costing four times the estimate is a failure however well it runs, and clients rarely get that figure from a supplier being paid to build it.
- We prefer simpler architectures. Elaborate is easy to build and the operational burden lands on you rather than on us, which is why we resist it.
- We state latency honestly. There is no local region, and round trip time from Kenya is a real input rather than a detail to discover during testing.
- We report resources nobody needs. Finding unused infrastructure from finished projects frequently pays for the engagement, and it reduces what you spend with us later.
- We hand over operating documentation. Infrastructure only we understand is a dependency you did not agree to when you chose a public cloud.
Frequently asked questions about AWS
Why do AWS bills grow unexpectedly?
Data transfer mostly. Charges for data leaving the platform and crossing zones are invisible in a small test and material at production volume.
Do you estimate cost before building?
Yes, and clients rarely get that figure from a supplier being paid to build. An architecture costing four times the estimate is a failure however well it runs.
Is there an AWS region in Kenya?
No, so workloads run from other regions and round trip time is a real design input rather than a footnote to discover later.
Does that latency matter?
For most business applications it is acceptable. For anything latency sensitive it needs designing around, and knowing beforehand is the point.
Why prefer simpler architectures?
Because elaborate is easy to build and the operational burden lands on you. A system your team can run is worth more than one that impresses.
Can you reduce our current bill?
Often. Unused resources from finished projects are common, and finding them frequently pays for the engagement.
What is right sizing?
Matching resources to actual usage rather than what was provisioned optimistically at the start, which is usually generous.
Should we use managed services?
Frequently yes. They cost more per unit and less in your people time, and that trade is usually worth making for a small team.
Can it connect AWS to our business systems?
Yes, and that is common where an application runs on AWS and the operational systems sit elsewhere.
How long does AWS work take?
Three to eight weeks depending on scope, with the cost estimate produced before the build rather than alongside it.
Do we need a dedicated cloud engineer?
For a simple architecture, usually not, which is one of the arguments for keeping it simple.
What about data residency?
Worth checking against your obligations before choosing a region, particularly for regulated data, and we would raise it early.
Can it handle high traffic?
Yes, and scaling is one of the genuine advantages, though it also means cost scales with traffic in ways worth modelling.
Who owns the account?
You do. We work in your account rather than ours, so nothing is hostage to a supplier relationship.
Can our team take it over?
Yes, and it is documented for that. Infrastructure only we understand is a dependency you did not sign up for.
What if we want to move off AWS later?
Simpler architectures move more easily. Heavy use of platform specific managed services makes leaving harder, which is worth weighing upfront.
Do you set up cost alerts?
Yes, as standard, since a bill trend visible weekly is manageable and the same trend at month end is a surprise.
Can it host AI workloads?
Yes, and those particularly need cost modelling since usage based charges scale with success rather than with headcount.
Who can access our AWS account?
Credentials you issue with the narrowest permissions that work, revocable by you at any time.
What does AWS work cost?
Scope determines the build, quoted alongside an estimated monthly running cost so both numbers are visible.
Glossary of terms
AWS terms in plain language.
- Data transfer cost
- Charges for data leaving the platform or crossing zones, which surprise people most often.
- Region
- The geographic location of infrastructure, which matters here since there is no local Kenyan region.
- Availability zone
- A separate facility within a region, where crossing between them carries a charge.
- Managed service
- A service AWS operates for you, which costs more per unit and less in your time.
- Right sizing
- Matching resources to actual usage rather than to what was provisioned optimistically.
- Orphaned resource
- Infrastructure still running and still billed for a project that ended.
Related services in Integrations
Talk to us about AWS
Open your AWS bill and find the largest line you cannot immediately explain. That is usually where to start.
Start your project