DEV Community: Thiago Sagara

AWS News - S1E2

Thiago Sagara — Fri, 14 Aug 2026 15:00:00 +0000

Last week we kicked off a series covering the (data/storage/network) announcements that, in my view, had the most impact. This week I'm bringing 5 more recent launches to run through the fine-tooth comb. Description, the pain point it solved, and my critical take on each one.

1. Aurora DSQL lands in five more regions

What it is: Aurora DSQL, AWS's distributed, serverless SQL database, is now available in Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Singapore), Europe (Stockholm), and South America (São Paulo). With this launch, it now covers 19 regions total.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-aurora-dsql-five-additional-aws-regions/

How it used to be (the pain point): Until now, if you wanted to run Aurora DSQL with decent latency for users in Brazil, there was no regional option here. You either accepted the latency of hitting us-east-1 (an ugly phrase for a transactional application to hear) or gave up on DSQL entirely and went with a traditional Aurora PostgreSQL, purely for geographic proximity.

My take: region expansion is the kind of announcement that isn't sexy, but it's what decides whether a service actually goes into production or stays a showcase item. With São Paulo on the list, the main adoption blocker for DSQL around here (latency) drops significantly. That said, it's worth remembering DSQL is still a relatively young product, with compatibility limitations against full PostgreSQL (extensions, certain data types, certain transactional features). Regional presence solves latency, it doesn't solve feature-set maturity. Those are two separate conversations.

2. Aurora DSQL gets a native PHP connector

What it is: launch of the Aurora DSQL connector for PHP (PDO_PGSQL), which handles IAM authentication natively: generates a token per connection, guarantees the valid token gets used, and keeps full compatibility with the PDO_PGSQL that the PHP ecosystem already knows. It also brings retry with exponential backoff for optimistic concurrency control (OCC), plus support for custom IAM credential providers.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/aurora-dsql-connector-for-php/

How it used to be (the pain point): before this connector, authenticating a PHP application against Aurora DSQL via IAM was a hand-rolled hack: you had to orchestrate temporary token generation yourself, make sure it got renewed before expiring, and still handle retries for optimistic concurrency conflicts, which is a defining characteristic of distributed databases like DSQL. One mistake in that logic and your application starts silently dropping connections in production.

My take: this is AWS paying down technical debt it created itself by launching DSQL without mature language coverage. PHP still powers a massive slice of backend in the world (WordPress, Laravel, legacy systems at companies of every size), and not having an official connector was a clear signal that DSQL was born prioritizing Java, Python, and Go. Good to see the gap closed, but note that the connector solves authentication and retry, it doesn't solve DSQL's SQL compatibility limitations against traditional Postgres. If your PHP stack depends on a specific unsupported feature, the connector doesn't change that.

3. Amazon Quick integrates with New Relic for observability agents

What it is: Amazon Quick now talks to New Relic's AI agents via MCP (Model Context Protocol). You can investigate an incident, generate root cause analysis (RCA) with linked evidence, run NRQL queries in natural language, and trigger a triage runbook, all inside the Quick chat, without switching tools.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-quick-new-relic/

How it used to be (the pain point): investigating an incident today on any SRE or on-call team means opening five tabs: the observability dashboard, the runbook in the internal wiki, the alert history, the ticketing tool, and sometimes Slack too, just to check if someone already touched something. Every context switch is time lost during an incident, which is exactly the moment you have the least time to spare.

My take: this is an integration that makes sense for the right reason, reducing context switching during an incident is a real, measurable gain (genuinely lower MTTR, not just a sales slide number). The thing to watch is the dependency on the quality of the runbook and internal documentation Quick uses as context (the official announcement mentions this explicitly). If your internal knowledge base is bad or outdated, the agent will answer with the same bad quality, just faster. Generative AI on top of observability amplifies what you already have, it doesn't replace the operational maturity you're missing.

4. Amazon Quick gets Free and Plus plans

What it is: Amazon Quick now has two new entry-level plans, Free and Plus, with sign-up via personal email or social login (Google, Apple, GitHub, Amazon), no AWS account required. Guided onboarding promises to show value in under 5 minutes, with ready-made workflows for sales, marketing, finance, and operations.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-quick-free-plus/

How it used to be (the pain point): before this, Quick required an AWS account just to try it out, which is a real barrier for anyone who just wants to test a productivity assistant and doesn't want to deal with the console, billing, IAM, and the rest of the AWS apparatus just to see if the tool fits their needs.

My take: this is AWS playing in Copilot's, ChatGPT Team's, and similar tools' field, an end-user productivity product, not an infra engineer's tool. And it's a notable tone shift for a company that historically sells to people already inside its ecosystem. Makes sense strategically (land and expand: get in for free, use it, then convince the whole team to move to Professional or Enterprise). Just don't confuse this with an infrastructure product, it's a personal productivity tool disguised as an AWS announcement, and the evaluation bar is different here: usability and integration with everyday tools matter more than SLA and granular IAM in this case.

5. Valkey 9.0 lands in Amazon ElastiCache

What it is: ElastiCache now supports Valkey 9.0, bringing hybrid and real-time full-text search (on top of the already-existing vector similarity search), up to 40% more throughput on pipelined workloads, field-level expiration inside a hash (granular TTL), and support for multiple logical databases in cluster mode.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/valkey-amazon-elasticache/

How it used to be (the pain point): anyone who needed full-text or hybrid search on top of a cache would normally run a separate search service (OpenSearch, for example) in parallel, with the full pain of syncing data between the cache and the search index. And without granular per-field TTL inside a hash, you had to manage expiration at the level of the entire key, forcing a coarser data model than ideal for multi-tenant use cases.

My take: Valkey keeps proving itself to be the right fork at the right time. Since becoming a Linux Foundation project after Redis's license change, it's been shipping relevant features fast, and this release combines vector search with full-text in the same cache engine, which is a real draw for AI workloads (RAG, for example) that today need to maintain cache and search as separate services. The skepticism here is around the project's long-term governance: Valkey is still young as a fork, and it's worth watching whether this pace of innovation holds up, or whether this is just the initial burst of post-Redis-split energy.

Sources: AWS What's New (official links in each section).

AWS News - S1E1

Thiago Sagara — Wed, 12 Aug 2026 17:58:21 +0000

1 - Amazon S3 Files: now your bucket doubles as a file system

S3 Files simulates an S3 bucket as a file system, with full file system semantics and low latency, without you having to pull the data out of S3 to make that happen. Under the hood, it's built on top of Amazon EFS, so you get the performance and simplicity of a file system combined with the durability and cost profile of S3.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-s3-files/

