DEV Community: Nehemiah Cheburet

How a Tier-1 Bank Can Use AWS Managed Services Without Losing Cloud Exit Optionality

Nehemiah Cheburet — Thu, 30 Jul 2026 19:46:54 +0000

Cloud migration is usually assessed through security, availability, performance and cost. Portability often comes later, when an organisation needs to change providers, satisfy a regulator or renegotiate a major contract.

For KenyaBank, portability must be designed in from the start.

KenyaBank is a Tier-1 Kenyan commercial bank serving about 4.2 million customers through 68 branches. It is modernising a legacy core banking environment running on Oracle WebLogic and Oracle Database in its Westlands data centre. The target architecture introduces AWS services such as Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon EventBridge, Amazon MSK, AWS IAM Identity Center, AWS Systems Manager and AWS CloudFormation.

These services reduce infrastructure work and speed up delivery, but each one creates a different level of AWS dependency.

The useful question is not:

Does the architecture contain vendor lock-in?

Almost every cloud architecture does.

The better question is:

Is the lock-in understood, controlled and justified by the business value it provides?

This article reviews five AWS-specific dependencies in KenyaBank's target architecture, estimates the effort required to replace each one and assigns an overall portability score.

Current and Target Context

KenyaBank's current environment includes:

A monolithic Java EE core banking application
Oracle WebLogic application servers
A 3.8 TB Oracle 11g database
A legacy internet banking application
Local teller servers in 68 branches
On-premises Microsoft Active Directory
MPLS connectivity between branches and the Westlands data centre

The target architecture uses the Strangler Fig pattern to modernise gradually. Internet banking will be containerised, the database will move towards Aurora PostgreSQL, and applications will increasingly communicate through events and managed messaging services.

This improves scalability and resilience, but it also introduces AWS-specific APIs, data models and operations.

What Vendor Lock-In Means Here

Vendor lock-in exists when moving an application, its data or its operations away from a provider would require significant time, cost or redesign.

For this assessment, lock-in is grouped into three types:

Type	Meaning	Example
API lock-in	Application code depends on provider-specific SDKs, APIs, event formats or behaviours.	Code built around DynamoDB `PutItem`, `Query` and `UpdateItem` cannot simply point to PostgreSQL.
Data lock-in	Data is stored in a model or format that is hard to reproduce elsewhere.	DynamoDB partition keys, indexes, access patterns and consistency behaviour may need redesign.
Operational lock-in	Deployment, identity, monitoring, patching or support processes depend on provider tools.	An app may be portable, but the operating model may need to be rebuilt.

Scoring Method

Each dependency is assessed using five factors:

Factor	Question
Application coupling	How much code uses AWS-specific APIs?
Data coupling	How difficult is the data to export and remodel?
Infrastructure coupling	Can the deployment definition run elsewhere?
Operational coupling	Must procedures and skills be rebuilt?
Replacement availability	Is there a mature portable alternative?

Portability is scored from 1 to 5:

Score	Interpretation
1	Highly proprietary; substantial redesign required
2	Significant lock-in; migration would be difficult
3	Moderate lock-in; migration is feasible with planning
4	Mostly portable; limited provider-specific changes
5	Highly portable; based mainly on open standards

Exit effort is expressed in engineering effort, not cost, because a financial estimate would require details such as table count, event volume, test coverage, staff rates and recovery requirements.

Dependency 1: Amazon DynamoDB

KenyaBank plans to use DynamoDB for session storage. This is attractive because DynamoDB provides managed scaling, high availability and low-latency key-value access without database server administration.

It is also the strongest source of lock-in in the assessed architecture.

Assessment	Result
Lock-in type	API and data
Portability score	2/5
Estimated exit effort	High, about 12-20 person-weeks
Justification	Partly justified

DynamoDB applications often depend on partition keys, sort keys, secondary indexes, conditional writes, TTL attributes, streams, capacity behaviour and AWS SDK models. Exporting the records is only the first step. KenyaBank would still need to design a target schema, translate data types, recreate indexes and expiration behaviour, rewrite the data-access layer, migrate active sessions, test performance and cut over without invalidating customer sessions.

