Threat tactic spotlight: Subdomain takeover

Post Syndicated from Matt Gurr original https://aws.amazon.com/blogs/security/threat-tactic-spotlight-subdomain-takeover/

In this blog post you’ll learn how to detect and prevent subdomain takeover – a tactic where threat actors exploit dangling DNS records to redirect traffic to attacker-controlled resources. We’ll explain the issue, how the situation arises, and how you can use various AWS features and services to help mitigate the impact of this tactic.

Under the shared responsibility model, securing configurations in the cloud is your responsibility. AWS supports you through strong defaults, guidance in the Security Pillar of the Well-Architected Framework, and security services to help you meet that responsibility. The AWS Customer Incident Response Team (AWS CIRT) also monitors for new and trending tactics that threat actors use to exploit specific customer configurations, so that you can make informed design decisions and improve your response plans.

AWS CIRT has observed threat actors actively scanning for public DNS CNAME records that point to resources that no longer exist, looking for subdomain takeover opportunities.

Note: The subdomain takeover tactic does not leverage vulnerabilities of AWS services. It exploits a dangling DNS record to redirect traffic to an attacker-controlled resource.

Quick DNS Primer

CNAME Records: A CNAME (Canonical Name) record is a DNS entry that points one domain name to another. For example, api.example.com can be configured to point to api.example.s3-website-us-east-1.amazonaws.com. This feature of DNS enables users to configure a memorable, human-friendly domain name while the actual resource lives at a longer, machine-generated AWS hostname. A security issue emerges when the target resource is deleted but the CNAME record pointing to it remains – creating a “dangling” record.

Dangling Records: When a resource (like an S3 bucket) is deleted but the DNS record pointing to it is left behind, that DNS record becomes “dangling”, pointing to a resource that no longer exists. For resources in globally shared namespaces, threat actors can potentially reclaim the name of your deleted resource and serve malicious content through your DNS record.

What is subdomain takeover?

A subdomain is a prefix added to a domain that allows you to organize access to your resources. A subdomain takeover occurs when you delete the underlying resource and a threat actor creates a new resource with the same name to take advantage of the DNS records still pointing to it.

A subdomain takeover is possible when a CNAME record points to an AWS resource that uses a globally shared DNS namespace where the resource name can be chosen by any AWS customer. The following AWS resources meet these criteria:

Amazon S3 (global namespace): Bucket names like mybucket.s3.amazonaws.com are globally unique and can be claimed by any account if the bucket is deleted. Note: S3 buckets created with account regional namespaces (launched March 2026) are scoped to your account and are not subject to this issue.

Amazon CloudFront: Distribution domain names like d111111abcdef8.cloudfront.net are assigned by AWS and cannot be chosen by an attacker. However, if you delete a distribution and another customer creates one that happens to receive the same domain name, a dangling CNAME could resolve to their content.

AWS Elastic Beanstalk: Environment names like myapp.elasticbeanstalk.com are globally unique and can be claimed by any account if the environment is terminated.

Resources like Amazon VPC, Amazon EC2 instances, or private hosted zones are not subject to this tactic because they do not expose globally claimable DNS namespaces.

MITRE ATT&CK classifies this technique under T1584.001: Compromise Infrastructure – Domains.

Analyzing an example scenario

Consider the following scenario:

You create a DNS CNAME record pointing to your S3 website endpoint. The subdomain subdomain.example.com now resolves to subdomain.example.s3-website-us-east-1.amazonaws.com, which serves content from the S3 bucket named subdomain.example. If your team deletes the bucket and forgets to delete the DNS record, users that navigate to the site will see an error stating that the bucket doesn’t exist. However, at this point, if a threat actor sees this error and moves in to claim the bucket name, they will be able to set up their own site that users will see when they navigate to the subdomain.example.com site.

Figure 1 shows an S3 bucket named subdomain.example (a globally unique bucket name) configured to host a static website, with the S3 website endpoint subdomain.example.s3-website-us-east-1.amazonaws.com.

Figure 1: S3 bucket configured as a static website

Figure 1: S3 bucket configured as a static website

As shown in Figure 2, we use Amazon Route 53 to create a CNAME record to resolve to our Amazon domain name; to give users a friendly name and so they do not have to remember the long S3 website name in URLs.

Figure 2: DNS Resolver configured with CNAME record pointing to origin bucket

Figure 2: DNS Resolver configured with CNAME record pointing to origin bucket

The customer’s AWS administrator decides to stop serving content from the S3 bucket and deletes it, as shown in Figure 3.

Figure 3: Resource deleted without removing the CNAME record

Figure 3: Resource deleted without removing the CNAME record

With the S3 bucket deleted and the CNAME record still in place, the DNS record is now dangling. A threat actor identifies this situation and creates a new S3 bucket with the same global name subdomain.example in an AWS account that the threat actor controls, as shown in Figure 4. The threat actor can now serve content from this new bucket, including potentially malicious content. End users remain unaware of this switch and continue to access subdomain.example.com, trusting the content because it appears to originate from a URL they recognize.

Figure 4: Subdomain takeover happens

Figure 4: Subdomain takeover happens

Potential impacts of a sub-domain takeover

Consider these potential impacts:

Reputation risk: There is a potential risk to your organization’s reputation, because you don’t control the content being served from the threat actor’s site that your DNS record points to.

Potential exposure to phishing campaigns: Users within your organization might have the subdomain bookmarked in their browser, not knowing the resource is no longer available, then unsuspectingly navigate to the site that now hosts malware or is used to phish user credentials.

Blocking: If the subdomain is flagged by security vendors for malicious activity, it could impact your business operations.

Financial loss: Subdomain takeover incidents can result in a financial impact due to the potential disruption to service delivery as you deal with the event.

Proactive detection

AWS Config for proactive detection

For proactive detection, you can use AWS Config to continuously monitor your Route 53 CNAME records and verify that the target resources exist in your account.

Prerequisite: This approach requires AWS Config recorder to be enabled for the resource types you want to monitor (S3 buckets, CloudFront distributions, Elastic Beanstalk environments). If Config isn’t recording a resource type, it won’t appear in the inventory check. For more information, see Setting up AWS Config with the console.

Why use AWS Config inventory instead of DNS resolution checks?

A common approach is to check whether a CNAME resolves to a valid endpoint. However, this method has a critical flaw: if an attacker has already claimed the resource, DNS resolution will succeed – to their resource, not yours. You would have no indication that you don’t own what’s responding.

By querying AWS Config’s recorded configuration items, you’re checking whether the resource exists in your account inventory, not just whether something responds at that DNS name. This approach correctly identifies dangling CNAMEs even after a takeover has occurred.

Implementation approach:

Account-level vs. organization-level scope

The reference implementation queries AWS Config inventory within a single account. This means that if a CNAME record in Account A points to a resource that legitimately exists in Account B within the same AWS organization, the rule will flag it as NON_COMPLIANT.

For organizations that share resources across accounts, you can modify the solution to use an AWS Config Aggregator, which queries resource inventory across all accounts in your organization. This is similar to how IAM Access Analyzer supports both account-level and organization-level scopes. To use this approach, you need an organization-level Config Aggregator already configured, and the Lambda function’s IAM role needs the config:SelectAggregateResourceConfig permission.

We recommend starting with account-level scope for simplicity, then expanding to organization-level if your environment includes cross-account resource sharing.

The main idea is to create a custom AWS Config rule that queries your Route 53 hosted zones for CNAME records, then parses each CNAME target to determine whether it points to a known AWS resource pattern such as S3, CloudFront, or Elastic Beanstalk. For each match, the rule cross-references the target against your AWS Config inventory to verify that the resource actually exists in your account. If the resource isn’t found, the rule marks the CNAME record as NON_COMPLIANT, surfacing it for review.

The Config rule should focus on known AWS resource patterns:

  • S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com
  • CloudFront: *.cloudfront.net
  • Elastic Beanstalk: *.elasticbeanstalk.com

Note: CNAME records pointing to external third-party services are outside the scope of this detection mechanism, as those resources won’t appear in your AWS Config inventory.

NON_COMPLIANT findings from your Config rule can be routed to AWS Security Hub for centralized visibility, or trigger SNS notifications to alert your security team.

Figure 5: Dangling DNS Detection Solution

Figure 5: Dangling DNS Detection Solution

Reference implementation:

We’ve published a complete implementation of this detection approach as an open-source solution. The solution deploys a Lambda function that discovers CNAME records across all your Route 53 hosted zones and uses pattern matching to identify targets pointing to S3, CloudFront, and Elastic Beanstalk. It then queries your AWS Config inventory to verify whether each target resource still exists in your account. When a dangling record is detected, the solution generates a HIGH severity finding in Security Hub and can optionally send SNS notifications to alert your security team. A CloudWatch metrics dashboard is also included for ongoing compliance tracking.

Deployment:

# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection

# Build the Lambda deployment package
./scripts/package.sh

# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/

# Deploy the CloudFormation stack
aws cloudformation deploy \
  --template-file infrastructure/template.yaml \
  --stack-name dangling-dns-detection \
  --parameter-overrides \
      LambdaCodeS3Bucket=YOUR_BUCKET \
      EvaluationFrequency=TwentyFour_Hours \
  --capabilities CAPABILITY_NAMED_IAM

The stack creates an AWS Config custom rule that runs on your specified schedule (default: every 24 hours), evaluating all CNAME records and reporting compliance status.

Mitigating the effects

Mitigating subdomain takeover requires both preventive procedures and responsive capabilities.

Prevention: Standard operating procedure

The most effective mitigation is a standard operating procedure for resource deprovisioning that ensures DNS records are removed before the underlying resource:

  1. Within your DNS zone, delete the CNAME record that points to the fully qualified domain name (FQDN) of the resource that you plan to deprovision.
  2. Wait for the DNS TTL to expire before deleting the resource. DNS resolvers cache records for the duration of the TTL (for example, a TTL of 3600 means resolvers may serve the old record for up to one hour). If you delete the resource before the TTL expires, a threat actor could claim the resource name while cached CNAME entries are still directing traffic to it.
  3. Deprovision the resource that you no longer want to use.
  4. Run a DNS check of the CNAME record that you removed to verify that the resource is no longer resolving.

Key principle: Always delete DNS first, wait for the TTL to expire, then delete the resource. This order eliminates the window where a dangling record could be exploited.

Prevention: S3 account regional namespaces

As mentioned earlier, AWS introduced account regional namespaces for Amazon S3 general purpose buckets in March 2026. While this is a meaningful step toward mitigating the S3-specific takeover vector, there are important operational limitations to be aware of:

Existing buckets are unaffected. Buckets already created in the global namespace cannot be migrated to an account regional namespace. The bucket names remain globally unique and claimable by anyone if the bucket is deleted.

Global namespace is still the default. When creating a new bucket through the console, CLI, or SDK, the global namespace remains the default selection. Users who aren’t aware of the new option will continue creating globally-scoped buckets.

Existing IaC templates require updates. Existing infrastructure-as-code templates (CloudFormation, CDK, Terraform) that don’t explicitly opt in to the account regional namespace will continue provisioning buckets in the global namespace. For CloudFormation, this means setting the BucketNamespace property to account-regional. For other IaC tools, consult their documentation for the equivalent configuration. Organizations need to audit and update their templates to opt in.

For these reasons, the dangling DNS detection approach described in this post remains critical – particularly for organizations with existing S3 infrastructure, and for CloudFront, and Elastic Beanstalk resources where no equivalent namespace scoping exists.

Response: Notification and remediation

When a dangling DNS record is detected, the reference solution described in the Detection section automatically creates a HIGH severity finding in AWS Security Hub and reports the CNAME record as NON_COMPLIANT in AWS Config. If you provide an SNS topic ARN during deployment, the solution also sends notifications to alert your security or operations team via email, Slack, or other channels. For production environments, consider a human-in-the-loop workflow where these notifications are reviewed by a team member who approves the DNS record deletion before it’s executed. This prevents accidental deletion of legitimate records during transient issues.

The reference solution also includes a CloudWatch dashboard for tracking compliance status and evaluation metrics over time, giving your team ongoing visibility into DNS health across your hosted zones.

Note: Fully automated remediation (auto-deleting DNS records) carries risk – a false positive could disrupt legitimate services. We recommend starting with detection and notification, then evaluating automation based on your detection accuracy and operational maturity.

Conclusion

Subdomain takeover is a preventable misconfiguration that can have significant impact on your organization. A layered defense approach provides the best protection:

Prevention: Implement a standard operating procedure that deletes DNS records before deprovisioning the underlying resource.

Detection: Use AWS Config custom rules to proactively identify CNAME records pointing to resources that no longer exist in your account.

Response: Configure notifications through SNS or Security Hub so your team can respond quickly when dangling records are detected.

Monitoring: Maintain ongoing visibility through CloudWatch dashboards to track DNS health and compliance status.

The key insight is that good DNS hygiene – knowing when your CNAME records point to a nonexistent resource – is your first line of defense. Automated detection through AWS Config provides a safety net when operational procedures fail. And if you detect an issue, having a playbook ready to enact your response can lower the impact and your mean time to recovery.

