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.
Top comments (0)