For ordinary session storage, DynamoDB may create more coupling than necessary. Redis, PostgreSQL or MongoDB could provide a more portable model depending on the session requirements. Redis is especially worth testing because it supports short-lived session workloads and can run across cloud and self-managed environments.

Recommended control:

Validate whether the expected session volume genuinely requires DynamoDB.
Place a repository interface between application code and DynamoDB.
Keep business logic dependent on SessionRepository, not the AWS SDK.
Maintain alternative implementations such as RedisSessionRepository or PostgreSqlSessionRepository.

This will not remove data migration work, but it reduces the amount of application code that must change.

Dependency 2: Amazon EventBridge

EventBridge can route business and operational events between loosely coupled components. It is useful for AWS service integration, but it can become risky if core banking events are defined around EventBridge itself.

Assessment	Result
Lock-in type	API and operational
Portability score	2/5
Estimated exit effort	Medium to high, about 8-14 person-weeks
Justification	Yes, at AWS integration boundaries

Coupling can appear in the EventBridge event envelope, PutEvents calls, event-pattern syntax, rule-to-target configuration, IAM permissions, dead-letter handling, Scheduler usage and AWS-specific target integrations.

If producers publish raw EventBridge events directly, a move to Kafka, Google Cloud Pub/Sub or another event platform would require changes across many applications. Consumers may also become dependent on fields such as source, detail-type, account, region and detail.

The control is to separate the business event from the transport. KenyaBank should use a portable event specification such as CloudEvents and treat EventBridge as one possible delivery mechanism.

Recommended control:

Standardise domain events using CloudEvents.
Publish through an internal EventPublisher interface.
Keep AWS SDK calls inside adapters.
Store schemas in a provider-neutral repository.
Avoid placing business rules only in EventBridge rule definitions.
Use EventBridge mainly for AWS-native operational events.

Dependency 3: AWS CloudFormation

CloudFormation gives KenyaBank repeatable AWS deployments, change tracking and automated infrastructure management. The problem is that CloudFormation templates use AWS-specific resource types such as AWS::S3::Bucket and AWS::EC2::VPC.

Assessment	Result
Lock-in type	Operational
Portability score	2/5
Estimated exit effort	Medium, about 8-16 person-weeks
Justification	Not for the long-term target state

The deployed resources may use standard technologies, but the infrastructure definition cannot run directly on Azure, Google Cloud or on-premises platforms. Coupling increases with intrinsic functions, nested stacks, StackSets, exports, transforms, Lambda-backed custom resources and CloudFormation-specific pipelines.

Moving from CloudFormation to Terraform or OpenTofu would require stack inventory, resource mapping, state import, dependency rewrites, non-production testing, production safeguards and careful retirement of stacks without deleting live resources.

The risk is not rewriting YAML. The risk is transferring control of running infrastructure without accidental replacement or deletion.

Recommended control:

Use Terraform or OpenTofu for new infrastructure.
Create modules around capabilities, not individual resources.
Keep environment values separate from reusable modules.
Stop adding new CloudFormation custom resources.
Apply deletion protection and lifecycle safeguards before importing production resources.
Retain CloudFormation templates until rollback is no longer needed.

Dependency 4: AWS IAM Identity Center

IAM Identity Center provides workforce access across AWS accounts. KenyaBank plans to connect its existing Active Directory environment using SAML 2.0 and SCIM, with permission sets assigned to teams such as Banking Operations, Technology Operations, Development and Audit.

This dependency is more acceptable because the identity federation interfaces are based on open standards.

How a Tier-1 bank can benefit from AWS-managed services without making a future cloud exit unnecessarily difficult

Nehemiah Cheburet — Wed, 29 Jul 2026 19:14:36 +0000

Cloud migration decisions are often evaluated through the lenses of security, availability, performance and cost. Portability is usually considered much later—sometimes only when an organisation needs to change providers, meet a new regulatory requirement or negotiate a major contract renewal.

For KenyaBank, portability cannot be an afterthought.

The bank is undertaking an 18-month programme to modernise a legacy core banking environment currently running on Oracle WebLogic and Oracle Database in its Westlands data centre. The target architecture introduces AWS services including Amazon Aurora PostgreSQL, Amazon DynamoDB, Amazon EventBridge, Amazon MSK, AWS IAM Identity Center, AWS Systems Manager and AWS CloudFormation.
These services reduce infrastructure-management overhead and accelerate delivery. However, each managed service creates a different degree of dependency on AWS.