If you have feedback about this post, submit comments in the Comments section below.

Matt Gurr

Matthew Gurr

Matthew is the Senior Incident Response lead in the Asia-Pacific region for the AWS Customer Incident Response Team (AWS CIRT). He has a passion for helping customers proactively prepare for a security event. In his spare time, he enjoys cycling, music, and reading.

Luis Pastor

Luis Pastor

Luis is a Senior Security Solutions Architect at AWS leading the Infrastructure Security and Compliance Technical Field Communities. He drives security architecture for enterprise customers across financial services, healthcare, and retail, specializing in cloud security transformation and regulatory compliance frameworks. Before AWS, Luis architected security solutions in hybrid cloud environments.

Geoff Sweet

Geoff Sweet

Geoff has been in industry since the late 1990s. He began his career in electrical engineering. Starting in IT during the dot-com boom, he has held a variety of diverse roles, such as systems architect, network architect, and, for the past several years, security architect. Geoff specializes in infrastructure security.

Ariam Michael

Ariam Michael

Ariam is a Solutions Architect at AWS. She has supported various customers in the Worldwide Public Sector, specifically SLG and Federal Civilian customers. She is passionate about security, specifically Data Protection helping customers implement encryption and best practices.

AI-assisted data development with Kiro and SageMaker Unified Studio

Post Syndicated from Zach Mitchell original https://aws.amazon.com/blogs/big-data/ai-assisted-data-development-with-kiro-and-sagemaker-unified-studio/

AI coding assistants are transforming software development, but data engineering presents unique challenges: governed data access, shared compute environments, and compliance controls that are designed to remain in place. How do you bring the power of agentic AI development into a governed data environment? With the AWS Toolkit for Visual Studio Code, you can connect Kiro, VS Code, or Cursor directly to Amazon SageMaker Unified Studio.

When you connect your editor to a SageMaker Unified Studio Space (a cloud-based compute environment inside your project), you get AI-assisted development with your preferred tools while your data governance, project permissions, and compute are managed by SageMaker Unified Studio. Additionally, SageMaker Unified Studio automatically generates steering files (like AGENTS.md) that provide your AI assistant with context about your project environment, so it understands your data and project configuration from the first prompt.

This post demonstrates the integration using Kiro. The same Remote Access connection works with VS Code and Cursor. The post starts by showing what you can do with this integration: using natural language to explore and analyze data in a governed environment. We then walk through the setup so you can try it yourself.

What’s new

With the AWS Toolkit, you can connect Kiro, VS Code, and Cursor to your SageMaker Space over a secure SSH tunnel. No additional extensions or SSH key management required. After the connection is established, your IDE has full access to your Space’s file system, compute, and data services.

Two capabilities make this especially powerful for data work:

  • Automatic AI steering – When connecting Kiro to SageMaker Unified Studio,  Kiro generates AGENTS.md and smus-context.md files that provide your AI assistant with context about your environment, including project configuration, environment details, and utilities for discovering your data catalog and project structure. Kiro detects these files automatically; other editors can use them as context for their own AI features.
  • MCP server support – have Kiro discover and configure itself for the Model Context Protocol servers on your remote SageMaker space ( like smus_local and aws-dataprocessing) to give your agent direct access to your AWS Glue Data Catalog, Amazon Athena queries, and SageMaker Unified Studio project metadata.

The following diagram shows how the components connect:

Architecture diagram: How the components connect

See it in action: AI-assisted development with governed data

Before walking through the setup, we explain what you can do with this integration. This walkthrough uses Kiro as the editor. With Kiro connected to a SageMaker Unified Studio Space, MCP servers configured, and steering documents in place, we can use natural language to explore data and build analytics. The AI assistant has all the context it needs to do this well.

Note: Agentic AI output is nondeterministic. The exact code, tool choices, and responses Kiro produces will vary between sessions, even with the same prompt. The following walkthrough shows one representative session. Your experience will differ in the specifics, but the patterns and capabilities demonstrated here are consistent.

Step 1: Explore the data

Start with a simple prompt:

show my databases and the tables I have access to

Even with native MCP tools available, Kiro often prefers the AWS Command Line Interface (AWS CLI) and bash to retrieve information. This is expected and typically does not affect the outcome. If you prefer MCP tools for every operation, you can add that preference to a steering document.

Kiro used the sagemaker_studio SDK to discover the catalog:

python3 -c "
from sagemaker_studio import Project
project = Project()
conn = project.connection()
catalog = conn.catalog()
print('Databases:')
for db in catalog.databases:
    print(f'  - {db.name}')
"
Databases:
  - default
  - sagemaker_sample_db

Then it drilled into the table schema:

python3 -c "
from sagemaker_studio import Project
project = Project()
conn = project.connection()
catalog = conn.catalog()
db = catalog.database('sagemaker_sample_db')
print('Tables in sagemaker_sample_db:')
for t in db.tables:
    print(f'  - {t.name}')
    print(f'    Columns: {[(c.name, c.type) for c in t.columns]}')
"
Tables in sagemaker_sample_db:
  - churn
    Columns: [('state', 'string'), ('account_length', 'int'),
              ('area_code', 'string'), ('phone', 'string'),
              ('intl_plan', 'string'), ('vmail_plan', 'string'),
              ('vmail_message', 'int'), ('day_mins', 'double'),
              ('day_calls', 'int'), ('day_charge', 'double'),
              ('eve_mins', 'double'), ('eve_calls', 'int'),
              ('eve_charge', 'double'), ('night_mins', 'double'),
              ('night_calls', 'int'), ('night_charge', 'double'),
              ('intl_mins', 'double'), ('intl_calls', 'int'),
              ('intl_charge', 'double'), ('custserv_calls', 'int'),
              ('churn', 'boolean')]

Kiro discovered the sagemaker_sample_db.churn dataset, a sample dataset that ships with SageMaker Unified Studio containing 10,000 rows and 21 columns of customer churn data (state, account length, call minutes, service calls, churn flag, and more). Notice that we did not write any of this code. We asked a question in natural language, and Kiro chose the right SDK calls, explored the catalog, and surfaced the results.

Another, more natural way to get the same answer is to ask directly. Prompting “Let us sample the churn table.” yields the same catalog paths and schema output, along with additional metrics like row count and a data sample, all from a single conversational prompt:

SageMaker Unified Studio console showing the sagemaker_sample_db.churn dataset listed in the catalog

Figure 1 — The sagemaker_sample_db.churn dataset in the catalog

Schema view showing the 21 columns of the churn table including state, account_length, call minutes, and the churn boolean

Figure 2 — Churn dataset schema with 21 columns

from sagemaker_studio import sqlutils
result = sqlutils.sql(
    'SELECT COUNT(*) AS total_rows FROM sagemaker_sample_db.churn',
    connection_name='default.sql'
)
print('=== Total Row Count ===')
print(result)
=== Total Row Count ===
   total_rows
0       10000

With the schema and row count in hand, Kiro sampled the data to round out its understanding of the dataset:

Comprehensive data sample showing 10 rows from the churn table with all 21 columns populated

Figure 3 — Comprehensive data sample after Kiro catalog exploration

Step 2: Run analytics with full context

With the data explored, ask Kiro to run a data quality evaluation:

Can we run basic statistical evaluations for data quality?

Because Kiro had already explored the catalog and sampled the data, it made smart choices about how to run the analysis. Instead of using PySpark for this 10,000-row table, Kiro used Athena using sqlutils to run the evaluation directly. It produced a thorough data quality report:

  • 10,000 rows, 21 columns, zero nulls across all columns. Clean on that front.
  • 5,000 duplicate rows (50 percent). Significant, worth investigating before modeling.
  • Outliers minimal. Most columns have less than 1 percent outlier rate by IQR.
  • Churn is nearly 50/50 split (50.04 percent False, 49.96 percent True). Unusually balanced, indicating synthetic data.
  • Clear signal in key features. Churners and non-churners show differences in day_mins (7.52 vs. 3.52), eve_mins (5.95 vs. 4.11), and vmail_message (175 vs. 278).
  • State distribution roughly uniform (~2% each), intl_plan and vmail_plan near 50/50.

The key insight here is what Kiro did not do. It did not default to PySpark because the environment supports Spark. Having explored the data first, understanding the table size, column types, and that churn is a proper Boolean (not a string), Kiro independently chose the right engine for the workload and produced correct analytics on the first pass.

Best practice: Explore first, code second

Start every AI-assisted development session with data exploration. Ask your AI assistant to discover your catalog, sample your tables, and understand the schema before asking it to build anything. This single step helps reduce a common source of errors in AI-assisted data work: the LLM making assumptions about data it has not seen.

Exploring your data gives the large language model (LLM) the context it needs to properly help with your project. It saves hallucinations and rework, results in faster development time, and reduces token costs.

Ready to try it yourself? The following sections walk through the full setup: prerequisites, connecting your editor to your SageMaker Space, configuring MCP servers, and working with notebooks.

Prerequisites

Before you begin, make sure you have the following:

  • A SageMaker Unified Studio domain and project with at least one project that has a compute environment provisioned (Tooling or ToolingLight). These should come standard with every SageMaker project except those provisioned with the SQL & Gen AI blueprints. If you need to set up SageMaker Unified Studio, see Getting started with Amazon SageMaker Unified Studio.
  • A Space with Remote Access enabled. Either a JupyterLab or Code Editor Space works. The instance must have at least 8 GiB of memory (for example, ml.t3.large or larger). The default ml.t3.medium (4 GiB) can’t enable Remote Access. You must upgrade the instance type first, then toggle Remote Access to Enabled in the Configure Space dialog.
  • A VS Code-compatible editor. Kiro, VS Code, Cursor, or another VS Code-based IDE installed on your local machine. This walkthrough uses Kiro, but the Remote Access connection has been tested with VS Code and Cursor as well.
  • AWS Toolkit v4.1.0 or later. Kiro ships with the AWS Toolkit pre-installed. For VS Code and Cursor, install the AWS Toolkit extension and verify your version is 4.1.0 or later (Cmd+Shift+X and search for “AWS Toolkit”).
  • AWS credentials. You must be authenticated in the SageMaker Unified Studio panel of the AWS Toolkit with the same identity (AWS IAM Identity Center or AWS Identity and Access Management (IAM)) that you use to access SageMaker Unified Studio in the browser.
  • Network connectivity. Your Space must have internet access (PublicInternetOnly mode, or virtual private cloud (VPC) with a NAT gateway or HTTP proxy that allows VS Code and Open VSX endpoints).

The following screenshots show the SageMaker Unified Studio portal and the Configure Space dialog. Navigate to your project, select your Space, and verify the configuration. Remote Access is disabled when the instance has less than 8 GiB of memory. Select an instance with at least 8 GiB, such as ml.t3.large, then enable Remote Access. This is a one-time configuration per Space.

SageMaker Unified Studio portal showing the Spaces list for a project

Figure 4 — SMUS project Spaces overview in the portal

Configure Space dialog with the instance type selector open and ml.t3.large highlighted

Figure 5 — Configure Space dialog showing instance type selection

Configure Space dialog with the Remote Access toggle set to Enabled on an 8 GiB instance

Figure 6 — Enabling Remote Access on a Space with 8 GiB or more

Connecting your editor to your SageMaker Space

There are two ways to connect: directly from the SageMaker Unified Studio portal, or from your local IDE using the AWS Toolkit.

Method 1: Connect from the SageMaker Unified Studio portal

To launch your IDE directly from the portal, navigate to your project’s Code Spaces page, find your Space, and choose Open in to select your editor (Kiro, VS Code, or Cursor):

Code Spaces list with the Open in menu showing options for Kiro, VS Code, and Cursor

Figure 7 — Open in Local IDE from the Code Spaces list

You can also launch from within a Space’s details page:

Space details page with the Open in menu expanded

Figure 8 — Open in Local IDE from the Space details page

Or from within the JupyterLab or Code Editor browser environment:

JupyterLab toolbar with the Open in Local IDE option visible

Figure 9 — Open in Local IDE from JupyterLab

Your browser will prompt you to allow opening the IDE. Confirm, and the editor launches with an SSH connection to your Space already established via the AWS Toolkit. No additional configuration is typically required.

Method 2: Connect from your IDE via the AWS Toolkit

  1. Open your editor on your local machine. Then, in the AWS Toolkit panel, choose Sign in. Authenticate with your IAM Identity Center or IAM credentials, the same identity you use to access SageMaker Unified Studio in the browser. The following screenshots show Kiro, but the steps are the same in VS Code and Cursor.Figure 10 — AWS Toolkit button in Kiro
    Figure 10 — AWS Toolkit button in KiroAWS Toolkit panel expanded in Kiro showing the Sign in option

    Figure 11 — AWS Toolkit panel expanded

    AWS Toolkit Sign in dialog with profile selection

    Figure 12 — AWS Toolkit Sign in dialog

  2. Choose your AWS profile. You must have a profile configured in the AWS CLI with the correct account and AWS Region set.
  3. In the Toolkit panel, browse your SageMaker Unified Studio domains and projects. Select the project that you want to work in.