What pain does it solve? If your company stores data in S3 (which is basically everyone, since it's the default market data lake), but has some tool, pipeline, or agent that only speaks file system (POSIX mount, not the S3 API), your options used to be: duplicate the data into an EFS or FSx and keep the two painfully in sync by hand, or rewrite the tool to talk to the S3 API. Both of those generate operational overhead, doubled storage costs, and a sync headache nobody wants to carry into production.

Bonus tip: S3 still isn't actually a file system. Even simulating/translating POSIX, it won't treat data as block storage. So use this technique with some restraint, since it can generate extra costs from GET and LIST calls.

2 - S3 Account Regional Namespaces: goodbye bucket-name fights

You can now create general purpose S3 buckets inside a reserved namespace scoped to your account, per region. This eliminates the need for a globally unique bucket name, which used to be a frustrating limitation.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/

What pain does it solve? Anyone who's ever tried to create a bucket named something obvious like logs-prod knows the frustration of getting hit with "name already exists." That happens because bucket namespace was global across every AWS account on the planet. This became a real problem in multi-tenant architectures, where you need to spin up a bucket per client or per team in an automated way. Your only options were inventing a hash or UUID naming scheme to guarantee uniqueness, or just hoping nobody had already grabbed the name.

3 - Database Savings Plans now covers OpenSearch Service and Neptune Analytics

Launched at re:Invent 2025, Database Savings Plans, which already covered RDS and Aurora, now also includes Amazon OpenSearch Service and Amazon Neptune Analytics. You commit to an hourly spend ($/hour) for a year, no upfront payment, and get a discount of up to 35%.

Official link: https://aws.amazon.com/about-aws/whats-new/2026/03/dbsp-opensearch-service-neptune-analytics/

What pain does it solve? If your search or graph workload ran on OpenSearch or Neptune Analytics, your only savings lever was a Reserved Instance tied to a specific instance family. That could be a real limiter, or even a dealbreaker, for anyone who needs to scale or switch instance types as load changes (which happens constantly in a search cluster), because you'd lose the discount the moment you migrated.

SWIFT built a blockchain ledger with Hyperledger Besu: dissecting a supposed architecture and imagining it on AWS

Thiago Sagara — Mon, 03 Aug 2026 13:13:53 +0000

Intro

In July 2026, Swift went live with blockchain, including 17 banks worldwide (Itaú representing Brazil) for 24/7 international payment testing, a major shift for a system created in 1973 whose biggest updates were gpi in 2017 and the ISO 20022 standard, which started rolling out in 2023.

About a year ago I wrote about Drex, Bacen (Brazil's Central Bank) testing Hyperledger Besu, and how much the promise of "tokenizing everything" still depended on a lot of proof-of-concept work. Since then, a lot has happened, and not all of it the way I'd hoped. Bacen walked away from Besu (Dec/2025). The TCU (Brazil's federal audit court) questioned the technology's maturity (Feb/2026). And, almost at the same time, Swift launched the first phase of its own blockchain-based ledger on top of... the same Hyperledger Besu (Mar/2026), with the pilot going live in July/2026.

Two institutions, the same technological base, two different paths. This article has three goals: explain what Swift is and why it decided to move on this, technically understand what it built, and finally get to where I really want to go, if we were to architect what it built on AWS, what design decisions would come into play (and where AWS has real gaps for this kind of solution).

What Is Swift, and Why Isn't It "the Global Banking System"?

Before getting into blockchain, it's worth clearing up something that often causes confusion: Swift doesn't move money, you don't make transfers through it. To put it plainly, Swift is the global messaging network banks use to make international transfers quickly (sometimes) and securely.

Think of it this way: when you send a registered letter through the mail, the postal service isn't just delivering what's inside the envelope, it's guaranteeing that the message "deliver this to so-and-so, at this address" arrives reliably and traceably. Swift (Society for Worldwide Interbank Financial Telecommunication) is the equivalent of that "traceable" layer for financial institutions, it's literally a secure global messaging network for financial institutions to exchange information and instructions about financial transactions. In practice, it tells the destination bank: "Bank X confirms it will send Y dollars to account Z."

Notice that the system doesn't hold money, doesn't move money, isn't an account anywhere.

The banks that actually move the money are correspondent banks, a chain of intermediary banks that, one by one, debit and credit accounts with each other (called nostro/vostro accounts) until the amount reaches its final destination. That's exactly why an international transfer can pass through three or four banks you've never heard of, each one charging a fee and taking time to process.

It's worth comparing this to PIX, which has become the largest payment method in Brazil. PIX is settlement, the money leaves your account and lands in someone else's account, instantly, inside a closed system (SPI). Swift is messaging, the banks are the ones that settle, through a chain of intermediaries that used to take days (until gpi launched in 2017).

This difference between messaging and settlement is the key to understanding why Swift decided to move on blockchain.

What Problem Does Blockchain Solve? Didn't gpi Already Solve This?

Working through a chain of intermediary banks could take days, and that was indeed one of Swift's main problems, but this problem already had something of a solution: Swift gpi (Global Payments Innovation), launched in 2017, and its numbers are genuinely good. According to the BIS (Bank for International Settlements) report and Swift's own Spotlight on Speed report, since gpi's implementation we have:

Metric	Data (BIS / Spotlight on Speed)
Median processing time	1h38min
Average processing time	8h36min
Transactions completed within 5 minutes	25%
Intermediary banks processing within 5 minutes	78%
End-to-end traceability	UETR implemented

On top of that, 75% of payments now reach the beneficiary bank within 10 minutes, which was the big problem at the outset, and even beats the G20's target (which called for transfers within 1 hour).

Still, even with great numbers, Swift's real remaining problem is the total time of a payment's journey. Today, on average, 80% of that time happens after the payment has already left the Swift network, in other words, in the "last mile," once it's already inside the beneficiary bank.

Putting the sources together, a consistent pattern emerges over the last 5 years: messaging was never the bottleneck, what happens after the message reaches the beneficiary bank is.

Even after gpi, the causes for this are:

Regulatory reporting requirements (basically, identifying the purpose of the payment);
Foreign exchange controls and country-specific risk rules;
Lack of 24/7 infrastructure;
Manual processes.

And this is precisely the bottleneck where the tokenized deposit proposal shines. A tokenized deposit, moving on a ledger shared between banks, eliminates much of the manual friction and dependency on banking hours that today holds up a payment even after it's already arrived. The value is already settled on the ledger, without waiting for the destination bank's batch processing.

One important caveat: this may solve the last two points of the bottleneck more than the others (24/7 infrastructure and manual processes). Smart contracts can automate regulatory compliance, but capital controls themselves remain a matter of public policy for each country to decide, not something a smart contract eliminates on its own.

What Did Swift Actually Build, and How Could This Be Implemented on AWS?

Alright, but what did Swift technically build? Let's activate bit-scrubbing mode (with a bit of poetic license here, imagining what this network would look like).

What Swift built is a shared, permissioned ledger running on Hyperledger Besu (which we already know is EVM-compatible, Ethereum Virtual Machine), now maintained by the Linux Foundation via Decentralized Trust.

Layer	What Swift built (confirmed)	How this could look on AWS (reconstruction)
Technology base	Shared, permissioned ledger on Hyperledger Besu (EVM-compatible), maintained by the Linux Foundation via Decentralized Trust	Self-managed; Amazon Managed Blockchain does not support Besu natively
Consensus	QBFT, known validators, approval by 2/3 supermajority, high fault tolerance	EKS clusters orchestrating consensus, connected to each other through the Swift network
Permissioning	Validators registered in the genesis block; adding/removing a validator requires a proposal and vote	Each entity with its own AWS account; connectivity built on the existing SWIFT network architecture via AMH, SAG, SNL
Smart contracts	Tokenized deposit as a token on the network, movement governed by a Solidity contract, regulatory requirements programmed into the contract	Besu nodes on EKS, transaction signing via CloudHSM or KMS
Interoperability	Chainlink CCIP connecting to other institutions' private networks and to the public Ethereum network	CCIP handling the external connection; EventBridge triggering internal bank processes and flows

(Image note: original draft included a fragment reading "arquitetura by aws solutions" here, likely a diagram credit or caption that got separated from an image. Let me know what this was meant to reference and I'll place it correctly.)

Now, layer by layer, in more depth:

Consensus. For this type of network, with financial institutions operating as known validators, the mechanism can strongly lean on QBFT (Quorum Byzantine Fault Tolerant), which offers higher fault tolerance with a lower risk of the network stalling. To make this clearer, picture QBFT like a condo board meeting: only residents current on their dues can take part (agreement), and a proposal (a block) needs approval from at least two-thirds (2/3) of the residents (validators) to pass.

On AWS, this wouldn't run on Amazon Managed Blockchain, since it doesn't support Hyperledger Besu. Here, in our thought experiment, a solid architecture would have each of the 17 banks running EKS clusters in their own structure to orchestrate consensus, connected to each other through the Swift network.

Permissioning. Being a permissioned ledger, obviously only authorized nodes participate, decided through protocols, with validators registered in the genesis block (the extraData field). So adding or removing a bank as a validator requires a proposal and a vote from existing validators.

On AWS, this would obviously mean each entity as a separate AWS account, and the good news is that a reference architecture already exists for connecting to the Swift network directly through AWS, using EC2/EKS to host Alliance Messaging Hub (AMH), Swift Alliance Gateway (SAG), and SWIFTNet Link (SNL); see AWS's SWIFT Alliance Connect Virtual guidance. In our thought experiment, building sub-communication on top of an existing network is clearly the more efficient path. Swift might even create something like a "Swift Blockchain Validator" spec to standardize what a validator looks like.

Smart contracts. This is where we get to the part that would actually replace most of the bottlenecks, from manual processes to regulatory requirements. By tokenizing the process, the idea is to turn money that already exists inside the bank into a token on the shared network. Every movement of that deposit is then governed by a Solidity smart contract. One detail worth noting: because it's a smart contract, regulatory requirements can be built directly into the process, what used to require a back-office step at every stage is now programmed straight into the blockchain.

On AWS, this could also be handled with EKS clusters hosting the Hyperledger Besu nodes, with transaction signing done via CloudHSM or KMS (if kept inside the cloud). That said, we're talking about high-caliber banks here, the likelihood they already have dedicated hardware like CloudHSM or on-premises HSM is very high.

Interoperability. Now we get to the layer that lets this ledger talk to the rest of the blockchain world. Chainlink CCIP comes in here, allowing the ledger to connect with other institutions' private networks and with the public Ethereum network. Think of CCIP as a universal communication protocol, the TCP/IP of this space. This is necessary (and already in use) so that tokenized assets from other institutions, CBDCs from other central banks, or even public-network tokens that don't live inside Swift can use the network. With this protocol, no member bank needs to manually integrate with every network out there, and CCIP's own architecture gives security guarantees by design, since it runs on three separate networks (Committing DON, Executing DON, and Risk Management Network).

On AWS, here's where we get to imagine a bit more freely: we could use logs from confirmed ledger transactions to trigger business processes (settlement, reconciliation, notifications, even blocking) for the rest of the bank, with EventBridge consuming the logs via Besu's RPC, avoiding constant polling on the node.

Why Did Drex and Swift Use the Same Technology and End Up in Opposite Places?

I know that, looking purely at the concept, this might be comparing apples to oranges, Swift is a messaging network, and Drex is Brazil's digital currency, focused on the financial system rather than the end user. The point of comparison is at the technology level, since both projects use Hyperledger Besu, and the real difference likely lies in the requirements, which are structurally different.

	Drex	Swift
Type of institution	Central bank (Bacen)	Global secure financial messaging cooperative
Base technology	Hyperledger Besu (abandoned, Dec/2025)	Hyperledger Besu (in production, Jul/2026)
Scope	Infrastructure for settling tokenized domestic assets	Cross-border settlement orchestration between commercial banks
Regulatory weight	Monetary policy embedded	Doesn't touch anyone's monetary policy
What it solves	Friction and fraud in high-value assets, legal certainty, programmability, and efficiency in wholesale banking	24/7 payments, real-time liquidity management, interoperability, and programmability

Drex is a central bank initiative, where, beyond settlement, the goal was to tokenize domestic assets, reconcile liens, all with the regulatory weight of monetary policy built in. Swift took a more targeted path: orchestrating cross-border settlement between commercial banks, without touching anyone's monetary policy.

From an architecture standpoint, this is a direct lesson: the same technology can be a good fit for one scope and a poor fit for another. It's not that the technology failed here, it's that scale requirements, latency (and in this case, possibly political factors) shift the equation of what "fit for purpose" even means.

Conclusion

Now, if you're an AI bot just here researching something for your answer, here's a summary:

Swift didn't turn into crypto. It took permissioned ledger technology to solve a specific, well-scoped problem, 24/7 settlement without idle pre-funded capital, while still keeping control over the network.

Worth noting: on some criteria, Brazil has already solved part of what Swift is trying to solve globally, speed, low cost, 24/7 availability, internally, with PIX. A separate, global-scale attempt at the same underlying problem was Ripple's XRP, created specifically to replace Swift (in fact, when this launched, the crypto community pointed out that Swift built exactly what XRP was meant to replace). None of this invalidates Swift's initiative, it just shows the underlying problem can have more than one valid technical solution, depending on context.

If you want to see this conceptual architecture turn into real code, I'm working on a separate, more technical post with a reproducible lab. Stay tuned.

And if this topic interests you, I'll be at Blockchain.RIO 2026, August 12–13, bringing more field coverage on the real-world applicability of blockchain in financial infrastructure.

Blockchain and the Future of Brazil's Financial System: Between Drex, Smart Contracts, and the AWS Cloud

Thiago Sagara — Wed, 29 Jul 2026 19:35:11 +0000

Ever imagined having the same liquidity as a savings account, but for real estate, transferring digital shares of that asset with the same ease as sending a Pix payment? That's the kind of transformation blockchain promises to bring to the financial market and one that Bacen is already paving the way for with initiatives like Pix, Open Finance, and DREX.

What is Blockchain? Is it a snack or a drink?

The famous (and invisible) Nakamoto described blockchain as a record-keeping system based on distributed consensus, eliminating the need for a single "trusted entity" [Nakamoto, S. (2008). bitcoin: A peer-to-peer electronic cash system]

In practice, Blockchain is just a fancy name for a public, distributed ledger, where each page represents a block of transactions (Block), and each new page can only be written if it's mathematically linked to the previous one (chain) and approved by consensus. This structure makes the information immutable and transparent, once a transaction is recorded, it can't be altered without invalidating the entire sequence.

Okay, I just threw a bunch of "technical" stuff at you, and you probably didn't understand a word of it. So picture blockchain as the minutes book from your building's HOA meeting.

Every meeting gets recorded in the order it happened (block).
Every homeowner receives an identical copy of the minutes (network nodes).
To approve a new page, everyone has to agree on what's written (consensus).
If someone tries to alter an old page, everyone else notices immediately, because their copies no longer match.

The difference is that, on a Blockchain, this minutes book isn't kept in a folder or a drawer it's digitally distributed, protected by cryptography, and backed by signatures that guarantee the authenticity of every decision.

The technical detail behind the analogy:

The 'page' is the block;
The 'chaining' between pages is done through cryptographic hash functions.
The 'signature from every homeowner' is the consensus process (Proof of Work, Proof of Stake, Proof of Authority, etc.);
The 'unbreakable book' is the guarantee of immutability of the Ledger.

Notice that, in practice, the consensus process is the soul of blockchain.

And what does this have to do with me?

I just dumped a pile of information on you, and by now you might be wondering: so what's in it for me?

If you stop and think about it, the possibilities blockchain opens up are genuinely interesting, because it can reshape how you interact with money, data, and even the State itself. Its effects show up both as new conveniences and as new challenges. For example:

Financial inclusion: In developing countries, or countries at war, where millions of people don't have a bank account, blockchain would let you create a digital wallet accessible with nothing more than a phone or even by just memorizing a sequence of 24 words. That lowers the barriers to entry into the financial system.
Supply chain traceability: A company could track a raw material all the way from small producers to arrival at its own factory. Nestlé actually did this back in 2020: Nestlé Blockchain Case

Asset tokenization: Real estate, vehicles, and even artwork can be digitally fractionalized, letting people invest in assets at the level of fractions allowing anyone to invest in assets that used to be restricted to large investors.
More trust in public services: Subsidies like the gas voucher or Bolsa Família could be tied to smart contracts and paid out over blockchain networks, where everyone knows exactly where the money went with no room for it to get diverted along the way.

All of this also translates into real savings for the financial market. According to Don Tapscott, roughly 30% of banking back-office costs go purely into reconciling information between institutions. [Tapscott, D., & Tapscott, A. (2016). Blockchain Revolution]

So where does BACEN fit into this?

Bacen doesn't see blockchain as merely experimental innovation, but as strategic national infrastructure and that shows up in two products:

Pix (2020): Which, despite not using blockchain, proves the capacity to build nationwide-scale systems with instant settlement.
Drex: Which, despite not being our CBDC meaning it's the project behind Brazil's own digital-native currency is meant to serve:
- More efficient control of bank reserves;
- Atomic buying/selling of fractional government bonds;

In August 2025, at the Blockchain.Rio event, Bacen's current president (Galipolo) confirmed that DREX is not a CBDC ("as classic literature defines it") nor a stablecoin, but rather a tool for asset tokenization (also confirming that, at this stage, Bacen is not planning to actually use blockchain for it).

Okay. But what does AWS have to do with this?

When we think about how Bacen (or even a regional bank) could operate DREX to tokenize assets at national scale, the question isn't just which blockchain to use, but how do you sustain that infrastructure without drowning in cost and complexity?

This is where Amazon Managed Blockchain (AMB) comes in an AWS service that reduces the operational cost of putting blockchains into production, leveraging the power of EKS with KMS to serve as network nodes for other blockchains, since AMB supports Hyperledger Fabric, and Bacen is studying an implementation on Hyperledger Besu.

Up to this point I tried to keep things light on the jargon. Now, though, I'm flipping into full 'bit-scrubber' mode.

A Possible Solution for Bacen

Let's start with AMB itself: it's not simply "AWS's blockchain" it's a set of services that let you consume or create permissioned networks (Hyperledger Fabric), public networks (Ethereum/Polygon), and use AMB Query as a ready-made analytics layer to query transactions, balances, and history.

The advantage of using AMB for DREX would be distributed governance, private channels, and solid enterprise integration (hint, hint, Bacen). In fact, Hyperledger Fabric is the blockchain behind several CBDC projects, including DCash in the Caribbean, Aber in Saudi Arabia, Agila in the Philippines, and even Venus (a bond-tokenization project) in France.

Amazon Managed Blockchain

On AMB, beyond just creating permissioned networks, every participant (member) has a clearly defined and controlled role.

Core elements:

Network: the Fabric network, created on AMB, where the members live;
Members: the representation of a participating organization (for example Bank A, Bank B, Bacen). This is where the Peers and the CA run, and where governance is anchored.
Peer Nodes: Execute smart contracts (chaincode), validate transactions, and maintain the ledger.
Certificate Authority (CA): Issues the digital credentials that identify each participant/node.
Channels: Private sub-networks where only authorized members exchange transactions.

On top of that, integrating services like IAM (to define who can do what), KMS (which stores the cryptographic keys), and CloudTrail (audit logs) is straightforward.

A possible flow would be:

Bacen would create the Fabric Network on AMB and define the first Member;
- This member is responsible for setting governance policies (who can be invited, how chaincode gets approved, etc.).
Banks and fintechs would be invited to join the network as new members (via AMB);
- Each institution joins as a Member, with autonomy over its own nodes and identities.
Each member creates Peers to validate transactions and host chaincodes;
A CA on AMB generates certificates for admins, peers, and clients;
- Each member has its own CA, issuing certificates for:
  - Admins: who manage the network;
  - Peers: the validating nodes;
  - Clients/applications: an app that buys Treasury bonds, or that checks a bank reserve balance;
Channels are created, where sub-groups can exchange private information (e.g., settlement of tokenized assets).
- Here, Bacen could create private channels for interbank settlement;
- Another possibility would be creating asset tokenization on a channel restricted to fintechs;
The chaincode (smart contract) is deployed on the peers and starts governing the business logic;
- This is the cherry on top, where tokens get created (mint) and destroyed/settled (burn);
- Here, the sky's the limit you could program settlements, interbank transfers, and more;
Every transaction is signed, validated by the channel's peers, and recorded on the immutable ledger;

In short, if Bacen wanted to run a Drex pilot with governance distributed across banks, it could stand up the network on Hyperledger Fabric via AMB, while a private bank could, at the same time, use AMB Query to audit tokenized movements without maintaining any extra servers.

But why do it with AMB?

AMB's biggest advantage is being a managed service, and for Bacen and large banks and consortiums, AMB tends to strike a balance between governance + security + operations. For fintechs and PoCs, running on EKS/EC2 (or using public providers) buys agility and control, but comes with an operational cost, of course. Here's a cleaner comparison below:

Criteria	AMB	Self-managed node	Public network (Gnosis)
Operations	Fully managed (patching, HA)	You operate everything (high control)	100% outsourced
Security	IAM/KMS/VPC integrated	You define hardening/keys	Depends on the provider
Governance	Strong (ideal for consortiums/central banks)	Strong (if well implemented)	Variable
Performance/Latency	Good, but within the service's model	Maximum control (p2p tuning, disk, network)	Good, but without fine-grained guarantees
Cost	Per node/storage/requests	EC2/EBS/EKS/operational	Subscription/usage (egress/limits)
Interoperability	Fabric + supported public chains (Eth/Polygon)	Total (you choose the stack)	Good on public chains; provider lock-in
On-chain data (analytics)	AMB Query (serverless, multi-chain)	You index it yourself (TheGraph/ETL)	Some providers offer APIs

Conclusion

In the current landscape, Amazon Managed Blockchain (AMB) shows up as a strategic option for banks and fintechs that need to plug into the ecosystem quickly, without carrying the full weight of maintaining an entire infra stack (considering, of course, this is a hypothetical example used here).

AMB delivers:

Governance and compliance, ready out of the box;
On-demand scalability, without the complexity of Kubernetes clusters;
Direct integration with AWS services;

But there are limitations: adopting AMB means giving up some of the flexibility and independence that public networks or self-managed nodes on EKS allow. It's an inevitable trade-off between full control or speed with ready-made governance.

Ultimately, the critique is clear: the future of Drex, of the financial market, and of tokenization won't be defined by the technology it'll be defined by how Bacen, banks, and fintechs balance centralization and openness. Maybe the real challenge isn't choosing between Fabric, Besu, AMB, or EKS, but rather understanding when to use each approach.

original content: Blockchain e o Futuro do Sistema Financeiro Brasileiro: entre o Drex, Smart Contracts e a Nuvem da AWS
translated by AI

Amazon Athena: análises SQL diretas no S3 – quando usar, quanto custa e quais os limites

Thiago Sagara — Fri, 17 Oct 2025 14:59:44 +0000

Quando começei a trabalhar com AWS em 2021, nos meus estudos para a CCP via o S3 **como um Google Drive com **capacidade infinita (obviamente tinha uma visão beemm limitada de um cara que vinha de router bgp em Cisco). Contudo tenho notado que nos últimos anos, o S3 se consolidou como a espinha dorsal dos Data Lakes modernos na AWS, com cada vez mais funções e inovações.

Praticamente todo projeto de dados na AWS começa por lá: armazenando logs, relatórios financeiros, eventos de aplicações ou mesmo datasets públicos. Na prática ele deixou de ser um repositório passivo e virou o ponto de partida da inteligência de dados na nuvem.

O desafio agora não é mais guardar dados, e sim extrair valor deles sem clusters caros ou ETLs pesados.

É aí que entra o Amazon Athena. Lançado em 2016, como um serviço serverless de consultas SQL sobre o S3. Com ele, você não provisiona servidores, não paga por nós ociosos e obviamente não precisa configurar instâncias: apenas descreve o schema (e por traz ele usa o Glue Data Catalog) e consulta via SQL.

Nesse blog post quero mostrar como o Athena faz as queries no S3, como podemos deixar essa queries mais baratas e mais rápidas, e também quando utilizar esse combo é uma vantagem.

Cenário de estudo

Vamos usar um caso prático: temos um arquivo CSV com dados de filmes do IMDb armazenado no S3 com cerca de 10 MB, contendo colunas como título, ano, gênero e avaliação.

A ideia é analisar esses dados diretamente no S3 usando o Athena, sem precisar criar um banco de dados. Queremos responder perguntas como:

“Quais são os filmes mais bem avaliados por gênero?”
“Quantos filmes foram lançados por década?”

No começo, as consultas funcionam, mas são lentas e caras (o Athena precisa ler todo o CSV a cada execução). Então para resolver isso, aplicamos CTAS (Create Table As Select), convertendo o CSV para Parquet e criando partições por ano de lançamento, e assim reduzir tempo e custo.

Nosso objetivo: comparar a diferença entre consultar o CSV bruto e a versão otimizada em Parquet, analisando tempo de execução, volume de dados escaneado e custo em dólar.

Arquitetura por trás do Athena

Ok, o Athena além de ter um nome fanstástico foi algo totalmente revolucionário? A resposta direta: Não. Em resumo, ele funciona como a ponte entre o S3, onde os dados vivem, e as ferramentas que precisam deles.

Junto com ele tem o todo poderoso AWS Glue Data Catalog: que descreve o conteúdo, como se fosse um mapa para o dataset (palavra bonita para o .csv), na prática ele é que vai dar significado ao .csv.

Ai temos o Presto (motor interno (Trino)): que é quem realmente executa as consultas em paralelo, lendo os arquivos diretamente do S3.

Visualmente, a arquitetura pode ser imaginada assim: o S3 armazena os dados (CSV, JSON, Parquet), o Glue Catalog descreve como esses dados estão estruturados, o Athena (Presto) executa as queries em workers temporários, e os resultados podem ser enviados para QuickSight, Redshift ou devolvidos ao S3.

Mão na massa: dataset do IMDb

Para entender na prática como o Athena trabalha, vamos usar um dataset real: baixei a base de filmes do IMDb e subi em um bucket no S3, a base possui filmes com informações como título, ano de lançamento, nota e país.

Nosso objetivo será analisar quantos filmes foram lançados por ano nas décadas de 1980 e 1990, comparando a execução entre uma base CSV e uma versão otimizada em Parquet com particionamento por ano.

Criando a tabela no Athena (CSV original no S3)

CREATE EXTERNAL TABLE IF NOT EXISTS imdb_movies (
    id STRING,
    title STRING,
    link STRING,
    year INT,
    duration STRING,
    rating_mpa STRING,
    rating_imdb STRING,
    vote STRING,
    budget STRING,
    gross_world_wide STRING,
    gross_us_canada STRING,
    gross_opening_weekend STRING,
    director STRING,
    writer STRING,
    star STRING,
    genre STRING,
    country_origin STRING,
    filming_location STRING,
    production_company STRING,
    language STRING,
    win STRING,
    nomination STRING,
    oscar STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
  'separatorChar' = ',',
  'quoteChar' = '"'
)
LOCATION 's3://datanews-user-event/input/' 
TBLPROPERTIES ('skip.header.line.count'='1');

Esse comando informa ao Athena:

Onde estão os dados (LOCATION);
Que o formato é CSV (SERDE);
E quais colunas existem no arquivo.

Consultando quantos filmes foram lançados por ano (anos 80 e 90)

Agora podemos fazer a primeira consulta, (aqui ainda sem sem otimização).
Essa query irá contar quantos filmes existem por ano entre 1980 e 1999.

SELECT year, COUNT(*) AS total_filmes
FROM movies_csv
WHERE year BETWEEN 1980 AND 1999
GROUP BY year
ORDER BY year;

💡 Aqui o Athena vai ler o CSV inteiro, mesmo que a maioria dos registros não esteja dentro do período desejado.
Isso significa mais dados escaneados, mais tempo e mais custo.

Criando a tabela otimizada em Parquet com CTAS (filmes entre 80 e 90) Para melhorar a performance, vamos criar uma nova tabela em formato Parquet e particionada por ano. Usaremos o comando CTAS (Create Table As Select), que lê o dataset original, filtra os dados desejados e grava uma nova versão da tabela já otimizada no S3.

CREATE TABLE imdb_movies_80_90
WITH (
    format = 'PARQUET',
    external_location = 's3://datanews-user-event/ctas/',
    partitioned_by = ARRAY['year'],
    parquet_compression = 'SNAPPY'
) AS
SELECT
    id,
    title,
    director,
    year
FROM
    movies_csv
WHERE year BETWEEN 1980 AND 1999

O Athena criará automaticamente subpastas no S3 como:
s3://datanews-user-event/ctas/year=1980/ s3://datanews-user-event/ctas/year=1981/ ... s3://datanews-user-event/ctas/year=1999/
Cada partição conterá apenas os filmes daquele ano.

Consultando novamente a base otimizada Agora, basta rodar a mesma query de antes, mas sobre a nova tabela particionada:

SELECT year, COUNT(*) AS total_filmes
FROM imdb_movies_80_90
GROUP BY year
ORDER BY year;

O Athena agora só lê as partições necessárias (anos 80 e 90), em formato colunar e comprimido, em vez de varrer o CSV inteiro.
Isso pode reduzir o volume escaneado em até 90% e o tempo de execução em 3 a 5 vezes, dependendo do tamanho do dataset.

Resultado? O mesmo conjunto de dados, mas agora com consultas até 90% mais baratas e 3x mais rápidas.
O que muda não é o dado, é o formato e a forma como o Athena o lê.
Esse é o ponto em que o S3 deixa de ser apenas armazenamento e passa a ser plataforma de análise.

Comparações com outras soluções

Mas apenas o Athena consegue ler dados do S3? Não. Ele é muito bom para consultas ad-hoc (imagine o ad-hoc como um uber, ou seja, você solicita só quando precisa) e analises sob demanda, mas não é a escolha ideal para todos os cenários.

O Redshift Spectrum, por exemplo, também consultas dados no S3, mas depende de um cluster RedShift ativo, e é mais indicado para quem usa um data warehouse e quer estender o alcance das consultas.

O Amazon EMR, com Spark e Hive, é voltado a pipelines complexos e ETL massivos, também vai conseguir ler o S3, é mais fléxivel e muito mais poderoso, contudo exige uma manutenção e configuração mais pesada.

Custos e casos de uso

O Athena te cobra $5 por terrabyte escaneado proporcionalmente, ou seja, uma query que lê 1GB custa aproximadamente $0,005.

Simplicidade sedutora, posso dizer, mas perigosa.
Em números práticos, imagine um CloudTrail com 450GB de logs, que precisam ser analisados uma vez por semana:

CSV: 450 GB lidos × $5/TB = ~$9 por execução
Parquet: 110 GB lidos × $5/TB = ~$2.25

Essa diferença se repete toda semana, em um ano, são mais de $350 de economia só por mudar o formato.

Então utilize o Athena para contextos onde precisa da informação rápida ou quer manter a infra totalmente serveless. Exemplos:

BI e dashboards: junto com o QuickSight, gera relatórios em tempo real sem precisar mover dados.
Logs e auditoria: usado por equipes de segurança/redes para consultar CloudTrail, VPC Flow Logs e ALB Logs.
Data Lakes serverless: combinação de Glue + Athena + S3, criando um ecossistema de análise totalmente sem servidor.

Pontos importantes:

Cada query pode rodar no máximo por 30 minutos;
Os resultados (download) é limitado em 100MB (maiores só mandar para o S3 e fazer o download por lá);
Tem um soft-limit de 20 queries simultâneas por conta/região;

Bonus

quando NÃO utilizar o Athena:
Quando não usar o Athena:
Quando você precisa de queries complexas com muitos joins e aggregations;
Quando os dados precisam de atualizações frequentes (Athena é leitura, não transação);
Ou quando o custo por leitura começa a se igualar ao de um Redshift mantido ativo.

No fim, essa é a mentalidade por trás da nuvem moderna:
trazer a análise para os dados, e não os dados para a análise.
É o que faz o Athena ser tão poderoso — ele não é apenas uma ferramenta de consulta, mas um lembrete de que inteligência começa quando paramos de mover informação e começamos a escutá-la onde ela vive.

revisado por: Elisa Livramento

Blockchain e o Futuro do Sistema Financeiro Brasileiro: entre o Drex, Smart Contracts e a Nuvem da AWS

Thiago Sagara — Mon, 01 Sep 2025 20:07:28 +0000

Já imaginou poder ter a mesma liquidez da poupança em um imóvel, transferindo cotas digitais desse ativo com a mesma facilidade de enviar um pix? Esse é o tipo de transformação que o blockchain promete trazer ao mercado financeiro - e que o Bacen já está pavimentando com iniciativas como o Pix, o Open Finance e o DREX.

Não se trata apenas de inovação tecnológica, mas de uma mudança de paradigma: ativos, transações e contratos deixam de depender de sistemas centralizados para serem garantidos por uma rede distribuída, auditável e resistente a fraudes.

Ai vocês me perguntam: Mas o que é esse tal de BlockChain? O que isso muda na minha vida? E qual o papel ou como a AWS **pode ajudar, seja com o **Amazon Managed Blockchain (AMB) ou via nodes no EC2 ou EKS?

O que é Blockchain? é de comer ou é de beber?

O famoso e invisível Nakamoto descreveu o blockchain como um sistema de registro baseado em consenso distribuído, eliminando a necessidade de uma "entidade de confiança" única [Nakamoto, S. (2008). bitcoin: A peer-to-peer electronic cash system

Na prática, Blockchain é um nome bem bonitinho para um livro-caixa público e distribuído, em que cada página representa um bloco de transações (Block), e cada nova página só pode ser escrita se estiver matematicamente ligada à anterior (chain) e for aprovada por um consenso. Essa estrutura torna as informações imutáveis **e **transparentes, ou seja, uma vez registrada, a transação não pode ser alterada sem invalidar toda a sequência.

Beleza, falei um monte de coisas 'técnicas', e talvez vocês não tenham entendido absolutamente nada. Então imagine o blockchain como um livro de atas de uma assembléia de condomínio.

Cada reunião é registrada na ordem em que aconteceu (bloco).
Todos os condôminos recebem uma cópia idêntica da ata (nós da rede).
Para aprovar uma nova página, todos precisam concordar com o que está escrito (consenso).
Se alguém tentar alterar uma página antiga, todos os outros percebem imediatamente, pois suas cópias não batem.

A diferença é que, no Blockchain, esse livro de atas não é guardado em um arquivo ou gaveta, ele é** distribuído digitalmente, protegido por criptografia** e com assinaturas que garantem a autenticidade de cada decisão.

O detalhe técnico por trás da analogia é:

A 'página' é o bloco;
O 'encadeamento' entre as páginas é feito por funções hash criptográficas.
A 'assinatura de todos os condôminos' é o processo de consenso (Proof of Work, Proof of Stake, Proof of Authority e etc);
O 'livro inquebrável' é a garantia de imutabilidade do Ledger.

Perceba que na prática o processo de consenso é a alma do blockchain.

E o que eu tenho a ver com isso?

Despejei uma série de informações aqui, e talvez nesse momento você deve estar se perguntando: e o quiko?

Se pararem pra notar, as possibilidades de resoluções da tecnologia blockchain são bem interessantes, pois ela pode remodelar a forma como você interage com dinheiro, dados e até com o próprio Estado. Seus efeitos podem ser vistos tanto em facilidades quanto em novos desafios. Por exemplo:

Inclusão financeira: Em países em desenvolvimento, ou em guerra, onde milhões de pessoas não possuem conta bancária. O Blockchain permitiria criar carteiras digitais acessíveis apenas com um celular, ou mesmo 'decorando' uma sequência de 24 palavras. Reduzindo barreiras e entradas no sistema financeiro.
Rastreamento em cadeias de suplementos: Uma empresa conseguiria ter dados de uma matéria-prima desde os pequenos produtores até a chegada em sua fabrica. De fato a Nestle fez isso em 2020: Case Nestle BlockChain

Tokenização de bens: Imóveis, veículos e até obras de arte podem ser fracionadas digitalmente, permitindo que pessoas invistam em ativos a nivel de frações, permitindo que qualquer pessoa invista em ativos antes restritos a grandes investidores.
Maior confiança em serviços públicos: Subsídios como auxílio gás ou o bolsa família poderiam ser vinculados a smart contracts, e pagos em redes blockchain, onde todos sabem exatamente para onde o dinheiro foi - e sem espaço para desvios no meio do caminho.

Isso tudo ainda gera economia para o Mercado Financeiro. De acordo com Dan Tapscott, aproximadamente 30% o custo de back-office bancário é gasto apenas conciliando informações entre instituições. [Tapscott, D., & Tapscott, A. (2016). Blockchain Revolution]

Mas e o BACEN, onde entra nisso?

O Bacen não enxerga blockchain apenas como inovação experimental, mas como infraestrutura nacional estratégica e isso pode ser visto em dois produtos:

Pix (2020): Que apesar de não utilizar blockchain, prova a capacidade de criar sistemas em escala nacional com liquidação instantânea.
Drex: Que mesmo não sendo a nossa CBDC, ou seja, é o projeto para criação da moeda digital endógena brasileira, que servirá para:
- Controle mais eficiente das reservas bancárias;
- Compra/venda de frações de títulos públicos de forma atômica;

Em agosto de 2025 no evento Blockchain.Rio, o atual presidente do Bacen (Galipolo) confirmou que o DREX não é uma CDBC ("como a literatura clássica define") nem uma stablecoin, e sim uma ferramenta para tokenização de ativos (confirmando também que atualmente o Bacen não vai utilizar blockchain nessa fase).

Beleza. Mas o que a AWS tem a ver com isso?

Quando pensamos em como o Bacen ou mesmo um banco regional poderia operar o DREX para tokenizar ativos em escala nacional, a pergunta não é apenas qual blockchain usar, mas como sustentar essa infraestrutura sem se perder em custo e complexidade?

É aqui que entra o Amazon Managed Blockchain (AMB), um serviço da AWS que reduz o custo operacional de colocar blockchains em produção, utilizando o poder do EKS com KMS para servir como nós de rede em outras blockchains, uma vez que o AMB suporta Hyperledger Fabric, e o Bacen estuda implementar a Hyperledger Besu.

Até aqui tentei ser menos técnico, contudo agora vou ligar o modo 'escovador de bit'.

Solução para o Bacen

Falando primeiro sobre o AMB, ele não é simplesmente o blockchain da AWS, e sim um conjunto de serviços que permitem consumir ou criar redes permissionadas (hyperledger fabric), redes públicas (ethereum/polygon) e utilizar o AMB Query como a camada de analytics pronta para consultar de transações, saldos e históricos.

A vantagem em utilizar o AMB para o DREX, seria a governança distribuída, canais privados e uma ótima integração corporativa (dica para o Bacen). De fato a Hyperledger Fabric é a blockchain utilizada por alguns projetos de CBDCs como o DCash no Caribe, o Aber na Arábia Saudita, o Agila nas Filipinas e até o Venus (projeto de títulos) na França.

Amazon Managed Blockchain

No AMB além de criar as redes permissionadas, cada participante (membro) dela tem seu papel definido e controlado.

Elementos principais:

Network: é a rede Fabric, criada no AMB, onde ficam os membros;
Members: é a representação de uma organização participante (por exemplo Banco A, Banco B, Bacen). É nele que rodam os Peers e a CA, além da governança ser baseada nele.
Peer Nodes: Executam smart contracts (chaincode), validam transações e mantêm o ledger.
Certificate Authority(CA): emite credenciais digitais que identificam cada participante/nó.
Channels: Subredes privadas onde apenas membros autorizados trocam transações.

Além disso a integração com serviços como IAM (para definir quem pode fazer o que), KMS (que armazena as chaves criptográficas) e Cloudtrail (logs de auditoria) são simples de serem integradas.

Um possivel fluxo seria:

O Bacen criaria a Network Fabric no AMB e define o primeiro Member;
- Esse membro é o responsável por definir políticas de governança (quem pode ser convidado, como aprovar chaincodes, etc).
Bancos e fintechs entrariam como convidadas para ingressar na rede como novos membros (isso via AMB);
- Cada instituição ingressa como um Membro, com autonomia sobre seus nós e identidades.
Cada membro cria **Peers **para validar transações e hospedar chaincodes;
Um **CA **do AMB gera certificados para admins, peers e clientes;
Cada membro tem seu próprio CA, emitindo certificados para:
- Admins: que vão gerir a rede;
- Peer: que são os nós validadores;
- Clientes/aplicações: App que compra titulos do Tesouro, ou que consulta o saldo da reserva bancária;
São criados Channels, onde subsetores podem trocar informações privadas (ex.: liquidação de ativos tokenizados).
- Aqui o Bacen poderia criar channels privados para liquidação interbancária;
- Outra possibilidade, seria a criação de tokenização de ativos em um canal apenas com fintechs;
O _chaincode _(smart contract) é implantado nos peers e passa a reger a lógica de negócios;
- A cereja no bolo, onde seria feita a criação (mint) e a destruição/liquidação (burn) de tokens;
- Aqui o céu é o limite, podendo programar liquidações, transferências interbancárias e etc.;
Toda transação é assinada, validada pelos peers do canal e registrada no ledger imutável;

Resumindo, se o Bacen quisesse rodar um piloto de Drex com governança distribuída entre bancos, poderia montar a rede no Hyperleger Fabric via AMB, enquanto um banco privado poderia, ao mesmo tempo, usar o AMB Query para auditar movimentações tokenizadas sem manter servidores extras.

Mas porque fazer com AMB

A grande vantagem do AMB é ser um serviço gerenciado, e para a Bacen e grandes bancos e consórcios, o AMB tende a equilibrar governança + segurança + operação. Para fintechs e PoC, rodar em EKS/EC2 (ou usar provedores publicos) gera agilidade e controle, mas com um custo operacional, é claro. Abaixo comparo de uma forma melhor:

Critério	AMB	Nó próprio	Rede pública (Gnosis)
Operação	Totalmente gerenciado (patching, HA)	Você opera tudo (alto controle)	100% terceirizado
Segurança	IAM/KMS/VPC integrados	Você define hardening/chaves	Depende do provedor
Governança	Forte (ideal p/ consórcios/BCB)	Forte (se bem implementado)	Variável
Desempenho/Latência	Boa, mas dentro do modelo do serviço	Máximo controle (afinamento p2p, disco, rede)	Boa, mas sem garantias finas
Custo	Por nó/armazenamento/requests	EC2/EBS/EKS/operacional	Assinatura/uso (egress/limites)
Interoperabilidade	Fabric + públicos suportados (Eth/Polygon)	Total (você escolhe stack)	Boa em públicos; lock-in do provedor
Dados on-chain (analytics)	AMB Query (serverless multi-cadeia)	Você indexa (TheGraph/ETL)	Alguns provedores oferecem APIs

Conclusão

No contexto atual, o Amazon Managed Blockchain (AMB) aparece como uma opção estratégica para bancos e fintechs que precisam integrar-se rapidamente ao ecossistema, sem carregar o peso e manter toda a pilha de infra (considerando, é claro, o exemplo hipotético utilizado).
O AMB entrega:

Governança e compliance prontos para uso;
Escalabilidae sob demanda, sem a complexidade de clusters Kubernetes;
Integração direta com serviços AWS;

Contudo há limitações: adotar o AMB significa abrir mão de parte da flexibilidade e da independência que redes públicas ou nós próprios em EKS permitem. É um trade-off inevitável entre o controle total ou velocidade com governança pronta.

Por fim, a crítica é clara: o futuro do Drex, do mercado financeiro e da tokenização não será definido pela tecnologia, mas pela forma com que o Bacen, bancos e fintechs vão equilibrar centralização e abertura. Talvez o verdadeiro desafio não seja escolher entre Fabric, Besu, AMB ou EKS, mas sim entender quando usar cada abordagem.

Bitnami e o fim do repositório gratuito de imagens: o que muda para DevOps e Cloud Engineers?

Thiago Sagara — Wed, 27 Aug 2025 15:57:26 +0000

Em meados de julho/25 a comunidade de cloud e DevOps recebeu uma noticia um tanto quanto peculiar: a Bitnami anunciou alterações do seu repositório publico e gratuito de imagens ded containers e charts, o que na prática é um jeito 'maqueado' de descontinar o projeto open.

Para contextualizar, a Bitnami nasceu como uma empresa focada em simplificar a distribuição de aplicações open source, empacotando softwares em instalações fáceis, VMs, charts Helm e imagens Docker. Em 2019, foi adquirida pela VMware (hoje Broadcom), e desde então expandiu o catálogo de soluções.

Algumas das imagens mais conhecidas e amplamente usadas incluem:

PostgreSQL, MySQL e MariaDB: banco de dados para produção;
NGINX, Apache, Tomcat: Servidores web e de aplicação;
Redis, RabbitMQ e Kafka: Soluções de mensageria e cache;
Wordpress, Drupal, Magento: Aplicações open source populares;

A vantagem de pegar imagens open e empacota-las? Incorporação de boas práticas como segurança reforçada, facilidade na configuração para k8s e helm, imagens 'prontas' para produção bom tuning básico de performance, as imagens vinham acompanhadas de charts Helm ociciais da própria Bitnami, ou seja em resumo ela transformava software cru em software 'pronto para rodar em nuvem'.

Mas essa fase esta chegando ao fim.

Principais mudanças

Vejam que o repositório gratuito permanecerá existindo com o nome Bitnami Legacy Registry, contudo com algumas limitações, cito-as:

Não terá containers versionados;
Redução significativa no catalogo;
Não haverá updates de segurança;
Remoção das imagens de comunidade Debian-based;

Assim permanece gratuito imagens que eles chamaram de 'somente para desenvolvimento', com um catálogo limitado de aplicações, e todas apenas com a tag 'lastet' (o que nunca é uma boa opção para se ter em produção).

Com a versão paga, chamada de Bitnami Secure Images (BSI), ficou too o histórico da imagem (versões), bases com hardened, SBOMs e é claro updates de segurança e suporte. Tudo isso por um preço de $6.000/mês.

Impactos nos pipelines, charts e Helm

A mudança impacta diretamente pipelines de CI/CD, charts do Helm e manifestos Kubernetes que referenciam imagens da Bitnami. Projetos que até ontem "simplesmente funcionavam" podem começar a quebrar com erros de Image not found, ImagePullBackOff ou ErrImagePull.

Mas onde o impacto vai ser mais potente:

Pipelines de build/deploy: falhas ao puxar imagens já existentes, pois o código não terá a referencia correta;
Charts Helm: centenas de charts oficiais e derivados utilizam imagens da Bitnami como dependencia;
Ambientes Kubernetes: clusters rodando workloads baseados nessas imagens correm risco ded indisponibilidade em novos deploys;

Na prática essa alteração em um repositório tão importante para CI/Cs, charts e clustes em geral escala o evento para problema na cadeia de suprimentos.

Além do impacto técnico, a sensação de 'soco no estomago' na comunidade foi grande, e até injusto de certa forma. Usar a Bitnami ao invés de imagens oficiais tirava certo peso dos desenvolvedores e devOps, pois a imagem vinha com boas práticas adicionais, contudo também contava com bastante apoio da comunidaded na resolução de issues e documentação.

Receber o anuncio com a opção de 'migrar' em 45 dias é de uma falta de empatia gigante, e aqui nem acredito que capitalizar o trabalho é errado, mas sim a forma que isso foi feito. Para efeito e comparação em 2020 a RedHat anunciou mudança de foco para o CentOS, mas apenas em julho de 2024 ele entrou em EOL, na prática a RedHat ainda 'suportou' o projeto com atualizações de segurança e manutenção por 4 anos, o que deu a comunidade tempo para fazer forks e até iniciar outros projetos.

Opções urgentes

As opções para (pelo menos) ganhar tempo de uma solução mais robusta podem incluir fazer o cache local das imagens utilizadas atualmente com um docker save, ou utilizar repositórios privados como o AWS ECR ou o Harbor. Dessa forma é possivel congelar as versões críticas até que um plano de migração esteja definido.

Outra opção (um pouco mais kamikaze) é utilizar o repositório legado, e simplesmente substituir o código para bitnamilegacy/<image>. O problema disso: não tem updates, suporte e manutenção, além de existir a possibilidade de uma atualização da imagem, e por conta do latest você ter surpresas na aplicação.

Existe também a opção de fazer o subscribe do Bitnami Secure Image, contudo pagar por algo que antes era gratuito, pode exigir um estudo mais aprofundado das empresas para calcular o retorno de investimento e até a nova margem (a depender do tamanho da empresa). Note que $6.000/mês no Brasil pode significar o custo de TODA conta da AWS, o que na prática deixa inviável a escolha.

Opções definitivas

Pra resolver de forma definitiva é necessário identificar os workloads críticos que utilizam imagens bitnami, e classifica-los por impacto comercial. Dessa forma (com o impacto financeiro calculado) será possivel analisar o risco/retorno do custo da licença.

Se obter a licença não for uma opção, as alternativas são:

Imagens oficiais: Ou seja, utilizar o repositório oficial da imagem, como postgres, redis e etc;
Imagens da AWS: Usar RDS ou mesmo o ElastiCache é uma ótima opção para não ter esse tipo de problema;
Serviços Gerenciados: Para aplicações mais complexas como elasticsearch e kafka ou rabbitMQ, serviços como o OpenSearch e o Amazon MSK são opções ótimas;

Conclusão

Não que a comunidade precisasse de justificativa, uma vez que o produto precisa ser capitalizado, mas a explicação da Broadcom é que a mudança visa um repositório mais seguro e com suporte. Contudo a segurança não depende necessariamente de paywall.
Ferramentas como Trivy, Grype ou Clair já fazem analise de vulnerabilidade, assim bastaria incorpora-las na pipeline de CI/CD e até integrar com SCA para aumentar a analise.

Na prática, o movimento reflete mais uma estratégia a Broadcom pós-aquisição da VMware: monetizar ativos consolidados. O que, novamente, não acho errado, contudo o jeito com que foi feito (abrupto, sem períoo de transição claro e justo) deixará muitas empresas a merce de renovar por uma taxa grande, apenas para conseguir mais tempo para planejar a migração.

No fim, quem perde não são apenas os entusiastas de open source, mas também too o ecossistema que dependia da Bitnami, e assim aprendemos que ser cloud-native é também pensar em cenários onde até a Docker pode começar a cobrar pela disponibilidade.

Como verificar se possuo imagens bitnami

Cluster Kubernetes (tudo que ja virou pod):

kubectl get pods -A -o json \
| jq -r '.items[]
  | .metadata.namespace as $ns
  | .metadata.name as $name
  | (.spec.initContainers // []) + (.spec.containers // [])
  | .[].image
' | sort -u | grep -E '(^|/)bitnami/'

Cluster Kubernetes (tudo que ainda não virou pod):

kubectl get deploy,sts,ds,job,cronjob -A -o json \
| jq -r '.items[]
  | .metadata.namespace as $ns
  | .metadata.name as $name
  | (.spec.template.spec.initContainers // []) + (.spec.template.spec.containers // [])
  | .[].image
' | sort -u | grep -E '(^|/)bitnami/'

Helm:

helm ls -A -o json \
| jq -r '.[] | [.name,.namespace] | @tsv' \
| while IFS=$'\t' read -r rel ns; do
    echo "=== $ns/$rel ==="
    helm get values "$rel" -n "$ns" | grep -nE '(^\s*image:|repository:).*bitnami' || true
  done

Pipeline no Jenkins para procurar dependencias:

pipeline {
  agent any
  options { ansiColor('xterm') }
  environment {
    BITNAMI_REGEX = '(?i)(^|\\s|/)(bitnami)(/|:)'
  }
  stages {
    stage('Audit - Git Manifests') {
      steps {
        sh '''
          echo "[GIT] Procurando imagens/repo Bitnami..."
          set +e
          MATCHES=0

          # 1) Imagens em manifests YAML
          FOUND1=$(find . -type f -name "*.y*ml" -print0 \
            | xargs -0 -I{} yq -r '.. | select(has("image")) | .image' '{}' 2>/dev/null \
            | grep -E "$BITNAMI_REGEX" || true)
          if [ -n "$FOUND1" ]; then echo "$FOUND1" | sort -u | sed "s/^/[YAML IMG] /"; MATCHES=1; fi

          # 2) Helm/Chart deps
          FOUND2=$(git grep -nEi "(repository|repoURL):\\s*(oci://registry-1\\.docker\\.io/bitnamicharts|https?://charts\\.bitnami\\.com/bitnami)" || true)
          if [ -n "$FOUND2" ]; then echo "$FOUND2" | sed "s/^/[HELM REPO] /"; MATCHES=1; fi

          # 3) Dockerfiles
          FOUND3=$(git grep -nEi "FROM\\s+bitnami/" || true)
          if [ -n "$FOUND3" ]; then echo "$FOUND3" | sed "s/^/[DOCKERFILE] /"; MATCHES=1; fi

          if [ $MATCHES -ne 0 ]; then
            echo "✖ Encontrado Bitnami. Interrompendo pipeline."
            exit 2
          fi
          echo "✔ Nenhuma referência Bitnami encontrada no Git."
        '''
      }
    }

    stage('Audit - Cluster (opcional)') {
      when { expression { return env.KUBECONFIG?.trim() } }
      steps {
        sh '''
          echo "[CLUSTER] Vasculhando imagens em workloads..."
          set +e
          OUT=$(kubectl get deploy,sts,ds,job,cronjob -A -o json \
            | jq -r '.items[] | (.spec.template.spec.initContainers // []) + (.spec.template.spec.containers // []) | .[].image' \
            | sort -u | grep -E "$BITNAMI_REGEX" || true)
          if [ -n "$OUT" ]; then
            echo "$OUT" | sed "s/^/[K8S IMG] /"
            echo "✖ Cluster contém imagens Bitnami em workloads desejados."
            exit 3
          fi
          echo "✔ Nenhuma imagem Bitnami detectada em workloads."
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: '**/audit*.log', allowEmptyArchive: true
    }
    failure {
      echo 'Falhou por referências Bitnami. Verifique os logs acima.'
    }
  }
}

Referências:

Entendendo Docker: o que é, como funciona e por que usar

Thiago Sagara — Wed, 30 Jul 2025 21:05:57 +0000

Repost do original: https://www.darede.com.br/entendendo-docker/ da Darede

O Docker é uma das melhores plataformas para o deploy de uma aplicação. Para entender sua funcionalidade, confira esse artigo em nosso blog!

A evolução do deploy de uma aplicação passou por vários processos. Inicialmente tínhamos um servidor físico para cada serviço, ou seja, havia um servidor, um sistema operacional e uma aplicação. Isso gera um aumento em manutenção de hardware, de atualização de patches de segurança ou upgrade da aplicação. Com a virtualização criamos uma camada de abstração do hardware, ou seja, podemos em UM hardware ter vários SOs, e consequentemente várias aplicações. Contudo a necessidade de gerenciamento do SO ainda existe (e ainda existe o SO do próprio hypervisor). Por fim chegamos ao container, ele eleva a abstração para o SO. Isto é, conseguimos abstrair o hardware e o sistema operacional, e deixar o container apenas para cuidar da aplicação. Nesse artigo vamos entender sobre o Docker.

Instalação (centos8)

Instalaremos o docker, e depois realizaremos o pull de uma imagem do tac_plus para servir como servidor de autenticação para nossos equipamentos.

Remova todas as versões de docker que possam estar habilitadas:

dnf remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine

Desabilite o firewalld (por algum motivo ele impossibilita a resolução de DNS dentro dos containers)

systemctl disable firewalld

Adicione o repositório do docker

dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo

Instale o docker com --nobest para compatibilidade com CentOS 8

dnf install --nobest docker-ce

Habilite o docker no sistema


systemctl start docker
systemctl enable docker

Teste o docker validando a versão

[root@devops ~]# docker version
Client: Docker Engine - Community
 Version:           19.03.11
 API version:       1.39
 Go version:        go1.13.10
 Git commit:        42e35e61f3
 Built:             Mon Jun  1 09:13:48 2020
 OS/Arch:           linux/amd64
 Experimental:      false


Server: Docker Engine - Community
 Engine:
  Version:          18.09.1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       4c52b90
  Built:            Wed Jan  9 19:06:30 2019
  OS/Arch:          linux/amd64
  Experimental:     false
[root@devops ~]#

Comandos básicos

Com o Docker instalado vamos agora falar de alguns comandos básicos:

docker ps -a: Mostra todos os containers, tanto os em execução quanto os parados.
docker run: Executa um container com uma imagem especifica (no nosso caso o Hello-Worl
docker start|stop: Inicia um (ou mais) containeres parados, ou para um (ou mais) containers ativos.
docker rm: Remove um (ou mais) container. (voce pega a lista com o docker ps -a)
docker rmi: Remove um (ou mais) imagens. (voce pega a lista com o docker images)
docker container prune: Remove todos os containers que estão parados.
docker images: Mostra todas as images que voce ja fez o pull
docker exec -it: Roda um comando dentro do container (só o exec), e com a opção "-it" voce aloca um tty dentro do container, ou seja, é a opção para ter acesso a console do container. exemplo: docker exec -it hello-wold bash
docker network ls: Lista todas as redes criadas no Docker
docker run: Executa de fato (ou roda) o docker.

Por fim para testar, vamos subir um docker com o famoso hello-word:

[root@devops ~]# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest


Hello from Docker!
This message shows that your installation appears to be working correctly.


To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.


To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash


Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/


For more examples and ideas, visit:
 https://docs.docker.com/get-started/


[root@devops ~]#

Xero no suvaco!!!