The real question is therefore not:

“Does the architecture contain vendor lock-in?”

Almost every cloud architecture does.

A more useful question is:

“Is the lock-in understood, controlled and justified by the business value it provides?”

This article audits five AWS-specific dependencies in KenyaBank’s target architecture, estimates the effort required to replace each one and assigns the overall architecture a portability score.
KenyaBank is a Tier-1 Kenyan commercial bank serving approximately 4.2 million customers through 68 branches.

Its existing environment includes:

A monolithic Java EE core banking application
Oracle WebLogic application servers
A 3.8 TB Oracle 11g database
A legacy internet-banking application
Local teller servers in 68 branches
An on-premises Microsoft Active Directory environment
MPLS connectivity between branches and the Westlands data centre

The target architecture uses the Strangler Fig pattern to extract capabilities from the monolith gradually. Internet banking will be containerised, the database will move towards Aurora PostgreSQL, and applications will increasingly communicate through events and managed messaging services.

This gives KenyaBank a more scalable and resilient platform, but it also introduces several AWS-specific interfaces, data models and operational processes.

What is cloud vendor lock-in?

Vendor lock-in occurs when moving an application, its data or its operational processes away from a provider would require significant time, cost or redesign.

Lock-in is not a single condition. For this assessment, it is divided into three categories.

API lock-in

API lock-in occurs when application code depends directly on a provider-specific SDK, API, event format or service behaviour.

For example, application code written around DynamoDB operations such as PutItem, Query and UpdateItem cannot simply be pointed at PostgreSQL.

Data lock-in

Data lock-in occurs when data is stored using a proprietary model or format that is difficult to reproduce in another platform.

The challenge is not always exporting the raw records. It may involve translating partition keys, indexes, access patterns, relationships, transactions and consistency behaviour.

Operational lock-in

Operational lock-in occurs when an organisation’s deployment, identity, monitoring, patching or support processes depend on provider-specific tooling.

The application may remain technically portable, but the operating model must be rebuilt before it can run elsewhere.

The portability-scoring method

Each dependency is assessed using five factors:

Factor Question
Application coupling How much code uses AWS-specific APIs?
Data coupling How difficult is it to export and remodel the data?
Infrastructure coupling Can the deployment definition run elsewhere?
Operational coupling Must procedures and skills be rebuilt?
Replacement availability Is there a mature portable alternative?

The portability scale is defined as follows:

Score Interpretation
1 Highly proprietary; substantial redesign required
2 Significant lock-in; migration would be difficult
3 Moderate lock-in; migration is feasible with planning
4 Mostly portable; limited provider-specific adjustments
5 Highly portable; based mainly on open standards

Exit effort is expressed in engineering effort rather than a fixed monetary amount. A defensible financial estimate would require application size, event volume, table count, test coverage, staff rates and recovery requirements that are not provided in the scenario.

The estimates assume a multidisciplinary team containing cloud, application, database, security and testing specialists.

Dependency 1: Amazon DynamoDB
How KenyaBank uses it

The proposed architecture uses DynamoDB for session storage. This is attractive because DynamoDB provides managed scaling, high availability and low-latency key-value access without requiring KenyaBank to manage database servers.

It is also the strongest source of lock-in in the assessed architecture.

Nature of the lock-in

Classification: API lock-in and data lock-in
Portability score: 2 out of 5
Estimated exit effort: High — approximately 12–20 person-weeks

DynamoDB applications are normally designed around:

Partition and sort keys
DynamoDB-specific query operations
Global and local secondary indexes
Conditional writes
Time-to-live attributes
DynamoDB Streams
Provisioned or on-demand capacity behaviour
AWS SDK request and response models

Although DynamoDB tables are flexible, that flexibility does not make them automatically portable. The table design is typically based on application access patterns rather than relational normalisation.

AWS supports full and incremental table exports to Amazon S3. These exports do not consume table read capacity, but the supported export formats are DynamoDB JSON and Amazon Ion—not a ready-made PostgreSQL schema. AWS documentation: DynamoDB export to S3