Kiro AWS Toolkit panel showing SageMaker Unified Studio domains and projects in a tree view

Figure 13 — Browsing SMUS domains and projects in Kiro

Important: The credentials that you use in the AWS Toolkit must match the identity that you use in the SageMaker Unified Studio portal. The Toolkit validates that your identity has access to the Space.

AI steering: How SageMaker Unified Studio pre-seeds AI context

The real value of the feature comes from what you don’t need to do. When connected to Kiro SageMaker Unified Studio automatically generates steering files that guide your AI assistant with project context, so you can focus on building analytics rather than configuring connections. When you open a SageMaker Unified Studio project, SageMaker Unified Studio presents a prompt to create steering files: an AGENTS.md file that references a newly created smus-context.md. These files provide context about your project environment, such as project configuration, environment details, and utilities for discovering your data catalog and project structure. Kiro detects and applies these files automatically; in other editors, you can reference them as context for your AI features.

SageMaker Unified Studio popup offering to create AGENTS.md and smus-context.md steering files

Figure 14 — SMUS popup offering to create steering files

Kiro file explorer showing the generated AGENTS.md and smus-context.md files at the project root

Figure 15 — Generated AGENTS.md and smus-context.md steering files

Without these steering files, your AI assistant would need several back-and-forth prompts to discover what data you have and how to access it. With them, the assistant understands your project from the first prompt: how to discover your databases, how your environment is configured, and what tools are available. The steering files also help properly configure MCP servers, which you set up in the next section.

Exploring your project

After you’re connected, the project structure expands into Data and Compute sections in the sidebar, as it would in the SageMaker Unified Studio portal.

Kiro sidebar showing the Data and Compute sections expanded under a SageMaker Unified Studio project

Figure 16 — Project Data and Compute sections in the Kiro sidebar

You can explore your data catalog and S3 buckets directly from the sidebar:

Kiro sidebar with the data catalog tree and S3 buckets expanded under the project

Figure 17 — Exploring the data catalog and S3 buckets from the sidebar

You can also remote into a compatible Space for direct development. Hover over a Space and select the remote icon on the right:

Kiro sidebar showing the remote connection icon next to a compatible Space

Figure 18 — Remote connection icon on a compatible Space

After a moment, the Space opens in a new Kiro window:

New Kiro window opened with a remote connection to the SageMaker Unified Studio Space

Figure 19 — Space opened in a new Kiro window

You must sign in again, and then trust the authors of the files in the Space:

Trust authors dialog asking to confirm trust for files in the remote Space

Figure 20 — Trust authors dialog for the Space files

You’re now connected to your Space. The Toolkit works on the Space the way it does locally, except the resources are scoped to the project’s permissions.

Kiro window connected to a SageMaker Unified Studio Space with the AWS Toolkit panel active

Figure 21 — Connected to the SMUS Space with the Toolkit active

Setting up MCP servers

Before you can use AI-assisted development effectively, you must give Kiro access to your data services through Model Context Protocol (MCP) servers. MCP servers extend the Kiro agent with tools: the ability to query catalogs, run SQL, manage credentials, and more.

Out of the box, Kiro has no MCP servers configured:

Kiro MCP servers panel with no servers configured

Figure 22 — Kiro MCP servers panel with no servers configured

Prompt Kiro to find and configure the MCP servers that ship pre-installed on your SageMaker Space. Using the steering file context, Kiro located the servers and generated the configuration. If a server fails to connect, select the failed entry and Kiro will suggest fixes. You might need additional prompts to get the smus_spark_upgrade server (a pre-installed MCP server for managing Spark session upgrades) working correctly.

Kiro chat panel showing the agent discovering and configuring SageMaker Unified Studio MCP servers

Figure 23 — Kiro discovering and configuring SMUS MCP servers

MCP servers panel after iterating on configuration fixes, showing servers connected

Figure 24 — MCP servers after iterating on configuration fixes

For more deterministic results, you can also configure the MCP servers manually. Here is a sample configuration:

{
    "mcpServers": {
        "smus_local": {
            "command": "python3",
            "args": ["-m", "sagemaker_studio.mcp_server"],
            "env": {}
        },
        "aws-dataprocessing": {
            "command": "uvx",
            "args": ["awslabs.aws-dataprocessing-mcp-server@latest"],
            "env": {
                "AWS_REGION": "us-east-1",
                "FASTMCP_LOG_LEVEL": "ERROR"
            },
            "disabled": ["emr_*"]
        }
    }
}

Note: Your MCP configuration might vary depending on your SageMaker Unified Studio environment. Use the preceding configuration as a starting point and let your editor adjust if a server fails to connect.

Next, add the AWS Data Processing MCP server to get catalog information and Athena query capabilities. This isn’t strictly required (Kiro can use Python or AWS CLI for the same tasks), but it gives the agent native tools for catalog and query operations.

AWS Data Processing MCP server tools listed in Kiro with the Amazon EMR tool group disabled

Figure 25 — AWS Data Processing MCP server tools with Amazon EMR tools disabled

You can list the tools that each MCP server provides. Because the AWS Data Processing MCP server includes tools for many services, we recommend disabling tools that you don’t need for a given project to save model context. For this walkthrough, disable the Amazon EMR tools to focus on AWS Glue and Amazon Athena.

Exploring data with notebooks

Kiro supports Jupyter notebooks in your SageMaker Space with the same language and connection selectors that you would find in SageMaker JupyterLab or Code Editor. Open the command palette (Cmd+Shift+P) and create a new Jupyter notebook:

Kiro command palette filtered to the Create New Jupyter Notebook command

Figure 26 — Command palette to create a new Jupyter notebook

New Jupyter notebook open in Kiro showing language and connection selectors at the bottom-right of a cell

Figure 27 — New Jupyter notebook opened in Kiro with language and connection selectors in a notebook cell

As in SageMaker JupyterLab, you get language and connection selectors in the bottom right of each cell. Choose the connection selector to see your available connections:

SageMaker connection selector dropdown showing the available connections for the project

Figure 28 — SageMaker connection selector

Select PySpark to fill in the magic commands for your cell. Write your code (in this case, enter spark and press Shift+Enter) to verify the session starts:

Notebook cell prefilled with the PySpark magic command and a spark verification statement

Figure 29 — PySpark magic command and spark verification code

PySpark cell running in the Kiro notebook

Figure 30 — Running the PySpark cell

If this is your first time using Jupyter with Kiro, you’re prompted to install the Jupyter extension. After it’s installed, select the kernel from Python Environments → Base:

Jupyter kernel selection prompt in Kiro after installing the Jupyter extension

Figure 31 — Jupyter kernel selection prompt

Kernel picker showing the Python kernel selected from the Base environment

Figure 32 — Selecting the Python kernel from the Base environment

Re-run your cell. After a few moments, AWS Glue provisions a PySpark session:

AWS Glue provisioning a PySpark session in a Jupyter notebook in Kiro

Figure 33 — AWS Glue provisioning a PySpark session in a Jupyter notebook in Kiro

You see results the way you would in JupyterLab in the SageMaker Unified Studio portal:

PySpark code running in a Jupyter notebook in Kiro with output cells populated

Figure 34 — PySpark code running in a Jupyter notebook in Kiro

The notebook generate button

You will notice a Generate button underneath notebook cells. Let’s test it with a simple prompt:

looking at the above cell for reference, show me the accounts where state = california
using pyspark prefixing the cell with `%%pyspark default.spark` and sorting by
account_length

Notebook cell showing the Generate button populated with a natural language prompt

Figure 35 — Using the Generate button with a natural language prompt

Generated PySpark code populating a notebook cell after using the Generate button

Figure 36 — Generated PySpark code from the prompt

This prompt builder, like other notebook generation features, doesn’t have good context on the surrounding cells. You must be explicit about what you want because it won’t read other code or cells as input.

While the Kiro notebook generate button works for straightforward edits, for serious code generation, we recommend that you use Kiro agent mode. This mode has full project and SageMaker context, as demonstrated in the “See it in action” walkthrough earlier in this post.

What’s happening under the hood

When you connect your editor to a SageMaker Unified Studio Space, the AWS Toolkit extension establishes a secure SSH tunnel between your local IDE and your cloud-based Space.

Key details:

  • SSH tunnel. The connection is managed entirely by the AWS Toolkit (v4.1.0+) or VS Code’s built-in SSH extension. No separate Remote SSH extension is needed; the capability is built in.
  • File system access. Your editor sees the Space’s persistent storage at /home/sagemaker-user/, including shared project files and notebooks or scripts you create.
  • SageMaker Unified Studio steering context. The integration generates AGENTS.md and smus-context.md files that provide your AI assistant with context about your project environment and utilities for understanding your data. This is what makes the assistant effective from the first prompt.
  • MCP server integration. MCP servers like smus_local (for project metadata and environment utilities) and aws-dataprocessing (for AWS Glue Data Catalog and Amazon Athena) extend your editor’s AI with direct access to your data services. Your own MCP servers will be equally valuable here.
  • Credential flow. The Toolkit uses your existing AWS identity (IAM Identity Center or IAM) to authenticate to the Space. No separate SSH keys to manage. The aws_context_provider tool from the smus_local MCP server handles credential discovery for agent operations.

Best practices

To work effectively with your IDE and SageMaker Unified Studio:

  • Explore your data before building. Start every session by asking your AI assistant to discover your catalog, sample your data, and understand the schema. This single step helps reduce the most common source of errors in AI-assisted data work: the LLM making assumptions about data it has not seen. See the “See it in action” walkthrough earlier in this post for a concrete example of the difference this makes.
  • Use the SageMaker Unified Studio steering files. When prompted to create AGENTS.md and smus-context.md, accept. These files are the foundation that makes everything else work: environment context, MCP server configuration, and project understanding. Without them, your AI assistant starts from zero on every prompt. Kiro detects these automatically; in other editors, add them as context.
  • Disable unused MCP tools. The AWS Data Processing MCP server includes tools for AWS Glue, Amazon EMR, Amazon Athena, and more. Disable the services that you’re not using for a given project to save model context and reduce noise.
  • Be specific in your prompts. The more detail you give your AI (column names, query patterns you prefer, output formats), the closer the first pass will be. “Run data quality evaluation using Athena SQL” gets you better code than “check my data.”
  • Always test interactively first. Whether in notebooks or the terminal, validate code before deploying it. AI agents can iterate quickly, but catching issues in an interactive session is faster than debugging a failed AWS Glue job. Athena PySpark and the SageMaker sqlutils and sparkutils packages are great for this.
  • Stop your Space when idle. Your Space runs on compute (the same instance types as Code Editor and JupyterLab). If idle, the Space will terminate after 60 minutes and close your remote connection. Close the remote window and reconnect to continue.

Things to know

  • Notebook agent mode. For notebook-heavy analytics workflows where you want agentic AI to generate and run cells directly, SageMaker Notebooks with Data Agent in SageMaker Unified Studio is the recommended option today. Current notebook support in local editors covers editing, running, and generating code in individual cells.
  • MCP setup takes iteration. Configuring MCP servers may require iteration, especially for servers with complex authentication. Many AI-enabled editors can self-correct when a server fails. For more deterministic results, use the preceding MCP configuration JSON as a starting point rather than relying solely on auto-discovery.
  • CLI preference. AI agents often prefer the AWS CLI and bash even when MCP tools are available. This doesn’t affect outcomes, but you can steer your assistant toward MCP tools using a steering document if you prefer consistency.

Security and governance boundaries

A core benefit of this integration is that your existing security and governance controls remain enforced. Your editor connects to your SageMaker Space through a secure SSH tunnel managed by the AWS Toolkit. It does not bypass your organization’s access controls. Data access is governed by the same AWS Lake Formation permissions and IAM Identity Center authentication that apply when you work in the SageMaker Unified Studio portal directly. Your project-level permissions, database grants, and column-level security policies apply consistently whether a query originates from an AI agent, a notebook cell, or the SageMaker console. Data access is governed by the boundaries you define in your SageMaker Unified Studio domain and project configuration.

Clean up

To avoid ongoing charges from billable resources (SageMaker Space compute charges per hour, AWS Glue sessions charge per DPU-hour, Amazon Athena queries charge per TB scanned):

  1. Stop your Space – In the SageMaker Unified Studio portal, navigate to your project’s Spaces and stop the Space you used for this walkthrough.
  2. Disconnect: Close the remote connection in your editor (File → Close Remote Connection).
  3. Verify AWS Glue sessions are terminated – If you ran PySpark queries during this walkthrough, verify that the sessions are stopped. In the SageMaker Unified Studio portal, navigate to Data processing and confirm no active AWS Glue sessions remain. Sessions auto-terminate when the Space stops, but verify to avoid unexpected charges.
  4. Delete demo resources (optional) – File deletion is permanent and cannot be undone. Back up any work that you want to retain before proceeding. If you created scripts or files during this walkthrough that you no longer need, delete them from /home/sagemaker-user/. For example, delete any test notebooks, Python scripts, or generated data files. The sample sagemaker_sample_db.churn dataset is read-only and doesn’t need cleanup.

