We often talk about the “ideal” state, one where every device has a managed client like the Cloudflare One Client installed, providing deep visibility and seamless protection. However, reality often gets in the way.
Sometimes you are dealing with a company acquisition, managing virtual desktops, or working in a highly regulated environment where you simply cannot install software on an endpoint. You still need to protect that traffic, even when you don’t fully manage the device.
Closing this gap requires moving the identity challenge from the device to the network itself. By combining the browser’s native proxy capabilities with our global network, we can verify users and enforce granular policies on any device that can reach the Internet. We’ve built the Gateway Authorization Proxy and Proxy Auto-Configuration (PAC) File Hosting to automate this authentication and simplify how unmanaged devices connect to Cloudflare.
The problem: sometimes IP addresses aren’t enough
Back in 2022, we released proxy endpoints that allowed you to route traffic through Cloudflare to apply filtering rules. It solved the immediate need for access, but it had a significant “identity crisis.”
Because that system relied on static IP addresses to identify users, it was a bit like a security guard who only recognizes cars, not the people inside them. If a car (a specific IP) showed up, it was let in. But if the driver switched cars or worked from a different location, the guard got confused. This created a few major headaches:
Anonymous Logs: We knew the IP address, but we didn’t know the person.
Brittle Policies: If a user moved to a new home or office, the endpoint broke or required an update.
Manual Maintenance: You had to host your own PAC file (the “GPS” that tells your browser where the proxy is) — one more thing for your team to manage.
The solution: the Authorization Proxy
Authorization proxy Access policy setup page
The new Gateway Authorization Proxy adds a “badge reader” at the entrance. Instead of just looking at where the traffic is coming from, we now use a Cloudflare Access-style login to verify who the user is, before enforcing Gateway filtering.
Think of this as moving from a guest list based on license plates, to a system where everyone has their own badge. This brings several massive benefits:
True identity integration: Your logs related to proxy endpoints now show exactly which user is accessing which site. You can write specific rules like “only the Finance team can access this accounting tool,” even without a client installed on the device.
Multiple identity providers: This is a superpower for large companies or those undergoing M&A. You can choose which identity providers to show your users. You can display one or multiple login methods (like Okta and Azure AD) at the same time. This is a level of flexibility that competitors don’t currently offer.
Simplified billing: Each user simply occupies a “seat,” exactly like they do with the Cloudflare One Client. There are no complicated new metrics to track.
To make this possible, we had to overcome the technical hurdle of associating a user’s identity with every request, and without a device client. Read on to see how it works.
How Authorization Proxy tracks identity
The Authorization Proxy uses signed JWT cookies to maintain identity, but there’s a catch: when you first visit a new domain through the proxy, there’s no cookie yet. Think of it like showing your badge at each new building you enter.
The flowchart above illustrates exactly how this authentication process works:
First visit to a domain: When you navigate to a new domain, the Gateway Authorization Proxy checks if a domain identity cookie is present. If not, you’re redirected to Cloudflare Access, which then checks for an existing Cloudflare Access identity cookie. If you’re already authenticated with Cloudflare Access, we generate a secure token specifically for that domain. If you’re not, we redirect you to login with your identity provider(s).
Invisible to users: This entire process happens in milliseconds thanks to Cloudflare’s global edge network. The redirect is so fast that users don’t notice it — they simply see their page load normally.
Repeat visits are instant: Once the cookie is set, all subsequent requests to that domain (and its subdomains) are immediately authorized. No more redirects needed.
Because of this approach, we can log and filter traffic per person across all domains they access, and revoke access in an instant when needed — all without requiring any software installation on the user’s device.
To make it easy, we have included starter templates to get you up and running in minutes. We have also integrated our AI assistant, Cloudy, to provide summaries that help you understand exactly what your PAC file is doing, without having to read through lines of code.
Is this right for your team?
While we still recommend the Cloudflare One Client for greater control and the best user experience, the Auth Proxy is the perfect fit for specific scenarios:
Virtual desktops (VDI): Environments where users log into a virtual machine and use a browser to reach the Internet.
Mergers and acquisitions: When you need to bring two different companies under one security umbrella quickly.
Compliance constraints: When you are legally or technically prohibited from installing software on an endpoint.
What’s next?
This expands our clientless security options to connect to Cloudflare One, and we are already working on expanding our supported identity methods related to Authorization Endpoints. Look out for Kerberos, mTLS, and traditional username/password authentication to give you even more flexibility in how you authenticate your users.
The Gateway Authorization Proxy and PAC File Hosting are available in open beta today for all account types. You can get started by going to the “Resolvers and Proxies” section of your Cloudflare dashboard.
Most security teams spend their days playing a high-stakes game of Whac-A-Mole. A user’s credentials get phished, or they accidentally download a malicious file, and suddenly you’re in incident response mode.
We built our SASE platform, Cloudflare One, to stop that cycle. By placing Access and Gateway in front of your applications and Internet traffic, we gave you the tools to decide who gets in and where they can go.
Today, we’re making those decisions smarter. You can now incorporate User Risk Scores directly into your zero trust network access (ZTNA) policies. Instead of just checking “Who is this user?” and “Is their device healthy?”, you can now ask, “How has this user been behaving lately?” and adjust their access in real time.
Step 1: From “what” to “how”
For years, traditional corporate access was binary. You either had the right login and the right certificate, or you didn’t. But identity is fluid. A legitimate user can become a risk if their account is compromised or if they start exhibiting “insider threat” behaviors — like impossible travel, multiple failed login attempts, or triggering data loss prevention rules by moving sensitive data.
Cloudflare One now continuously calculates a risk score for every user in your organization based on these behaviors.
Example list of users and their risk scores
Once you’ve onboarded your team to Cloudflare One, you can navigate to the Team & Resources > Users > Risk Score section of the dashboard. Here, you can define which behaviors matter to you. For example, you might decide that impossible travel has a “high” risk level, while using a device in need of an update is “medium.”
Cloudflare’s risk engine continuously evaluates telemetry from across the SASE platform. For internal signals, the engine monitors logs from Cloudflare Access (e.g., successful/failed logins, geographic context) and Cloudflare Gateway (e.g., malware hits, risky browsing categories, or sensitive data triggers in DLP).
For third-party signals, we’ve built service-to-service integrations with partners like CrowdStrike and SentinelOne. These integrations allow Cloudflare to ingest external telemetry, such as CrowdStrike’s device posture attributes, and map it to a user’s profile.
The calculation logic is designed to be deterministic:
Selection: Administrators choose which specific “risk behaviors” (impossible travel, DLP violations, and more) to enable for their organization.
Aggregation: The engine identifies all risk events associated with a user.
Scoring: A user’s risk score is determined by the highest risk level (low, medium, or high) of any enabled behavior triggered during that period.
Reset: If an admin investigates and clears an incident, they can manually reset the user’s score, which preserves the history but resets their access based on risk data gathered going forward.
Step 2: Easily apply adaptive access
Knowing a user is risky is step one. Doing something about it — automatically — is step two.
In the past, if a security analyst saw a suspicious user, they’d have to manually revoke sessions or move the user into a “restricted” group in their Identity Provider (IdP). That takes time — time an attacker uses to move laterally.
Now, you can build Adaptive Access policies. When you create or edit an Access policy, you’ll find a new selector: User Risk Score.
Example of the new User Risk Score selector in an Access policy.
This allows you to create global or application-specific rules such as: “If a user’s risk score is high, they cannot access the Finance Portal,” or “If a user’s risk score is medium, they must use a physical security key to log in.” Such rules ensure corporate operations are not interrupted while additional layers of security are applied.
Step 3: Closing the loop
The best part of this system is that it’s dynamic. If a user’s risk score drops after being reviewed and cleared by an investigator, their access is automatically restored based on your policy. Today, risk-based access can revoke access in the middle of an active session when risk score increases. In the future, we will explore expanding this to enforce step-up MFA in the middle of an active session when the risk score changes as well.
We’ve also made sure this works with the tools you already use. If you use Okta, Cloudflare can share these risk signals back to Okta, ensuring that a user flagged on the network is also restricted at the front door of your SSO. This integration uses the Shared Signals Framework, which enables the sharing of risk signals across platforms.
Move faster, stay secure
We built Cloudflare One so that security teams could stop being the “department of no” and start being the department of “yes, and safely.” Incorporating user risk scores into your Access policies is the next step in that journey. It moves your security from a static snapshot at login to a continuous, living conversation with your network architecture.
If you’re already a Cloudflare customer, you can start exploring these risk signals in your dashboard today. If you’re still wrestling with legacy VPNs or manual security reviews, we’d love to help you flip the switch.
You can get started for free for up to 50 users — no sales call required. For larger organizations looking to integrate third-party signals like CrowdStrike or SentinelOne into their global policies, our team is ready to walk you through a ZTNA pilot.
Trust is the most expensive vulnerability in modern security architecture. In recent years, the security industry has pivoted toward a zero trust model for networks — assuming breach and verifying every request. Yet when it comes to the people behind those requests, we often default back to implicit trust. We trust that the person on the Zoom call is who they say they are. We trust that the documents uploaded to an HR portal are genuine.
That trust is now being weaponized at an unprecedented scale.
In our 2026 Cloudflare Threat Report, we highlight a rapidly accelerating threat vector: the rise of “remote IT worker” fraud. Often linked to nation-states, including North Korea, these are not just individual bad actors. They are organized operations running laptop farms: warehouses of devices remotely accessed by workers using stolen identities to infiltrate companies, steal intellectual property (IP), and funnel revenue illicitly.
These attackers have evolved and continue to do so with advancements in artificial intelligence (AI). They use generative AI to pass interviews and deepfake tools to fabricate flawless government IDs. Traditional background checks and standard identity providers (IdPs) are no longer enough. Bad actors are exploiting an identity assurance gap, which exists because most zero trust onboarding models verify devices and credentials, not people.
To close this gap, Cloudflare is partnering with Nametag, a pioneer in workforce identity verification, to bring identity-verified onboarding and continuous identity assurance to our SASE platform, Cloudflare One.
Your biggest insider threat was scheming from the start
The challenge with insider risk is that companies naturally want to trust their employees. By the time malicious actors are detected by traditional data loss prevention (DLP) or user entity behavior analytics (UEBA) tools, they are already inside the perimeter. They have valid credentials, a corporate laptop, and access to sensitive repositories.
The “remote IT worker” scheme exploits the gap between hiring and onboarding. Attackers use stolen or fabricated identities to get hired. Once the laptop is shipped to a “mule” address (typically a domestic laptop farm located in the country of the remote worker’s alleged employment), it is racked and connected to a keyboard, video, and mouse (KVM) switch. The remote actor then logs in via VPN (or perhaps remote desktop), appearing to be a legitimate employee.
Because the credentials are valid and the device is corporate-issued, standard zero trust network access (ZTNA) policies often see this traffic as “safe” — when in fact it’s an enormous risk to your business.
Enter identity-verified zero trust
Cloudflare Access already serves as the aggregation layer for your security policies — checking attributes such as device posture, location, and user group membership before granting access to applications, infrastructure, or MCP servers. Through our partnership with Nametag, we are adding a critical new layer: workforce identity verification.
Previously, IT departments had no choice but to assume trust throughout the new user onboarding process. They could either ship a laptop to an address provided by the new hire and then send their initial credentials to their personal email, or require them to come in person –– costly and impractical in a world of distributed workforces and contractors.
Nametag replaces assumed trust with verified identity, ensuring that the person receiving, configuring, and connecting a device to protected resources is a real person, a legitimate person, and the right person throughout the entire process. This integration allows organizations to uncover and stop bad actors, including North Korean IT workers, before they gain access to any internal resources or data.
How it works
Nametag is integrated using OpenID Connect (OIDC). You can configure it as an IdP within Cloudflare Access or chain it as an external evaluation factor alongside your primary identity provider (like Okta or Microsoft Entra ID).
Example of the Cloudflare Access login page prompting for a user to authenticate using Nametag.
Here is an example workflow for a high-security onboarding scenario:
Trigger: A new user attempts to access their initial onboarding portal (protected by Cloudflare Access).
Challenge: Instead of just asking for a username and password, Cloudflare directs the user to Nametag for authentication via OIDC.
Verification: The user enters their new work email address, then snaps a quick selfie and scans their government-issued photo ID using their phone.
Attestation: Nametag’s Deepfake Defense™ identity verification engine leverages advanced cryptography, biometrics, AI and other features to ensure that the user is both a real person and the right person. Nametag’s technology uniquely prevents bad actors from using deepfake IDs and selfies in sophisticated injection attacks or presentation attacks (e.g., holding up a printed photo).
Enforcement: If that check is successful, Nametag returns an ID token to Cloudflare to complete the OIDC flow. Cloudflare then grants or denies access to the application based on the user’s identity and the Access policies.
All of this happens before the user can access email, code repositories, or other internal resources.
Verifying your identity with Nametag takes under 30 seconds to complete. No biometrics are stored after this interaction.
A layered defense
This partnership complements Cloudflare’s existing suite of insider threat protections. Today, you can:
Scan for data exfiltration using our API-driven DLP.
Nametag provides the missing link: identity assurance. It moves us from knowing what account is logging in, to knowing exactly who is behind the keyboard.
In an era where AI can fake a face and a voice, cryptographic proof of identity is the only way to safely trust your workforce.
Beyond onboarding: continuous verification
While stopping bad actors at the door is critical, the threat landscape is dynamic. Legitimate credentials can be sold, and legitimate employees can be compromised.
To protect against that present and ever-evolving risk, Cloudflare Access now incorporates user risk scores so security teams can build context-aware policies. If a user’s risk score suddenly increases from low to high, access can be revoked to any (or all) applications.
In the future, you’ll be able to enforce step-up verification based on signals such as user risk score, in the middle of an active session. Rather than hitting the “big red button” and potentially disrupting a user who does have a legitimate reason for accessing the production billing system from an usual location, you will instead be able to challenge the user to verify with Nametag or by using Cloudflare’s independent MFA with strong authentication methods. If the user is a session hijacker or a bot, they will be unable to pass these checks.
This capability will also extend to self-service IT workflows. Password resets and MFA device registration are prime targets for social engineering (e.g., the MGM Resorts help desk attacks). By placing Nametag behind Cloudflare Access for these specific portals, you eliminate the possibility of a support agent being socially engineered into resetting a password for an attacker.
Defend against the future, now
Security cannot rely on assumptions. As AI tools lower the barrier to entry for sophisticated fraud, your defenses must evolve to verify the human element with cryptographic certainty. The “remote IT worker” threat is not a hypothetical scenario—it is an active campaign targeting organizations globally.
You don’t need to overhaul your entire infrastructure to stop it. You can layer these protections on top of your existing IdP and applications immediately.
Cloudflare One is free for up to 50 users, allowing you to pilot identity-verified onboarding flows or protect high-risk internal portals right now.
Get started:Sign up for Cloudflare One to begin building your policy engine.
Deploy the integration: Follow the step-by-step guide to connect Nametag to Cloudflare Access in minutes.
Understand the risk: Read the full Cloudflare Threat Report to see the data behind the rise in insider threats and AI impersonation.
Don’t wait for a breach to verify your workforce. Start implementing a SASE architecture that trusts nothing — not even the face on the screen — without verification.
The Swiss Financial Market Supervisory Authority (FINMA) has published several requirements and guidelines about engaging with outsourced services for the regulated financial services customers in Switzerland.
An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to support of adherence with FINMA requirements.
The latest report covers the 12-month period from October 1, 2024 to September 30, 2025 for the following circulars:
2018/03 Outsourcing – banks, insurance companies and selected financial institutions under FinIA
2023/01 Operational risks and resilience – banks
Business Continuity Management (BCM) minimum standards proposed by the Swiss Insurance Association.
AWS has added the following five services to the current FINMA scope:
Customers can find the FINMA ISAE 3000 report on AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact. Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below
So much of what you interact with on GitHub depends on search—obviously the search bars and filtering experiences like the GitHub Issues page, but it is also the core of the releases page, projects page, the counts for issues and pull requests, and more. Given that search is such a core part of the GitHub platform, we’ve spent the last year making it even more durable. That means, less time spent managing GitHub Enterprise Server, and more time working on what your customers care most about.
In recent years, GitHub Enterprise Server administrators had to be especially careful with search indexes, the special database tables optimized for searching. If they didn’t follow maintenance or upgrade steps in exactly the right order, search indexes could become damaged and need repair, or they might get locked and cause problems during upgrades. Quick context if you’re not running High Availability (HA) setups, they’re designed to keep GitHub Enterprise Server running smoothly even if part of the system fails. You have a primary node that handles all the writes and traffic, and replica nodes that stay in sync and can take over if needed.
Much of this difficulty comes from how previous versions of Elasticsearch, our search database of choice, were integrated. HA GitHub Enterprise Server installations use a leader/follower pattern. The leader (primary server) receives all the writes, updates, and traffic. Followers (replicas) are designed to be read-only. This pattern is deeply ingrained into all of the operations of GitHub Enterprise Server.
This is where Elasticsearch started running into issues. Since it couldn’t support having a primary node and a replica node, GitHub engineering had to create an Elasticsearch cluster across the primary and replica nodes. This made replicating data straightforward and additionally gave some performance benefits, since each node could locally handle search requests.
Unfortunately, the problems of clustering across servers eventually began to outweigh the benefits. For example, at any point Elasticsearch could move a primary shard (responsible for receiving/validating writes) to a replica. If that replica was then taken down for maintenance, GitHub Enterprise Server could end up in a locked state. The replica would wait for Elasticsearch to be healthy before starting up, but Elasticsearch couldn’t become healthy until the replica rejoined.
For a number of GitHub Enterprise Server releases, engineers at GitHub tried to make this mode more stable. We implemented checks to ensure Elasticsearch was in a healthy state, as well as other processes to try and correct drifting states. We went as far as attempting to build a “search mirroring” system that would allow us to move away from the clustered mode. But database replication is incredibly challenging and these efforts needed consistency.
What changed?
After years of work, we’re now able to use Elasticsearch’s Cross Cluster Replication (CCR) feature to support HA GitHub Enterprise.
“But David,” you say, “That’s replication between clusters. How does that help here?”
I’m so glad you asked. With this mode, we’re moving to use several, “single-node” Elasticsearch clusters. Now each Enterprise server instance will operate as independent single node Elasticsearch clusters.
CCR lets us share the index data between nodes in a way that is carefully controlled and natively supported by Elasticsearch. It copies data once it’s been persisted to the Lucene segments (Elasticsearch’s underlying data store). This ensures we’re replicating data that has been durably persisted within the Elasticsearch cluster.
In other words, now that Elasticsearch supports a leader/follower pattern, GitHub Enterprise Server administrators will no longer be left in a state where critical data winds up on read-only nodes.
Under the hood
Elasticsearch has an auto-follow API, but it only applies to indexes created after the policy exists. GitHub Enterprise Server HA installations already have a long-lived set of indexes, so we need a bootstrap step that attaches followers to existing indexes, then enables auto-follow for anything created in the future.
Here’s a sample of what that workflow looks like:
function bootstrap_ccr(primary, replica):
# Fetch the current indexes on each
primary_indexes = list_indexes(primary)
replica_indexes = list_indexes(replica)
# Filter out the system indexes
managed = filter(primary_indexes, is_managed_ghe_index)
# For indexes without follower patterns we need to
# initialize that contract
for index in managed:
if index not in replica_indexes:
ensure_follower_index(replica, leader=primary, index=index)
else:
ensure_following(replica, leader=primary, index=index)
# Finally we will setup auto-follower patterns
# so new indexes are automatically followed
ensure_auto_follow_policy(
replica,
leader=primary,
patterns=[managed_index_patterns],
exclude=[system_index_patterns]
)
This is just one of the new workflows we’ve created to enable CCR in GitHub Enterprise Server. We’ve needed to engineer custom workflows for failover, index deletion, and upgrades. Elasticsearch only handles the document replication, and we’re responsible for the rest of the index’s lifecycle.
How to get started with CCR mode
To get started using the new CCR mode, reach out to [email protected] and let them know you’d like to use the new HA mode for GitHub Enterprise Server. They’ll set up your organization so that you can download the required license.
Once you’ve downloaded your new license, you’ll need to set `ghe-config app.elasticsearch.ccr true`. With that finished, administrators can run a `config-apply` or an upgrade on your cluster to move to 3.19.1, which is the first release to support this new architecture.
When your GitHub Enterprise Server restarts, Elasticsearch will migrate your installation to use the new replication method. This will consolidate all the data onto the primary nodes, break clustering across nodes, and restart replication using CCR. This update may take some time depending on the size of your GitHub Enterprise Server instance.
While the new HA method is optional for now, we’ll be making it our default over the next two years. We want to ensure there’s ample time for GitHub Enterprise administrators to get their feedback in, so now is the time to try it out.
We’re excited for you to start using the new HA mode for a more seamless experience managing GitHub Enterprise Server.
Want to get the most out of search on your High Availability GitHub Enterprise Server deployment? Reach out to support to get set up with our new search architecture!
This is a guest post by Edijs Drezovs, CEO and Founder of GOStack, Viesturs Kols, Data Architect at GOStack, and Krisjanis Beitans, Senior Data Engineer at GOStack, in partnership with AWS.
Yggdrasil Gaming develops and publishes casino games globally, processing massive amounts of real-time gaming data for game performance analytics, player behavior insights, and industry intelligence. As Yggdrasil’s system grew, managing dual-cloud environments created operational overhead and limited their ability to implement advanced analytics initiatives. This challenge became critical ahead of the launch of the Game in a Box solution on AWS Marketplace, which generates increases in data volume and complexity.
Yggdrasil Gaming reduced multi-cloud complexity and built a scalable analytics foundation by migrating from Google BigQuery to AWS analytics services. In this post, you’ll discover how Yggdrasil Gaming transformed their data architecture to meet growing business demands. You will learn practical strategies for migrating from proprietary systems to open table formats such as Apache Iceberg while maintaining business continuity.
Yggdrasil worked with GOStack, an AWS Partner, to migrate to an Apache Iceberg-based lakehouse architecture. The migration helped reduce operational complexity and enabled real-time gaming analytics and machine learning.
Challenges
Yggdrasil faced several critical challenges that prompted their migration to AWS:
Multi-cloud operational complexity: Managing infrastructure across AWS and Google Cloud created significant operational overhead, reducing agility and increasing maintenance costs. The data team had to maintain expertise in both environments and coordinate data movement between clouds.
Architecture limitations: The existing setup couldn’t effectively support advanced analytics and AI initiatives. More critically, the launch of Yggdrasil’s Game in a Box solution required a modernized, scalable data environment capable of handling increased data volumes and enabling advanced analytics.
Scalability constraints: The architecture lacked the unified data foundation with open standards and automation required to scale efficiently. As data volumes grew, costs increased proportionally, and the team needed an environment designed for modern analytics at scale.
Solution overview
Yggdrasil worked with GOStack, an AWS APN partner, to design their new lakehouse architecture. The following diagram shows the high level overview of this architecture.
The combination of Amazon S3, Apache Iceberg, and Amazon Athena allowed Yggdrasil to move away from provisioned, always-on compute models. The Amazon Athena pay-per-query pricing charges only for data scanned, removing idle compute costs during off-peak periods. Internal cost modeling performed during the evaluation phase indicated that this architecture could reduce analytics system costs by 30–50% compared to compute-based warehouse pricing models of other solutions, particularly for bursty workloads driven by game launches, tournaments, and seasonal traffic. By adopting AWS-native analytics services, Yggdrasil reduced operational complexity through native integration with AWS Identity and Access Management (AWS IAM), Amazon EKS, and AWS Lambda, helping simplify security, governance, and automation across the analytics system.
The solution centers on a modern lakehouse architecture built on Amazon S3, which provides durable and cost-efficient storage for Iceberg tables in Apache Parquet format. Apache Iceberg table format provides ACID transactions, schema evolution, and time travel capabilities while maintaining an open standard. AWS Glue Data Catalog serves as the central technical metadata repository, while Amazon Athena acts as the serverless query engine used by dbt-athena and for ad-hoc data exploration. Amazon EMR runs Yggdrasil’s legacy Apache Spark application in a fully managed environment, and AWS Lake Formation provides centralized security and governance for data lakes, allowing fine-grained access control at database, table, column, and row levels.
The migration followed a phased approach:
Establish lakehouse foundation – Set up Apache Iceberg-based architecture with Amazon S3 with AWS Glue Data Catalog
Implement real-time data ingestion – Deploy Debezium connectors for real-time change data capture from EKS and Google Kubernetes Engine (GKE) clusters
Migrate processing pipelines – Re-system ETL pipelines using AWS Lambda, and legacy data applications re-systemed on Amazon EMR
Modernizing the transformation layer – Implement dbt with Amazon Athena for modular, reusable models
Enable governance – Configure AWS Lake Formation for comprehensive data governance
Establish lakehouse foundation
The first phase of the migration focused on building a solid foundation for the new data lakehouse architecture on AWS. The goal was to create a scalable, secure, and cost-efficient environment that could support analytical workloads with open data formats and serverless query capabilities.
GOStack provisioned an Amazon S3-based data lake as the central storage layer, providing virtually unlimited scalability and fine-grained cost control. This storage-compute separation enables teams to decouple ingestion, transformation, and analytics processes, with each component scaling independently using the most appropriate compute engine.
To establish dataset interoperability and discoverability, the team adopted AWS Glue Data Catalog as the unified metadata repository. The catalog stores Iceberg table definitions and makes schemas accessible across services such as Amazon Athena and Apache Spark workloads on Amazon EMR. Most datasets, both batch and streaming, are registered here, enabling consistent metadata visibility across the lakehouse.
The data is stored in Apache Iceberg tables on Amazon S3, selected for its open table format, ACID transaction support, and powerful schema evolution features. Yggdrasil required ACID transactions for consistent financial reporting and fraud detection, schema evolution to accommodate rapidly changing gaming data models, and time travel queries to align with regulatory audit requirements.
GOStack built a custom schema conversion and table registration service. This internal tool converts source-system Avro schemas into Iceberg table definitions and manages the creation and evolution of raw-layer tables. By controlling schema translation and table registration directly, the team makes sure that metadata stays consistent with the source systems and provides predictable, versioned schema evolution aligned with ingestion needs.
The initial setup made the following components:
Amazon S3 bucket structure design: Implemented a multi-layer layout (raw, curated, and analytics zones) aligned with data lifecycle best practices.
AWS Glue Data Catalog integration: Defined database and table schemas with partitioning strategies optimized for Athena performance.
Iceberg configuration: Enabled versioning and metadata retention policies to balance storage efficiency and query flexibility.
Security and compliance: Configured encryption at rest using AWS Key Management Service (AWS KMS), helped enforce access controls via AWS IAM and Lake Formation, and implemented Amazon S3 bucket policies following the principle of least privilege.
The redesign of the previous GCP setup helped deliver price-performance improvements. Yggdrasil reduced ingestion and processing costs by approximately 60% while also lowering operational overhead through a more direct, event-driven pipeline.
Implement real-time data ingestion
After establishing the lakehouse architecture, the next step focused on enabling real-time data ingestion from Yggdrasil’s operational databases into the raw data layer of the lakehouse. The objective was to capture and deliver transactional changes as they occur, making sure that downstream analytics and reporting reflect the most up-to-date information.
To achieve this, GOStack deployed Debezium Server Iceberg, an open-source project that integrates change data capture (CDC) directly with Apache Iceberg tables. It was deployed as Argo CD applications on Amazon EKS and used Argo’s GitOps-based model for reproducibility, scalability, and seamless rollouts.
This architecture provides an efficient ingestion pathway – streaming data changes directly from the source system’s outbox tables into the Apache Iceberg tables registered in the AWS Glue Data Catalog and physically stored on Amazon S3, bypassing the need for intermediate brokers or staging services. By writing data in the Iceberg table format, the ingestion layer maintained transactional guarantees and immediate query availability through Amazon Athena.
Because Yggdrasil’s source systems emitted outbox events containing Avro records, the team implemented a custom outbox-to-Avro transformation within Debezium. The outbox table stored two key components:
The Avro schema definition
The JSON-encoded payload of each record
The custom transformation module combined these elements into valid Avro records before persisting them into the target Iceberg tables. This approach preserved schema fidelity and verified compatibility with downstream processing tools.
To dynamically route incoming change events, the team leveraged Debezium’s event router configuration. Each record was routed to the appropriate Apache Iceberg table (backed by Amazon S3) based on topic and metadata rules, while table schemas and partitioning were governed on the AWS Glue side to maintain stability and alignment with the lakehouse’s data organization standards.
This setup helped deliver low-latency ingestion with end-to-end streaming from database outbox to S3-based Iceberg tables in near real time. The team managed operations end to end on Amazon EKS using Helm charts deployed via Argo CD in a GitOps model for fully declarative, version-controlled operations. ACID-compliant Iceberg writes verified that partially written data could not corrupt downstream analytics. The modular transformation logic allowed future expansion to new source systems or event formats without rearchitecting the ingestion pipeline.
This Debezium Server solution provides fast, real-time data ingestion. GOStack considers it an interim architecture. In the long term, the ingestion pipeline will evolve to use Amazon Managed Streaming for Apache Kafka (Amazon MSK) as the central event backbone. Debezium connectors will act as producers, publishing change events to Apache Kafka topics, while Apache Flink applications will consume, process, and write data into Iceberg tables.
This planned evolution toward a Kafka-based streaming architecture verifies Yggdrasil’s lakehouse remains not only scalable and cost-efficient today, but also future-ready – capable of supporting richer streaming analytics and broader data integration scenarios as the organization grows.
Migrate processing pipelines
Once real-time data ingestion was established, GOStack turned its focus to modernizing the data transformation layer. The goal was to simplify the transformation logic, reduce operational overhead, and unify the orchestration of analytical workloads within the new AWS-based lakehouse.
GOStack adopted a lift-and-shift approach for some of Yggdrasil’s data pipelines to support a fast and low-risk transition away from GCP. The lightweight Cloud Run functions that previously handled extraction tasks – pulling data from file shares, SharePoint, Google Sheets, and various third-party APIs – were re-implemented using AWS Lambda. These Lambda functions now integrate with the same external systems and write data directly into Iceberg tables.
For more complex processing, previous Apache Spark applications running on Dataproc were migrated to Amazon EMR with minimal code changes. This allowed it to preserve the existing transformation logic while benefiting from the managed scaling capabilities of EMR and improved cost control on AWS.
Over time, these processes will be gradually refactored and consolidated into containerized workflows on the EKS cluster, fully orchestrated by Argo Workflows. This phased migration allows Yggdrasil to move workloads to AWS quickly and decommission GCP resources sooner, while still leaving room for continuous improvement and modernization of the data system over time.
Finally, a lot of analytical transformations that previously lived as BigQuery stored procedures and scheduled queries, that were now rebuilt as modular dbt models executed with dbt-athena. This shift made transformation logic more transparent, maintainable, and version-controlled, improving both developer experience and long-term governance.
Modernizing the transformation layer
With the ingestion pipelines migrated to AWS, GOStack turned its focus to simplifying and modernizing Yggdrasil’s analytical transformations. Rather than replicating the previous stored-procedure–driven approach, the team rebuilt the transformation layer using dbt to help improve maintainability, lineage visibility, orchestration, and long-term governance.As part of this redesign, several data models were reshaped to fit the new lakehouse architecture. The most significant effort involved rewriting a critical Spark-based financial transformation into a set of SQL-driven dbt models. This shift not only aligned the logic with the lakehouse design but also removed the need for long-running Spark clusters, helping generate operational and cost savings.For the curated data layers, replacing the legacy warehouse, GOStack consolidated numerous scheduled queries and stored procedures into structured dbt models. This provides standardized, version-controlled transformations and clear lineage across the analytical stack.
Orchestration was simplified as well. Previously, coordination was split between Apache Airflow for Spark workloads and scheduled queries analytical transformations, creating operational friction and dependency risks. In the new architecture, Argo Workflows on Amazon EKS orchestrates dbt models centrally, consolidating the transformation logic within a single workflow engine. While most transformations still run on time-based schedules today, the system now supports event-driven execution through Argo Events, giving the opportunity to progressively adopt trigger-based workflows as the transformation layer evolves.
This unified orchestration framework can bring multiple benefits:
Consistency: One orchestration layer for data workflows across ingestion and transformation.
Automation: Event-driven dbt runs help remove manual scheduling and reduce operational overhead.
Scalability: Argo Workflows scales with the EKS cluster, handling concurrent dbt jobs seamlessly.
Observability: Centralized logging and workflow visualization help improve visibility into job dependencies and data freshness.
Through this transformation, Yggdrasil successfully unified its data lakes and warehouses into a modern lakehouse architecture, powered by open data formats, serverless query engines, and modular transformation logic. The move to dbt and Athena not only simplified operations but also helped pave the way for faster iteration, simpler governance, and greater developer productivity across the data environment.
Lakehouse performance optimizations
While performance tuning is an ongoing journey, as part of the transformation redesign, GOStack made few performance-oriented tweaks to make sure Athena queries can be fast and cost-efficient. The Apache Iceberg tables were stored in Parquet with ZSTD compression, providing strong read performance and reducing the amount of data scanned by Athena.
Partitioning strategies were also aligned to actual access patterns using Iceberg’s native partitioning. Raw data zones were partitioned by ingestion timestamp, enabling efficient incremental processing. Curated data used business-driven partition keys, such as player or game identifiers and date dimensions, to help optimize analytical queries. These designs made sure Athena could prune unneeded data and consistently scan only the relevant partitions.
Iceberg’s native partitioning features, including transforms such as bucketing and time slicing, replace traditional Hive partitioning patterns. Because Iceberg manages partitions internally in its metadata layer, not all Glue or Athena partition constructs apply. Relying on Iceberg’s native partitioning helps provide predictable pruning and consistent performance across the lakehouse without introducing legacy Hive behaviors.
To handle the high volume of small files produced by real-time ingestion, GOStack enabled AWS Glue Iceberg compaction. This automatically merges small Parquet files into larger segments, helping improve query performance and reduce metadata overhead without manual intervention.
Enable governance
The team adopted AWS Lake Formation as the primary governance layer for the curated zone of the lakehouse, leveraging Lake Formation hybrid access mode to manage fine-grained permissions alongside existing IAM-based access patterns. This hybrid mode provides an incremental and flexible pathway to adopt Lake Formation without forcing a full migration of legacy permissions or internal pipeline roles, making it an ideal fit for Yggdrasil’s phased modernization strategy.
Lake Formation offers centralized authorization, supporting database, table, column, and, critically for Yggdrasil, row-level permissions. These capabilities are essential because of the company’s multi-tenant operating model:
Game development partners require access to data and reports pertaining only to their own games, facilitating both security and compliance alignment with partner agreements.
iGaming operators integrating with Yggdrasil’s system must receive operational and financial insights exclusively for their own data, enforced automatically through reporting tools backed by curated Iceberg tables.
With Lake Formation hybrid access mode, tenant-specific row-level access policies are consistently enforced across Amazon Athena, AWS Glue, and Amazon EMR, without introducing breaking changes to existing IAM-based workloads. This allowed Yggdrasil to implement strong governance for external consumers while keeping internal operations stable and predictable.
Internally, Lake Formation is also used to grant the Analytics team and BI tools targeted access to curated datasets, straightforward but centrally managed to maintain consistency and reduce administrative overhead.
For ingestion and transformation workloads, the team continues to rely on IAM roles and policies. Services such as Debezium, dbt, and Argo Workflows require broad but controlled access to raw and intermediate storage layers, and IAM provides a straightforward, least-privilege mechanism for granting those permissions without involving Lake Formation in the internal pipeline path.
By adopting Lake Formation in hybrid access mode and combining it with IAM for internal services, Yggdrasil established a governance model that can balance strong security with operational flexibility – enabling the lakehouse to scale securely as the business grows.
Results and business impact
The new lakehouse, built on Amazon Athena, Amazon S3, and AWS Glue Data Catalog, now underpins advanced analytics and AI/ML use cases such as player behavior modeling, predictive game recommendations, and fraud detection.
The optimized lakehouse design allows Yggdrasil to rapidly onboard new analytics workloads and business use cases, helping deliver measurable outcomes:
Reduced operational complexity through consolidation on AWS analytics services
Cost optimization with a 60% reduction in data processing costs
Improved data freshness with 75% lower latency for analytics results (from 2 hours to 30 minutes)
Enhanced governance using the AWS Lake Formation fine-grained controls
Future-ready architecture leveraging open formats and serverless analytics
Conclusion
Yggdrasil Gaming’s migration journey illustrates how organizations can successfully transition from proprietary analytics systems to an open, flexible lakehouse architecture. By following a phased approach guided by AWS Well-Architected Framework principles, Yggdrasil maintained business continuity while establishing a modern foundation for their data needs.
Based on this experience, several lessons emerged to help guide your own move to an AWS-based lakehouse:
Assess your current state: Identify pain points in your existing data architecture and establish clear objectives for modernization.
Start small: Begin with a pilot project using AWS analytics services to validate the lakehouse approach for your specific use cases.
Design for openness: Leverage open table formats like Apache Iceberg to maintain flexibility and avoid vendor lock-in.
Implement gradually: Follow a phased migration strategy similar to Yggdrasil’s, prioritizing high-value workloads.
Optimize continuously: Use performance tuning techniques for Amazon Athena to help maximize efficiency and minimize costs.
Organizations running Apache Kafka as their streaming platform need comprehensive monitoring to maintain reliable operations. Without proper visibility into broker health, resource utilization, and data flow metrics, teams risk service disruptions, data loss, and degraded performance that can impact critical business operations. Effective monitoring and alerting are essential to detect anomalies early, from high system load to connectivity issues, enabling teams to take preventive action before problems affect production workloads.
Amazon Managed Streaming for Apache Kafka (Amazon MSK) addresses these monitoring challenges by publishing detailed metrics to Amazon CloudWatch. The service emits metrics at 1-minute intervals for provisioned (Standard) clusters, with flexible monitoring levels (DEFAULT, PER_BROKER, PER_TOPIC_PER_BROKER, or PER_TOPIC_PER_PARTITION) to control granularity and cost. At the DEFAULT level (free), cluster-level metrics are available; higher levels (paid) expose broker-level, per-topic and per-partition metrics.
In this post, I show you how to implement effective monitoring for your MSK clusters using Amazon CloudWatch. You’ll learn how to track critical metrics like broker health, resource utilization, and consumer lag, and set up automated alerts to prevent operational issues. By following these practices, you can work to improve streaming operations reliability, optimize resource usage, and support high availability for your mission-critical applications.
Key metrics to monitor
This article groups important Amazon MSK metrics into logical categories. For each, we highlight key metrics and what they indicate:
Broker Health and Cluster Availability:
ActiveControllerCount is a cluster-level metric where each broker reports whether it’s the active controller (1) or not (0). In a healthy cluster, exactly one broker serves as the active controller at any time. When viewing this metric with the average statistic, the value equals 1 divided by the number of brokers. For example, a 3-broker cluster shows 0.33 (1/3). Set CloudWatch alarm thresholds accordingly—for 6 brokers, alert if average falls below 0.166(1/6). When using the sum statistic, the value should always be 1, indicating one active controller regardless of cluster size. If the sum differs from 1, a controller election is in progress—typically during maintenance activities, configuration changes, or rolling restarts. Note: For a KRaft-based clusters, the ActiveControllerCount is only exposed on dedicated controller endpoints so the sample count is 3 and only controller will report value of 1. Thus, the average is always 0.33 no matter how many brokers there are in the cluster. To monitor the broker health for Kraft-based clusters, check LeaderCount metric. If a broker is not emitting any metric, then it’s a good indication that broker might be unhealthy.
OfflinePartitionsCount (cluster): Number of partitions with no active leader. Non-zero values mean data is temporarily unavailable or unwritable. Trigger alerts if it rises above 0.
UnderReplicatedPartitions (per broker): Number of partitions where not all replicas are caught up. This should stay at 0 under normal conditions. Spikes indicate traffic exceeds capacity or replication lag; sustained values often mean a configuration/ACL issue. Refer to Troubleshoot your Amazon MSK cluster
UnderMinIsrPartitionCount (per broker): Partitions below the minimum in-sync replica (ISR) count. A non-zero value means potential data loss risk if brokers fail. Monitor to ensure replication is healthy. Refer to Custom configurations
GlobalPartitionCount (cluster): Total number of partitions across all topics (leaders only). Useful for capacity planning and sanity checks.
CPU: Total broker CPU utilization is defined as CpuUser + CpuSystem. Best practice is to keep average CPU utilization under 60% . Set alarms on the sum of user+system to detect overload.
CPUCreditBalance / CPUCreditUsage (per broker): For burstable instance types(T3), tracks earned/spent CPU credits. A declining credit balance or high credit usage warns that the instance may be CPU-starved.
Memory: MemoryUsed, MemoryFree (per broker) show RAM usage. Critically, HeapMemoryAfterGC (per broker) reports JVM heap usage (%) after garbage collection. AWS recommends alerting if HeapMemoryAfterGC exceeds 60%, to avoid out-of-memory issues.
Disk: Kafka brokers use attached EBS storage for topic data. Monitor KafkaDataLogsDiskUsed (per broker) – percentage of disk used by message logs. Best practice: alarm when data log usage exceeds 85%. Also track RootDiskUsed: the percentage of the root disk used by the broker.
EBS I/O: Volume metrics (per broker) such as VolumeQueueLength, VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes indicate I/O latency and throughput. Rising queue lengths or latency (such as VolumeTotalReadTime) suggest disk contention.
Network: Basic network stats per broker include NetworkRxPackets, NetworkTxPackets, and errors/drop counts (NetworkRxErrors, NetworkTxErrors, NetworkRxDropped, NetworkTxDropped). Unexpected errors or drops can indicate network issues.
Topic and Partition Activity:
Throughput: BytesInPerSec and BytesOutPerSec measure inbound/outbound data rates per broker or per topic. Sustained drops can signal lost producers/consumers; spikes may require scaling.
Replication Traffic: ReplicationBytesInPerSec/ReplicationBytesOutPerSec (per topic) show inter-broker replication volume.
Consumer Lag: Consumer lag metrics quantify the difference between the latest data written to your topics and the data read by your applications. Amazon MSK provides the following consumer-lag metrics, which you can get through Amazon CloudWatch or through open monitoring with Prometheus: EstimatedMaxTimeLag, EstimatedTimeLag, MaxOffsetLag, OffsetLag, and SumOffsetLag. For information about these metrics, see Amazon MSK metrics for monitoring Standard brokers with CloudWatch.
Client Connections :
ConnectionCount (per broker): Total active connections (clients + inter-broker). Sudden drops or sustained high counts (hitting limits) merit attention.
ClientConnectionCount (per broker, with auth filter): Active authenticated client connections.
ConnectionCreationRate / ConnectionCloseRate (per broker): New or closed connections per second. Spikes in connection churn may indicate client issues.
Authentication: IAMNumberOfConnectionRequests and IAMTooManyConnections (per broker) show IAM auth request rates and throttle breaches (limit of 100 simultaneous connections).
Network Bandwidth Metrics:
TrafficShaping > 0 (any throttling) metric serves as your primary warning signal. When this value exceeds zero, your MSK cluster is experiencing network throttling at the EC2 layer, with packets being dropped or queued due to exceeded allocations. This throttling manifests as reduced throughput, increased latency, and potential network errors that impact both producer and consumer performance. TrafficShaping issues stem from two possible bandwidth limitations: BwInAllowanceExceeded & BwOutAllowanceExceeded :
BwInAllowanceExceeded tracks when inbound aggregate bandwidth surpasses broker maximums.
BwOutAllowanceExceeded monitors when outbound aggregate bandwidth exceeds limits. Both BwInAllowanceExceeded and BwOutAllowanceExceeded metrics directly contribute to overall network throttling events.
Other Operational Metrics:
Thread Pools: RequestHandlerAvgIdlePercent, NetworkProcessorAvgIdlePercent (per broker) show how busy Kafka’s internal thread pools are. Consistently low idle (%) can indicate bottlenecks.
ZooKeeper: For ZooKeeper-based MSK clusters, ZooKeeperRequestLatencyMsMean and ZooKeeperSessionState reflect ZK performance (for older Kafka versions that use Zookeeper). For ZooKeeperSessionState, anything other than 1 for 5-10 mins should be alarming as there can be chances broker has an issue or zookeeper is not able to connect to brokers due to some intermittent network issue.
Tiered Storage: For clusters with tiered storage enabled, Amazon MSK provides metrics like RemoteFetchBytesPerSec, RemoteCopyBytesPerSec, RemoteLogSizeBytes, and related error/queue metrics. These track offloading to remote storage.
Intelligent rebalancing metrics: For MSK Provisioned clusters using Express brokers, Amazon MSK provides two key metrics to monitor rebalancing operations: RebalanceInProgress and UnderProvisioned metrics. See Monitor Intelligent rebalancing metrics
By grouping metrics into these categories, you can build dashboards and alerts that comprehensively cover Amazon MSK health and performance. Amazon CloudWatch also provides automatic dashboards for Amazon MSK.
Let’s take a quick look on how to access CloudWatch automatic dashboard. In the AWS Console, go to the CloudWatch service. When in the CloudWatch console, select Dashboards. Open the Automatic dashboard tab and search for MSK in the Filter Bar.
These dashboards offer per-configured visualizations of key metrics, enabling quick insights into the health and performance of your MSK clusters.
Recommended CloudWatch alarms
Setting alarms on key metrics helps catch issues early. Detecting issues early is crucial in streaming applications where every second counts. A single failing broker can trigger a chain reaction – halting data ingestion, backing up upstream systems, and breaking downstream applications. This can quickly escalate from delayed order processing to lost revenue. Proactive monitoring helps catch and fix problems before they impact your business operations. Based on AWS best practices and experience, consider alarms such as:
Metric (Dimension)
Alarm Condition
Rationale
ActiveControllerCount (cluster)
≠ 1 (count)
Only one active controller should exist. Deviation implies cluster instability.
CPU Utilization (Sum(CPUUser+CPUSystem), per broker)
> 60% (average) for 5+ mins
Helps maintain headroom for broker load and maintenance. High CPU may slow processing as outlined in the MSK best practices documentation
HeapMemoryAfterGC (broker)
> 60% (percentage)
Indicates Kafka heap is filling up. Helps prevent OOM by alerting early.
KafkaDataLogsDiskUsed (broker)
≥ 85% (percent)
Warns that disk is nearly full. Helps prevent data loss by providing time for scaling or cleanup.
OfflinePartitionsCount (cluster)
> 0 (count)
Any offline partition means unavailable data. Immediate investigation needed.
UnderReplicatedPartitions (broker)
> 0 (count)
No replicas lagging under healthy conditions. Spikes or sustained lag can indicate overload or ACL misconfiguration.
UnderMinIsrPartitionCount (broker)
> 0 (count)
There must be topics with partitions that have either less in-sync replicas than the min.insync.replicas setting or with RF=MinISR. To find these topics whose partitions are under replicated, use command: <path-to-your-kafka-installation>/bin/kafka-topics.sh –bootstrap-server <bootstrap-server:port> —command-config client.properties –describe –under-min-isr-partitions
ConnectionCount (broker)
Sudden drop (e.g. < 90% of baseline) or spike above high threshold
Detect client connectivity issues or connection floods. Unexpected drops may mean a broker is unreachable. Refer to Amazon MSK Standard broker quota
CPUCreditBalance (for T3 broker)
< some low threshold (e.g. 10 credits)
For burstable instances, alerts when credits are nearly exhausted, which degrades performance.
VolumeQueueLength (broker)
> 0 (sustained) or rising
Indicates I/O operations are queuing, possible disk bottleneck.
NetworkRxErrors/TxErrors (broker)
> 0 (count)
Any network errors can cause packet loss or disconnections.
IAMTooManyConnections (broker)
> 0 (count)
Exceeding IAM connection limit (100) blocks new connections.
Consumer Lag (MaxOffsetLag or SumOffsetLag) (per consumer-group/topic)
> threshold (depends on SLAs, e.g. growing beyond expected)
Alerts on slow consumers so you can scale consumers or investigate backlogs.
TrafficShaping
> 0 (any throttling)
This is an indication that brokers are exceeding their allocated network bandwidth.
These are illustrative thresholds; adjust them for your workload and SLAs. The remaining metrics listed in the CloudWatch metrics for Standard and Express brokers documentation are susceptible to downstream impact from anomalies in the primary metrics above. It is recommended to enable CloudWatch alarms on a single test cluster first to validate thresholds before extending coverage across your MSK fleet.
Conclusion
In this post, we covered the important CloudWatch metrics and alarms for monitoring Amazon MSK clusters effectively. By implementing these recommended alarms, you can proactively detect and respond to potential issues before they impact your Kafka workloads. To learn more about Amazon MSK monitoring, refer to the Amazon MSK Monitoring Best Practices documentation or explore our Amazon MSK Workshops hands-on experience.
The Finnish Transport and Communications Agency (Traficom) Cyber Security Centre published PiTuKri, which consists of 52 criteria that provide guidance across 11 domains for assessing the security of cloud service providers.
An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to demonstrate adherence with PiTuKri requirements. This attestation demonstrates the AWS commitment to meet security expectations for cloud service providers set by Traficom.
The latest report covers a 12-month period from October 1, 2024 to September 30, 2025. AWS has added the following five services to the current PiTuKri scope:
Security and compliance is a shared responsibility between AWS and the customer. When customers move their computer systems and data to the cloud, security responsibilities are shared between the customer and the cloud service provider. For more information, see the AWS Shared Security Responsibility Model.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below
This
404 Media article looks at how the US Customs and Border Protection
agency (CBP) is using location data from phones to track the location of
people of interest.
Specifically, CBP says the data was in part sourced via real-time
bidding, or RTB. Whenever an advertisement is displayed inside an
app, a near instantaneous bidding process happens with companies
vying to have their advert served to a certain demographic. A side
effect of this is that surveillance firms, or rogue advertising
companies working on their behalf, can observe this process and
siphon information about mobile phones, including their
location. All of this is essentially invisible to an ordinary phone
user, but happens constantly.
We should note that the minimal advertising shown on LWN is not delivered
via this bidding system.
AWS and cloud computing changed how businesses operate. Organizations now store, process, and manage data in the cloud at scale while treating compute resources as a utility. Cloud architecture requires weighing trade-offs to find solutions that fit your specific requirements. Failing to follow best practices in cloud architecture design can lead to undesirable results and hidden costs, such as the cost of security and availability events.
The impact of architectural decisions extends beyond technical considerations to include business reputation, regulatory compliance, and market opportunities. According to research from IBM and Ponemon Institute, cloud misconfiguration risk has emerged as a significant security consideration over the past decade, reflecting the growing importance of cloud infrastructure. The report highlights how AI adoption is advancing rapidly, creating new opportunities to strengthen security and governance frameworks. The findings indicate that organizations benefit most when AI systems are implemented with robust architecture and governance practices.
Prioritize cloud architecture best practices as you move to the cloud. In this post, we discuss how following the AWS Cloud Adoption Framework (AWS CAF) and AWS Well-Architected Framework can help reduce these risks through proper implementation of AWS guidance and best practices while taking into consideration the practical challenges organizations face in implementing these best practices, including resource constraints, evaluating trade-offs and competing business priorities.
Background
The AWS CAF helps you identify transformation opportunities, evaluate your cloud readiness, and build your transformation roadmap using AWS best practices.
The AWS Well-Architected Framework helps cloud architects build secure, high-performing, resilient, efficient, and sustainable infrastructures for their applications. It provides guidance based on six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. The AWS Well-Architected Framework can help you learn the strategies and best practices for architecting workloads in the cloud, measure your architecture against these best practices, and improve your architecture through remediation of any identified issues. High risk issues (HRIs) identified in the AWS Well-Architected Tool are architectural and operational choices that AWS has found might have a significant negative impact to a customer’s business. These HRIs might affect organizational operations, assets, and individuals. Medium risk issues (MRIs) might also negatively impact business, but to a lesser extent. These issues are based on customer responses in the AWS Well-Architected Tool. Low risk issues (LRIs) require ongoing monitoring and evaluation. The cloud environment is dynamic, and what is a low risk today might become a higher risk tomorrow due to changes in your architecture, applications, or the threat landscape. The key is to constantly review and improve your cloud architecture to maintain a low-risk profile and maximize the benefits of the AWS cloud.
AWS Well-Architected Lenses extend the guidance offered by the AWS Well-Architected Framework to specific industry and technology domains, such as generative AI. Generative AI has rapidly evolved from experimental projects to mission-critical enterprise applications. However, many organizations face a significant challenge: successfully transitioning promising generative AI prototypes into robust production systems that can reliably deliver business value at scale. As your organization explores AI opportunities, architecting secure, compliant, and cost-effective solutions based on comprehensive well-architected guidance becomes critical for production success. The AWS Generative AI Lens provides architectural best practices for designing and operating generative AI workloads on AWS.
Let’s examine three areas where unoptimized architecture creates hidden costs: security, availability, and resource efficiency.
The hidden price of unoptimized cloud architecture: Security, availability, and cost
Cloud security protects your assets and creates competitive advantages. Robust security architecture reduces the risk of incidents that could affect business goals, revenue, and reputation. It helps protect data and intellectual property and leads to stronger compliance with various regulatory requirements. This strong security posture directly improves business opportunities and reduces the risk of hidden costs associated with security incidents.
Well-designed cloud architecture helps provide reliability of your services and reduces the risk of disruptions and downtime. Some common costs associated with downtime include lost productivity and revenue and failure to meet Service Level Agreements (SLAs) for your customers. Availability disruptions can lead to lost productivity because employees can’t access the systems and tools they need to perform their jobs. These concerns might directly affect business outcomes and revenue. Failure to meet SLA requirements could also lead to customer dissatisfaction in addition to several costs like penalties, hiring external consultants to fix the problem, or implementing new infrastructure.
Cloud providers offer a wide array of services, including storage, CPU, and memory resources. Over-provisioning cloud resources to avoid performance issues often leads to unnecessary costs. Although it might mitigate the risk of hardware limitations impacting workload performance, overallocation comes with its own financial drawbacks. Resource demand varies significantly across different workloads. Many applications don’t require continuous operation around the clock. Some might be dormant on weekends, whereas others might only be active for a few days each month. Certain workloads might even follow seasonal patterns, with fluctuating resource needs throughout the year. Understanding these diverse usage patterns is crucial for efficient resource allocation and cost management in cloud environments.
How the AWS Well-Architected Framework helps you avoid unnecessary cost
The AWS Well-Architected Framework provides you with a robust set of guidelines for building secure, reliable, and cost-efficient cloud infrastructures. By following the framework’s best practices and architectural patterns, organizations can minimize the risks and costs associated with security events, availability disruptions, and inefficient resource utilization, leading to more successful and profitable cloud deployments.
Reducing security risks with the AWS Well-Architected Framework
The AWS Well-Architected Framework emphasizes security as one of its six pillars. By following the best practices outlined in the framework, you can improve security posture of your workloads and reduce the risk of incidents and the potential hidden cost associated with them. The following are some security best practices:
Identity and access management – The framework encourages implementing strong identity and access management practices, such as the principle of least privilege, multi-factor authentication, and regular auditing of access policies, which help prevent unauthorized access to cloud resources.
Data protection – The framework promotes that customers use data encryption at rest and in transit, making sure sensitive information remains secure and reducing the risk of unauthorized or unintended access. The framework also recommends building mechanisms to keep people away from data.
Infrastructure protection – Following the framework’s guidelines, you can implement network segmentation, intrusion detection and prevention systems, and automated patch management to protect your cloud infrastructure from potential events.
Monitoring and incident response – The framework recommends continuous monitoring of your AWS environments, automated security alerts, and effective incident response plans to quickly detect and mitigate potential security events.
Minimizing downtime with the AWS Well-Architected Framework
Fault tolerance and high availability – The framework encourages the design of fault-tolerant and highly available systems, using techniques such as redundancy, automatic failover, and distributed systems architecture, to provide continuous operation even during component failures or outages.
Scalability – The framework recommends designing systems to automatically scale based on demand, so businesses can handle peak loads and maintain optimal performance.
Backup and disaster recovery – The framework suggests implementing regular data backups and robust disaster recovery plans to recover quickly from data loss or infrastructure failures. Recommendations include regular testing of backup and recovery plans.
Monitoring and performance management – The framework encourages monitoring and observability of system performance and the use of proactive performance management techniques to identify and resolve potential issues before they result in downtime.
Optimizing operational costs with the AWS Well-Architected Framework
Resource efficiency – The framework promotes right-sizing and consolidation of cloud resources, so businesses only pay for the resources they need.
Cost-aware architecture – The framework encourages you to consider the cost implications of your design choices, helping you identify cost-effective solutions without compromising performance or security.
Monitoring and cost management – The framework recommends regular monitoring and analysis of cloud spending, helping you identify and eliminate wasteful expenses and optimize your cloud costs.
Understand pricing models – The framework recommends understanding and taking advantage of a variety of cloud pricing models designed to help users optimize costs based on their specific needs. These include On-Demand, Reserved Instances, Savings Plans, and Spot Instances, each with its own advantages and ideal use cases. Understanding these models and their differences is crucial for effective cost optimization in the AWS Cloud.
Conclusion
Organizations constantly face the possibility of service disruptions whether they result from human error, misconfigured systems, natural disasters, infrastructure issues, or cyberattacks. Business, technology, and security leaders can reduce risks from service disruptions and unoptimized cloud architecture by improving their defenses, allocating resources more effectively, and building resilience into their systems. Effective cloud design and optimization delivers more than just cost savings, such as:
Faster innovation through reinvestment of saved resources
Enhanced security and operational efficiency
Improved ability to scale and adapt to business needs
Better customer experiences and faster time-to-market
The ability to make informed architecture and design decisions by balancing trade-offs across Well-Architected pillars.
Find automated ways to handle failures or sudden spikes in demand to prevent disruptions and latency issues before they affect your end users.
To help you accelerate your cloud optimization efforts, AWS provides several tools and resources:
At AWS, we’re dedicated to helping you optimize your cloud journey. By implementing these strategies and best practices described in the AWS CAF and AWS Well-Architected Framework, you can unlock the full potential of the cloud, driving innovation and growth while maintaining security and operational excellence.
Start by running the AWS Well-Architected Framework Review on your workloads. Consider using AWS’s extensive network of Solutions Architects, technical account managers, and AWS Well-Architected Partners, who can help conduct AWS CAF reviews and Well-Architected Framework Reviews. This expertise, combined with AWS’s elastic infrastructure, can help you scale efficiently and build a solid cloud foundation for sustainable growth in the digital age.
One of the contradictions of the modern open-source movement is
that projects which respect user freedoms often rely on proprietary
tools that do not: communities often turn to non-free software for
code hosting, communication, and more. At Configuration Management
Camp (CfgMgmtCamp) 2026, Jan Ainali spoke
about the need for open-source projects to adopt open tools;
he hoped to persuade new and mature projects to switch to open
alternatives, even if just one tool, to reduce their dependencies on
tech giants and support community-driven infrastructure.
Matthew Garrett examines
the factors that go into the decision about whether to install a
firmware update or not.
I trust my CPU vendor. I don’t trust my CPU vendor because I want
to, I trust my CPU vendor because I have no choice. I don’t think
it’s likely that my CPU vendor has designed a CPU that identifies
when I’m generating cryptographic keys and biases the RNG output so
my keys are significantly weaker than they look, but it’s not
literally impossible. I generate keys on it anyway, because what
choice do I have? At some point I will buy a new laptop because
Electron will no longer fit in 32GB of RAM and I will have to make
the same affirmation of trust, because the alternative is that I
just don’t have a computer.
Security updates have been issued by AlmaLinux (containernetworking-plugins, gnutls, kernel, libpng, and skopeo), Debian (firefox-esr, php8.2, and spip), Fedora (erlang and python-pillow), Red Hat (go-toolset:rhel8, golang, and yggdrasil), SUSE (cups, fluidsynth, gvfs, haproxy, libsoup, libsoup-3_0-0, mozilla-nss, python-azure-core, and shim), and Ubuntu (git and mailman).
For years, the cybersecurity industry has suffered from a “data gravity” problem. Security teams are buried under billions of rows of telemetry, yet they remain starved for actionable insights.
A Threat Intelligence Platform (TIP) is a centralized security system that collects, aggregates, and organizes data about known and emerging cyber threats. It serves as the vital connective tissue between raw telemetry and active defense.
The underlying architecture of Cloudflare’s Threat Intelligence Platform sets it apart from other solutions. We have evolved our Threat Intelligence Platform to eliminate the need for complex ETL (Extract, Transform, Load) pipelines by using a sharded, SQLite-backed architecture. By running GraphQL directly on the edge, security teams can now visualize and automate threat response in real time. Instead of one massive database, we distribute Threat Events across thousands of logical shards — meaning sub-second query latency, even when aggregating millions of events across global datasets.
By unifying our global telemetry with the manual investigations performed by our analysts, our intelligence platform creates a single source of truth that allows security teams to move from observing a threat to preemptively blocking it across the Cloudflare network. We believe your intelligence platform shouldn’t just tell you that something is “bad”; it should tell you why it’s happening, who is behind it, and automatically prevent it from happening again.
In this post, we’ll explore some of the features that make the Cloudforce One experience powerful and effective.
Why are we launching a Threat Intelligence Platform?
When we announced the Cloudforce One team in 2022, we quickly realized that tracking adversary infrastructure required tools that didn’t yet exist. So we built our own.
What began as an internal project has evolved into a cloud-first, agentic-capable Threat Intelligence Platform (TIP) designed for our users. We have moved from conceptualizing “observable” events across various datasets to building a platform that maps the entire lifecycle of a threat. Today, the Cloudflare TIP allows you to correlate actors to malware, link cases to indicators, and store everything in one unified ecosystem.
We are moving beyond simple data access to provide a fully integrated, visual, and automated command center for your SOC. Our motivation behind building this TIP stems from the core tenets of effective threat intelligence: relevance, accuracy, and actionability. We needed a highly extensible system that can integrate multiple datasets, support multi-tenancy, enable group-based and tenant-to-tenant sharing, and scale efficiently on the edge.
By using Cloudflare Workers, we’ve built a next-generation developer stack that ensures rapid innovation. We can now synthesize millions of threat events into real-time graphs and diagrams and instantly answer the critical questions: What happened? And what does it mean?
Because our GraphQL endpoint is built in the same Worker that is driving the Threat Events platform, your data is always live and there are no delays between ingestion and availability. Whether you are applying complex analysis or drilling down into a specific event, the platform responds instantly. As Workers runtime evolves, our TIP inherits these optimizations automatically. For example, Smart Placement ensures our query-handling Workers are physically located near the Durable Objects they are fanning out to, minimizing tail latency. And the ability to use larger CPU limits and Hyperdrive allows us to maintain higher performance connection pooling directly at the edge, rather than backhauling the logic to a single datacenter.
Beyond the SIEM: historical context and intelligence enrichment
While a SIEM (Security Information and Event Management) is designed for real-time log aggregation and immediate alerting, it often lacks the specialized schema and long-term retention needed for deep adversary tracking. Our TIP fills this gap by acting as a dedicated intelligence layer that enriches raw logs with historical actor patterns. The goal of our platform isn’t to replace a SIEM, but to complement it. Our TIP provides the long-term, structured storage for Threat Events — retained and indexed at the edge — needed to bridge the gap between technical telemetry and executive insight.
The Cloudflare Managed Defense and Threat Intelligence Platform are designed to operate in a symbiotic loop, creating a powerful force multiplier for threat detection and response. By integrating the TIP directly with the SOC, analysts gain immediate, rich context for any alert or event. Instead of just seeing an anomalous IP address or a suspicious file hash, the SOC team can instantly see its history, its association with known threat actors, its role in broader campaigns, and its risk score as determined by the TIP’s analytics. This immediate context eliminates time-consuming manual research and enables faster, more accurate decision-making.
Conversely, as the intel analyst team investigates incidents and hunts for new threats, their findings become a crucial source of new intelligence.
Newly discovered indicators of compromise (IOCs) are fed back into the TIP, enriching the platform for all users and enhancing its automated defenses. This continuous feedback loop ensures the intelligence is always current and grounded in real-world observations, providing unparalleled visibility into the threat landscape and allowing security teams to shift from a reactive to a proactive defense posture.
An architecture that eliminates bottlenecks
To ensure every piece of Cloudforce One telemetry is actionable, we had to solve a fundamental storage problem: how do you provide low-latency, complex queries over billions of events without the overhead of a traditional centralized database?
We chose a sharded architecture built on SQLite backed Durable Objects. By distributing Threat Events across this high-cardinality fleet of storage units, we ensure that no single database becomes a point of contention during high-volume ingestion. Each shard is a Durable Object, providing a consistent, transactional interface to its own private SQLite database.
This architecture allows us to use the full Cloudflare developer stack. We use Cloudflare Queues to ingest and distribute incoming telemetry asynchronously, ensuring that high-volume attack spikes don’t saturate our write throughput. Once ingested, data is stored in R2 for long-term retention, while the “hot” index remains in the Durable Object’s SQLite storage for instant retrieval.
Parallel execution at the edge
The real power of this approach is visible during a search. When a user queries our GraphQL endpoint — which also runs in a Worker — the platform doesn’t query a single table. Instead, it fans out the request to multiple Durable Objects in parallel. Because Durable Objects are distributed across our global network, we can aggregate results with minimal latency. After we verify the user’s permissions and eliminate the shards that would not contain our events (by date), here is a simplified look at how the Worker handles a multi-shard fan-out:
// A conceptual look at fanning out a query to multiple shards
async function fetchFromShards(shards, query) {
const promises = shards.map(shardId => {
const stub = TELEMETRY_DO.get(shardId);
return stub.querySQLite(query); // Calling the DO's storage method
});
// Parallel execution across the Cloudflare network
const results = await Promise.all(promises);
return results.flat();
}
This parallelism ensures a fluid experience whether you are auditing a single dataset for a year of history or synthesizing a month of activity across every dataset in your account. By moving the compute — the SQL execution — to where the data lives, we eliminate the bottleneck of a single, monolithic database.
Visualize the Adversary with dynamic graphs and diagrams
Numbers on a spreadsheet don’t tell stories; patterns do. We’ve introduced dynamic visualizations to help you “see” the threat landscape.
Sankey Diagrams to trace the flow of attacks from origin to target, identifying which regions are being hit hardest and where the infrastructure resides.
Industry and dataset distribution of attacks, for users to instantly pivot your view to see if a specific campaign is targeting your sector (e.g., Finance or Retail) or if it’s a broad-spectrum commodity attack.
Correlating telemetry through attribute mapping
A single indicator, such as an IP address, provides limited utility without historical and relational context. We have structured our Threat Insights to act as a pivot point, allowing you to correlate disparate threat events across multiple datasets into a single, cohesive campaign or exploit.
Instead of manual cross-referencing, the platform automatically maps our internal actor nomenclature to recognized industry aliases — such as linking our internal tracking to “Fancy Bear” or “APT28.” This ensures that your local environment’s telemetry is instantly interoperable with broader global research and threat intelligence feeds.
Search, filters, and alerts
Saved configurations and real-time notifications help you get notified the second our telemetry matches your custom filters, allowing you to react at the speed of the edge. Effective threat hunting requires the ability to filter global telemetry by specific technical attributes. The platform supports high-cardinality searches across our entire dataset — including IP addresses, file hashes, domains, and JA3 fingerprints — with results typically returned in seconds.
To move beyond manual searching, you can persist these query parameters as saved configurations. These configurations act as triggers for our real-time notification engine; when new incoming telemetry matches your defined filters, the platform pushes an alert to your configured endpoints. This transition from pull-based searching to push-based alerting ensures that your security stack can respond to matches as soon as they are ingested by our global network.
Automated rules and STIX2 Exports
Intelligence is only “actionable” if it results in a reduced attack surface. We’ve built the TIP to handle the translation between raw telemetry and security enforcement automatically.
For organizations using third-party or in-house SIEM or SOAR platforms, interoperability is a requirement. However, mapping disparate internal data schemas to the STIX2 (Structured Threat Information eXpression) standard is traditionally a high-latency ETL task. We’ve moved this translation to the edge.
When a user requests a STIX2 export, a Worker dynamically maps our internal SQLite records to the STIX2 JSON schema. This means we are first converting raw IP addresses, file hashes, and domain names into standardized STIX cyber observables. Then we define relationship objects using our platform’s internal mapping to link indicator objects to threat-actor or malware objects, preserving the context of the investigation. Finally, we automatically manage the modified and created timestamps in UTC to ensure your downstream tools can track the evolution of the threat.
Instant Protection via the Firewall API
Beyond exports, the platform allows you to close the loop between discovery and defense. When you identify a malicious pattern in a Sankey diagram or a specific Actor campaign, you can generate a security rule with one click.
Under the hood, the TIP interacts directly with the Cloudflare Firewall Rules API. It takes the filtered attributes of your investigation (e.g., a specific JA3 fingerprint combined with a list of known malicious ASNs) and compiles them into a wire-protocol rule that is deployed across our global network in seconds.
Human-in-the-loop intelligence
While automation handles the bulk of telemetry, the most complex threats require human intuition. We’ve integrated a Requests for Information (RFI) Portal directly into the platform, allowing users to task Cloudforce One analysts with deep-dive investigations.
From a technical perspective, the RFI system isn’t just a ticketing portal; it’s a data-enrichment pipeline. When a subscriber uses a number of “tokens” to initiate a request, the workflow triggers a series of events:
The RFI Worker pulls the specific Threat Event IDs related to the query from the sharded SQLite storage, packaging the relevant telemetry for the analyst
Cloudforce One analysts use an internal version of the TIP to perform reverse engineering or pivot across global datasets
Once the investigation is complete, the findings (new IOCs, actor attributions, or campaign notes) are written back into our global intelligence feed
This ensures that the “human” insight doesn’t just sit in a PDF report. Instead, the resulting metadata is pushed back to the edge as a threat event where relevant, where it can be used by the WAF or Firewall rules you’ve already configured. We’ve moved from a static “report” model to a dynamic “intel-as-code” model, where human analysis directly improves the platform’s automated detection logic in real time.
From data management to active hunting
The shift from managing ETL pipelines to active threat hunting isn’t just about a new interface but about where the compute happens. By moving the storage, aggregation, and visualization layers to the Cloudflare global network, we’ve removed the “data gravity” that typically slows down a SOC. Defenders no longer need to wait for logs to sync to a central repository before they can ask, “Is this IP related to a known campaign?” The answer is now available at the edge, in the same environment where the traffic is being filtered.
To ensure this intelligence is accessible regardless of your team’s size or specific requirements, we’ve structured our Cloudforce One access into three functional levels:
Cloudforce One Essentials allows customers to access the default datasets in threat events, search for indicators, and conduct threat hunting investigations.
Cloudforce One Advantage allows customers to access our Threat Intelligence Analyst custom insights via requests for information.
Cloudforce One Elite, the complete package, includes brand protection, a high number of requests for information, and access to all threat events datasets.
The Internet moves fast, and the infrastructure used by adversaries moves even faster. By centralizing your telemetry and your response logic in one integrated platform, you can stop building pipelines and start defending your network.
Today’s threat landscape is more varied and chilling than ever: Sophisticated nation-state actors. Hyper-volumetric DDoS attacks. Deepfakes and fraudsters interviewing at your company. Even stealth attacks via trusted internal tools like Google Calendar, Dropbox, and GitHub.
After spending the last year translating trillions of network signals into actionable intelligence, Cloudforce One has identified a fundamental evolution in the threat landscape: the era of brute force entry is fading. In its place is a model of high-trust exploitation that prioritizes results at all costs. In order to equip defenders with a strategic roadmap for this new era, today we are releasing the inaugural 2026 Cloudflare Threat Report. This report provides the intelligence organizations need to navigate the rise of industrialized cyber threats.
The new barometer for risk: Measure of Effectiveness (MOE)
Cloudforce One has observed a broader shift in attacker psychology. To understand how these methods win, we have to look at the why behind them: the Measure of Effectiveness, or MOE.
In 2026, the modern adversary is trading the pursuit of “sophistication” (complex, expensive, one-off hacks) in favor of throughput. MOE is the metric attackers use to decide what to exploit next. It is a cold calculation of the ratio of effort to operational outcome.
Why use an expensive zero-day exploit when a stolen session token (Identity) has a higher MOE?
Why build a custom server when a reputation shield (LotX) provides free, nearly untraceable infrastructure with a high delivery rate?
Why write code manually when AI can automate the discovery of the connective tissue that links your most sensitive data?
In 2026, the most dangerous threat actors aren’t the ones with the most advanced code; it’s the ones who can integrate intelligence and technology into a single, continuous system that achieves their mission in the shortest time possible.
Key findings from the 2026 Cloudflare Threat Report
Eight key trends — all driven by their MOE — will define the threat landscape in 2026:
AI is automating high-velocity attacker operations. Threat actors use generative AI for real-time network mapping, exploit development, and the creation of deepfakes, enabling low-skill actors to conduct high-impact operations.
State-sponsored pre-positioning is compromising critical infrastructure resilience. Chinese threat actors, including Salt Typhoon and Linen Typhoon, are prioritizing North American telecommunications, commercial, government, and IT services, anchoring their presence now for long-term geopolitical leverage.
Over-privileged SaaS integrations are expanding the blast radius of attacks. As demonstrated by the GRUB1 breach of Salesloft, the connective tissue of third-party API integrations allows a single compromised API to cascade into a breach affecting hundreds of distinct corporate environments.
Adversaries are weaponizing trusted cloud tooling to mask attacks. Threat actors actively target legitimate SaaS, IaaS, and PaaS tools such as Google Calendar, Dropbox, and GitHub to camouflage malicious actions within benign enterprise activity.
Deepfake personas are embedding adversarial operatives within Western payrolls. North Korea has operationalized the remote IT worker scheme, using deepfakes and fraudulent identities to embed state-sponsored operatives directly into Western payrolls for espionage and illicit revenue.
Token theft is neutralizing multi-factor authentication. By weaponizing infostealers like LummaC2 to harvest active session tokens, attackers bypass traditional multi-factor authentication and move straight to post-authentication actions.
Relay blind spots are enabling internal brand spoofing. Phishing-as-a-service bots are exploiting a blind spot where mail servers fail to re-verify a sender’s identity, allowing high-trust brand impersonations delivered directly to user inboxes.
Hyper-volumetric strikes are exhausting infrastructure capacity. Hyper-volumetric distributed denial-of-service (DDoS) attacks, fueled by massive botnets like Aisuru, are breaking records on a regular basis, closing the window for human response.
Deep dive: How attackers are weaponizing cloud tooling
Now let’s take a deeper look at one high-MOE tactic we identified: weaponized cloud tooling. Instead of using known malicious servers, attackers are utilizing legitimate cloud ecosystems like Google Drive, Microsoft Teams, and Amazon S3 to mask their command-and-control (C2) traffic. This is known as “living off the land” (or off of anything-as-a-service): wearing the uniform of trusted providers, attackers make their activity nearly indistinguishable from benign corporate traffic.
SaaS platforms are also being used by threat actors to host, launch, redirect, or scale attacks. For instance, services like Amazon SES and SendGrid, designed for legitimate bulk email delivery, are frequently exploited to launch sophisticated phishing and malware distribution campaigns.
How some groups are applying these tactics
While the exploitation of cloud resources is an established tradecraft, 2025 investigations highlighted an accelerated maturation in nation-state strategy: actors are continuing to shift from mere infrastructure abuse toward pervasive living-off-the-land. We predict that for 2026, threat actors will attempt to standardize these techniques as a strategic aim for their operational playbooks.
Here are some of those threat actor groups, where they are based, and examples of their approaches.
Threat Actor
Country
Technique
Details
Example
FrumpyToad
China
Logic-based C2
Moving “inside the box” of reputable SaaS logic to evade detection.
Weaponizes Google Calendar for cloud-to-cloud C2 loop, reading and writing encrypted commands directly into event descriptions.
PunyToad
China
Encrypted tunneling
Utilizing legitimate developer tools to bypass egress filtering.
Uses tunneling capabilities and cloud computing to create resilient, living-off-the-cloud architectures, masking backend origin IPs and prioritizing long-term persistence.
NastyShrew
Russia
Paste site dead drop resolvers
Using public “paste” sites to coordinate shifting infrastructure.
Uses services like Teletype.in and Rentry.co as dead drop resolvers (DDR); infected hosts poll these sites to retrieve rotating C2 addresses.
PatheticSlug
North Korea
PaaS-ing the perimeter
Exploiting the “reputation shield” of cloud ecosystems to mask malicious delivery.
Used Google Drive and Dropbox to host XenoRAT payloads, leveraging GitHub for covert C2, successfully blending into legitimate enterprise traffic.
CrustyKrill
Iran
SaaS-hosted phishing
Blending credential harvesting into common cloud hosting.
Hosts C2 pages on Azure Web Apps (.azurewebsites.net) and uses ONLYOFFICE to host payloads, giving their operations a veneer of legitimacy.
How Cloudforce One unmasked the 2026 landscape
Establishing MOE requires more than just high-level observation. To truly unmask the 2026 landscape, this report details how Cloudforce One leverages a unique blend of internal expertise and global telemetry to uncover insights that traditional security models miss.
Our methodology is varied. For example:
As part of our AI-driven defense research, we tasked an AI coding agent with a self-vulnerability analysis, using the agent to uncover its own security gaps. This “dogfooding” uncovered CVE-2026-22813 (9.4 CVSS), a critical flaw in markdown rendering pipelines allowing for unauthenticated Remote Code Execution.
Our deep dives into Phishing-as-a-Service (PhaaS) reveal that the barrier to entry has a vanished barrier to entry. Analysts observed attackers leveraging high-reputation domains (Google Drive, Azure, etc.) to bypass filters. Email telemetry found an identity gap, where nearly 46% of analyzed emails failed DMARC (an email authentication protocol), revealing a large surface area that PhaaS bots are rapidly exploiting.
We tracked the transition from stealthy exploitation to attempted blackout, uncovering a 31.4 Tbps baseline for DDoS. Our telemetry also showed that, in the past 3 months, 63% of all logins involve credentials already compromised elsewhere and that 94% of all login attempts now originate from bots.
Through every stage of this research, Cloudforce One has leveraged our massive global telemetry and frontline threat intelligence to connect the dots across seemingly isolated incidents. Whether we are dogfooding our own AI agents to preempt zero-day exploits or tracking attacks launched by millions of bot-infected hosts tunneling through residential proxies, this unified visibility allows us to see the throughline between a single phished credential and a multi-terabit blackout.
The path forward: Drive MOE to zero with autonomous defense
Identifying these throughlines is only the first step. When threats move at machine speed, human-centric defense is no longer a viable shield. To counter “offense by the system,” defenders across the industry must pivot to a model of autonomous defense in order to drive the adversary’s MOE to zero.
This shift toward autonomous defense requires moving beyond manual checklists and fragmented alerts. Organizations must harden the connective tissue of their networks, using real-time visibility and automated response capabilities. In this new era, the goal isn’t just to build a better wall — it’s to ensure your system can act faster than the attacker, even when no one is watching.
Through our unmatched threat visibility and the expertise of our Cloudforce One researchers, we provide the intelligence you need to outpace industrialized cyber threats. To explore the full data set, deep-dive case studies, and tactical recommendations, read the complete 2026 Cloudflare Threat Report.
And if you’re interested in learning more about our threat intelligence, managed defense, or incident response offerings, contact Cloudforce One experts.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