Exporting the records is therefore only the beginning. KenyaBank would still need to:

Choose a replacement platform.
Design the target schema.
Translate DynamoDB-specific data types.
Recreate indexes and expiration behaviour.
Rewrite the repository or data-access layer.
Migrate active sessions.
Validate performance and consistency.
Run the old and new stores in parallel.
Cut over without invalidating customer sessions.

Possible alternatives

Potential alternatives include:

Redis for short-lived customer sessions
PostgreSQL for durable relational session records
MongoDB for document-oriented access
A Kubernetes-compatible Redis deployment
A managed Redis service available from multiple providers

For temporary session data, Redis would normally provide a more portable model than DynamoDB because its commands and client libraries are available across cloud and self-managed environments.

Is the lock-in justified?

Partly.

DynamoDB is justified when KenyaBank needs very high scale, predictable low latency and minimal database administration. However, using it for ordinary session storage may create more coupling than necessary.

The bank should first validate whether the expected session volume genuinely requires DynamoDB. If not, a portable Redis-based implementation may provide enough performance while reducing exit complexity.
Recommended control

KenyaBank should implement a repository interface between application code and DynamoDB:

SessionRepository
├── DynamoDbSessionRepository
├── RedisSessionRepository
└── PostgreSqlSessionRepository

The business logic should depend on SessionRepository, not directly on the AWS SDK. This will not eliminate data migration, but it will reduce the amount of application code that must be rewritten.

Dependency 2: Amazon EventBridge
How KenyaBank uses it

EventBridge can route business and operational events between loosely coupled application components. Rules match events and deliver them to configured targets.
AWS describes an EventBridge event bus as a router that receives events and delivers them to one or more destinations. Rules use AWS-specific event patterns to inspect event metadata and detail fields. AWS documentation: EventBridge event patterns

Nature of the lock-in

Classification: API and operational lock-in
Portability score: 2 out of 5
Estimated exit effort: Medium to high — approximately 8–14 person-weeks

Coupling may develop in several places:

The EventBridge event envelope
PutEvents API calls
AWS SDK integrations
Event-pattern syntax
Event bus policies
Rule-to-target configuration
Dead-letter queue configuration
IAM permissions
EventBridge Scheduler
AWS-specific target integrations
If business applications publish raw EventBridge events directly, a move to Kafka, Google Cloud Pub/Sub or another event platform will require changes to every producer.

Consumers may also depend on fields such as source, detail-type, account, region and detail.

Exit approach

A controlled exit would require KenyaBank to:

Inventory event buses, schemas, rules and targets.
Define a provider-neutral event contract.
Introduce an event-publishing abstraction.
Translate existing events into the new format.
Recreate routing and filtering rules.
Implement retry and dead-letter handling.
Run dual publishing during transition.
reconcile missed or duplicated events.
Retire EventBridge rules after validation.
Is the lock-in justified?

Yes, but only at the integration boundary.
EventBridge is valuable for AWS service integration and operational automation. It can significantly reduce the code required to connect AWS services.

For core banking domain events, however, the event itself should not be defined by EventBridge.

KenyaBank should use a portable event specification such as CloudEvents and treat EventBridge as one possible transport.

A portable business event might look like this:

{
"specversion": "1.0",
"type": "ke.kenyabank.payment.completed.v1",
"source": "/core-banking/payments",
"id": "a03ac2f8-5e51-4c51-95d5-7714be667350",
"time": "2026-07-29T09:30:00Z",
"datacontenttype": "application/json",
"data": {
"paymentReference": "PAY-104582",
"status": "COMPLETED"
}
}

The same logical event could be transported through EventBridge, Amazon MSK or another cloud’s event service.

Recommended control
Standardise domain events using CloudEvents.
Publish through an internal event interface.
Keep AWS SDK calls inside adapters.
Store event schemas in a provider-neutral repository.
Avoid placing business rules exclusively in EventBridge rule definitions.
Use EventBridge mainly for AWS-native operational events.
Dependency 3: AWS CloudFormation
How KenyaBank uses it

CloudFormation defines AWS infrastructure as YAML or JSON templates. It gives KenyaBank repeatable deployments, change tracking and automated infrastructure management.