Conclusion

This post showed what happens when agentic AI meets governed data, and walked through how to set it up yourself.

Three key insights emerged from this hands-on experience:

  1. SageMaker Unified Studio steering files transform the developer experience. Your AI assistant is project-aware from the first prompt, understanding your environment and available data without manual setup.
  2. MCP servers bridge “AI that writes code” with “AI that queries your data”. The smus_local and aws-dataprocessing servers are essential for effective agentic data work.
  3. The “explore first” pattern pays immediate dividends. When your AI assistant understands your data before writing code, it makes smarter engine choices and produces correct analytics on the first pass.

This integration brings together two capabilities that are stronger together: your IDE handles the AI-assisted coding and iteration, while SageMaker Unified Studio handles data governance, access control, and compute management. You get the productivity of an agentic AI coding assistant without compromising on the controls your organization requires.

To get started, download Kiro, install VS Code or Cursor, and add the AWS Toolkit for Visual Studio Code (v4.1.0 or later). Then visit the Amazon SageMaker Unified Studio documentation and the AWS Data Processing MCP Server to set up your first Space. For related reading, see Speed up delivery of ML workloads using Code Editor in Amazon SageMaker Unified Studio.

About the authors

Zach Mitchell

Zach Mitchell

Zach is a Senior Big Data Architect in AWS Worldwide Specialist Organization for Analytics. He works with customers to design and build data applications on AWS, with a focus on SageMaker Unified Studio, AWS Glue, and AWS Lake Formation. Outside of work, he enjoys building things with code and occasionally writing about it.

Anchit Gupta

Anchit Gupta

Anchit is a Senior Product Manager on the Amazon SageMaker Unified Studio team at AWS.

Leah Wagner

Leah Wagner

Leah is a Senior Solutions Architect in AWS Worldwide Specialist Organization for Analytics.

Bhargava Varadharajan

Bhargava Varadharajan

Bhargava is a Senior Software Engineer on the Amazon SageMaker Unified Studio team at AWS.

Majisha Namath Parambath

Majisha Namath Parambath

Majisha is a Software Development Engineer on the Amazon SageMaker Unified Studio team at AWS.

The LWN public topics list

Post Syndicated from corbet original https://lwn.net/Articles/1078039/

Part of running LWN is keeping a list of potentially interesting topics
that may merit the effort to turn into articles. As an experiment, we are
now exposing that list to our subscribers at the
Project Leader and Supporter levels. The hope is that this list will
provide useful insights into what is on our radar and which might be coming
to LWN in the near future.

[Topic list screenshot]

With this feature, we hope to give our most committed subscribers a look
behind the curtain and the ability to provide input on the topics they are
most interested in reading about. There, is, thus, a simple voting
mechanism built into this list. No topic will be chosen (or rejected)
solely on the basis of votes; there are a lot of considerations that go
into topic selection, and that will not change. But more information about
where our readers’ interests lie will, hopefully, be helpful.

For all readers: we are always happy to welcome topic suggestions sent to
[email protected].

Modernize Amazon Redshift: RA3 to RG Migration best practices

Post Syndicated from Nita Shah original https://aws.amazon.com/blogs/big-data/modernize-amazon-redshift-ra3-to-rg-migration-best-practices/

Amazon Redshift is a fully managed, AI-powered cloud data warehouse used by tens of thousands of customers to analyze exabytes of data with industry-leading price-performance. Amazon Redshift delivers SQL analytics across your entire lakehouse in Amazon SageMaker Unified Studio, unifying data from multiple sources. Zero-ETL integrations remove complex pipelines by connecting streaming, databases, and enterprise applications for near real-time insights.

On May 12, 2026, Amazon Redshift launched Graviton-based RG instances, a new generation of provisioned nodes. RG instances deliver up to 2.2x as fast for data warehouse workloads and up to 2.4x as fast for data lake workloads, at 30 percent lower price per vCPU compared to RA3 instances. RG instances support all data lake formats supported by RA3 and remove the per-TB scanning charges for Amazon Redshift Spectrum.

In this post, you learn how to migrate Amazon Redshift RA3 clusters to Graviton-based RG instances. We compare the Elastic Resize, Classic Resize, and Snapshot/Restore migration strategies, with key considerations and best practices to support a smooth migration. We also provide mapping guidance from RA3 to RG to help you right-size your cluster.

Who should migrate to RG?

We recommend that all RA3 customers plan their migration to RG to maximize price-performance. RG is designed to deliver improved performance for both compute-intensive and I/O-intensive workloads compared to RA3, so regardless of your workload pattern, you might see performance improvements. Amazon Redshift Graviton RG instances maintain feature parity with prior-generation RA3 instances, so you can migrate without loss of functionality.

RG node types

The RG instance family currently has two node types available. The following table shows the RG instance types, hardware specifications, and the equivalent RA3 node types. Use these specifications to inform sizing decisions when migrating from RA3.

Node type Configuration vCPU Memory Max storage/node Node range Status RA3 equivalent
RG.xlarge Multi Node 4 32 GB 16 TB 2-32 GA (05/12/2026) Direct equivalent to RA3.xlplus.
RG.4xlarge Multi Node Only 16 128 GB 128 TB 2-64 GA (05/12/2026) 1.33x more vCPUs and memory vs RA3.4xlarge

Note: We plan to extend support for additional instance types in the future to provide an optimal price/performance fit for your Amazon Redshift workloads.

For more details on instance types, see the Amazon Redshift documentation.

RA3 to RG node mapping

