Cloud Architecture
A small event-driven banking workflow on AWS
A file, a function and an API can teach most lessons in cloud integration.
Small proofs of concept are useful when they preserve the uncomfortable parts of production. My AWS banking integration POC is deliberately simple—a file, a function and an API—but it includes identity, validation, idempotency and result handling because those are where real integrations fail.
Let events move work, not hide state
An object arriving in S3 is a clean trigger, but the workflow still needs an explicit state. Which file was accepted? Which rows failed validation? Has this checksum already been processed? What can safely be retried?
I use a correlation reference from ingestion through the downstream request and final result. It turns logs into a trace and makes duplicate detection possible. Without that reference, event-driven systems can become collections of successful functions around an unsuccessful business process.
Security is part of the path
Least-privilege IAM, encryption and secrets management are obvious checklist items. The important question is whether security remains understandable during support. Can an operator distinguish an expired client certificate from an application rejection? Is the failure visible without exposing sensitive payloads?
For bank connectivity, mutual TLS also needs lifecycle thinking: issuance, rotation, expiry alerting and tested rollback. A certificate is not a one-time configuration value.
A POC should answer a production question
The point was not to demonstrate that Lambda can read S3. It was to explore how a small team could build a controlled batch integration with clear failure handling and auditability.
A useful POC removes a named uncertainty. If it only proves that services can be connected, it has probably tested the documentation rather than the design.