However, CloudFormation templates use AWS-specific resource identifiers such as AWS::S3::Bucket and AWS::EC2::VPC. AWS documents these service-specific resource and property definitions in its CloudFormation resource reference. AWS documentation: CloudFormation resource syntax.

Nature of the lock-in

Classification: Operational lock-in
Portability score: 2 out of 5
Estimated exit effort: Medium — approximately 8–16 person-weeks

The deployed resources may use standard technologies, but the infrastructure definition cannot be applied directly to Azure, Google Cloud or an on-premises platform.

Coupling increases when templates use:

AWS-specific resource types
Intrinsic functions such as Ref and Fn::GetAtt
Nested stacks
CloudFormation exports
StackSets
AWS-specific transforms
Lambda-backed custom resources
CloudFormation deployment pipelines

Custom resources create additional coupling because they can invoke Lambda or SNS-based provisioning logic. AWS documentation: CloudFormation custom resources
Exit approach

Migrating from CloudFormation to Terraform or OpenTofu would involve:

Inventorying all stacks and nested stacks.
Mapping resources into the target tool.
Rewriting parameters, outputs and dependencies.
Importing existing infrastructure into the new state.
Comparing both infrastructure definitions.
Testing changes in a non-production account.
Freezing CloudFormation changes during transition.
Transferring resource ownership in controlled phases.
Retiring stacks without deleting live resources.

The main risk is not reproducing the YAML syntax. It is safely transferring control of already-running infrastructure without accidental replacement or deletion.

Is the lock-in justified?

Not for the long-term target state.

CloudFormation is a capable option for AWS-only environments, but KenyaBank’s portability objective favours Terraform.
The bank does not need to replace every existing template immediately. A phased six-month migration would be safer:

Month 1: inventory and prioritisation
Month 2: Terraform/OpenTofu standards and modules
Months 3–4: non-production migration
Month 5: production resource import
Month 6: validation and CloudFormation retirement
Recommended control
Use Terraform or OpenTofu for new infrastructure.
Create modules around architectural capabilities rather than individual resources.
Keep environment values separate from reusable modules.
Prohibit new CloudFormation custom resources during the transition.
Apply deletion protection and lifecycle safeguards before importing production resources.
Retain CloudFormation templates until rollback is no longer necessary.
Dependency 4: AWS IAM Identity Center
How KenyaBank uses it

IAM Identity Center provides workforce access to multiple AWS accounts. KenyaBank intends to connect its existing Active Directory environment using SAML 2.0 and SCIM, with permission sets assigned to teams such as Banking Operations, Technology Operations, Development and Audit.

This dependency is more nuanced than DynamoDB because its identity-federation interfaces use open standards.

AWS IAM Identity Center supports SAML 2.0 for authentication and SCIM for user and group provisioning. An identity provider that implements these standards is expected to interoperate with IAM Identity Center. AWS documentation: SAML and SCIM federation

Nature of the lock-in

Classification: Primarily operational lock-in
Portability score: 3 out of 5
Estimated exit effort: Medium — approximately 6–12 person-weeks
The following elements are relatively portable:

User identities retained in Active Directory
SAML-based authentication
SCIM-based provisioning
Group membership
General role-based access principles

The AWS-specific components include:

Permission sets
AWS account assignments
IAM policies
AWS Organizations integration
AWS account and organisational-unit mappings
AWS-specific attributes and session controls

Permission sets determine the level of access users and groups receive in AWS accounts. These permissions cannot be transferred directly to another cloud because other providers use different resource and policy models. AWS documentation: IAM Identity Center permission sets
Exit approach

Moving to another platform would require KenyaBank to:

Retain Active Directory or another independent identity provider as the system of record.
Integrate the target platform through SAML or OpenID Connect.
Recreate user and group provisioning.
Translate AWS permission sets into target-cloud roles.
Replace IAM policy conditions.
test privileged and emergency access.
validate separation of duties.
update access-review and audit procedures.
Is the lock-in justified?

Yes.

The lock-in is acceptable because the authoritative identities remain outside AWS and federation relies on standard protocols. KenyaBank receives centralised access management across its AWS accounts without making AWS the permanent system of record for workforce identities.