Current Node Type Node Range Recommended RG Type Recommended RG Node Count
RA3.xlplus 1-32 RG.xlarge 1:1 mapping (same #node count)
RA3.4xlarge 2 RG.4xlarge 2 RG.4xl nodes for 2 nodes of RA3.4xl
RA3.4xlarge 3-64 RG.4xlarge 3 RG nodes per 4 RA3.4xl nodes (round up to nearest even)

Note: These are starting recommendations. Depending on your specific workloads, you might need to adjust the target RG node configurations. We recommend testing your workload in a lower environment and validating performance before committing to a target configuration. To test a full production workload, you can also use the Amazon Redshift Test Drive utility.

Mapping consideration: Within the RG family, 1 node of RG.4xlarge equals 4 nodes of RG.xlarge.

Choosing between RG node types: When sizing your Amazon Redshift cluster, a key decision is whether to use fewer large nodes or a greater number of smaller nodes. The key differentiator between RG node types is local SSD cache capacity. Larger nodes provide more local cache per node, which reduces the need to fetch data from managed storage and improves performance for I/O-intensive queries.

Consider larger node types when your workload involves:

  • Significant disk spill – complex queries with large intermediate result sets that exceed available memory.
  • Leader node-heavy processing – high numbers of concurrent client connections, complex query compilation with many joins and subqueries, or heavy final-stage aggregation.
  • Large volumes of frequently accessed data – hot datasets that benefit from local SSD cache to minimize fetches from managed storage.
  • Large result sets – queries returning substantial data volumes back to the client application.
  • Frequent metadata operations – workloads with high catalog lookup activity or CURSOR-based fetches with many small batches.

Prerequisites

You must have the following prerequisites to follow along with this post.

  • An existing Amazon Redshift cluster running RA3 node types.
  • AWS Identity and Access Management (IAM) permissions to perform resize operations (redshift:ResizeCluster, redshift:DescribeClusters).
  • AWS Command Line Interface (AWS CLI) installed and configured (for AWS CLI-based migration).
  • A recent manual snapshot (no more than 10 hours old) if you plan to use Classic Resize.
  • Sufficient storage capacity in the target RG configuration for your existing data.

Migration approach

The following diagram compares the three migration approaches.

Three migration approaches: Elastic Resize, Classic Resize, and Snapshot/Restore, showing trade-offs in downtime, write availability, and supported target configurations

Elastic Resize is the recommended method for performing the node upgrade when the target RG node configuration falls within the supported bounds of Elastic Resize. You can use it to change the node type (for example, from RA3 to RG) and to add or remove nodes from an Amazon Redshift cluster.

When an Elastic Resize is performed, Amazon Redshift first creates a snapshot of the source cluster. A new target cluster is provisioned with the latest data from the snapshot, and data is transferred to the new cluster in the background. During this period, data is read-only. When the resize nears completion, Amazon Redshift updates the endpoint to point to the new cluster and drops all connections to the source cluster. Although unlikely, in case of a failure, rollback happens automatically in most cases without manual intervention.

Advantages

  1. Typically completes quickly, taking approximately 10–15 minutes on average. We recommend it as your first option.
  2. Minimal downtime, because the cluster remains in a read-only state during the resize operation.
  3. Cluster endpoint remains the same, so no connection string changes are required.
  4. Can be run on demand or scheduled during a maintenance window.

Considerations

  1. When performing an Elastic Resize to change the node type on a producer cluster, data sharing is unavailable while connections are dropped and transferred to the new target cluster.
  2. Verify that your target node configuration has enough storage for your existing data.
  3. Not all target configurations are available under Elastic Resize. Consider Classic Resize or Snapshot/Restore in those cases.
  4. An Elastic Resize operation can’t be canceled after it’s initiated.
  5. Data slices remain unchanged. This can potentially cause some data or CPU skew.

You can use either the AWS Management Console or the AWS CLI to initiate an Elastic Resize.

To resize a cluster using the console, follow these steps

  1. Sign in to the AWS Management Console.
  2. Open the Amazon Redshift console at https://console.aws.amazon.com/redshiftv2/.
  3. On the left navigation menu, choose Provisioned clusters.
  4. Choose the cluster to resize.
  5. For Actions, choose Resize. The Resize cluster page appears.
  6. On the Resize cluster page, select the resize type: Elastic resize (recommended).Resize cluster console showing Elastic resize selected as the resize type
  7. Under New configuration, select the node type (for example, rg.4xlarge).
  8. Enter the number of nodes.
  9. Depending on your choices, choose Resize now or Schedule resize.

To resize a cluster using the AWS CLI, follow these steps

# Initiate an Elastic Resize to upgrade from RA3 to RG node type
aws redshift resize-cluster \
    --cluster-identifier <my-RA3-cluster> \  # Source cluster ID
    --node-type rg.4xlarge \                 # Target RG node type
    --number-of-nodes <#nodes> \             # Target node count
    --no-classic                            # false = Elastic Resize

2. Classic Resize

Classic Resize is recommended when the change in cluster size or node type isn’t supported by Elastic Resize. It’s also required for single-node to multi-node conversions.

When you perform a Classic Resize, Amazon Redshift creates a target cluster and migrates your data and metadata from the source cluster using a backup and restore operation. This makes sure that all data, including database schemas and user configurations, is accurately transferred. The source cluster restarts initially and is unavailable for a few minutes. After that, the cluster becomes available for read and write operations while the resize continues in the background.

Enhanced Classic Resize comprises two stages:

  1. Stage 1 (critical path): Migrating the metadata from the source cluster to the target cluster. During this stage, the source cluster is in read-only mode. This is typically a very short duration. The cluster is then made available for read and write queries. All tables with KEY distribution style are temporarily stored with EVEN distribution and are redistributed to KEY style in Stage 2.
  2. Stage 2 (off critical path): Redistributing the data per the previous distribution style. This runs in the background. Duration depends on data volume, cluster workload, and node type.

For additional details, see Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize.

Advantages

  1. Supports all possible target node configurations.
  2. Allows for comprehensive reconfiguration of the source cluster.
  3. Rebalances data slices to the default per node, which leads to even data distribution across nodes.

Considerations

  1. The size of the data on the source cluster must be below 2 petabytes (PB). Use the Snapshot/Restore approach for data larger than 2 PB.
  2. Before initiating, make sure a manual snapshot is available that is no more than 10 hours old. If not, take a new manual snapshot.
  3. The snapshot used to perform the Classic Resize can’t be used for a table restore or other purpose.
  4. The cluster must be in a virtual private cloud (VPC).
  5. While the resize is in progress, queries can take longer to complete. Consider enabling concurrency scaling.
  6. Drop tables that aren’t needed before performing a Classic Resize to accelerate data distribution.
  7. Classic Resize takes more time to complete than Elastic Resize.
  8. Plan and schedule the resize operation during off-peak hours or maintenance windows.

You can use either the console or the following AWS CLI command to initiate a Classic Resize.

To run a Classic Resize through the console, follow the resize instructions in the preceding section and choose Classic resize, as shown in the following screenshot.

Resize cluster console showing Classic resize selected as the resize type

Classic Resize using the AWS CLI

# Initiate Classic Resize via AWS CLI
aws redshift resize-cluster \
    --cluster-identifier <my-ra3-cluster> \  # Source cluster ID
    --node-type rg.4xlarge \                 # Target RG node type
    --number-of-nodes <#nodes> \             # Target node count
    --classic                                # true = Classic Resize

To monitor a Classic Resize of a provisioned cluster in progress, including KEY distribution, use SYS_RESTORE_STATE. It shows the percentage completed for the table being converted. You must be a superuser to access the data.

Elastic Resize vs. Classic Resize

Behavior Elastic Resize Classic Resize
System tables Elastic Resize retains system log data. Classic Resize doesn’t retain system tables and data.
Changing node types When the node type doesn’t change, Elastic Resize is an in-place resize and most queries are held. With a new node type selected, a new cluster is created and queries are dropped as the resize completes. A new cluster is created. Queries are dropped during the resize.
Session and query retention Elastic Resize retains sessions and queries when the node type is the same in the source and target. If you choose a new node type, queries are dropped. Classic Resize doesn’t retain sessions and queries. Queries are dropped, and you can expect some performance degradation. Run the resize during a period of light use.
Canceling a resize operation You can’t cancel an Elastic Resize. For a Classic Resize to an RG or RA3 cluster, you can’t cancel.

3. Snapshot, Restore, Resize

Use this method when you need near-constant write access during the migration, or when you want to validate the new RG setup without affecting the existing cluster.

Steps

  1. In the Amazon Redshift console, choose Provisioned clusters dashboard, select your source cluster, choose Actions, then choose Create manual snapshot. Specify a snapshot name and choose Create snapshot.
  2. Select your snapshot.
  3. Choose Restore from snapshot.
  4. Specify the cluster ID and configuration (target cluster).
  5. Verify that the sample data exists in the target cluster by following these steps:
    1. Connect to the target cluster using the new endpoint.
    2. Run SELECT COUNT(*) FROM <table_name> for key tables and compare counts with the source cluster.
    3. Verify that all schemas exist.
    4. Validate that user permissions were restored correctly.
  6. If you write data to the source cluster after taking the snapshot, manually copy the data to the target cluster.
  7. Update your application connection strings to use the new cluster endpoint.

Advantages

  1. Allows validation of the new RG setup without affecting the existing cluster.
  2. Offers flexibility to restore to different Regions or Availability Zones, which provides additional disaster recovery options.
  3. Minimizes the amount of time that the cluster is unavailable for write operations.

Considerations

  1. Setting up the new cluster and restoring data can take longer than Elastic Resize.
  2. Any data written to the source cluster after the snapshot must be copied manually to the target cluster.
  3. A new Amazon Redshift endpoint is created, so connection string changes are required.
  4. To keep the cluster endpoint the same, consider renaming both clusters so the new target cluster has the same name as the original source cluster.

Fallback

You can revert to RA3 at any time using any of the migration approaches described earlier.

DMS, Zero-ETL, and data sharing considerations during migration

If your Amazon Redshift cluster is an AWS Database Migration Service (AWS DMS) target, has Zero-ETL integrations, or is a data sharing producer, keep the following in mind when resizing from RA3 to RG.

AWS DMS change data capture (CDC) tasks aren’t impacted by the resize. The replication instance operates independently and resumes writing after the cluster is available. No task restart is required.

Zero-ETL tables temporarily become unavailable during the resize and enter a resync state. How long the resync takes depends on data volume. Use svv_integration_table_state to check when all tables are back to Synced. For additional details, see Zero-ETL considerations.

When you resize a producer cluster, data sharing is temporarily unavailable while connections transfer to the new cluster. This typically lasts several minutes. Consumer clusters can’t access shared data during this period. After the resize completes, data sharing resumes automatically with no reconfiguration needed. Plan a brief outage window for consumer workloads that depend on the producer being resized.

Snapshot/Restore impact on DMS, Zero-ETL, and data sharing

Zero-ETL integrations are tied to the original cluster. A restored cluster is treated as a new cluster, so replication doesn’t automatically resume. After the restore, you need to create a new Zero-ETL integration pointing to the restored cluster. It performs an initial sync to bring the data current.

AWS DMS connections are endpoint-based. A restored cluster receives a new endpoint, so AWS DMS tasks won’t automatically connect to it. After the restore, you must update the AWS DMS endpoint configuration with the new cluster address and restart the migration tasks.

Data sharing is tied to the cluster namespace. A restored cluster has a different namespace, so existing data shares don’t carry over. As a producer, you need to create new data shares and re-share them with consumer clusters. As a consumer, you lose access until the producer reestablishes the share from the new cluster.

Migration best practices

  1. Inform downstream teams before the migration. This includes data sharing consumers, Zero-ETL applications, and BI/ETL pipelines.
  2. Schedule the migration during a maintenance window to reduce impact on production.
  3. Take a manual snapshot before starting the resize. This serves as your rollback point.
  4. Test your target RG configuration with a representative workload before migrating production.
  5. Confirm that downstream applications are working after completion.

Clean up

To avoid incurring future charges, delete the RG provisioned cluster and any manual snapshots created during migration testing. Deleting a cluster permanently removes all data. Make sure you are deleting only the test cluster. Consider taking a final snapshot before deletion if you need to retain any test data.

Conclusion

In this post, we covered the migration options, considerations, and best practices for upgrading Amazon Redshift RA3 instances to Graviton-based RG instances. For more details on the performance benefits of RG, see the announcement blog post.

Start upgrading to Amazon Redshift RG instances today and take advantage of better price-performance with the guidance in this post. For architectural support or proof of concept (POC) assistance, contact AWS Support.

About the authors

Nita Shah

Nita Shah

Nita is a Sr. Analytics Specialist Solutions Architect at AWS based out of New York. She has been building enterprise data platforms, data warehousing, and analytics solutions for over 20 years and specializes in Amazon Redshift. She is focused on helping customers design and build enterprise-scale well-architected analytics and decision support platforms.

Ankit Sahu

Ankit brings over 18 years of expertise in building innovative data products and services. His diverse experience spans product strategy, go-to-market execution, and digital transformation initiatives. Currently, as Sr. Product Manager at Amazon Web Services (AWS), Ankit is driving the vision and strategy for Amazon Redshift.

Vinayaka Gangadhar

Vinayaka is an Analytics Specialist at Amazon Web Services (AWS), where he helps customers build and troubleshoot scalable data platforms and derive meaningful insights through AWS analytics services, with deep expertise in Amazon Redshift and Amazon OpenSearch. When not solving complex analytics challenges, he enjoys exploring new technologies and spending quality time with his family. LinkedIn: /vinayaka-gangadhar

Ricardo Serafim

Ricardo Serafim

Ricardo is a Senior Analytics Specialist Solutions Architect at AWS.

[$] The state of Fedora in 2026

Post Syndicated from jzb original https://lwn.net/Articles/1077832/

On June 15 at Fedora’s Flock conference, held in
Prague, Fedora Project Leader (FPL) Jef Spaleta delivered a short “State of
Fedora” keynote that provided a bit of insight into the status of the
project. Topics included the overall growth for Fedora usage, ways to increase
contributions, and an alarming decline in the number of active packagers working
on the project.

KDE Plasma 6.7 released

Post Syndicated from jzb original https://lwn.net/Articles/1078160/

Version
6.7 of KDE’s Plasma desktop has been released. Notable changes in
this release include per-screen virtual desktops, faster desktop
switching, introduction of the Union
theming system as a tech preview, as well as many other improvements and bug
fixes. The release is dedicated to Eric Laffoon, a longtime KDE
supporter, who passed away in May.

See the KDE
wiki for a full list of new features, and the Changelog
for a list of all commits in this release.

Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Post Syndicated from Анета Василева original https://www.toest.bg/protestite-v-albaniya-ili-kak-arhitekturata-otnovo-izleze-na-terena-na-politicheskoto/

Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Оказах се в Албания точно в началото на т.нар. Фламингова революция. На 30 май протестиращ беше влачен от охраната на заградена зона в природния резерват до Звърнец, а аз преминах границата с Гърция на път за Тирана и две важни архитектурни събития, които предстояха там през първата седмица на юни. Тогава все още не беше ясно, че протестите ще станат това, което са в момента, а архитектурата ще се окаже буквално в центъра им. 

И все пак още в първите дни нещо го подсказваше. 

„Аз съм родом от Вльора. Трябва да отидете до Звърнец, там е прекрасно. Искат да го застрояват“, каза ми Арта, собственичка на малък семеен хотел на крайбрежието в Южна Албания. „Е, не протестирате ли?“, попитах аз. „Да, но нищо няма да стане“, отговори тя и се върна в кухнята, където всичко се готвеше с продукти от градината им. 

От 15 години само строим. Най-големият ни страх е да не изгоним чуждите инвеститори,

каза ми няколко дни по-късно приятел архитект, вече в Тирана. Протестите бяха започнали, а ние се качвахме по стъпалата на Пирамидата в центъра на града, бивш музей на комунистическия диктатор Енвер Ходжа, а днес стартъп хъб, реконструиран през 2023 г. по проект на холандското суперстудио MVRDV. Беше третият ден на протести, а от върха на пирамидата се виждаше, че хората са наистина много. 

Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Пирамидата в Тирана – денем и по време на протестите вечер © Анета Василева

„Видя ли интервюто на Иванка? Скандално. Мисля, че то вбеси хората най-много“, отбеляза Виола, също архитектка, на другата вечер пак в Тирана. Виола е албанка, израснала в Канада, дете на емигранти от 90-те. В момента е университетска преподавателка в Торонто, дошла за същата конференция за опазване на модернизма в Албания като мен. Имаше предвид интервюто на Иванка Тръмп за Дейвид Сенра от края на май, в което дъщерята на американския президент описва своята находка в Средиземно море – необитаемия остров Сазан, на запад от албанския бряг, който със съпруга си Джаред Къшнър „откриват“ съвсем случайно, докато са на яхта на приятели и спират да поплуват. „Плувахме до острова. Изкачихме се пеша, боси чак до върха и просто бяхме очаровани“, казва Иванка. Действително скандално, особено като се има предвид, че островът не е частен, както тя го нарича, а бивша държавна военна база с много стар бетон, по който, освен всичко друго, доста трудно се ходи бос. 

Сега ще се опитам да обясня как и защо именно архитектурата е толкова тясно преплетена с политическите вълнения в Албания в момента и всъщност до огромна степен е тяхна първопричина. 

Застрояването и Албания

В Албания се строи много – и навсякъде. Усещането е като в България в началото на по-миналото десетилетие, онзи пръв строителен бум, който преживяхме след 2000 г., преди да влезем в Европейския съюз, и който де факто съсипа градовете, планините и черноморското ни крайбрежие. 

Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Презастроявяне на пристанището във Вльора и в Тирана © Анета Василева

Строителството е свързано с непоклатимата неолиберална вяра в трансформиращата роля на свободния пазар, която всички бивши комунистически държави в Европа споделят. Разбираемо – след провала на държавния социализъм и сивата пустош, която той оставя навсякъде в края на 80-те. И после идват 90-те, с цялата им мътилка, липса на правила и регулации, с неясния произход на частния капитал, с всички балкански войни, мутри, бедност и кич. Най-неподходящото време, в което да се говори за публично пространство, общество и колективна (архитектурна) отговорност. Строителството е и много успешен начин за пране на пари.

Албания обаче е преживяла много, много повече от България. Страната получава независимост от Османската империя едва през 1912 г. През 1939 г. вече е окупирана от фашистка Италия на Мусолини (италианските архитектурни влияния са видими и до днес). Партизаните комунисти на Енвер Ходжа вземат властта в края на Втората световна война, флиртуват със Сталин, после с Тито, най-дълго с Мао и Китай, за да изолират държавата в края на 60-те от целия свят, включително от Източния блок. И да построят близо 200 000 бункера из цялата страна в параноичен опит да се отбраняват от всички на всяка цена. Балканска версия на Северна Корея, както гласи любимото клише на западните медии, когато пишат за Албания. 

Комунистическият режим тук пада най-късно – чак през 1992 г.,

и албанците се втурват да емигрират – първо към Италия, а оттам и към целия най-после отворен свят. Останалите в страната първо започват да купуват коли (през 1992 г. в Тирана има само 200 леки автомобила), а после да строят – навсякъде. Приватизацията на държавната собственост е още по-тъмна и хаотична, отколкото в България, и през 90-те не е ясно коя земя на кого е, затова всички строят където им падне – магазини, бараки, къщи, ресторанти – всичко. Качеството е ужасно, градовете (и особено Тирана) не приличат на нищо. 

И тук на сцената излиза главният герой в албанския политически живот и до днес – художникът Еди Рама, който става кмет на Тирана през 2000 г. Той заварва посткомунистически хаос с куп незаконни сгради, висока престъпност, никакви публични пространства, проблеми с боклука и канализацията и много сиви сгради навсякъде. Рама става международно популярен с радикалното си решение да боядиса целия град в ярки цветове – евтино и ефектно, а и логично за един художник, който познава психологията на цветовете. Отделно, той събаря хиляди незаконни постройки и изчиства от тях бреговете на река Лана, за да създаде нови паркове и обществени зони. Няколко пъти го пребиват. 

Изобщо – герой. Рама става любимец на световните медии, на лъскавите списания за архитектура, дизайн и градски живот, а през 2004 г. печели международната награда „Кмет на годината“. Той е лице на неолиберализма на Балканите, оглавява Социалистическата партия на Албания, приятел е с Тони Блеър, обявява, че страната ще се развива прогресивно и по трети път – без ляво и дясно. 

През 2020 г. албанският архитект и преподавател Саймир Кристо много добре описва ситуацията с Тирана и цветовете на Рама в една своя статия за холандския архитектурен портал Archined:

Това не е наивен опит да се разведрят жителите на Тирана, за да забравят авторитарния режим, който е властвал почти половин век. В крайна сметка никога не се започва от нулата след падането на един режим. Днес в Тирана по-скоро наблюдаваме директния западен маниер да се представят посткомунистическите страни като сиви, а капитализмът и развитието – като „жизнени“ и „цветни“.

Еди Рама и архитектурата

Днес Еди Рама е министър-председател на Албания за четвърти пореден мандат и е обещал страната да влезе в Европейския съюз до 2030 г. А основното му оръжие за международен престиж, привличане на чуждестранни инвеститори, развитие на туризма и икономиката и преобразяване на страната е едно – архитектурата. Еди Рама обича архитектурата и обожава световноизвестните архитекти. 

От 2008 г., когато белгийското студио 51N4E печели международния архитектурен конкурс за реконструкция на централния площад „Скендербег“ в Тирана, до ден днешен градът е истинска площадка за игра на архитектите от цял свят. И нямам предвид само поувехналите стархитекти (т.нар. архитекти звезди на миналото), а всички, включително „социално отговорните“ сред тях. През 2019 г. Общинският съвет на Тирана одобрява новия общ устройствен план на града, разработен от италианското студио Stefano Boeri Architetti и кръстен неслучайно „Тирана 2030“. Планът предвижда компактен полицентричен град с много нови публични пространства, линейни паркове и екологични коридори, 2 млн. нови дървета и всички модни думи на съвременното градоустройство. Той отприщва безпрецедентен строителен бум, който превръща Тирана в град на кули и купища нови строежи, докато се задъхва в задръствания и липса на паркоместа. 

В момента в столицата се проектират, строят или имат разрешение за строеж над 140 небостъргача

на принципа на наложеното от Еди Рама публично-частно партньорство. Албанските архитекти са изключени от процеса. Те чертаят техническите проекти, обслужват разрешенията за строеж и критикуват властта, че инвестира в нови публични пространства не заради жителите на Тирана, а за да повишава пазарната стойност на новите частни инвестиции из града. Легендарен е списъкът на Еди Рама с над 150 чуждестранни архитектурни студиа, измежду които той избира на кого какви проекти да възлага. Особена е слабостта му към популярни архитекти и носители на наградата „Прицкер“, а всички те нямат нищо против да играят ролята на придворни проектанти на албанския „владетел“. 

Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Downtown One Tirana е почти завършен 140-метров небостъргач, проектиран от холандското студио MVRDV и известен с пикселизираната си фасада / Двете кули, проектирани от белгийското студио 51N4E – TID Tower (вляво) и Book Building (вдясно) / Новите цветни фасади на реконструирания стар базар в Тирана / 85-метровият небостъргач Skanderbeg Building, проектиран от холандското студио MVRDV като фигуративна скулптура, пресъздаваща лицето на албанския национален герой, а според някои – приличаща и на Еди Рама © Анета Василева

В интерес на истината, всички тези нови сгради са безкрайно интересни и в момента Тирана е колоритна мозайка от всякакви стилове и архитектурни похвати на фона на хаотично-еклектичното си постсоциалистическо наследство. На всичко отгоре новите сгради и пространства са проектирани добре, повечето са изпълнени отлично. Взети сами за себе си, са чудесни примери за съвременна архитектура с ниво на детайл и качество на изпълнение, за които съвременната българска архитектура може само да мечтае. Всъщност тя си мечтаеше точно за същото някъде около 2008 г., когато стартира първата Седмица на архитектурата у нас (т.нар. Sofia Architecture Week – SAW) – затворено платено събитие за инвеститори, институции и международни архитекти, което да даде старт на една друга София на визии, конкурси и чуждестранни архитектурни проекти. 

Но не се получи. За добро или за лошо, в София така и няма сграда или примерно площад на „световноизвестен архитект“. А усилията на целия екип на списание ЕДНО и SAW да убедят българската власт, че си струва да се инвестира в звездна архитектура и дизайн, така и не хванаха на каменистата българска почва поради липса на местен Еди Рама. Може би е било за добро.

Защото през първата седмица на юни в Тирана ме беше срам, че съм архитект от чужбина. 

Точно тогава Еди Рама посрещна световния архитектурен елит – буквално всички, за които човек може да се сети – на второто поредно издание на фестивала Bread and Heart. Събитието беше в Book Building, последната кула, проектирана от белгийските любимци на Рама 51N4E до площада „Скендербег“. Албанските архитекти по принцип бойкотираха форума. И как не – от години те се чувстват сведени до чертожници на чужденците. Намерих само една местна позната, която беше посетила целия форум и която сподели:

 Аз ги питах какво мислят за корупцията и за протестите, за презастрояването и проблемите, а те ми казаха: „Ние какво можем да направим, дошли сме тук да проектираме и да строим. Вашите неща си ги оправяйте вие, ние нищо не можем да направим.“

Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Book Building / Полицаи (на сянка под дървото), пазещи архитектите от протестиращите / Екран с Еди Рама и протестиращи, които го освиркват © Анета Василева

Интересното беше, че достъпът до цялата сграда беше блокиран, ограждения прекъсваха пешеходното движение към площада, а полицаи пазеха архитектурния елит от любовта на тълпата. Защото през първите дни на протестите в Тирана те завършваха именно пред Book Building и освиркваха не само екрана с образа на Рама, опънат на един от ъглите на сградата и предаващ на живо, но и архитектите вътре. Архитектите, които обслужват чужденците, които ще застроят тяхната Албания. „Еди Рама е свършен!“ беше единият от най-популярните възгласи тогава. Другият – „Албания не е за продан!“.

А сега да се върнем на протестите.

Edi Rama ka mbaru, ka mbaru!1

Големите протести в Албания започнаха в началото на юни като екологични – срещу намеренията за строителство на луксозен курорт в защитените природни зони на остров Сазан и лагуната Вьоса-Нарта – ценна средиземноморска влажна зона, която предоставя убежище на над 200 вида птици и повече от 70 застрашени вида. Инвестицията се свързва с имената на Иванка Тръмп и съпруга ѝ Джаред Къшнър. Зад нея стоят няколко компании с неясни или криминални собственици, а проектът получава предварително одобрение като стратегическа инвестиция от албанското правителство през декември 2025 г. Междувременно защитената зона е намалена като обхват, а през 2021 г. е разрешено в района да се изгради летище. Еди Рама подкрепя проекта, който е оформен като обичайното публично-частно партньорство, тъй като островът все още е държавен, но брегът вече е частен.

Протестите в Албания, или как архитектурата отново излезе на терена на политическото
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Природният резерват, който Иванка Тръмп и Джаред Къшнър „откриват“ и планират да застроят © Анета Василева

Следват разкрития за устройствени и архитектурни планове за курорта от ноември 2025 г., които вбесяват още повече протестиращите заради стотиците хиляди квадратни метри застроена площ, които се предвиждат, хилядите жилища и хотелски стаи и визията за затворен ултралуксозен резерват само за свръхбогати. За няколко дни протестите се разраснаха в пъти, състояха се и в други градове освен Тирана и Звърнец, хората излизат на улицата ежедневно, а тълпата в Тирана расте с всеки следващ ден. Това вече са политически протести – за оставката на Еди Рама и цялото правителство, срещу целия управляващ елит, включително срещу опозиционния лидер Сали Бериша, който подкрепя курорта.

Архитекти в Тирана ми пишат, че последните дни протестите са станали и националистически – именно като реакция срещу чуждестранните инвеститори, които правителството на Рама толкова цени, и защото „Албания не е за продан“. 

Архитектурата и властта

За мен е важно да осъзнаем ролята на архитектурата като инструмент на властта – за пореден път болезнено оголена и в този албански случай.

Архитектура и диктатори
Архитектурата никога не е само изкуство и винаги е била политическа, винаги е флиртувала с властта, категорична е Анета Василева в най-новия си текст. В него с редица красноречиви примери тя се движи…
Протестите в Албания, или как архитектурата отново излезе на терена на политическотоТоестАнета Василева
Протестите в Албания, или как архитектурата отново излезе на терена на политическото

Еди Рама е лицето на либералната демокрация – такава, каквато я познаваме от Клинтън и Обама, на онази американска Демократическа партия, която загуби последните избори и отвори път към една съвсем различна Америка. Това, което се случва в Тирана и Албания в момента, е като надгробен камък на неолиберализма от първите две десетилетия на нашия век. Точно като библиотеката „кенотаф“ на Барак Обама в Чикаго, която отвори врати този същия юни под канонада от критики. Стархитектите вече са в миналото. Големите студиа отмират. Необходимо е адаптивно преизползване на ресурси. В същото време има потребност от качество и отношение – към средата, към хората, към контекста. Арогантната архитектурна самоувереност е неадекватна за времето ни, архитектурното его само пречи, а лицемерието винаги излиза наяве – рано или късно. 

Именно срещу това реагираха ожесточено албанските архитекти по време на фестивала Bread and Heart в Тирана. Под бляскавите постове в социалните мрежи за изминалите дни на „вдъхновение и споделени идеи“, чиито автори очевидно не чуваха гласовете на тълпата под прозорците на Book Building, те пишеха гневни коментари в социалните мрежи, които биваха изтривани.

Завършвам с един такъв изтрит коментар на албанската архитектка и преподавателка Мамица Бурда:

Всички говорят за деколонизация, отстояване на пространства, отказ от растежа, регенерация, пространствена справедливост, колективна грижа, общи блага, общности, адаптивно преизползване, бъдеще без въглеродни емисии и други модни концепции. Веднага щом човек започне да работи в бедни страни с висока степен на корупция и пране на пари обаче, принципите изведнъж се променят. Албания определено е лакмус за съвременната архитектурна практика. Тя показва дали архитектите наистина отстояват ценностите, които пропагандират – социална отговорност, устойчивост и обществен интерес, – или тези принципи изчезват, когато се сблъскат с възможност за печалба и популярност.

1 „Еди Рама е свършен, свършен е!“ (алб.) – най-често скандираният възглас в първите дни на протестите в Тирана.

Security updates for Tuesday

Post Syndicated from jzb original https://lwn.net/Articles/1078158/

Security updates have been issued by AlmaLinux (mod_http2, postfix, and webkit2gtk3), Debian (bird2, libgd-perl, and libreoffice), Fedora (7zip, ack, hugo, and perl-Mojo-JWT), Mageia (atril, evince, xreader, emacs, lcms2, libgcrypt, libinput, libsndfile, putty, and sudo), Red Hat (openssl and osbuild-composer), SUSE (cheat, chromedriver, containerized-data-importer, cyrus-imapd, freeipmi, graphicsmagick, java-11-openj9, java-17-openj9, kitty, kubevirt, kubevirt-1.6, libcaca, libopenssl-3-devel, librav1e0_8, neonmodem, opensc, openssh, openssl-1_0_0, openssl-1_1, openssl-3, perl-HTTP-Daemon, perl-XML-LibXML, python-python-dotenv, python311-paramiko, python311-PyJWT, python311-starlette, python311-tornado6, qemu, restic, and trivy), and Ubuntu (adsys, cups, fastnetmon, freerdp2, freerdp3, mesa, nginx, rsync, ruby2.3, ruby2.5, and tmux).

Cloudflare DMARC Management is now generally available

Post Syndicated from Ayush Kumar original https://blog.cloudflare.com/dmarc-management-ga/

When we first launched DMARC Management, it was driven by a simple belief: every domain on the Internet deserves strong email authentication, and cost should never be the reason it doesn’t happen. As part of our mission to help build a better Internet, we made DMARC Management available for free to every Cloudflare customer. We wanted to give everyone the tools to understand and improve their DMARC posture without needing to hire an email security consultant or parse XML report files by hand.

Today, we are taking that commitment further. Cloudflare DMARC Management is now generally available, with a redesigned experience built to help you reach full DMARC enforcement as easily as possible.


The DMARC Management dashboard offers a unified view of your email authentication posture.

What email authentication actually does for you

Every time someone receives an email “from” your domain, their email provider asks a simple question: did the real owner of this domain actually send this? Without a way to answer that question, anyone can send an email pretending to be you and your recipients will have no way to tell the difference.

Email authentication is the set of DNS records that answers that question. There are four protocols that protect your domain:

  • SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are allowed to send email on behalf of your domain.

  • DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every email you send, so receiving servers can verify the message hasn’t been tampered with in transit.

  • DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication: let it through, quarantine it, or reject it outright. It also sends you reports on who is sending email as your domain.

  • BIMI (Brand Indicators for Message Identification) lets you display your brand logo next to your emails in supported inboxes, but only if your DMARC policy is strong enough.

When all four are configured correctly, spoofed emails get blocked before they reach anyone’s inbox and your legitimate emails are far more likely to be delivered. When they’re missing or misconfigured, you’re exposed to brand impersonation and deliverability penalties from the large email mailbox providers.

DMARC is no longer optional

DMARC has always been important. But over the past two years, the stakes have gotten significantly higher. Google, Microsoft, and Yahoo have all announced or implemented stricter email authentication enforcement. Domains that do not have proper DMARC, SPF, and DKIM records configured (or worse, have them configured incorrectly) are increasingly seeing their legitimate emails land in spam folders or get rejected outright. What was once a best practice is now a requirement. Poor email hygiene directly translates to poor deliverability, and for many businesses, that means lost revenue and missed communications.

The message from the industry is clear: if you send email from your domain, you need these records configured correctly. The grace period is over.

The problem: DMARC is confusing, and mistakes are costly

Here is the challenge. The journey from p=none (monitor only, no emails are blocked) to p=quarantine (suspicious emails are sent to spam) to p=reject (unauthenticated emails are blocked outright) is filled with uncertainty. Enable enforcement too early, and you risk breaking legitimate email flows from third-party services you forgot were sending on your behalf. Move too slowly, and you leave your domain exposed to spoofing, and now, to deliverability penalties from the very providers your customers use.

Most organizations know they need DMARC enforcement. But actually getting there requires understanding aggregate XML reports, identifying every legitimate sending source across your infrastructure, and building enough confidence that tightening your policy will not break anything.

We built Cloudflare DMARC Management so that any customer can navigate this journey on their own. No need for professional services engagement. No spreadsheet analysis of aggregate reports. No guessing which IP address belongs to which vendor. The goal is to make the path to full DMARC enforcement as self-service as possible, giving you the visibility and confidence to tighten your policy without breaking anything.


DMARC reports show sending source alignment across your domain.

What we shipped

Deeper report visibility with source investigation

We redesigned the reporting experience to make it easier to understand what is happening with your email traffic. You can now see at a glance which sending sources are passing or failing DMARC, SPF, and DKIM alignment and drill deeper than ever before.

Every report now surfaces the source IP address alongside the sending service, giving you the granularity to distinguish between legitimate infrastructure and unauthorized senders. You can now open any IP address directly in our Investigate tab, which surfaces all the threat intelligence Cloudflare has on that address — reputation data, geolocation, autonomous system number (ASN) details, and any known associations with malicious activity.

This turns your DMARC reports from a passive data feed into an active investigation tool.



Drilling into a sending source reveals IP-level detail and Cloudflare threat intelligence in the Investigate tab.

What you see

What it tells you

Source IP address

The specific infrastructure sending email on behalf of your domain

Sending service name

The organization or provider behind the IP

DMARC / SPF / DKIM alignment

Whether each authentication check passed or failed for that source

Investigate tab

Cloudflare threat intelligence: reputation, geolocation, ASN, and known threat associations

Email authentication record status

One of the most common questions customers ask is: “Are my records set up correctly?”

Until now, answering that question required manually inspecting DNS TXT records and understanding what each tag and value means across multiple specifications. With this release, you can see the status of every email authentication record you need: DMARC, DKIM, SPF, and BIMI, in a single view.

Each record type gets a clear pass, warning, or fail status based on automated analysis. You can drill into any record to see specific findings about what we detected and recommendations for how to fix it. If your DKIM key is malformed, we flag it. If you are missing a BIMI record and your DMARC policy is strong enough to support one, we let you know that too.


Record analysis cards show pass, warning, or fail status for each email authentication record, with actionable recommendations.

The recommendations are written in plain language, not RFC jargon. The goal is to make it obvious what action to take next, regardless of your email security expertise.

Record

What we check

SPF

Multiple records, lookup limits, permissive +all, missing mechanisms

DKIM

Key formatting, missing or malformed public keys

DMARC

Policy strength, monitoring vs. enforcement, reporting configuration

BIMI

Logo URL format, Verified Mark Certificate (VMC)  presence

SPF lookup audit

This one addresses a problem that silently breaks email for more organizations than you would expect. The SPF specification (RFC 7208) imposes a hard limit of 10 DNS lookups per SPF evaluation. Every include:, a, mx, redirect, and exists mechanism in your SPF record counts toward that limit, and so do the nested lookups inside each include:. Exceed 10 and receiving mail servers return a permerror, which means your SPF check fails entirely.

Most people have no idea they are over the limit until their email starts getting rejected.

DMARC Management now lets you audit your SPF record and see exactly how many lookups it incurs. You can drill into every mechanism in the record, see which include:chains are the most expensive, and identify where to consolidate or flatten your record to get back under the limit.


The SPF lookup audit traces every DNS lookup in your SPF record, showing exactly where you are against the 10-lookup limit.

Getting started

To use DMARC Management, you need to have your domain’s DNS on Cloudflare. Then you can turn on DMARC Management under the Email tab for that domain in the Cloudflare dashboard.

1. Navigate to your domain in the Cloudflare dashboard.

2. Go to Email > DMARC Management.

3. Follow the setup wizard to start receiving DMARC reports.

4. Review your record analysis and recommendations.

5.  Work toward p=quarantine (suspicious emails go to spam) or p=reject (unauthenticated emails are blocked entirely) at your own pace.

What’s next

We are going to continue building on top of DMARC Management, and our goal is to keep it accessible. We have several things planned that we are excited to ship: deeper forensic reporting, smarter recommendations, and tighter integration with the rest of the Cloudflare platform.

If you are not yet using Cloudflare for your DNS, you can get started here. Once your domain is on Cloudflare, DMARC Management is available immediately with no additional configuration or cost required.

Your domain is either protected or it isn’t. Head to Email > DMARC Management in your Cloudflare dashboard to get started.

What students and teachers in England want from a computing curriculum

Post Syndicated from Rachel Arthur original https://www.raspberrypi.org/blog/what-students-and-teachers-in-england-want-from-a-computing-curriculum/

The UK Government is undertaking the first major review of England’s curriculum and qualifications system since the current national curriculum was introduced in 2014. We believe that this is an excellent opportunity not simply to update the computing curriculum content, but to reconsider what computing education is for, who it serves, and how it prepares young people for life in a digital society.

Today, we are launching a report featuring 6 key priorities for curriculum reform based on discussions we have had with students and teachers. 

Students and educators sit at a table discussing England's curriculum review and The Future of England's Computing Curriculum.

Putting students and teachers at the heart of the conversation 

Too often, curriculum reform happens around students and teachers rather than with them. Yet these are the people who experience computing education every day, and they have valuable insights into what is working, what is not, and what needs to change. 

Our new report is based on a series of student focus groups and teacher workshops held by us and the University of Cambridge in Manchester, London, and Cambridge during spring 2026.

Teachers sit at a table discussing England's curriculum review and The Future of England's Computing Curriculum.

The student discussions included young people currently studying computer science at GCSE and A level (ages 14–18), as well as young people who had decided to not continue with the subject. We also brought together 18 computing teachers from secondary schools across England to explore curriculum priorities and challenges for implementation. 

Although participants in our workshops had differing perspectives, they consistently pointed to the same underlying challenge: the current curriculum no longer reflects the realities of technology, work, or young people’s lives. 

“AI is everywhere now, we need to understand how it works, not just be told not to use it.”
– Student, London

In particular, many students highlighted a lack of confidence in their practical digital skills despite using technology constantly in everyday life.

“I can code a bit, but I don’t know how to use Excel properly, that’s what I’ll actually need.”
– Student, London

Calls for a practical, relevant, inclusive, and future-facing curriculum

Students and teachers are not calling for a less rigorous curriculum. Nor are they arguing that computing should lose its technical foundations, with teachers consistently emphasising the value of understanding computational thinking, programming, algorithms, data, and computer systems and networks.

Instead, students and teachers want to make computing education more practical, relevant, inclusive, and future-facing.

Teachers sit at a table discussing England's curriculum review and The Future of England's Computing Curriculum.

Teachers particularly emphasised the importance of helping students understand how AI systems function, including issues such as bias, training data, limitations, and ethical implications. Participants argued that computing education should help young people understand the technologies shaping their lives, not simply prepare them for examinations. Perhaps the strongest area of agreement was that curriculum reform will only succeed if it is matched by investment in teaching.

Six key priorities for curriculum reform 

Based on our discussions with students and teachers, we have identified several priorities for curriculum reform.

1. Guarantee a core digital education for every young person

All students should leave school with a strong foundation in digital literacy, online safety, data awareness, and AI literacy. These should be treated as essential components of modern education, not optional extras.

2. Modernise curriculum content

The curriculum should focus on contemporary technologies and concepts, including AI, cybersecurity, and data, while trimming content that is overly specific, outdated, or disconnected from modern practice. Foundations such as programming, algorithms, and computational thinking should remain central.

3. Prioritise practical and applied learning

Computing should be taught through making, experimentation, and problem solving. Project-based learning, physical computing, and relevant, real-world applications should become central approaches across all ages.

4. Introduce greater flexibility and specialisation

The revised curriculum should balance a shared foundation with opportunities for students to specialise in areas aligned with their interests and aspirations.

5. Embed inclusion throughout the curriculum

Any reforms should actively address barriers to participation by ensuring inclusive teaching approaches, diverse, relatable role models, and accessible learning experiences.

6. Invest in teachers and implementation

Curriculum reform must be accompanied by sustained investment in teacher recruitment, professional development, and classroom resources. Without this, reforming the curriculum  risks widening existing inequalities in provision.

Read our full report

We believe listening to students and teachers should be central to curriculum reform. You can read the full report now:

Download the report PDF

The post What students and teachers in England want from a computing curriculum appeared first on Raspberry Pi Foundation.

AWS WAF adds AI traffic monetization capability to help content owners charge AI bots for content access

Post Syndicated from Esra Kayabali original https://aws.amazon.com/blogs/aws/aws-waf-adds-ai-traffic-monetization-capability-to-help-content-owners-charge-ai-bots-for-content-access/

AWS WAF now includes AI traffic monetization capability that gives digital content owners and publishers a way to charge AI bots and agents for access to protected web content directly at the network edge. The capability helps content owners and publishers set per-request pricing by content path, bot category, or verification tier without modifying their origin infrastructure or writing application code. Content owners can define granular access policies per agent type, collect payments in stablecoins to their preferred wallet, and monitor revenue and bot activity from a single dashboard.

AI bot traffic now accounts for more than 50% of web traffic for many content providers, with AI-specific crawlers growing more than 300% year-over-year. Unlike traditional search engine crawlers, which index content and return measurable referral traffic back to publisher websites, AI bots consume the same content to generate summaries and responses in AI interfaces, with little to no traffic sent back to the original source. Publishers bear the infrastructure costs of serving that traffic without the page views, ad impressions, or subscription conversions that typically offset those costs. AWS WAF Bot Control already gives customers visibility into bot activity and the ability to block or rate-limit traffic, but setting pricing and collecting payment from AI agents has not been possible until now. AI traffic monetization is a new Bot Control capability that closes that gap, giving content owners and publishers a way to configure pricing rules directly through the AWS WAF console and collect payments from AI agents through third-party payment integrations, without building custom payment infrastructure or negotiating individual licensing agreements. Payment settlement and verification flows are provided by Coinbase’s x402 Facilitator. Integration with Stripe for direct account payments and Machine Payments Protocol (MPP) support is coming soon.

Getting Started with AI Traffic Monetization
Before configuring monetization, confirm that AWS WAF Bot Control is enabled at Common or Targeted level on the web ACL associated with your CloudFront distribution. Bot Control provides the agent classification that monetization rules depend on. If you have not set this up yet, visit Adding the AWS WAF Bot Control managed rule group to your web ACL documentation. In the AWS Management Console, go to WAF & Shield and choose Protection packs (web ACLs) in the left navigation pane to get started.

A protection pack is the core configuration unit for AI traffic monetization. It defines which content paths are monetized, what each agent verification tier is charged, which payment methods you accept, and what license terms apply. To create one, choose Create protection pack (web ACL).

In Tell us about your app, select one or more app categories that describe your content (for example, Content & publishing systems, E-commerce & transaction platforms, or Enterprise & business applications), and choose an App focus. AWS WAF uses these selections to recommend suitable security protections for your configuration.

In Select resources to protect, choose Add resources to associate regional or global resources such as CloudFront distributions with this protection pack. You can skip this step and add resources later.

In Choose initial protections, select from AWS WAF managed rule packages based on your app category and resource selections. You can also choose individual rules instead of packages.

In Name and describe, provide a name and optional description for the protection pack.

Optionally, expand Customize protection pack (web ACL) to configure additional settings including pricing tiers, payment methods, content scope, and license terms.

When finished, choose Create protection pack (web ACL).

Once your protection pack is in place, review the AI traffic analysis dashboard to understand the impact of AI bot traffic on your content before setting your pricing strategy. In the WAF & Shield console, go to AI traffic analysis in the left navigation pane. Select your protection pack (web ACL) from the dropdown to populate the dashboard.

The AI traffic analysis dashboard breaks down traffic into four categories visible in the bot traffic overview panel: All bot requests, AI bot requests, Verified AI bot traffic, and Unverified AI bot traffic. The dashboard surfaces infrastructure impact metrics including bandwidth consumed, estimated monthly cost, and peak request rates. A per-path heatmap shows which content paths receive the most AI bot activity by hour, giving you the data you need to make informed pricing decisions.

AWS WAF Bot Control classifies over 650 distinct AI bot and agent types including GPTBot, Claude-Web, and Perplexity-Bot, and assigns each a verification tier:

  • Verified — Agent identity confirmed through Web Bot Auth (WBA) Ed25519 cryptographic signature, or sourced from a documented IP range with a known set of user-agents and domain names.
  • Unverified — Agent recognized through user-agent matching, behavioral fingerprinting, and IP reputation, but identity not cryptographically confirmed.

Once you have reviewed your traffic patterns, return to Protection packs (web ACLs), select your protection pack from the list, and choose Configure AI monetization from the right panel to set pricing and access policies. Each protection pack defines the pricing, agent policies, accepted payment methods, and license terms that apply to a defined set of content paths. You can create multiple protection packs and apply different pricing to different content zones within the same distribution. Once created, associate the protection pack with your web ACL by opening the web ACL and choosing Add protection pack.

For each agent verification tier within the pack, you can assign one of six actions: Monetize (return a 402 with pricing), Allow (grant free access), Block (deny access entirely), Count (log without charging), CAPTCHA (present a puzzle to verify a human sender), or Challenge (run a silent check to verify the client is a browser, not a bot).

In the Edit monetization configuration page, configure the following:

Under Payment settlement, select one or more blockchain networks for stablecoin payments. Any wallet address on the supported networks is accepted, whether self-managed or hosted by a wallet provider such as Coinbase. For each network, provide your wallet address and set a Base price per page in USDC. You can add multiple networks using Add network. AWS does not process payments or take a fee on content revenue; disbursement is self-managed or managed by your wallet provider.

When a Monetize rule matches an incoming request, AWS WAF returns an HTTP 402 Payment Required response. The response body contains a machine-readable price manifest in JSON format using the x402 open protocol for machine-to-machine payments. The manifest includes the content price in USDC, accepted blockchain networks such as Base and Solana, the destination wallet address, the maximum payment timeout, and the payment scheme.

Any x402-compatible agent runtime can complete this flow autonomously. The client submits a signed payment authorization on their payment network of choice. AWS WAF verifies it, fetches the content, integrates with third-party facilitator services for settling the payment on-chain, and serves the response.

Note that the Monetize action is supported exclusively for web ACLs associated with Amazon CloudFront distributions. Adding a Monetize rule to a regional web ACL is not supported.

Since the Currency mode toggle is available directly in the monetization configuration page, you can switch between Real and Test mode at any time. Before going live, use test mode on non-production traffic to validate pricing, wallet configuration, and x402 payment flows. Note that test mode still enforces x402 payments, but those payments can be made on testnets such as Base Sepolia or Solana Devnet using test funds obtained from faucets such as faucet.circle.com. To activate test mode, toggle Currency mode to Test in your protection pack configuration. AWS WAF returns real price manifests and runs the full payment flow identically to production on the configured test chain. All events are logged with CurrencyMode: TEST. When satisfied with the configuration, toggle Currency mode back to Real to begin processing real payments.

Once you have switched Currency mode to Real, navigate to AI access monetization in the left navigation pane to track monetization outcomes in real time. Note that the AI access monetization dashboard only reflects activity from real currency mode and does not display test transactions.

The Revenue dashboard shows Total revenue, revenue broken down by Verified bots and Unverified bots, and Avg. per request. The Top revenue sources panel groups earnings by bot category, and the AI access patterns panel ranks content paths by revenue generated. Use the Settlements tab to reconcile payments by provider and review payment method distribution and failed payment attempts.

Now Available
AI traffic monetization is available now for Amazon CloudFront customers at no additional charge beyond standard AWS WAF pricing. The capability is available in all edge locations where AWS WAF web ACLs are associated with Amazon CloudFront distributions.

To learn more about AI traffic monetization, see the AWS WAF Developer Guide.

— Esra

NIS2 is raising the bar. Here’s how to turn readiness into resilience.

Post Syndicated from sabeen malik original https://www.rapid7.com/blog/post/so-nis2-compliance-turn-readiness-into-resilience

The NIS2 directive asks covered organizations to take a more structured approach to risk management, governance, supply chain security, and incident reporting. It expands the scope of who may be covered, raises expectations around management body accountability, introduces clearer and more enforceable requirements, and increases pressure on organizations to show that security is being managed in a consistent, defensible way. Reporting timelines are one of the most visible parts of that shift, with early warning required within 24 hours of awareness for significant incidents, incident notification within 72 hours, and a final report within one month. It also arrived in a landscape that is still uneven, with member states continuing to implement the directive in different ways across the EU.

That combination has created a familiar challenge for CISOs and security teams, as the questions coming from boards and leadership are no longer just about whether the organization understands the regulation, but whether it can meet the requirements in practice. NIS2 reaches into risk management, reporting, governance, and supply chain oversight, which means readiness depends on how well security works across the business, not just on how well a policy is written.

That is why the most useful way to think about NIS2 is as an operational resilience exercise. Compliance still matters, of course, and teams need to know what the directive requires. What tends to make the difference over time is whether security leaders can connect those requirements to the real conditions of the environment: what is exposed, where ownership sits, how incident response works in practice, how supply chain risk is monitored, and how quickly the organization can move when something material happens.

Regulations are easier to absorb than operating model changes. A team may understand that NIS2 raises expectations around governance and incident handling, while still finding it difficult to answer basic questions quickly when pressure rises. Which business services are most critical? Which third parties matter most? Who owns the decision when a serious issue lands? How prepared are we to investigate, communicate, and report inside the timelines the directive expects? Those are the questions that separate a compliance project from a resilience program.

That is also why we have been building practical content to help teams move from interpretation to action.

Our ebook is the best place to start if you want the wider context. It is designed to help security leaders understand what NIS2 means in practical terms, how to think about the directive beyond a narrow checklist, and how to connect compliance obligations to a broader resilience strategy. If your team needs a stronger narrative for internal stakeholders, or a clearer way to explain why NIS2 should influence operational priorities, the ebook is the most useful first read.

Next, our NIS2 Readiness Toolkit is built for teams that want to assess where they are and what to do next. iIt is as a way to bridge the gap between NIS2 requirements and operational reality, with a focus on risk, reporting, and governance. It is designed to help teams spot gaps, focus effort, and simplify the path from regulatory complexity to a more defensible security strategy. In other words, it gives you a practical framework for understanding where readiness is strong, where it is uneven, and what deserves attention first.

Our infographic, seen below, is the quickest asset to use when you need to communicate one of the most tangible parts of NIS2: the 24-hour reporting requirement. Some stakeholders need the long-form explanation. Others need a practical view of what has to happen between incident awareness and early notification. The infographic helps teams bring that operational pressure into planning conversations, leadership updates, and internal alignment without requiring everyone to start with a longer asset first.

REQ-18355_-_Infographic_The_24-Hour_Rule-1.png

⠀

Taken together, these assets are useful because they serve different parts of the same problem. The ebook gives you a strategic view, the toolkit helps you assess readiness and prioritize action, and the infographic helps communicate the big picture quickly and clearly.

Enforcement expectations, reporting maturity, and national interpretation continue to evolve, and security teams are working through those changes at the same time as the wider threat landscape becomes more complex. A stronger response starts with clarity, but it needs to move quickly into coordination, ownership, and repeatable process if it is going to hold up under pressure.

If your organization is still treating NIS2 as a point-in-time compliance exercise, now is a good moment to widen the lens. The directive is pushing security leaders beyond a comply-once approach and toward a model of being continuously secure. Teams that build better visibility, stronger governance, and clearer response processes for NIS2 will be better prepared not only for regulatory scrutiny, but for the wider operational demands that are already shaping the market.

Does Your Security Programme Align With NIS2 Requirements?

Post Syndicated from sabeen malik original https://www.rapid7.com/blog/post/so-aligning-security-programmes-with-nis2-requirements

If your organization operates in the EU, or works with organizations that do, NIS2 is no longer something on the horizon. It is here and it applies to a far wider range of sectors than its predecessor, the original NIS Directive (Directive (EU) 2016/1148), and it comes with real consequences for organizations that cannot demonstrate they are meeting its requirements. The good news? You do not have to figure out how to approach it alone.

Rapid7 has developed a dedicated NIS2 resource page that shows how the Command Platform can support key technical and operational aspects of NIS2 readiness, highlights common security program gaps, and explains where our solutions can help strengthen visibility, prioritization, detection, and reporting readiness. It is not a substitute for the broader organizational, legal, and governance measures the directive also requires, but it can be a useful starting point if you are evaluating your security capabilities and want a clearer picture of where tooling can support your approach. If you are in the early stages of assessing readiness, or further along and looking for a clearer view of the technical side, it is worth 10 minutes of your time.

What are the NIS2 requirements organizations need to meet?

NIS2, formally Directive (EU) 2022/2555, expands the scope of EU cybersecurity regulation significantly. More sectors are covered,the requirements are more demanding, and, crucially, the expectations have shifted from “do you have policies in place?” to “can you demonstrate that your controls actually work, continuously?”.

Article 21 mandates specific risk-management measures, including risk analysis, incident handling, business continuity, supply chain security, vulnerability handling, access control, and policies regarding the use of cryptography and encryption.. Article 23 introduces strict incident reporting timelines: an early warning within 24 hours, a full notification within 72 hours, and a detailed report within one month of a significant incident.

For many security teams, these timelines necessitate a shift in operational readiness. Timely and accurate incident reporting requires pre-established detection workflows, investigation processes, and contemporaneous documentation practices to be in place prior to an incident..

NIS2 also raises the stakes at a leadership level. Executive accountability for cybersecurity is now formalised. This is not just a technical team problem. It is a governance issue that touches CISOs, boards, and senior leadership across every in-scope organization.

Why traditional compliance approaches fall short of NIS2

Many security programs were designed around a different set of expectations. Periodic vulnerability scans.,annual audits, and compliance reports that reflected a moment in time rather than ongoing operational health.

NIS2 necessitates a move toward continuous, defensible risk management. This involves maintaining comprehensive asset visibility, identifying threat-aware exposures with high likelihood of exploitability, and validating the effectiveness of detection capabilities to support regulatory reporting requirements..

It is a meaningful operational shift, and it is exactly the kind of shift where having the right platform and the right partner matters.

How does Rapid7 support NIS2 compliance?

Rapid7 views NIS2 as an operational readiness challenge. The objective is to assist organizations in transitioning from periodic compliance assessments to continuous resilience: a sustained, measurable security posture designed to support regulatory alignment and strengthen defense-in-depth against emerging threats. The platform integrates exposure management, vulnerability management, cloud security, SIEM, and managed detection and response to provide broad support for the core requirements of Article 21 within a unified, connected view of risk..

That means organizations can move from scattered, point-in-time security activity to continuous visibility, threat-informed prioritization, faster incident workflows, and the kind of evidence and reporting that NIS2 and regulators actually demand.

A few areas where this makes a real difference:

Knowing what you are actually exposed to

Rapid7 is positioned as a Leader in the 2025 Gartner® Magic Quadrant™ for Exposure Assessment Platforms, a technology category fundamental to the Continuous Threat Exposure Management (CTEM) framework, which supports the proactive risk-management objectives of NIS2. Surface Command provides centralized visibility across internal and external environments, supporting the identification of unmanaged assets, shadow IT, and security control gaps that may otherwise remain undetected. Exposure Command utilizes active risk scoring and attack path analysis to identify and prioritize exposures based on reachability and threat context, helping teams focus remediation efforts on high-impact risks.

Responding and reporting faster

Rapid7’s SIEM and MDR capabilities are designed to support the detection, investigation, and reporting speed necessitated by NIS2. 24/7 monitoring and managed response facilitate the capture of essential telemetry and investigation trails within the SIEM, streamlining the evidence collection process for regulatory reporting.

Demonstrating that controls work

NIS2 is not satisfied by a list of tools you have purchased. It wants evidence that your controls are effective. Rapid7 provides continuous risk scoring, detection metrics, and audit-ready reporting that translates security activity into governance-ready language for leadership and regulators.

Where to go next for NIS2 readiness

This post covers the highlights, but Rapid7’s NIS2 resource page goes much deeper.

It walks through each of Article 21’s requirements in plain language, maps them to specific Rapid7 capabilities, and shows how the platform supports risk analysis… MFA monitoring, and technical assessment of cryptographic configurations. Whether you are a CISO seeking a strategic overview, a security manager evaluating technical controls, or a compliance lead mapping regulatory requirements to platform capabilities, our guidance is designed to support your objectives. NIS2 is operational; your approach to resilience should be as well. NIS2 is operational and your readiness should be too.

See how Rapid7 supports NIS2 compliance here. 

The collective thoughts of the interwebz