Recommended control
Keep Active Directory as the authoritative identity store.
Group users by business function, not by AWS service.
Document every permission-set mapping.
Export permission definitions into version control.
Maintain a cloud-neutral access matrix.
Test emergency access independently of normal federation.
Avoid manually creating long-lived IAM users.

This approach allows the bank to retain a portable identity-governance model even though cloud permissions remain provider-specific.
Dependency 5: AWS Systems Manager
How KenyaBank uses it

KenyaBank intends to manage EC2 instances and 68 branch servers through AWS Systems Manager.

Systems Manager hybrid activations allow on-premises servers, virtual machines and edge devices to register as managed nodes. Those machines then use the SSM Agent to communicate with AWS Systems Manager. AWS documentation: Systems Manager hybrid environments

This gives the bank centralised inventory, patching, command execution, automation and audit history without requiring SSH access or bastion hosts.

Nature of the lock-in

Classification: Operational lock-in
Portability score: 2 out of 5
Estimated exit effort: Medium to high — approximately 10–18 person-weeks

The servers themselves remain portable, but the management processes become AWS-specific.

Coupling includes:

SSM Agent registration
Hybrid activation codes
IAM service roles
Patch baselines
Maintenance windows
State Manager associations
Run Command documents
Automation runbooks
Inventory and compliance reports
Parameter Store integration
CloudWatch and EventBridge automation

The greater the number of SSM documents and automated remediation workflows, the greater the exit effort.

Exit approach

Potential replacements include:

Ansible Automation Platform
Red Hat Satellite
Canonical Landscape
Microsoft Configuration Manager
Azure Arc
Google Anthos
Kubernetes-based management where appropriate

Migration would require:

Deploying the replacement agent or configuring agentless access.
Recreating the server inventory.
Translating patch baselines.
Rebuilding maintenance schedules.
Rewriting automation documents.
Replacing IAM-based authorisation.
Reconstructing audit and compliance reporting.
Operating both platforms during transition.
Deregistering the servers from Systems Manager

Is the lock-in justified?

Yes for the AWS estate; only partly for branch servers.

Systems Manager is a strong fit for EC2 because it integrates naturally with IAM, CloudTrail, Patch Manager and AWS automation.

Using it for all branch infrastructure provides consistency, but it makes the operational model AWS-dependent even when the servers are physically located outside AWS.

For a regulated bank, that trade-off may still be justified if the centralised audit trail and reduced reliance on SSH materially improve security.

Recommended control
Write automation in scripts or Ansible where practical.
Keep SSM documents thin and use them to invoke portable scripts.
Store scripts in version control.
Maintain an independent configuration-management database.
Export compliance results into the bank’s central reporting platform.
Document how servers would be managed if Systems Manager were unavailable.
Test replacement management tooling on a small branch-server sample.

Consolidated portability assessment
Dependency Primary lock-in Portability Exit effort Is it justified?
DynamoDB session store API and data 2/5 High Partly
Amazon EventBridge API and operational 2/5 Medium–high Yes, at AWS integration boundaries
AWS CloudFormation Operational 2/5 Medium No for the long-term target
IAM Identity Center Operational 3/5 Medium Yes
AWS Systems Manager Operational 2/5 Medium–high Yes, with controls

[Screenshot placeholder: KenyaBank dependency and exit-effort matrix]

Dependencies that improve portability

Not every AWS-managed service creates the same level of risk.

Two choices in the KenyaBank architecture make the environment more portable.

Amazon MSK

Amazon MSK runs open-source Apache Kafka and supports existing Kafka clients, tools and plugins. AWS documentation: What is Amazon MSK?

If KenyaBank uses standard Kafka APIs, portable schemas and open-source connectors, producers and consumers can move to another Kafka distribution with relatively limited application changes.

AWS-specific authentication, monitoring, replication and control-plane automation can still create operational coupling, but the data plane is substantially more portable than EventBridge.

Estimated portability: 4 out of 5.

Amazon Aurora PostgreSQL

Aurora PostgreSQL is PostgreSQL-compatible and supports standard PostgreSQL tools. AWS documents migration options including pg_dump, pg_restore and AWS DMS. AWS documentation: Migrating Aurora PostgreSQL data
Portability decreases if KenyaBank depends on Aurora-specific capabilities such as:

Aurora Global Database
Aurora Serverless scaling behaviour
Cluster endpoints
Aurora-specific replicas
Backtrack or other engine-specific functions
AWS-specific monitoring and failover automation

If the database schema, SQL and drivers remain PostgreSQL-standard, the exit path is still considerably easier than leaving a proprietary database model.

Estimated portability: 4 out of 5.

Overall portability score: 3 out of 5

KenyaBank’s proposed architecture receives an overall portability score of:

3/5 — Moderately portable

The score is not a simple average of the five dependencies. It considers their architectural importance and the effect of existing mitigation opportunities.

The architecture earns a moderate score because:

Aurora PostgreSQL provides a PostgreSQL-compatible exit path.
Amazon MSK is based on open-source Apache Kafka.
SAML and SCIM reduce identity coupling.
Containers make the application runtime relatively portable.
The Strangler Fig pattern supports incremental change.

The score is prevented from reaching 4 or 5 because:

Session management depends on DynamoDB’s proprietary data model.
Domain events risk becoming coupled to EventBridge.
Infrastructure is described using CloudFormation.
Branch operations depend heavily on Systems Manager.
AWS-specific IAM and automation remain embedded in the operating model.

The architecture is therefore portable in principle, but exiting AWS would still require a planned transformation programme rather than a simple redeployment.

Recommended portability-improvement plan

KenyaBank does not need to avoid managed services. It needs to isolate their use.

Introduce application adapters

Applications should call internal interfaces rather than AWS SDKs directly.

Examples include:

SessionRepository
EventPublisher
SecretProvider
ObjectStorageClient
IdentityClaimsMapper

Each interface can have an AWS implementation today and another implementation in the future.

Adopt portable event contracts

Core banking events should use:

CloudEvents envelopes
JSON Schema, Avro or Protobuf contracts
Versioned domain-event names
Provider-neutral metadata
A schema-compatibility policy

EventBridge and MSK should transport events without owning their business meaning.

Move infrastructure definitions towards Terraform or OpenTofu

CloudFormation stacks should be replaced gradually. Production resources should be imported carefully rather than recreated.

This change improves infrastructure portability, although the resources defined may still be AWS-specific.

Use PostgreSQL-compatible features by default

Aurora-specific capabilities should require an architecture decision record explaining:

The business benefit
The portability impact
The alternative considered
The exit approach
The trigger for reassessment

Keep identity outside the cloud provider

Active Directory should remain the workforce identity authority. IAM Identity Center should provide AWS access federation rather than become the only identity repository.

Keep operational scripts portable

Systems Manager runbooks should invoke scripts that can also run through Ansible or another orchestration platform.

The bank should avoid encoding every operational procedure entirely inside SSM documents.

Test the exit plan

A portability strategy is only credible if it is tested.

KenyaBank should run an annual portability exercise that:

Restores a sample Aurora schema into standard PostgreSQL
Consumes an MSK topic using a non-AWS Kafka client
Replays EventBridge events into an alternative broker
Deploys one Terraform/OpenTofu-managed environment
Manages one branch server using an alternative tool
Exports a sample DynamoDB table and transforms its data

Final assessment

KenyaBank should not reject AWS-managed services merely because they introduce lock-in.

DynamoDB, EventBridge, IAM Identity Center and Systems Manager can reduce operational effort and improve availability, security and delivery speed. Those benefits may be more valuable than complete portability.

The most important finding is that not all lock-in is equally risky.

DynamoDB creates the greatest application and data portability concern. CloudFormation and Systems Manager create substantial operational dependence. IAM Identity Center is a more acceptable dependency because it integrates through SAML and SCIM, while Aurora PostgreSQL and Amazon MSK offer stronger portability foundations through PostgreSQL and Apache Kafka compatibility.

The recommended decision is therefore to continue with AWS, while introducing architectural boundaries around proprietary services.

KenyaBank does not need a platform that can move to another cloud overnight. It needs a platform whose dependencies are visible, whose business benefits are understood and whose exit paths remain technically achievable.

That is the difference between unmanaged vendor lock-in and a deliberate cloud strategy.

How to Auto-Merge Branches on Every Push Using GitHub Actions

Nehemiah Cheburet — Sun, 12 Jul 2026 09:50:14 +0000

We’ve all been there: you are working out of a develop branch, things are moving fast, and you want your production-ready main branch to stay instantly synced without the hassle of opening, reviewing, and manually clicking "Merge" on a Pull Request every single time.

If you are working on a solo project or running an internal staging-to-production pipeline where strict PR reviews aren't necessary, you can fully automate this with a lightweight GitHub Actions workflow.

In this quick guide, we’ll set up a workflow that automatically merges develop into main every single time you push code.

Step 1: Create the Workflow File
GitHub Actions looks for automation scripts inside a special directory in your repository. You can create this file locally or directly through the GitHub web interface.

Create a file at this exact path:

.github/workflows/auto-merge.yml

And paste the following YAML configuration:

name: Auto Merge Develop to Main

on:
  push:
    branches:
      - develop

jobs:
  merge-to-main:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Fetches full history so git can handle the merge properly

      - name: Configure Git Bot
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"

      - name: Merge develop into main
        run: |
          git checkout main
          git merge origin/develop --no-ff -m "chore: automatic merge develop to main [skip ci]"
          git push origin main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Note: If you are creating this via the GitHub web interface, make sure you commit this file directly to your develop branch so the trigger can find it!

Step 2: Fix the "Permission Denied" Gotcha
If you skip this step, your workflow will trigger, but it will immediately fail with a permission error. By default, GitHub Actions has read-only access to your repository. Because our script needs to write (push) code back to main, we have to elevate its permissions.

Head over to your repository on GitHub.

Click the Settings tab at the top.

On the left sidebar, click Actions > General.

Scroll all the way to the bottom to Workflow permissions.

Switch the toggle to Read and write permissions and hit Save.

Step 3: Test the Magic

To see it in action, make a small change to a file on your local develop branch, commit it, and push it up:

git add .
git commit -m "feat: testing auto merge"
git push origin develop

Now, click on the Actions tab in your GitHub repository. You’ll see the "Auto Merge Develop to Main" workflow running. Within a few seconds, it will complete, and your main branch will be perfectly updated.

(Don't forget to run git pull on your local machines to keep everything synced!)

⚠️ A Quick Reality Check
Before you throw this into every repo you own, keep two edge cases in mind:

Merge Conflicts: If someone pushes a hotfix directly to main, this script will fail when a conflict occurs. If that happens, the automation stops safely. You'll just need to merge main back into develop manually on your machine, resolve the conflict, and push to develop again.

Branch Protection Rules: If your main branch requires signed commits, approval reviews, or passing status checks before a merge, this native Git push will be blocked by GitHub. To bypass that, you would need to generate a Personal Access Token (PAT) with repository write access and substitute it for the default ${{ secrets.GITHUB_TOKEN }}.

Happy automating! Drop a comment below if you run into any issues setting this up.

How to create a VPC with Public and Private Subnets (NAT Gateway and Bastion Host)

Nehemiah Cheburet — Wed, 14 Jan 2026 19:56:52 +0000

In the world of cloud computing, "default" settings are often the enemy of security. When you launch your first resource on AWS, it’s tempting to put everything in a public subnet for the sake of simplicity. However, in a production environment, exposing your application servers or databases directly to the internet is like leaving your front door wide open in a crowded city.

The gold standard for cloud networking is the Virtual Private Cloud (VPC) configured with a "Public-Private" split.

By isolating your sensitive resources in a private subnet, you ensure they are invisible to the public web. But this raises two critical questions:

How do your private servers get out? (e.g., for software updates or API calls).

How do you get in? (e.g., for maintenance or troubleshooting).

The answer lies in two essential components: the NAT Gateway and the Bastion Host.

In this guide, we will walk through the end-to-end process of building a secure, professional-grade network architecture. We’ll cover everything from CIDR blocks and route tables to configuring the "Jump Box" that keeps your environment both accessible and airtight.

Whether you are preparing for the AWS Solutions Architect exam or building a secure home for your next big project, this walkthrough will give you the foundational knowledge you need to deploy with confidence.

**Defining the VPC
**In the AWS Console, when you head to VPC > Your VPCs > Create VPC, you generally have two choices: "VPC only" or "VPC and more." For this guide, let's focus on VPC only to understand the manual configuration of each component.