This post is written by Pascal Vogel, Solutions Architect, and Martin Sakowski, Senior Solutions Architect.
Large language models (LLMs) are proving to be highly effective at solving general-purpose tasks such as text generation, analysis and summarization, translation, and much more. Because they are trained on large datasets, they can use a broad generalist knowledge base. However, as training takes place offline and uses publicly available data, their ability to access specialized, private, and up-to-date knowledge is limited.
One way to improve LLM knowledge in a specific domain is fine-tuning them on domain-specific datasets. However, this is time and resource intensive, requires specialized knowledge, and may not be appropriate for some tasks. For example, fine-tuning won’t allow an LLM to access information with daily accuracy.
To address these shortcomings, Retrieval Augmented Generation (RAG) is proving to be an effective approach. With RAG, data external to the LLM is used to augment prompts by adding relevant retrieved data in the context. This allows for integrating disparate data sources and the complete separation of data sources from the machine learning model entirely.
Tools such as LangChain or LlamaIndex are gaining popularity because of their ability to flexibly integrate with a variety of data sources such as (vector) databases, search engines, and current public data sources.
In the context of LLMs, semantic search is an effective search approach, as it considers the context and intent of user-provided prompts as opposed to a traditional literal search. Semantic search relies on word embeddings, which represent words, sentences, or documents as vectors. Consequently, documents must be transformed into embeddings using an embedding model as the basis for semantic search. Because this embedding process only needs to happen when a document is first ingested or updated, it’s a great fit for event-driven compute with AWS Lambda.
This blog post presents a solution that allows you to ask natural language questions of any PDF document you upload. It combines the text generation and analysis capabilities of an LLM with a vector search on the document content. The solution uses serverless services such as AWS Lambda to run LangChain and Amazon DynamoDB for conversational memory.
Amazon Bedrock is used to provide serverless access to foundational models such as Amazon Titan and models developed by leading AI startups, such as AI21 Labs, Anthropic, and Cohere. See the GitHub repository for a full list of available LLMs and deployment instructions.
You learn how the solution works, what design choices were made, and how you can use it as a blueprint to build your own custom serverless solutions based on LangChain that go beyond prompting individual documents. The solution code and deployment instructions are available on GitHub.
Solution overview
Let’s look at how the solution works at a high level before diving deeper into specific elements and the AWS services used in the following sections. The following diagram provides a simplified view of the solution architecture and highlights key elements:
The process of interacting with the web application looks like this:
This upload triggers a metadata extraction and document embedding process. The process converts the text in the document into vectors. The vectors are loaded into a vector index and stored in S3 for later use.
When a user chats with a PDF document and sends a prompt to the backend, a Lambda function retrieves the index from S3 and searches for information related to the prompt.
An LLM then uses the results of this vector search, previous messages in the conversation, and its general-purpose capabilities to formulate a response to the user.
As can be seen on the following screenshot, the web application deployed as part of the solution allows you to upload documents and list uploaded documents and their associated metadata, such as number of pages, file size, and upload date. The document status indicates if a document is successfully uploaded, is being processed, or is ready for a conversation.
By clicking on one of the processed documents, you can access a chat interface, which allows you to send prompts to the backend. It is possible to have multiple independent conversations with each document with separate message history.
Embedding documents
When a new document is uploaded to the S3 bucket, an S3 event notification triggers a Lambda function that extracts metadata, such as file size and number of pages, from the PDF file and stores it in a DynamoDB table. Once the extraction is complete, a message containing the document location is placed on an Amazon Simple Queue Service (Amazon SQS) queue. Another Lambda function polls this queue using Lambda event source mapping. Applying the decouple messaging pattern to the metadata extraction and document embedding functions ensures loose coupling and protects the more compute-intensive downstream embedding function.
The embedding function loads the PDF file from S3 and uses a text embedding model to generate a vector representation of the contained text. LangChain integrates with text embedding models for a variety of LLM providers. The resulting vector representation of the text is loaded into a FAISS index. FAISS is an open source vector store that can run inside the Lambda function memory using the faiss-cpu Python package. Finally, a dump of this FAISS index is stored in the S3 bucket besides the original PDF document.
Generating responses
When a prompt for a specific document is submitted via the Amazon API Gateway REST API endpoint, it is proxied to a Lambda function that:
Loads the FAISS index dump of the corresponding PDF file from S3 and into function memory.
Performs a similarity search of the FAISS vector store based on the prompt.
If available, retrieves a record of previous messages in the same conversation via the DynamoDBChatMessageHistory integration. This integration can store message history in DynamoDB. Each conversation is identified by a unique ID.
Finally, a LangChain ConversationalRetrievalChain passes the combination of the prompt submitted by the user, the result of the vector search, and the message history to an LLM to generate a response.
Web application and file uploads
A static web application serves as the frontend for this solution. It’s built with React, TypeScript, Vite, and TailwindCSS and deployed via AWS Amplify Hosting, a fully managed CI/CD and hosting service for fast, secure, and reliable static and server-side rendered applications. To protect the application from unauthorized access, it integrates with an Amazon Cognito user pool. The API Gateway uses an Amazon Cognito authorizer to authenticate requests.
Users upload PDF files directly to the S3 bucket using S3 presigned URLs obtained via the REST API. Several Lambda functions implement API endpoints used to create, read, and update document metadata in a DynamoDB table.
Extending and adapting the solution
The solution provided serves as a blueprint that can be enhanced and extended to develop your own use cases based on LLMs. For example, you can extend the solution so that users can ask questions across multiple PDF documents or other types of data sources. LangChain makes it easy to load different types of data into vector stores, which you can then use for semantic search.
The solution presented in this blog post uses similarity search to find information in the vector database that closely matches the user-supplied prompt. While this works well in the presented use case, you can also use other approaches, such as maximal marginal relevance, to find the most relevant information to provide to the LLM. When searching across many documents and receiving many results, techniques such as MapReduce can improve the quality of the LLM responses.
Depending on your use case, you may also want to select a different LLM to achieve an ideal balance between quality of results and cost. Amazon Bedrock is a fully managed service that makes foundational models (FMs) from leading AI startups and Amazon available via an API, so you can choose from a wide range of FMs to find the model that’s best suited for your use case. You can use models such as Amazon Titan, Jurassic-2 from AI21 Labs, or Anthropic Claude.
AWS serverless services make it easier to focus on building generative AI applications by providing automatic scaling, built-in high availability, and a pay-for-use billing model. Event-driven compute with AWS Lambda is a good fit for compute-intensive, on-demand tasks such as document embedding and flexible LLM orchestration.
The solution in this blog post combines the capabilities of LLMs and semantic search to answer natural language questions directed at PDF documents. It serves as a blueprint that can be extended and adapted to fit further generative AI use cases.
Businesses are constantly evolving, often managing multiple product lines, customer segments, or even geographical locations. Furthermore, many business-to-business (B2B) companies that are Independent Software Vendors (ISVs) will often need to manage their customer’s marketing automation environment. This complexity necessitates a robust customer engagement strategy that can adapt and scale efficiently. However, managing disparate systems for each tenant is not only cumbersome but also resource-intensive, leading to increased operational costs and potential data silos. A multi-tenancy setup in Amazon Pinpoint addresses these challenges head-on, allowing businesses to streamline their customer engagement efforts under a unified architecture.
The question is not just whether to adopt multi-tenancy, but how to implement it in a way that aligns with your unique business requirements. Amazon Pinpoint offers multiple approaches to achieve this. This blog explores three:
Single Pinpoint Project: Simple but demands careful permissions management.
Multiple Pinpoint Projects: Granular control but limited by soft project quotas.
Multiple Account & Multi Pinpoint Projects: Highly scalable but needs comprehensive monitoring.
We’ll delve into the pros, cons, and best use-cases for each as well as how to choose the different multi-tenancy configuration depending on your communications channels needs, guiding you to make an informed architectural decision.
In this blog, we’ll cut through the complexity, helping you align your Amazon Pinpoint architecture with your business goals. Let’s get started.
Single Account / Single Project (SA/SP)
Overview
In a Single Pinpoint Project setup, all customer engagement activities reside within one project and multi-tenancy within this context will leverage customer endpoint attributes. This streamlined approach allows for easy management, especially for those new to Amazon Pinpoint. A configuration example for this case is shown below:
When preparing one Pinpoint Project and managing information for multiple tenants, tenant information can be managed by using custom user attributes of endpoints. Also, campaign information can be managed for each tenant by using the tag function for campaign information. The elements required to take this configuration are shown below.
S3 buckets that hold customer data:
Prepare an S3 bucket to store customer information lists to be imported into Pinpoint. Amazon Pinpoint allows you to import CSV files in S3 as segments. In order to make settings for each tenant in Amazon Pinpoint, we will include tenant information as custom user attributes in the CSV file.
Settings for each channel to be distributed are also required.
Campaign information can be assigned to tenant information by using the tag function.
Amazon Kinesis:
By using Amazon Pinpoint’s event stream settings, it can be saved to S3 via Kinesis.
Athena and S3 buckets to analyze event data:
Store Amazon Pinpoint event data in S3 and analyze it via Athena. Take advantage of this solution.
One thing to keep in mind when adopting this configuration is that customer endpoint information exists in the same Pinpoint Project. It is possible to specify values that can be used to identify each tenant, such as custom attributes, and solve the problem with AWS Identity and Access Management (IAM) policies, but it is necessary to manage access rights and attributes on your own.
Also, to add an endpoint, you’ll need to specify its Channel and Address. Take note that one project cannot have the same channel and address for different endpoints. From the above, if the channel and address of the endpoint do not overlap between tenants, it is possible to construct your own access permission control, then this pattern can be examined.
Since fewer components are required compared to other patterns, the configuration is easier to start with. Some customers that want to build on top of Pinpoint API and want to simplify configuration on the Pinpoint side as much as possible can also choose this option. However, this approach can get complex to manage later on as you onboard more tenants. The issue presents itself when you want to create detailed reporting for your tenant in this configuration. You’ll have to have dedicated tags on each campaigns, journeys to operationalize granular reporting for your Amazon Pinpoint project.
Lastly, take note of service limits per Amazon Pinpoint project/AWS account to ensure your use case will be scalable should the need arise.
Single Account / Multiple Projects (SA/MP)
Overview
For this architecture, you are still using a single AWS account to host your Amazon Pinpoint environment, however, you will be creating multiple projects for each customer or tenant. A configuration example for this case is shown diagram.
In this example, we will create multiple Amazon Pinpoint Projects. One major difference from the case of the Single Pinpoint Project is that it is possible to completely separate customer endpoint information. When importing customer data segments, it is possible to manage each tenant in a separate state simply by importing them from S3 into the target Pinpoint Project. This makes it easy to control permissions via IAM policies.
Also, with Amazon Pinpoint, you can use email addresses, SMS numbers, message templates, etc. for transmission obtained with the relevant account in common to all projects, and event data for each project can be aggregated via Amazon Kinesis. By adopting such a configuration, you gain the benefits of separating endpoint information per project while still retaining basic setting information management and operator operations.
An example starter solution architecture to set up this configuration are shown below.
S3 buckets that hold customer data:
Similar to SA/SP, prepare an S3 bucket to store a list of customer information to be imported into Pinpoint. CSV to be imported must be prepared for each project.
Amazon DynamoDB Table:
Prepare a DynamoDB (or other key-value database) table to manage Pinpoint project information. Tenant information can also be stored as metadata in the DynamoDB table.
AWS Lambda:
Create a Pinpoint Project using Lambda. Amazon Pinpoint allows you to create and configure projects using the Amazon Pinpoint API, the AWS SDK, or the AWS Command Line Interface (AWS CLI). Thus, it is possible to automate the creation of the Pinpoint project and associated campaigns/journeys. Tenant information is also registered in DynamoDB at the time of creation.
Multiple Amazon Pinpoint Projects:
This is a Project created by Lambda above. There will now be a Pinpoint Project for each tenant, and endpoint information will be completely separated. It is also easy to control access rights for each project by using the IAM function.
Message templates: templates can be created and shared across projects.
By using Amazon Pinpoint’s event stream settings, campaign/journeys/app/channels events can be streamed to Amazon Kinesis. Multiple Amazon Pinpoint projects can all stream to one Amazon Kinesis stream. When setup correctly, event data will be tagged with the relevant tenant information so that an analytics solution can decompose the stream later on.
Athena and S3 buckets to analyze event data:
Amazon Pinpoint event data is stored in Amazon S3 and analyzed via Amazon Athena. The analytics solution, Amazon Athena in this case will be responsible for filtering event data and according to the tenant. Refer to this solution for more details.
Note that Pinpoint projects have a soft limit of 100 projects per AWS account, which can be increased via raising a Support Ticket, other quotas also apply at the project and the account level which should be taken into account.
From the above, it is necessary to note that there are restrictions on quotas per account when using the SA/MP and more initial configurations would be required to automate the process of project creation for individual tenants. However, when compared to SA/SP architecture,
Multiple Accounts & Multi Pinpoint Projects (MA/MP)
Overview
Before diving into the MA/MP approach, it’s crucial to understand the role of AWS Organizations in this configuration. AWS Organizations allows you to consolidate multiple AWS accounts into an organization to achieve centralized governance and billing. This feature is particularly useful in a MA/MP setup, as it enables streamlined management of multiple AWS accounts and Amazon Pinpoint projects from a single central management AWS account. For more information on AWS Organizations, you can visit the official AWS Organizations documentation.
In an MA/MP setup, we utilize separate AWS Accounts for each customer or tenant. A configuration example for this case is shown below.
In this example, we have created a Management account and prepared multiple AWS accounts under it. The management account manages the AWS account ID and the Pinpoint project ID, and has a configuration created with Lambda. Customer data and Event Stream Data are managed through a Management account, and information on each project is aggregated. A major benefit of this configuration is the ability to segregate actions of individual tenants, preventing the such as noisy neighbours antipattern. It also enables AWS accounts from being freed from quota restrictions that cannot be handled by a single AWS account. Additionally, Amazon Pinpoint has excellent CloudFormation coverage, and it is also possible to deploy highly reproducible architectures automatically.
The elements required to set up this configuration are shown below.
Set up Organizations to manage multiple accounts. See Best Practices for setting up multiple accounts.
Management account:
Create an account to manage multiple account information. Here we will set the following elements. Use IAM roles and Service control policies (SCPs) when manipulating resources across accounts. This allows cross-account access. The required elements are the same as the SA/MP described above.
S3 buckets that hold customer data: With AWS, you can utilize S3 data across accounts. Set up cross-account settings and securely link customer data to each account.
Dynamo DB Table: Holds your AWS account ID, Pinpoint Project ID, and management information associated with it.
AWS Lambda: Create a Pinpoint project using Lambda.
Athena and S3 buckets to analyze event data: Event information from multiple accounts and Pinpoint projects is aggregated and analyzed.
AWS accounts and Pinpoint projects per tenant:
Depending on how tenants are separated, prepare an AWS account and Pinpoint Project. You can also consider automating account creation by using AWS CloudFormation.
There are cases where it is necessary to set the distribution channel email address, SMS number, etc. for each account. See the next section for details.
Amazon Kinesis is prepared for each account, but everything is stored in the same S3 in the Management account for easier bird-eye’s view reporting.
One thing to keep in mind is that since accounts are separated, it becomes necessary to manage each one separately. For example, newly created account will be placed in the sandbox state, and an application for actual use via support tickets is required for each account. Also, since all reputation is done on a single account, it is also necessary to monitor reputation for each account.
Navigating Channels in Amazon Pinpoint: Aligning Service Delivery with Architecture
Beyond choosing a Pinpoint architecture for multi-tenancy, it’s pivotal to decide which channels best deliver your services and how that decision is affected by your choice of multi-tenancy architecture. Below is a non-exhaustive lists of capabilities in Amazon Pinpoint that will help with your multi-channel, multi-tenancy configurations as well as potential blockers that you’d need to be aware of for each channels.
Email
Email is one of the most versatile channels, with integration with Amazon SES’s configuration sets and email suppression list capability, easily fitting into any of the three multi-tenancy models.
Configurations Sets: Using configuration sets, you’d be able to segregate your email sending activities using different IP Pools, as well as different event destinations.
You can use configuration sets in both Amazon Pinpoint and Amazon SES. Configuration sets rules that you configure in Amazon SES are also applied to email messages that you send using Amazon Pinpoint.
SA/SP and SA/MP: Email templates and sending IP addresses needs to be tagged using configuration sets for each tenant in the Pinpoint project.
MA/MP: Email templates and sending IP address can be sent using the account default, or follow granular tagging using configuration sets.
Email Suppression List: Suppression list is managed automatically at the account level. Alternatively, you can specify whether a specific configuration can override the account-level suppression list.
If any tenant sends to an email address that hard-bounced or complaint, all other tenants will also be unable to send emails to the same address.
You will have to manually override the account-level suppression list for each email addresses.
MA/MP:
If one of your tenant sends an email to a hard-bounced or complaint address, only the AWS account that the tenant belongs to will respect the suppression list i.e. other tenants in other AWS account can still send email to that email address.
Noisy Neighbour Threat: Broadly, this occurs when one tenant’s performance is degraded because of the activities of another tenant. Applied to email, the anti-pattern needs to be addressed because you don’t want one bad actor tenant to affect the entire environment’s email sending activity.
SA/SP and SA/MP:
Because email bounce and complaint rates are tracked at the account level, it is possible your entire account email sending domain to be blocked due to high bounce/complaint incidences from one bad tenant.
To mitigate this, it’s best practice to set up dedicated configuration sets and alarms to alert when any individual tenant is exhibiting high bounce/complaint rate.
MA/MP:
Offers the most segregation and ensure email identities/domains are only usable by one tenant/account.
You would need to anticipate the total daily sending quota and sending rate for all tenants in your AWS account and raise the service limits accordingly. Therefore, more planning will be involved to estimate the correct service limit threshold.
MA/MP:
You can raise service limits per individual tenant’s needs since each tenant will be on a separate AWS account.
It is best practice to have business process in place for individual tenant to notify of their email sending quota request in advance so that it can be raised accordingly for their AWS account.
Origination Identity procurement: When opting for MA/MP setup, remember that OIDs (phone numbers) are bound to AWS accounts.
Since OIDs do not carry across account, you will need to repeat the procurement process for every new AWS account.Number Pooling: This feature groups phone numbers or sender IDs. It’s particularly useful in a Single Project model to segment communications per tenant.
Configuration Sets: With the release of the V2 SMS and Voice API, you can now use configuration sets to manage your SMS opt-out lists, OIDs and event streaming destinations for a multi-tenant environment.
Take note that if you do not specify an OID in your API call, Amazon Pinpoint will attempt to use the most suitable (in terms of throughput and deliverability) OID to send your SMS. This
Similar to email, you can leverage number pooling and configuration sets to segregate SMS sending activity within a single account. This helps protect’s your SMS OID reputation because it can be costly and time-consuming to request new OIDs.
MA/MP:
Offers the most segregation and ensure numbers are only usable by one tenant/account.
SMS Opt Outs: Similar to the email channel’s suppression list, opt-outs are managed per account and configuration sets. Therefore, in a MA/MP setup, a customer that has opted out from communication in one account can still receive communications from other accounts.
Push Notifications
Amazon Pinpoint integrates with various push services like FCM, APNS, Baidu Cloud Push, and ADM.
Project-level Authentication: Authentication information is set at the Pinpoint Project level, requiring separate management.
Therefore, you will not be able to use the SA/SP architecture for multiple tenants using different applications.
Custom channels in Amazon Pinpoint allow you to send messages through any service that has an API, including third-party services. You can interact with APIs by using a webhook, or by calling an AWS Lambda function.If you are using custom channels extensively from Amazon Pinpoint, you’ll need to be aware of service limits in AWS Lambda, , especially if you’re considering SA/SP or SA/MP architectures.
Conclusion
In this blog, we’ve untangled the intricacies of implementing multi-tenancy in Amazon Pinpoint. Our deep dive covered three architectural patterns:
Single Account/Single Project (SA/SP): A beginner-friendly approach offering simple management but requiring meticulous permissions handling to segregate sending activity between different tenants.
Single Account/Multiple Projects (SA/MP): Offers granular control over customer data with slight increased in management complexity. However, this approach faces soft quotas and potential ‘Noisy Neighbor’ issues.
Multiple Accounts/Multiple Projects (MA/MP): Provides the most flexibility and isolation, albeit with increased management complexity.
Each approach comes with its own set of trade-offs related to ease of management/reporting, scalability, and control over customer data. Our discussion didn’t stop at architecture; we also examined how your multi-tenancy decisions will affect your channel configurations in Amazon Pinpoint. From email and SMS to push notifications, the architectural choices you make will have a direct impact on how efficiently you can manage these distribution channels. Armed with this information, you’re now better equipped to make informed decisions that align with your business objectives.
Call to Action
Your next step? Implement and architect your Amazon Pinpoint environment. Use the best practices and architectural guidelines outlined in this blog post as your north star. Going forward, the architectural blueprint you choose should be tailored to your specific needs—be it user count, company size, or distribution channels. Take into account not just the initial setup but also the long-term management aspects, including the respective service limits and quotas.
Tristan (Tri) Nguyen is an Amazon Pinpoint and Amazon Simple Email Service Specialist Solutions Architect at AWS. At work, he specializes in technical implementation of communications services in enterprise systems and architecture/solutions design. In his spare time, he enjoys chess, rock climbing, hiking and triathlon.
Tatsuya Nakamura
Nakamura Tatsuya is a Solutions Architect in charge of enterprise companies at AWS. He is mainly in charge of the trading company industry and the distribution/retail industry, also supporting the implementation of Amazon Pinpoint for Japanese customers. His career so far includes ERP implementation support and multiple new web service launches.
OpenSSH 9.5 is out. Significant changes include a transport-level ping
mechanism and keystroke timing obfuscation:
This attempts to hide inter-keystroke timings by sending
interactive traffic at fixed intervals (default: every 20ms) when
there is only a small amount of data being sent. It also sends fake
“chaff” keystrokes for a random interval after the last real
keystroke. These are controlled by a new ssh_config
ObscureKeystrokeTiming keyword.
Cloudflare Waiting Room protects sites from overwhelming traffic surges by placing excess visitors in a fully customizable virtual waiting room, admitting them dynamically as spots become available. Instead of throwing error pages or delivering poorly-performing site pages, Waiting Room empowers customers to take control of their end-user experience during unmanageable traffic surges.
A key decision customers make when setting up a waiting room is what pages it will protect. Before now, customers could select one hostname and path combination to determine what pages would be covered by a waiting room. Today, we are thrilled to announce that Waiting Room now supports coverage of multiple hostname and path combinations with a single waiting room, giving customers more flexibility and offering broader site coverage without interruptions to end-user flows. This new capability is available to all Enterprise customers with an Advanced Purchase of Waiting Room.
Waiting Room site placement
As part of the simple, no-coding-necessary process for deploying a waiting room, customers specify a hostname and path combination to indicate which pages are covered by a particular waiting room. When a site visitor makes a preliminary request to that hostname and path or any of its subpaths, they will be issued a waiting room cookie and either be admitted to the site or placed in a waiting room if the site is at capacity.
Last year, we added Waiting Room Bypass Rules, giving customers many options for creating exceptions to this hostname and path coverage. This unlocked capabilities such as User Agent Bypassing, geo-targeting, URL exclusions, and administrative IP bypassing. It also allowed for some added flexibility regarding which pages a waiting room would apply to on a customer’s site by adding the ability to exclude URLs, paths, and query strings. While this update allowed for greater specificity regarding which traffic should be gated by Waiting Room, it didn’t offer the broader coverage that many customers still needed to protect greater portions of their sites with a single waiting room.
Let’s review some simple yet impactful examples of why this broader coverage option was important for our customers. Imagine you have an online store, example.com, and you want to ensure that a single waiting room covers the entire customer journey — from the homepage, to product browsing, to checkout. Many sites would delineate these steps in the flow using paths: example.com/, example.com/shop/product1, example.com/checkout. Because Waiting Room assumes an implied wildcard at the end of a waiting room’s configured path, this use case was already satisfied for these sites. Thus, placing a waiting room at example.com/ would cover all the URLs associated with every step of this customer journey. In this setup, once a site visitor has passed the waiting room, they would not be re-queued at any step in their user flow because they are still using the same waiting room’s cookie, which indicates to Waiting Room that they are the same user between URLs.
However, many sites delineate different steps of this type of shopping flow using subdomains instead of or as well as paths. For example, many sites will have their checkout page on a different subdomain, such as checkout.example.com. Before now, if a customer had this site structure and wanted to protect their entire site with a single waiting room, they would have needed to deploy a waiting room at example.com/ and another at checkout.example.com/. This option was not ideal for many customers because a site visitor could be queued at two different parts of the same customer journey. This is because the waiting room at checkout.example.com/ would count the same visitor as a different user than the waiting room covering example.com/.
That said, there are cases where it is wise to separate waiting rooms on a single site. For example, a ticketing website could place a waiting room at its apex domain (example.com) and distinct waiting rooms with pre-queues on pages for specific events (example.com/popular_artist_tour). The waiting room set at example.com/ ensures that the main point of entry to the site does not get overwhelmed and crash when ticket sales for any one event open. The waiting room placed on the specific event page ensures that traffic for a single event can start queuing ahead of the event without impacting traffic going to other parts of the site.
Ultimately, whether a customer wants one or multiple waiting rooms to protect their site, we wanted to give our customers the flexibility to deploy Waiting Room however was best for their use cases and site structure. We’re thrilled to announce that Waiting Room now supports multi-hostname and path coverage with a single waiting room!
Getting started with multi-host and path coverage
Customers can now configure a waiting room on multiple hostname and path combinations — or routes — belonging to the same zone. To do so, navigate to Traffic > Waiting Room and select Create. The name of your domain will already be populated. To add additional routes to your waiting room configuration, select Add Hostname and Path. You can then enter another hostname and path to be covered by the same waiting room. Remember, there is an implied wildcard after each path. Therefore, creating a waiting room for each URL you want your waiting room to cover is unnecessary. Only create additional routes for URLs that wouldn’t be covered by the other hostname and path combinations you have already entered.
When deploying a waiting room that covers multiple hostname and path combinations, you must create a unique cookie name for this waiting room (more on that later!). Then, proceed with the same workflow as usual to deploy your waiting room.
Deploying a multi-language waiting room
A frequent customer request was the ability to cover a multi-language site with a single waiting room — offering different text per language while counting all site traffic toward the same waiting room limits. There are various ways a site can be structured to delineate between different language options, but the two most common are either by subdomain or path. For a site that uses path delineation, this could look like example.com/en and example.com/es for English and Spanish, respectively. For a site using subdomain delineation, this could look like en.example.com/ and es.example.com/. Before multihost Waiting Room coverage, the subdomain variation would not have been able to be covered by a single waiting room.
Waiting Room’s existing configuration options already supported the path variation. However, this was only true if the customer wanted to gate the entire site, which they could do by placing the waiting room at example.com/. Many e-commerce customers asked for the ability to gate different high-demand product pages selling the same product but with different language options. For instance, consider example.com/en/product_123 and example.com/es/product_123, where the customer wants the same waiting room and traffic limits to cover both URLs. Before now, this would not have been possible without some complex bypass rule logic.
Now, customers can deploy a waiting room that accommodates either the subdomain or path approach to structuring a multi-language site. The only remaining step is setting up your waiting room to serve different languages when a user is queued in a waiting room. This can be achieved by constructing a template that reads the URL to determine the locale and define the appropriate translations for each of the locales within the template.
Here is an example of a template that determines the locale from the URL path, and renders the translated text:
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
{{#waitTimeKnown}}
var minutes = parseInt( {{waitTime}} , 10);
var time = document.getElementById('waitTime');
if ( minutes < 61) {
time.innerText = translations[locale]["waittime_60_less"]
} else {
time.innerText = translations[locale]["waittime_60_greater"]
}
{{/waitTimeKnown}}
// translate template text for each of the elements with “id” suffixed with “msg”
for (const msg of ["inline-msg", "patience-msg"]) {
const el = document.getElementById(msg);
if (el == null) continue;
el.innerText = translations[locale][msg];
}
</script>
</body>
</html>
Here’s how the template works: given a site distinguishes different locales with various paths such as /en/product_123 or /es/product_123 in the <script /> body after the rendering the page, the locale is extracted from the location.pathname via locale = location.pathname.split(“/”)[1]. If there isn’t a locale specified within the translations object we default it to “en”. For example, if a user visits example.com/product_123, then by default render the English text template.
Similarly, in order to support a multi-language waiting room for sites that delineate site structure via subdomain, it would only require you to update how you extract the locale from the URL. Instead of looking at the pathname we look at the hostname property of the window.location object like locale = location.hostname.split(“.”)[0], given, we have site structure as following: en.example.com, es.example.com.
The above code is a pared down example of starter templates we have added to our developer documentation, which we have included to make it easier for you to get started with a multi-language waiting room. You can download these templates and edit them to have the look and feel aligned with your site and with the language options your site offers.
This is an example of the starter template provided in dev docs. This waiting room is in Queue-all mode and displays the Spanish text when the user visits example.com/es/product_123.
These templates can further be expanded to include other languages by adding translations to the `translations` object for each of the locales. Thus, a single template is able to serve multiple languages depending on whatever the locale the site is being served as either via subdomain or path.
How we handle cookies with a multihostname and path waiting room
The waiting room assigns a __cfwaitingroomcookie to each user to manage the state of the user that determines the position of the user in line among other properties needed to make the queueing decisions for the user. Traditionally, for a single hostname and path configuration it was trivial to just set the cookie as __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123. This ensured that when the page refreshed it would send us the same Waiting Room cookie for us to examine and update. However, this became non-trivial when we wanted to share the same cookie across different subdomain or path combinations, for example, on example.com/en/product_123.
Approaches to setting multiple cookies
There were two approaches that we brainstormed and evaluated to allow the sharing of the cookie for the same waiting room.
The first approach we considered was to issue multiple Set-Cookie headers in the HTTP response. For example, in the multi-language example above, we could issue the following in the response header:
This approach would allow us to handle the multiple hostnames and paths for the same waiting room. However, it does not present itself as a very scalable solution. Per RFC6265, there isn’t a strict limit defined in the specification, browsers have their own implementation-specific limits. For example, Chrome allows the response header to grow up to 256K bytes before throwing the transaction with ERR_RESPONSE_HEADERS_TOO_BIG. Additionally, in this case, the response header would grow proportionally to the number of unique hostname and path combinations, and we would be redundantly repeating the same cookie value N (where N is the number of additional routes) number of times. While this approach would have allowed us to effectively handle a bounded list of hostname and path combinations that need to be set, it was not ideal for cases where we can expect more than a handful routes for a particular site.
The second approach that we considered and chose to move forward with was to set the cookie on the apex domain (or the most common subdomain). In other words, we would figure out the most common subdomain from the list of routes and use that as the domain. Similarly, for the paths, this would entail determining the least common prefix from the list of paths and use that as the value to be set on the path attribute. For example, consider a waiting room with the following two routes configured, a.example.com/shoes/product_123 and b.example.com/shoes/product_456.
To determine the domain that would be set for the cookie, we can see that example.com is the most common subdomain among the list of domains. Applying the most common subdomain algorithm, we would get example.com as the domain. Applying the least common prefix algorithm on the set of paths, /shoes/product_123 and /shoes/product_456, we would get /shoes as the path. Thus, the set-cookie header would be the following:
Now, when a visitor accesses any of the pages covered by this waiting room, we can guarantee Waiting Room receives the right cookie and there will only be Set-Cookie included in the response header.
However, we are still not there yet. Although we are able to identify the common subdomain (or apex domain) and common path prefix, there would still be a problem if routes from one waiting room would overlap with another waiting room. For example, say we configure two waiting rooms for the same site where we are selling our special shoes:
Waiting Room A
a.example.com/shoes/product_123
b.example.com/shoes/product_456
Waiting Room B
c.example.com/shoes/product_789
d.example.com/shoes/product_012
If we apply the same algorithm as described above, we would get the same domain and path properties set for the two cookies. For Waiting Room A, the domain would be example.com and the path would be /shoes. Similarly, for Waiting Room B, the most common subdomain would also be example.com and least common path prefix would be /shoes. This would effectively prevent us from distinguishing the two cookies and route the visitor to the right waiting room. In order to solve the issue of overlapping cookie names, we introduced the requirement of setting a custom suffix that is unique to the customer’s zone. This is why it is required to provide a custom cookie suffix when configuring a waiting room that covers multiple hostnames or paths. Therefore, if Waiting Room A was assigned cookie suffix “a” and Waiting Room B was assigned cookie suffix “b”, the two Set-Cookie definitions would look like the following:
When a visitor makes a request to any pages where the two different waiting rooms are configured, Waiting Room can distinguish and select which cookie corresponds to the given request and use this to determine which waiting room’s settings apply to that user depending on where they are on the site.
With the addition of multihost and multipath Waiting Room coverage, we’re thrilled to offer more flexible options for incorporating Waiting Room into your site, giving your visitors the best experience possible while protecting your site during times of high traffic. Make sure your site is always protected from traffic surges. Try out Waiting Room today or reach out to us to learn more about the Advanced Waiting Room!
Cloudflare Waiting Room protege los sitios contra las sobrecargas vinculadas a los picos de tráfico, colocando el exceso de visitantes en una sala de espera virtual, completamente personalizable, donde son admitidos dinámicamente a medida que se liberan plazas. En lugar de mostrar páginas de error o entregar páginas del sitio con un bajo rendimiento, Waiting Room permite a los clientes tomar el control de su experiencia de usuario final durante los picos de tráfico inmanejables.
Una decisión clave que toman los clientes al configurar una sala de espera es acerca de qué páginas protegerán. Hasta ahora, los clientes podían seleccionar una sola combinación de nombre de host y ruta de acceso para determinar las páginas cubiertas por una sala de espera. Hoy nos complace anunciar que Waiting Room ahora ofrece compatibilidad con varias combinaciones de nombres de host y rutas de acceso con una sola sala de espera, y ofrece así a los clientes más flexibilidad y una cobertura más amplia del sitio sin interrupciones de los flujos de los usuarios finales. Esta nueva funcionalidad está disponible para todos los clientes Enterprise con una versión Advanced de Waiting Room.
Colocación de un sitio en Waiting Room
Durante la implementación de una sala de espera, un proceso sencillo y que no requiere codificación, los clientes especifican una combinación de nombre de host y ruta de acceso para indicar las páginas cubiertas por una sala de espera determinada. Cuando un visitante del sitio realiza una solicitud preliminar a ese nombre de host y esa ruta de acceso o a cualquiera de sus rutas de acceso secundarias, recibe una cookie correspondiente a la sala de espera y entonces se admite en el sitio o bien, si el sitio está saturado, se coloca en una sala de espera.
El año pasado añadimos la funcionalidad Waiting Room Bypass Rules, que ofrece a los clientes muchas opciones para crear excepciones a esta cobertura de nombre de host y ruta de acceso. Esta funcionalidad ha desbloqueado funciones como la omisión de agente de usuario, el filtrado por geolocalización, las exclusiones de URL y la omisión administrativa de direcciones IP. Asimismo, ha mejorado la flexibilidad en lo referente a las páginas a las que se debe aplicar una sala de espera en el sitio de un cliente, al añadir la posibilidad de excluir URL, rutas de acceso y cadenas de consulta. Aunque esta actualización permitió una mayor especificidad acerca del tráfico que debe filtrar Waiting Room, no ofrecía la cobertura más amplia que aún necesitaban muchos clientes para proteger áreas más extensas de sus sitios con una sola sala de espera.
Por qué los clientes necesitaban una cobertura más amplia de Waiting Room
Analicemos algunos ejemplos sencillos pero adecuados de por qué esta opción de una cobertura más amplia era importante para nuestros clientes. Imagina que tienes una tienda en línea, example.com, y quieres asegurarte de que una sola sala de espera cubre todo el recorrido del cliente, desde la página inicial a la navegación por los productos, y finalmente a la validación del pedido. Muchos sitios utilizan rutas de acceso para definir estos pasos en el flujo: example.com/, example.com/shop/product1, example.com/checkout. Puesto que Waiting Room supone que existe un comodín implícito al final de la ruta de acceso configurada para una sala de espera, este caso de uso ya estaba cubierto para estos sitios. Por lo tanto, la configuración de una sala de espera en la dirección example.com/ permitirá cubrir todas las URL asociadas con cada uno de los pasos de este recorrido del cliente. En esta configuración, una vez que un visitante del sitio entraba en la sala de espera, no se volvía a poner en cola en ningún otro paso del flujo del usuario, ya que seguía utilizando la misma cookie correspondiente a la sala de espera, lo que indica a Waiting Room que se trata del mismo usuario en distintas URL.
No obstante, muchos sitios utilizan subdominios en lugar de, o además de, rutas de acceso para definir distintos pasos de este tipo de flujo de compra. Por ejemplo, la página de validación del pedido de muchos sitios estará en un subdominio distinto, por ejemplo, checkout.example.com. Hasta ahora, si un cliente tenía esta estructura de sitio y quería proteger todo su sitio con una sola sala de espera, necesitaba implementar una sala de espera en la dirección example.com/ y otra en la dirección checkout.example.com/. Esta opción no era idónea para muchos clientes, puesto que un visitante del sitio podía encontrarse puesto en cola en dos lugares distintos del mismo recorrido de cliente. Esto se debe a que la sala de espera en la dirección checkout.example.com/ contabilizaría el mismo visitante como un usuario distinto que el de la sala de espera que cubre el sitio example.com/.
Dicho esto, en algunos casos es recomendable separar las salas de espera que cubren un solo sitio. Por ejemplo, un sitio web de venta de entradas podría implementar una sala de espera en su dominio raíz (example.com) y distintas salas de espera con pre-colas de espera en páginas dedicadas a eventos específicos (example.com/popular_artist_tour). La sala de espera definida en la página example.com/ garantiza que el punto de acceso principal al sitio no se sobrecargue y deje de estar accesible al abrir la venta de entradas para un evento específico. La sala de espera definida en la página dedicada al evento específico garantiza que el tráfico correspondiente a un evento determinado se pueda empezar a poner en cola de espera antes del evento sin afectar al tráfico que se dirige a otros lugares del sitio.
En definitiva, independientemente de si un cliente desea tener una o varias salas de espera para proteger su sitio, queríamos ofrecer a nuestros clientes la flexibilidad de implementar Waiting Room de la forma que se ajustara mejor a sus casos de uso y a su estructura del sitio. Nos complace anunciar que Waiting Room ahora admite la cobertura de varios nombres de host y rutas de acceso con una sola sala de espera.
Cómo empezar a utilizar la cobertura de varios hosts y rutas de acceso
Ahora los clientes pueden configurar una sala de espera en varias combinaciones de nombres de host y ruta (o rutas) de acceso correspondientes a la misma zona. Para ello, ve a Tráfico > Waiting Room y selecciona Create (Crear). El nombre de tu dominio ya estará rellenado. Para añadir reglas adicionales a la configuración de tu sala de espera, selecciona Add Hostname and Path (Añadir nombre de host y ruta de acceso). A continuación, puedes especificar otro nombre de host y ruta de acceso que desees que cubra la misma sala de espera. Recuerda que hay un comodín implícito al final de cada ruta de acceso. Por lo tanto, es innecesario crear una sala de espera para cada URL que desees que cubra tu sala de espera. Crea solo rutas de acceso adicionales para las URL que no estén cubiertas por las combinaciones de nombres de host y rutas de acceso que ya hayas especificado.
Al implementar una sala de espera que cubra varias combinaciones de nombres de host y rutas de acceso, debes crear un nombre de cookie exclusivo para esa sala de espera (más información más adelante). A continuación, continúa con el mismo flujo de trabajo de la forma habitual para implementar tu sala de espera.
Implementación de una sala de espera multilingüe
Los clientes nos han solicitado a menudo la posibilidad de cubrir un sitio multilingüe con una sola sala de espera, y ofrecer así texto específico para cada idioma al mismo tiempo que se contabiliza todo el tráfico del sitio en los mismos límites de la sala de espera. Hay varios métodos para estructurar un sitio a fin de definir las distintas opciones lingüísticas. Sin embargo, los dos más habituales son por subdominio o por ruta de acceso. Para un sitio que utilice la definición por ruta de acceso, podría presentarse así: example.com/en y example.com/es para inglés y español, respectivamente. Para un sitio que utilice la definición por subdominio, podría presentarse así: en.example.com/ y es.example.com/. Antes de que Waiting Room ofreciera la cobertura de varios hosts, la variación por subdominio no podría haber estado cubierta por una única sala de espera.
Las opciones de configuración existentes de Waiting Room ya admitían la variación por ruta de acceso. Sin embargo, esto solo era cierto si el cliente quería filtrar todo el sitio, lo que podía hacer definiendo la sala de espera en la página example.com/. Muchos clientes de comercio electrónico han solicitado la posibilidad de filtrar distintas páginas de productos con alta demanda que ofrecen el mismo producto pero con distintas opciones de idioma. Por ejemplo, considera example.com/en/product_123 y example.com/es/product_123, donde el cliente desea utilizar la misma sala de espera y aplicar los mismos límites de tráfico para cubrir ambas URL. Hasta ahora, esto no habría sido posible sin alguna compleja lógica de reglas de omisión.
Ahora, los clientes pueden implementar una sala de espera que se ajuste al método elegido de estructuración de un sitio multilingüe, ya sea por subdominio o por ruta de acceso. Para terminar, solo debes configurar tu sala de espera para que entregue distintos idiomas cuando un usuario se ponga en cola en una sala de espera. Para ello, puedes crear una plantilla que lea la URL a fin de determinar los parámetros de idioma y definir las traducciones adecuadas para cada idioma en la plantilla.
A continuación se muestra un ejemplo de una plantilla que determina los parámetros de idioma de la ruta de acceso de la URL, y que presenta el texto traducido:
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
{{#waitTimeKnown}}
var minutes = parseInt( {{waitTime}} , 10);
var time = document.getElementById('waitTime');
if ( minutes < 61) {
time.innerText = translations[locale]["waittime_60_less"]
} else {
time.innerText = translations[locale]["waittime_60_greater"]
}
{{/waitTimeKnown}}
// translate template text for each of the elements with “id” suffixed with “msg”
for (const msg of ["inline-msg", "patience-msg"]) {
const el = document.getElementById(msg);
if (el == null) continue;
el.innerText = translations[locale][msg];
}
</script>
</body>
</html>
La plantilla funciona de la forma siguiente: si un sitio distingue entre distintos parámetros de idioma con distintas rutas de acceso, como /en/product_123 o /es/product_123 en el cuerpo <script /> después de representar la página, el parámetro de idioma se extrae de location.pathname mediante locale = location.pathname.split(“/”)[1]. Si no se ha especificado ningún parámetro de idioma en el objeto `translations`, por defecto utilizamos “en”. Por ejemplo, si un usuario visita example.com/product_123, por defecto se representa la plantilla con el texto en inglés.
De la misma forma, para admitir una sala de espera multilingüe correspondiente a sitios que definen la estructura del sitio por subdominio, únicamente deberías actualizar cómo extraer el parámetro de idioma de la URL. En lugar de comprobar `pathname`, comprobamos la propiedad `hostname` del objeto `window.location` como `locale = location.hostname.split(“.”)[0]`, nuestra estructura del sitio será la siguiente: en.example.com, es.example.com.
El código anterior es un ejemplo simplificado de las plantillas iniciales que hemos añadido a nuestra documentación para desarrolladores. Las hemos incluido para que te sea más fácil empezar a utilizar una sala de espera multilingüe. Puedes descargar estas plantillas y editarlas para que su aspecto se ajuste a tu sitio y a las opciones de idioma que este ofrece.
Se trata de un ejemplo de la plantilla inicial proporcionada en los documentos para desarrolladores. Esta sala de espera está configurada para poner a todos los usuarios en cola de espera y muestra el texto en español cuando el usuario visita example.com/es/product_123.
Estas plantillas se pueden ampliar para incluir otros idiomas añadiendo las traducciones al objeto `translations` para cada uno de los idiomas. De esta forma, una única plantilla puede entregar varios idiomas, en función del parámetro de idioma que se aplique al sitio, ya sea por subdominio o por ruta de acceso.
Cómo gestionamos las cookies con una sala de espera que cubre varios nombres de host y rutas de acceso
La sala de espera asigna una cookie__cfwaitingroom a cada usuario para gestionar el estado del usuario, la cual determina la posición del usuario en la cola de espera, así como otras propiedades necesarias para decidir acerca de la colocación en cola de espera vinculadas al usuario. Tradicionalmente, para una configuración de un único nombre de host y ruta de acceso, era muy sencillo definir simplemente la cookie como __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123. Esto garantizaba que cuando se renovará la página nos enviaría la misma cookie de Waiting Room para que la analizáramos y actualizáramos. Sin embargo, dejó de ser sencillo cuando quisimos compartir la misma cookie en distintas combinaciones de subdominios o rutas de acceso, por ejemplo, en example.com/en/product_123.
Métodos para establecer varias cookies
Consideramos y evaluamos dos métodos para permitir el uso compartido de la cookie para la misma sala de espera.
El primer método que consideramos era emitir varios encabezados Set-Cookie en la respuesta HTTP. En el ejemplo multilingüe anterior, por ejemplo, podríamos añadir lo siguiente en el encabezado de la respuesta:
Este método nos permitiría gestionar los varios nombres de host y rutas de acceso para la misma sala de espera. Sin embargo, no se presenta como una solución escalable. La especificación RFC6265 no define ningún límite estricto, pero los navegadores aplican sus propios límites según cada implementación. Por ejemplo, Chrome permite que el encabezado de la respuesta tenga hasta 256 Kbytes antes de devolver un error ERR_RESPONSE_HEADERS_TOO_BIG para la transacción. Además, en este caso, el encabezado de la respuesta crecería proporcionalmente al número de combinaciones de nombres de host y rutas de acceso exclusivas, y estaríamos repitiendo de forma redundante el mismo valor de cookie N número de veces (donde N es el número de rutas adicionales). Aunque este enfoque nos habría permitido gestionar eficazmente una lista limitada de combinaciones de nombres de host y rutas de acceso que sería necesario establecer, no era idóneo para aquello casos donde se espera un número mayor de rutas para un sitio determinado.
El segundo enfoque que hemos considerado, y con el que decidimos seguir adelante, consistía en establecer la cookie en el dominio raíz (o el subdominio más habitual). En otras palabras, buscaríamos el subdominio más habitual en la lista de rutas y lo utilizaríamos como dominio. De la misma forma, en el caso de las rutas, esto implicaría determinar el prefijo menos habitual de la lista de rutas y utilizarlo como el valor que se debe establecer en el atributo path. Por ejemplo, considera una sala de espera con las siguientes dos rutas configuradas, a.example.com/shoes/product_123 y b.example.com/shoes/product_456.
Para determinar el dominio que se establecería para la cookie, podemos observar que example.com es el subdominio más habitual en la lista de dominios. Al aplicar el algoritmo de subdominio más habitual, obtendríamos example.com como subdominio. Al aplicar el algoritmo de prefijo menos habitual en el conjunto de rutas de acceso, /shoes/product_123 y /shoes/product_456, obtendríamos /shoes como ruta de acceso. Por lo tanto, el encabezado set-cookie sería el siguiente:
Ahora, cuando un visitante accede a cualquiera de las páginas cubiertas por esta sala de espera, podemos garantizar que Waiting Room recibe la cookie adecuada y que solo se habrá incluido Set-Cookie en el encabezado de la respuesta.
Sin embargo, aún no hemos terminado. Aunque podemos identificar el subdominio habitual (o dominio raíz) y el prefijo de ruta de acceso común, aún tendríamos un problema si las rutas desde una sala de espera se solaparan con las de otra sala de espera. Por ejemplo, supongamos que configuramos dos salas de espera para el mismo sitio donde vendemos nuestro calzado especial:
Sala de espera A
a.example.com/shoes/product_123
b.example.com/shoes/product_456
Sala de espera B
c.example.com/shoes/product_789
d.example.com/shoes/product_012
Si aplicamos el mismo algoritmo tal como hemos descrito anteriormente, se establecerían las mismas propiedades de dominio y ruta de acceso para ambas cookies. Para la sala de espera A, el dominio sería example.com y la ruta de acceso sería /shoes. De la misma forma, para la sala de espera B, el subdominio más habitual también sería example.com y el prefijo de ruta de acceso menos habitual sería be /shoes. Esto nos evitaría eficazmente distinguir ambas cookies y dirigiría al visitante a la sala de espera adecuada. Para resolver el problema del solapamiento de los nombres de cookie, hemos añadido el requisito de definir un sufijo personalizado exclusivo para la zona del cliente. Por este motivo, es necesario proporcionar un sufijo de cookie personalizado al configurar una sala de espera que cubra varios nombres de host y rutas de acceso. Por lo tanto, si se ha asignado a la sala de espera A el sufijo de cookie “a” y a la sala de espera B el sufijo de cookie “b”, las dos definiciones de Set-Cookie serán las siguientes:
Cuando un visitante envía una solicitud a una página donde hay configuradas dos salas de espera distintas, Waiting Room puede distinguir y seleccionar la cookie correspondiente a esa solicitud específica y utilizarla para determinar qué ajustes de sala de espera son aplicables a ese usuario, en función de dónde se encuentre en el sitio.
Con la adición de la cobertura de varios host y rutas de acceso a Waiting Room, nos complace ofrecerte opciones para que puedas incorporar Waiting Room en tu sitio con mayor flexibilidad, proporcionando así a tus visitantes la mejor experiencia posible, al mismo tiempo que proteges tu sitio durante periodos de mucho tráfico. Asegúrate de que tu sitio esté siempre protegido contra los picos de tráfico. Prueba ya Waiting Room o ponte en contacto con nosotros para saber más sobre la versión Advanced de Waiting Room.
Cloudflare Waiting Room protège les sites contre les surcharges liées aux pics de trafic en transférant l’excédent de visiteurs vers une salle d’attente virtuelle, entièrement personnalisable, dans laquelle les visiteurs sont admis dynamiquement, au fur et à mesure que des places se libèrent. Au lieu d’afficher des pages d’erreur ou de proposer une expérience insatisfaisante de l’affichage des pages du site, Waiting Room permet aux clients de prendre le contrôle de l’expérience de leurs utilisateurs finaux pendant les pics de trafic ingérables.
L’une des principales décisions que prennent les clients lors de la configuration d’une salle d’attente consiste à sélectionner les pages que protégera celle-ci. Jusqu’à présent, les clients pouvaient sélectionner un nom d’hôte et un chemin d’accès lors de la désignation des pages protégées par une instance de Waiting Room. Aujourd’hui, nous sommes ravis d’annoncer que Waiting Room propose désormais la prise en charge de combinaisons de noms d’hôtes et de chemins d’accès multiples pour une salle d’attente unique, offrant ainsi aux clients davantage de flexibilité et une prise en charge plus étendue des sites, sans interruption des flux des utilisateurs finaux.Cette nouvelle fonctionnalité est accessible à tous les clients Enterprise ayant préacheté Waiting Room.
Ajout d’un site dans Waiting Room
Le déploiement d’une salle d’attente est une procédure simple et sans codage, durant laquelle les clients spécifient une combinaison de nom d’hôte et de chemin d’accès afin de désigner les pages prises en charge par une salle d’attente particulière. Lorsqu’un visiteur du site transmet une requête préliminaire à ce nom d’hôte et ce chemin d’accès ou l’un de ses sous-chemins, il reçoit un cookie correspondant à la salle d’attente et est ensuite admis sur le site ou transféré vers une salle d’attente, si le site est saturé.
L’année dernière, nous avons ajouté la fonctionnalité Waiting Room Bypass Rules, qui offre aux clients de nombreuses options permettant de créer des exceptions à cette prise en charge des noms d’hôtes et des chemins d’accès. Cette fonctionnalité a débloqué des capacités telles que le contournement d’agent utilisateur, le ciblage par géolocalisation, les exclusions d’URL et le contournement d’adresses IP d’administration. Elle a également offert davantage de flexibilité au regard de la prise en charge par Waiting Room des pages du site d’un client en ajoutant la possibilité d’exclure des URL, des chemins d’accès et des chaînes de requête. Si cette mise à jour a permis de mieux définir le trafic devant être filtré par Waiting Room, elle n’offrait néanmoins pas la prise en charge étendue que recherchaient encore de nombreux clients pour protéger de plus vastes pans de leurs sites avec une salle d’attente unique.
Pourquoi les clients avaient besoin d’une prise en charge plus étendue par Waiting Room
Examinons quelques exemples simples, mais pertinents, des raisons pour lesquelles cette option de prise en charge étendue était importante pour nos clients. Imaginons que vous ayez une boutique en ligne, example.com, et que vous souhaitiez vous assurer qu’une salle d’attente unique couvre l’ensemble du parcours du client – de la page d’accueil jusqu’à la navigation sur les produits, puis au paiement. De nombreux sites emploient les chemins pour délimiter ces étapes au sein du flux : example.com/, example.com/shop/product1, example.com/payment. Puisque Waiting Room suppose qu’un caractère générique implicite est présent à la fin du chemin d’accès configuré pour une salle d’attente, ce scénario d’utilisation était déjà pris en charge pour ces sites. Ainsi, la configuration d’une salle d’attente à l’adresse example.com/ permettrait de couvrir toutes les URL associées à chaque étape du parcours du client. Dans cette configuration, lorsqu’un visiteur consultant le site avait traversé la salle d’attente, il ne réintégrait pas la file d’attente à une étape ultérieure de son parcours d’utilisateur, car il disposait toujours du même cookie correspondant à la salle d’attente, qui indique à Waiting Room qu’il s’agit d’un même utilisateur parcourant les différentes URL.
Cependant, de nombreux sites utilisent des sous-domaines à la place des chemins d’accès, ou conjointement à ceux-ci, pour délimiter les différentes étapes de ce type de parcours d’achat. Par exemple, la page de paiement de nombreux sites se trouve sur un sous-domaine différent, comme payment.example.com. Jusqu’à présent, si un client disposait de cette structure de site et souhaitait protéger l’ensemble de son site avec une salle d’attente unique, il devait configurer une première salle d’attente à l’adresse example.com/, et une deuxième salle d’attente à l’adresse payment.example.com/. Cette option était peu pratique pour de nombreux clients, car un visiteur pouvait se retrouver ajouté à une file d’attente à deux endroits différents du même parcours client. En effet, la salle d’attente de payment.example.com/ compterait le même visiteur comme un autre utilisateur de celui de la salle d’attente couvrant example.com/.
Cela étant dit, dans certains cas, il est judicieux de séparer les salles d’attente couvrant un même site. Par exemple, un site web de billetterie pourrait déployer une salle d’attente sur son domaine racine (example.com), puis déployer des salles d’attente distinctes avec des pré-files d’attente sur les pages consacrées à des événements spécifiques (example.com/popular_artist_tour). La salle d’attente de la page example.com/ permet d’éviter que le principal point d’accès au site ne soit submergé par les requêtes et que le site devienne inaccessible lors de l’ouverture de la vente de billets pour un événement donné. La salle d’attente placée sur la page de l’événement spécifique assure que le trafic correspondant à un événement particulier puisse être mis en file d’attente avant l’événement, sans toutefois affecter le trafic affluant vers d’autres parties du site.
En fin de compte, peu importe qu’un client souhaite déployer une ou plusieurs salles d’attente pour protéger son site : nous souhaitions offrir à chaque client la possibilité de déployer Waiting Room de la manière la plus adaptée à ses scénarios d’utilisation et sa structure de site. Nous sommes ravis d’annoncer que Waiting Room offre désormais la prise en charge de noms d’hôtes et de chemins d’accès multiples dans une salle d’attente unique !
Découvrir la prise en charge d’hôtes et de chemins d’accès multiples
Les clients peuvent désormais configurer une salle d’attente avec plusieurs combinaisons de noms d’hôtes et de chemins (ou d’itinéraires) appartenant à une même zone. Pour cela, accédez à Trafic > Waiting Room, puis sélectionnez Create (Créer). Le nom de votre domaine sera déjà renseigné. Pour ajouter des itinéraires supplémentaires à la configuration de votre salle d’attente, sélectionnez Add Hostname (Ajouter un nom d’hôte), puis Path (Chemin d’accès). Vous pouvez ensuite saisir un autre nom d’hôte et un autre chemin d’accès qui seront couverts par la même salle d’attente. N’oubliez pas qu’un caractère générique implicite est inclus après chaque chemin d’accès ; il n’est donc pas nécessaire de créer une salle d’attente pour chaque URL que vous souhaitez couvrir. Créez uniquement des itinéraires supplémentaires pour les URL qui ne seraient pas couvertes par les autres combinaisons de noms d’hôtes et de chemins d’accès que vous avez déjà spécifiées.
Lorsque vous déployez une salle d’attente couvrant plusieurs combinaisons de noms d’hôtes et de chemins d’accès, vous devez créer un nom de cookie unique pour cette salle d’attente (nous y reviendrons plus tard). Ensuite, appliquez le même flux de travail que d’habitude pour déployer votre salle d’attente.
Déployer une salle d’attente multilingue
Une demande fréquemment formulée par nos clients était la possibilité de couvrir un site multilingue avec une salle d’attente unique, en proposant des textes différents dans chaque langue, tout en comptabilisant l’ensemble du trafic du site dans les limites de la même salle d’attente. Il existe plusieurs façons de structurer un site pour à délimiter les différentes options linguistiques ; toutefois, les deux approches les plus courantes sont la délimitation par sous-domaine ou par chemin d’accès. Pour un site qui utilise la délimitation par chemin d’accès, cela pourrait se présenter ainsi : example.com/en et example.com/es pour l’anglais et l’espagnol, respectivement. Pour un site utilisant la délimitation par sous-domaine, la configuration pourrait être la suivante : en.example.com/ et es.example.com/. Avant la prise en charge d’hôtes multiples par Waiting Room, la variation des sous-domaines n’aurait pas pu être couverte par une salle d’attente unique.
Les options de configuration existantes de Waiting Room prenaient déjà en charge les variations de chemin d’accès. Cependant, cela n’était vrai que si le client souhaitait couvrir l’ensemble du site, ce qui était réalisable en en plaçant la salle d’attente à l’adresse example.com/. De nombreux clients dans le secteur de l’e-commerce ont demandé la possibilité de couvrir différentes pages de produits très demandées, proposant le même produit, avec des options linguistiques différentes. Par exemple, prenons le cas de example.com/en/product_123 et de example.com/es/product_123. Pour ces pages, le client souhaite couvrir les deux URL avec la même salle d’attente et des limites de trafic identiques. Jusqu’à présent, cela n’aurait pas été possible sans configurer une logique complexe basée sur des règles de contournement.
Désormais, toutefois, les clients peuvent déployer une salle d’attente couvrant, au choix, l’approche basée sur les sous-domaines ou les chemins d’accès pour structurer un site multilingue. L’unique étape restante consiste à configurer votre salle d’attente afin qu’elle puisse servir différentes langues lorsqu’un utilisateur est transféré vers une salle d’attente. Pour cela, vous pouvez développer un modèle lisant l’URL afin de déterminer les paramètres régionaux, puis définir les traductions appropriées pour chaque langue dans le modèle.
Voici un exemple de modèle qui détermine les paramètres régionaux à partir du chemin d’accès de l’URL, puis affiche le texte traduit :
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
{{#waitTimeKnown}}
var minutes = parseInt( {{waitTime}} , 10);
var time = document.getElementById('waitTime');
if ( minutes < 61) {
time.innerText = translations[locale]["waittime_60_less"]
} else {
time.innerText = translations[locale]["waittime_60_greater"]
}
{{/waitTimeKnown}}
// translate template text for each of the elements with “id” suffixed with “msg”
for (const msg of ["inline-msg", "patience-msg"]) {
const el = document.getElementById(msg);
if (el == null) continue;
el.innerText = translations[locale][msg];
}
</script>
</body>
</html>
Voici comment fonctionne le modèle : puisqu’un site distingue différents paramètres régionaux avec différents chemins tels que `/en/product_123` ou `/es/product_123` dans le corps `<script />` après avoir effectué le rendu de la page, le paramètre régional est extrait de `location.pathname` via `locale = location.pathname.split(“/”)[1]`. Si aucune langue n’est spécifiée dans l’objet `translations`, la valeur par défaut est « en ». Par exemple, si un utilisateur consulte le site example.com/product_123, par défaut, le site affiche le rendu du modèle de texte anglais.
De même, pour prendre en charge une salle d’attente multilingue pour les sites délimitant la structure du site par sous-domaine, il suffirait de modifier la manière dont le paramètre régional est extrait de l’URL. Au lieu d’examiner `pathname`, nous examinons la propriété `hostname` de l’objet `window.location` (par exemple, `locale = location.hostname.split(“.”)[0]`),étant donné que la structure de notre site est la suivante : en.example.com, es.example.com.
Le code présenté ci-dessus est un exemple réduit des modèles de démarrage que nous avons ajoutés à notre documentation pour développeurs afin de faciliter la configuration d’une salle d’attente multilingue. Vous pouvez télécharger ces modèles et les modifier afin d’adapter leur apparence et leur fonctionnalité à votre site et aux options linguistiques proposées par celui-ci.
Il s’agit d’un exemple du modèle de démarrage fourni dans la documentation pour développeurs. Cette salle d’attente est configurée pour mettre tous les utilisateurs en file d’attente et affiche le texte en espagnol lorsque l’utilisateur consulte la page example.com/es/product_123.
Ces modèles peuvent être étendus pour inclure d’autres langues en ajoutant des traductions à l’objet `translations` pour chacun des paramètres régionaux. Un modèle unique peut ainsi servir plusieurs langues en fonction des paramètres régionaux définis pour le site, qu’il s’agisse d’un sous-domaine ou d’un chemin d’accès.
Comment nous gérons les cookies avec une salle d’attente couvrant plusieurs noms d’hôtes et chemins d’accès
La salle d’attente alloue à chaque utilisateur un cookie `__cfwaitingroom` permettant de gérer son état ; ce cookie détermine la position de l’utilisateur dans la file d’attente, ainsi que d’autres propriétés nécessaires pour prendre les décisions de mise en file d’attente. Traditionnellement, pour une configuration comportant un nom d’hôte et un chemin d’accès uniques, il était extrêmement simple de définir le cookie comme ceci : `__cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123`. Ainsi, lorsque la page était actualisée, elle transmettait le même cookie Waiting Room, nous permettant de l’examiner et de le mettre à jour. Toutefois, cette procédure devenait beaucoup moins simple lorsque nous voulions partager le même cookie pour différentes combinaisons de sous-domaines ou de chemins d’accès, par exemple, `example.com/en/product_123`.
Approches de la configuration de plusieurs cookies
Nous avons envisagé et évalué deux approches permettant le partage du cookie pour une même salle d’attente.
La première approche que nous avons envisagée consistait à insérer plusieurs en-têtes `Set-Cookie` dans la réponse HTTP. Par exemple, dans l’exemple multilingue ci-dessus, nous pourrions ajouter les indications suivantes dans l’en-tête de la réponse :
Cette approche nous permettrait de gérer plusieurs noms d’hôtes et chemins d’accès pour une même salle d’attente. Cependant, elle ne constitue pas une solution très évolutive. Conformément à RFC6265, aucune limite stricte n’est définie dans la spécification ; les navigateurs comportent des limites particulières, spécifiques à l’implémentation. Par exemple, Chrome accepte une taille d’en-tête de 256 K octets avant de renvoyer l’erreur ERR_RESPONSE_HEADERS_TOO_BIG pour la transaction. Par ailleurs, dans ce cas, la taille de l’en-tête de réponse augmenterait proportionnellement au nombre de combinaisons uniques de noms d’hôtes et de chemins d’accès et, de manière redondante, nous répéterions N fois (où N représente le nombre d’itinéraires supplémentaires) la même valeur de cookie. Cette approche nous aurait permis de gérer efficacement une liste restreinte de combinaisons de noms d’hôtes et de chemins d’accès à définir ; toutefois, elle n’était pas idéale dans les situations où un site particulier comportait plus qu’un nombre limité d’itinéraires.
La deuxième approche à laquelle nous avons réfléchi, et que nous avons choisie, consistait à placer le cookie sur le domaine racine (ou le sous-domaine le plus courant). En d’autres termes, nous déterminons le sous-domaine le plus courant à partir de la liste des itinéraires, et nous l’utilisons comme domaine. De manière similaire, pour les chemins d’accès, il s’agirait de déterminer le préfixe le moins commun à partir de la liste des chemins d’accès et de l’utiliser comme valeur à définir par l’attribut de chemin d’accès. Prenons l’exemple d’une salle d’attente pour laquelle les deux itinéraires suivants ont été configurés : a.example.com/shoes/product_123 et b.example.com/shoes/product_456.
Pour déterminer le domaine défini pour le cookie, nous voyons que `example.com` est le sous-domaine le plus courant parmi la liste des domaines. L’application de l’algorithme du sous-domaine le plus courant renverrait le domaine `example.com` ; en revanche, l’application de l’algorithme du préfixe le moins courant à l’ensemble de chemins d’accès `/shoes/product_123` et `/shoes/product_456` renverrait le chemin d’accès `/shoes`. Par conséquent, l’en-tête Set-Cookie serait le suivant :
Désormais, lorsqu’un visiteur accède à l’une des pages couvertes par cette salle d’attente, nous pouvons garantir que Waiting Room reçoit le bon cookie et que l’en-tête de la réponse contiendra uniquement `Set-Cookie`.
Cependant, la configuration n’est pas encore terminée. Bien que nous soyons en mesure d’identifier le sous-domaine commun (ou domaine racine) et le préfixe de chemin d’accès commun, un problème demeurerait si les itinéraires correspondant à une salle d’attente étaient identiques à ceux définis pour une autre salle d’attente. Par exemple, supposons que nous configurions deux salles d’attente pour un même site, sur lequel nous vendons nos chaussures spéciales :
Salle d’attente A
a.example.com/shoes/product_123
b.example.com/shoes/product_456
Salle d’attente B
c.example.com/shoes/product_789
d.example.com/shoes/product_012
Si nous appliquons le même algorithme que celui décrit ci-dessus, nous obtiendrons les mêmes propriétés de domaine et de chemin d’accès pour les deux cookies. Pour la salle d’attente A, le domaine serait `example.com` et le chemin d’accès serait `/shoes`. De même, pour la salle d’attente B, le sous-domaine le plus courant serait également example.com, et le préfixe de chemin d’accès le moins courant serait `/shoes`. Concrètement, ceci nous empêcherait de distinguer les deux cookies et de rediriger le visiteur vers la salle d’attente correcte. Afin de résoudre le problème du chevauchement des noms de cookies, nous avons introduit la nécessité de définir un suffixe personnalisé unique pour la zone du client. C’est pourquoi il est nécessaire de spécifier un suffixe de cookie personnalisé lors de la configuration d’une salle d’attente couvrant plusieurs noms d’hôtes ou chemins d’accès. Par conséquent, si la salle d’attente A reçoit le suffixe de cookie « a » et la salle d’attente B le suffixe de cookie « b », les deux définitions de `Set-Cookie` se présenteront comme ceci :
Lorsqu’un visiteur transmet une requête à une page pour laquelle ces deux salles d’attente différentes sont configurées, Waiting Room peut distinguer et sélectionner le cookie correspondant à la requête transmise et l’utiliser pour déterminer les paramètres de la salle d’attente applicables à cet utilisateur en fonction de l’endroit où il se trouve sur le site.
Avec l’ajout de la prise en charge de plusieurs hôtes et chemins d’accès par Waiting Room, nous sommes ravis de proposer des options plus flexibles pour l’incorporation de Waiting Room sur votre site, et ainsi, d’offrir à vos visiteurs la meilleure expérience possible, tout en protégeant votre site pendant les périodes d’affluence. Assurez-vous que votre site est toujours protégé contre les pics de trafic. Essayez dès aujourd’hui Waiting Room ou contactez-nous pour en savoir plus sur la solution Advanced Waiting Room.
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
{{#waitTimeKnown}}
var minutes = parseInt( {{waitTime}} , 10);
var time = document.getElementById('waitTime');
if ( minutes < 61) {
time.innerText = translations[locale]["waittime_60_less"]
} else {
time.innerText = translations[locale]["waittime_60_greater"]
}
{{/waitTimeKnown}}
// translate template text for each of the elements with “id” suffixed with “msg”
for (const msg of ["inline-msg", "patience-msg"]) {
const el = document.getElementById(msg);
if (el == null) continue;
el.innerText = translations[locale][msg];
}
</script>
</body>
</html>
2023년 10월 4일, Cloudflare에서는 DNS 확인 문제를 겪었으며, 이 문제는 UTC 07:00에 시작하여 UTC 11:00에 끝났습니다. 1.1.1.1 또는 Warp, Zero Trust 등의 제품 또는 1.1.1.1을 사용하는 타사 DNS 확인자를 사용하는 사람 중 일부는 유효한 쿼리에 대해 SERVFAIL DNS 응답을 받았을 수도 있습니다. 이번에 서비스가 중단되어 정말 죄송합니다. 이번 서비스 중단은 공격이 아니라 내부 소프트웨어 오류로 발생했습니다. 이 블로그에서는 어떤 장애였는지, 장애가 왜 발생했는지, 이런 일이 다시 발생하지 않도록 우리가 무엇을 하고 있는지 설명하겠습니다.
배경
도메인 네임 시스템(DNS)에서 모든 도메인 네임은 DNS 영역 내에 존재합니다. 이 영역은 함께 제어되는 도메인 이름과 호스트 이름의 모음입니다. 예를 들어, Cloudflare에서는 도메인 이름 cloudflare.com을 관리하며, 우리는 이를 “cloudflare.com” 영역이라고 부릅니다. .com의 최상위 도메인(TLD)은 타사 소유이며 “com” 영역에 있습니다. TLD는 cloudflare.com에 접속하는 방법에 대한 지침을 제공합니다. 모든 TLD 위에는 루트 영역이 있으며, 이 영역은 TLD에 도달하는 방법에 대한 지침을 제공합니다 . 즉, 루트 영역은 다른 모든 도메인 이름을 확인할 수 있는 중요한 영역입니다. DNS의 다른 중요한 부분과 마찬가지로 루트 영역은 DNSSEC로 서명되며, 이는 루트 영역 자체에 암호화 서명이 포함되어 있음을 의미합니다.
루트 영역은 루트 서버에 게시되지만, 루트 서버에 연결할 수 없는 경우에도 루트 영역의 정보를 계속 사용할 수 있도록 DNS 운영자가 루트 영역의 복사본을 자동으로 검색하고 보유하는 것이 일반적입니다 . Cloudflare의 재귀 DNS 인프라는 이러한 접근 방식을 채택하여 확인 프로세스를 더 빠르게 만듭니다. 루트 영역의 새 버전은 일반적으로 하루에 두 번 게시됩니다. 1.1.1.1에는 기본 DNS 로직 위에 static_zone이라고 불리는 WebAssembly 앱이 실행되어 새 버전을 사용할 수 있을 때 해당 버전을 제공합니다.
사건 발생 과정
9월 21일, 루트 영역 관리의 알려진 요금제 변경의 일환으로 새로운 리소스 레코드 유형이 처음으로 루트 영역에 포함되었습니다. 새 리소스 레코드는 ZONEMD라고 불리며, 사실상 루트 영역의 콘텐츠에 대한 검사 합계입니다.
루트 영역은 Cloudflare의 코어 네트워크에서 실행되는 소프트웨어에 의해 검색됩니다. 이후 전 세계 Cloudflare의 데이터 센터로 재배포됩니다. 변경 후에도, ZONEMD 레코드가 포함된 루트 영역은 정상적으로 계속 검색되고 배포되었습니다. 그렇지만 해당 데이터를 사용하는 1.1.1.1 확인자 시스템에서 ZONEMD 레코드를 구문 분석하는 데 문제가 있었습니다. 영역은 전체가 로드되어 제공되어야 하므로, 시스템에서 ZONEMD를 구문 분석하지 못했다는 것은 Cloudflare의 확인자 시스템에서 새 버전의 루트 영역이 사용되지 않았다는 것을 의미했습니다. Cloudflare의 확인자 인프라를 호스팅하는 일부 서버에서는 새 루트 영역이 수신되지 않으면 요청별로 DNS 루트 서버를 직접 쿼리하는 방식으로 장애 조치되었습니다. 그러나 다른 서버에서는 변경 전인 9월 21일에 가져온 버전인 메모리 캐시에서 여전히 사용 가능한 루트 영역의 알려진 작동 버전에 계속 의존하고 있었습니다.
2023년 10월 4일 07:00 UTC에 9월 21일 루트 영역 버전의 DNSSEC 서명이 만료되었습니다. Cloudflare 확인자 시스템에서 사용할 수 있는 최신 버전이 없었으므로 일부 Cloudflare 확인자 시스템에서 DNSSEC 서명의 유효성을 검사할 수 없게 되었고, 그 결과로 오류 응답(SERVFAIL)을 전송하기 시작했습니다. Cloudflare 확인자가 SERVFAIL 응답을 생성하는 비율이 12% 증가했습니다. 아래 다이어그램에는 장애의 진행 상황과 사용자에게 장애가 표시되는 과정이 나와있습니다.
사고 타임라인 및 영향
9월 21일 6:30 UTC: 루트 영역의 마지막 풀 성공 10월 4일 7:00 UTC: 9월 21일에 획득한 루트 영역의 DNSSEC 서명이 만료되어 클라이언트 쿼리에 대한 SERVFAIL 응답이 증가함. 7:57: 예기치 않은 SERVFAIL에 대한 첫 외부 보고가 접수되기 시작함. 8:03: 내부적 Cloudflare 사고가 선언됨. 8:50: 재정의 규칙을 사용하여 1.1.1.1에서 오래된 루트 영역 파일을 사용하여 응답을 제공하지 못하도록 막으려는 첫 번째 시도가 있었음. 10:30: 1.1.1.1에서 루트 영역 파일을 미리 로드하는 것을 완전히 차단했음. 10:32: 응답이 정상으로 복귀함. 11:02: 사고 종결됨.
아래 차트에는 영향의 타임라인과 함께 SERVFAIL 오류로 반환된 DNS 쿼리의 비율이 나와있습니다.
우리는 정상 운영 시 일반 트래픽에 대한 기본 SERVFAIL 오류의 양을 예상합니다. 그 비율은 일반적으로 3% 정도입니다. 이러한 SERVFAIL은 DNSSEC 체인의 합법적인 문제, 권한 있는 서버에 연결하지 못함, 권한 있는 서버에서 응답하는 데 너무 오래 걸림 등으로 인해 발생할 수 있습니다. 사고 기간에 SERVFAIL의 양은 전체 쿼리의 15%로 최고조에 달했지만, 그 영향은 전 세계에 걸쳐 고르게 분산되지 않았고 주로 버지니아주 애쉬번, 독일 프랑크푸르트, 싱가포르 등의 대규모 데이터 센터에 집중되었습니다.
이 사고가 발생한 이유
ZONEMD 레코드 구문 분석에 실패한 이유
DNS에는 리소스 레코드를 저장하기 위한 바이너리 형식이 있습니다. 이 바이너리 형식에서 리소스 레코드 유형(TYPE)은 16비트 정수로 저장됩니다. 리소스 레코드 유형에 따라 리소스 데이터(RDATA)가 구문 분석되는 방식이 결정됩니다. 레코드 유형이 1이면 A 레코드라는 의미이며, RDATA는 IPv4 주소로 구문 분석될 수 있습니다. 레코드 유형 28은 AAAA 레코드로, 그 RDATA는 대신 IPv6 주소로 구문 분석될 수 있습니다. 파서가 알 수 없는 리소스 유형을 만나면 RDATA를 구문 분석하는 방법을 알 수 없지만, 다행히도 분석할 필요가 없습니다. RDLENGTH 필드가 RDATA 필드의 길이를 나타내어 파서가 불확실한 데이터 요소로 처리할 수 있으니까요.
static_zone에서 새로운 ZONEMD 레코드를 지원하지 않았던 이유는 당사에서 지금까지 루트 영역을 내부적으로 바이너리 형식이 아닌 프레젠테이션 형식으로 배포하기로 선택했기 때문입니다. 몇 가지 리소스 레코드의 텍스트 표현을 살펴보면 다양한 레코드가 표시되는 방식에 훨씬 더 많은 차이가 있음을 알 수 있습니다.
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023100400 1800 900 604800 86400
. 86400 IN RRSIG SOA 8 0 86400 20231017050000 20231004040000 46780 . J5lVTygIkJHDBt6HHm1QLx7S0EItynbBijgNlcKs/W8FIkPBfCQmw5BsUTZAPVxKj7r2iNLRddwRcM/1sL49jV9Jtctn8OLLc9wtouBmg3LH94M0utW86dKSGEKtzGzWbi5hjVBlkroB8XVQxBphAUqGxNDxdE6AIAvh/eSSb3uSQrarxLnKWvHIHm5PORIOftkIRZ2kcA7Qtou9NqPCSE8fOM5EdXxussKChGthmN5AR5S2EruXIGGRd1vvEYBrRPv55BAWKKRERkaXhgAp7VikYzXesiRLdqVlTQd+fwy2tm/MTw+v3Un48wXPg1lRPlQXmQsuBwqg74Ts5r8w8w==
. 518400 IN NS a.root-servers.net.
. 86400 IN ZONEMD 2023100400 1 241 E375B158DAEE6141E1F784FDB66620CC4412EDE47C8892B975C90C6A102E97443678CCA4115E27195B468E33ABD9F78C
알 수 없는 리소스 레코드가 발생하면 처리 방법을 쉽사리 알아낼 수 없습니다. 이 때문에 에지에서 루트 영역을 구문 분석하려고 우리가 사용하는 라이브러리에서는 처리하는 것을 시도하지 않고 대신 파서 오류를 반환합니다.
오래된 버전의 루트 영역이 사용된 이유
루트 영역을 로컬로 제공하기 위해 루트 영역을 로드하고 구문 분석하는 작업을 담당하는 static_zone 앱(RFC 7706)은 최신 버전을 메모리에 저장합니다. 새 버전이 게시되면 이 앱은 이를 구문 분석하고 성공적으로 구문 분석이 완료되면 이전 버전을 삭제합니다. 그러나 구문 분석에 실패했으므로 static_zone 앱은 최신 버전으로 전환하지 않고 이전 버전을 무기한 계속 사용했습니다. 1.1.1.1 서비스가 처음 시작될 때 static_zone 앱의 메모리에는 기존 버전이 없습니다. 루트 영역을 구문 분석하려고 할 때 실패하지만, 의존할 이전 버전의 루트 영역이 없기 때문에 다시 직접 루트 서버에 쿼리하는 것에 의존하여 들어오는 요청을 처리하게 됩니다.
static_zone 비활성화를 처음 시도했을 때 실패한 이유
우리는 초기에 1.1.1.1의 일부 동작을 프로그래밍 방식으로 변경할 수 있는 메커니즘인 오버라이드 규칙을 통해 static_zone 앱을 비활성화하려고 시도했습니다. 우리가 배포한 규칙은 다음과 같습니다.
phase = pre-cache set-tag rec_disable_static
이 규칙은 들어오는 모든 요청에 대해 rec_disable_static 태그를 추가합니다. static_zone 앱 내에서 이 태그가 설정되어 있는지 확인하고, 설정되어 있으면 캐시된 정적 루트 영역에서 응답을 반환하지 않습니다. 그러나 캐시 성능을 개선하기 위해 현재 노드가 자체 캐시에서 응답을 찾을 수 없는 경우 쿼리가 다른 노드로 전달되는 경우가 있습니다. 안타깝게도 다른 노드로 전달되는 쿼리에는 rec_disable_static 태그가 포함되어 있지 않으므로, 결국 우리가 앱을 완전히 비활성화할 때까지 static_zone 앱에서 오래된 정보로 계속 응답하게 되었습니다.
영향이 부분적이었던 이유
Cloudflare에서는 전체 시스템을 다시 시작한 후에만 적용될 수 있는 커널 업데이트와 같은 작업을 위해 서비스를 호스팅하는 서버의 롤링 재부팅을 정기적으로 수행합니다. 이번 중단 당시, ZONEMD 변경과 DNSSEC 무효화 사이에 재시작된 확인자 서버 인스턴스는 영향에 기여하지 않았습니다. 확인자 서버 인스턴스가 이 2주의 기간 동안 다시 시작되었다면 시작 시 루트 영역을 로드하지 못하고 대신 루트 서버로 DNS 쿼리를 전송하는 방식으로 다시 확인했을 것입니다. 또한 확인자는 잠재적으로 오래된 캐시에서 인기 있는 레코드를 계속 제공하여 영향을 제한하기 위한 목적으로 서브 스테일(RFC 8767)이라는 기술을 사용합니다. 레코드가 업스트림에서 검색된 후 TTL 시간(초)이 경과하면 레코드는 오래된 것으로 간주됩니다. 이로 인해 전체 서비스 중단은 발생하지 않았으며, 해당 기간 동안 1.1.1.1 서비스를 재시작하지 않은 서버가 많은 대규모 데이터 센터에서 주로 영향이 나타났습니다.
복원 및 후속 조치
이 사고는 광범위한 영향을 미쳤으며 Cloudflare에서는 당사 서비스의 가용성을 아주 중요하게 생각합니다. 개선 가능한 영역을 몇 가지 확인했으며, 재발을 초래할 수 있는 또 다른 허점이 있는지 찾기 위하여 계속 노력하겠습니다.
다음 사항을 즉시 작업하고 있습니다.
가시성: 우리는 static_zone에서 오래된 루트 영역 파일을 제공할 때 알려주는 알림을 추가하고 있습니다. 오래된 루트 영역 파일이 제공되는 것을 그처럼 오랫동안 눈에 알아차리지 못하는 경우는 없어야 합니다. 존재하는 캐싱을 통해 이를 더 잘 모니터링했다면 아무런 영향도 받지 않았을 것입니다. 업스트림 변경으로부터 고객과 사용자를 보호하는 것이 우리의 목표입니다.
복원력: 내부적으로 루트 영역을 수집하고 배포하는 방법을 재평가하겠습니다. 수집 및 배포 파이프라인은 새로운 RRTYPE을 원활하게 처리해야 하며, 파이프라인이 잠시 중단되어도 최종 사용자에게는 보이지 않아야 합니다.
테스트: 이 문제에 대한 테스트가 마련되어 있으며, 새로운 ZONEMD 레코드 구문 분석 시 미공개 변경 사항과 관련된 테스트도 포함되어 있지만, 우리는 루트 영역에서 구문 분석에 실패할 때 발생하는 상황을 적절하게 테스트하지 못했습니다. 테스트 범위와 관련 프로세스를 개선하겠습니다.
아키텍처: 루트 영역의 오래된 사본을 지정된 시점이 지나서 사용해서는 안 됩니다. 한정된 시간 동안은 오래된 루트 영역 데이터를 계속 사용할 수 있지만, 지정된 시점이 지나면 허용할 수 없는 운영상의 위험이 발생할 수 있습니다. 캐시된 루트 영역 데이터의 수명을 ‘RFC 8806: 확인자에 로컬로 루트 서버 실행’에 설명된 대로 더 잘 관리할 수 있도록 조치를 취하겠습니다.
결론
이번 사고가 발생한 것에 대해 깊은 유감을 표합니다. 이 사고로부터 한 가지 분명한 메시지를 얻을 수 있다면, 절대 무언가가 변하지 않을 것이라고 가정해서는 안 된다는 것입니다! 최신 시스템은 최종 실행 파일로 가져오는 긴 라이브러리 체인으로 구축되는 경우가 많은데, 각 라이브러리는 버그가 있거나 입력 변경이 발생했을 때 프로그램이 올바르게 작동할 수 있도록 충분히 빨리 업데이트되지 않을 수 있습니다. 우리는 입력 변경 시 정상적으로 작동하지 않는 시스템 및 구성 요소와 회귀를 감지할 수 있는 우수한 테스트를 마련하는 것이 얼마나 중요한지 잘 알고 있습니다. 또한 인터넷에서 가장 중요한 시스템(DNS 및 BGP)의 ‘형식’ 변경이 영향을 미칠 것이라는 점을 항상 가정해야 한다는 점도 잘 알고 있습니다.
내부적으로 후속 조치를 취해야 할 사항이 많으며, 당사에서는 이와 같은 일이 다시는 발생하지 않도록 불철주야 노력하고 있습니다.
През септември „Тоест“ не можа да поднови работата си, защото финансовите резерви на сайта се бяха изчерпали. В банковата сметка бяха останали пари, с които могат да се покрият по-малко от два авторски хонорара за статии, без да броим заплащането за редакторската и коректорската работа. Благодарение на спонтанната дарителска кампания финансирането на „Тоест“ е осигурено поне за няколко месеца напред – докато даряващите по-сериозни месечни суми преценят, че могат да продължават да го правят.
Но същностният проблем остава. И той не е на „Тоест“.
Например по същото време, когато „Тоест“ остана без пари, предаването „Въпросите“ по TV1 спря да съществува за неопределено време – също поради липса на финансиране. За него работеха журналисти като Генка Шикерова, Миролюба Бенатова, Светла Петрова, Емилия Милчева, както и Милен Цветков до смъртта си. В края на миналата година вестник „Сега“ престана да излиза на хартия, с което възможностите на аудиторията да получи качествено съдържание от „традиционен“ вестник се стесниха до абсолютния минимум.
Други медии, отстояващи редакционна независимост, приключиха съществуването си, защото новите им собственици така решиха. Например телевизионният канал BiT, в който работеха както едни от най-авторитетните имена в журналистиката като Нери Терзиева, Петко Георгиев и Ралица Василева, така и млади професионалисти като Ивайло Везенков, днес водещ в bTV. Или вестник „Култура“, който след 60 години съществуване беше спрян, защото не се вписваше в представите на собствениците си от Фондация „Комунитас“ за християнска насоченост. Списъкът може да продължи още дълго.
Глобалният генезис на проблема
Проблемът не е само български. Не е и само на медиите. В ерата на хартиените вестници и списания читателите си ги купуваха и по този начин финансираха редакциите. Затова на медиите се гледаше като на вид търговски дружества. С навлизането на интернет аудиторията вече може да намери голяма част от съдържанието, което я интересува, в мрежата, при това безплатно. Мрежата се превръща в конкуренция и на „класическите“ електронни медии – радиото и телевизията.
Аналогични проблеми възникват и в други сфери, например в музикалната и филмовата индустрия. Едно от исканията на стачкуващите доскоро холивудски сценаристи беше да получават справедлива част от печалбата от излъчването на филмите им в т.нар. стрийминг платформи. Тези платформи са проблем и за музикантите, защото все по-малко от техните почитатели биха си купили албумите им на физически носител.
Стратегии за оцеляване и последствията от тях
Музикантите все още могат да печелят от концерти, но да се върнем на българските медии. За да оцелее икономически, една онлайн медия може да прилага различни методи, както и комбинация от тях. Например да показва реклами и/или да ограничи достъпа до съдържанието си само до аудиторията, която е готова да плати за него.
При варианта с рекламите от ключово значение е популярността на медията, измерена в брой кликове. За осигуряването на повече кликове онлайн медиите прилагат различни методи. Отново – нерядко в комбинация:
Известен начин да се привлекат повече кликове е да се поднася информация по сензационен начин, без особена грижа за достоверността ѝ.
Повечето публикации също водят до повече кликове. Така в стремежа си да оцелеят някои медии, включително от по-читавите, публикуват комай всички прессъобщения, които им се изпращат, без проверка на съдържанието им и дори без да се прочетат внимателно. Например от уважаван сайт (нека спестим името му) читателят може да научи, че през изминалата година 64 мъже са станали донори на… яйцеклетки. И не, в „новината“ не става въпрос за транссексуални мъже.
Някои от препубликуваните прессъобщения по всичко приличат на платени, но в статията няма информация дали е така. Понякога тя дори излиза от името на журналист от медията.
Поддържането на секции с читателски коментари, които в България са се превърнали в пространство, населявано основно от разпространяващи омраза и дезинформация тролове, също е метод за привличане на кликове. Дори когато редакциите имат доброто желание, често нямат ресурси да отделят малкото „зърно“ от многото „плява“.
Друг проблем с рекламите е рискът платежоспособни рекламодатели да се оттеглят, ако бъдат засегнати интересите им, което нерядко води до цензура и автоцензура. Пример – статията на Йовко Ламбрев за А1, която никоя медия не отрази и която остана „незабелязана“ от сайтовете, препечатващи често съдържание от „Тоест“.
Частни медии и частни интереси по български
Възможен начин една медия да оцелее е да бъде притежавана/купена от човек, организация или корпорация с достатъчно средства за поддържането ѝ. Малцина са обаче онези, които биха си имали медия, без да търсят печалба от инвестицията си и без да искат да я използват за определени цели. И без в някакъв момент да решат просто да я захвърлят, както стана с BiT и вестник „Култура“.
Наличието на сериозен финансов ресурс в една медия само̀ по себе си не е гаранция, че този ресурс ще бъде използван за качествена журналистика, а не, да речем, за отвличане на общественото внимание и/или за обслужването на интересите на силните на деня.
Големите частни телевизии например разполагат с предостатъчно средства, за да правят сериозни журналистически разследвания. Вместо това централните новини се превръщат в своеобразно състезание за колко повече време и от колко повече репортери ще бъде отразена една и съща новина. Смъртта на Алексей Петров по bTV например отразяваха петима репортери, като две репортерки бяха от две различни страни на лобното му място. А миналата година, когато корабът „Вера Су“ беше заседнал край Камен бряг, един репортер всяка вечер се включваше от мястото на инцидента, брулен от влажния есенен вятър, с „новината“, че корабът още си е там.
На този фон внезапното номиниране на доскорошния директор на новините на bTV Антон Хекимян за кандидат-кмет от ГЕРБ оголва вече съществуващия проблем с медийната зависимост от властта.
Общественото финансиране и има ли то почва у нас
Един от възможните начини за финансиране на некомерсиални и независими медии е чрез данъци. В Германия например съществуват множество обществени медии и обединения на някои от тях, които предлагат съдържание, включително онлайн, свързано с редица непопулярни теми. Някои от тези теми са на границата на табуто (например документалният филм за двойка педофили, които са взели решение да не злоупотребяват с деца), а други са толкова тежки, че са трудно поносими (например проследяването на живота на дете, чиято майка бавно умира от рак).
Ала и съществуващите обществени медии в България често пъти не изпълняват функцията си да предоставят независимо от политически и икономически обременености съдържание в интерес на обществото. В степента, в която все пак я изпълняват, това става поради професионализма и съвестта на отделни журналисти. Нито ръководителят на БНТ Емил Кошлуков, нито по-голямата част от членовете на Съвета за електронни медии изглежда да проявяват разбиране що е то обществена медия. На този фон няма гаранция, че парите на данъкоплатците биха могли да подсигурят независимост на некомерсиални журналистически проекти.
В България все пак има независими медии, чиято издръжка идва от данъкоплатци, но… не от българските. „Дойче Веле“ е германска обществена медия, а „Свободна Европа“ се финансира от Конгреса на САЩ.
В дебрите на проектното финансиране
Медиите, които се опитват да са независими, често са обвинявани, че са „грантаджийски“, тоест че се финансират от проекти на различни организации, сякаш това е някакво престъпление. За една медия обаче проектното финансиране, макар понякога да го получава, трудно може да бъде разпределено безпроблемно, освен ако медията не е тясно специализирана в определена сфера. Защо?
Характерно за проектите е, че с много малки изключения те са по определени теми. Например една медия печели проект, по силата на който трябва в продължение на година да публикува определен брой материали по темата за равенството на половете. Но ако медията иска да отразява и други теми – да речем, местните избори или войната в Украйна, – се налага да търси начини да прехвърля пари „от единия джоб в другия“.
Всъщност поради разпространеното убеждение, че медиите трябва да са по дефиниция икономически печеливши начинания, много по-често се случва неправителствени организации да печелят проекти, свързани с медиите, отколкото медии да печелят проекти, гарантиращи собственото им оцеляване.
Година след година организации изпълняват проекти – било за изследване на медиите, било за обучения на журналисти. Изследванията водят до конкретни констатации и препоръки, обученията би трябвало да са научили журналистите на нещо. В резултат обаче медийната среда не се променя особено, защото препоръките не задължават медиите с нищо. И защото от обученията няма особен смисъл, ако те влизат в противоречие с изискванията към журналистическия труд. Колкото и да обясняват обучаващите каква е разликата между „хора, търсещи убежище“ и „нелегални мигранти“ или какво е „джендър“, ако от журналистите се иска да възпроизвеждат посланията на силните на деня, те най-вероятно това и ще правят.
В същото време – руска пропаганда, „четирихилядници“ и фабрики за тролове
Фондацията за хуманитарни и социални изследвания (ФХСИ) от години прави мониторинг на руската пропаганда в българските онлайн медии. По нейни данни тази пропаганда се увеличава. Преди малко повече от година пък бившата началничка на кабинета на Кирил Петков Лена Бориславова заяви пред радио „Дарик“, че определени публични личности вземат суми от порядъка на 4000 лв. месечно, за да разпространяват позициите на Русия.
Информация кои са т.нар. четирихилядници, не беше огласена, но в същото време е видно, че определени личности, между които и журналисти, разпространяват позиции в забележителен унисон с руските „опорни точки“. Като например твърдението, че Путин е политик „легалист“ в статия, публикувана в „Гласове“ от Явор Дачков и приписана от „Труд“ на Кеворк Кеворкян.
До неуспешния си опит за преврат ръководителят на паравоенната групировка „Вагнер“ Евгений Пригожин разполагаше с мощна „фабрика за тролове“, на които се плащаше, за да бъдат такива, и чието влияние надхвърляше границите на Русия.
Пропагандните послания, чиято цел е България да бъде отклонена от европейския си път, са не просто много, а и биват последователно прокарвани не само от публични личности, отделни журналисти, медии и редица сайтове. Те се разпространяват и от политически партии като БСП, „Възраждане“ и др. и не на последно място – от президента Румен Радев.
Борбата с пропагандата – да целиш слон с прашка
Докато пропагандата е професионално подготвена, добре организирана и за нея са отделени немалко средства, опитите за борба с нея не могат да се похвалят със същото. А в това отношение независимите медии биха могли да имат сериозна роля. Защото създават продукт, предназначен директно за аудиторията, без да са подчинени на частни и/или политически интереси. Но за да могат да достигнат до тази аудитория по адекватен начин, който може равностойно да противостои на пропагандата, те имат нужда от подкрепа.
Проблемът е, че това преобладаващо не се осъзнава нито от основните частни фондации, нито от публични организации като Европейската комисия, финансиращи проекти в защита на демократичните ценности. Те гледат на медиите предимно като на обект – било на изследване, било на обучение. И констатациите, че в тях има проблеми, не водят до смислени решения как е възможно те да бъдат преодолени.
Медиите не просто отразяват света. С начина си на отразяване и дори само с акцентирането върху едни теми и подминаването на други те неизбежно му влияят и го променят. Затова е от голямо значение кои медии каква чуваемост постигат.
Засега „Тоест“ оцеля – благодарение на ангажираната си аудитория. Това обаче не прави съществуването на независими медии в България много по-устойчиво, нито влиянието им – много по-голямо. Но поне дава надежда. На безрадостния медиен фон и това не е малко.
AWS Certificate Manager (ACM) lets you provision, manage, and deploy public and private Transport Layer Security (TLS) certificates for use with AWS services and your internal connected resources. You probably have many users, applications, or accounts that request and use TLS certificates as part of your public key infrastructure (PKI); which means you might also need to enforce specific PKI enterprise controls, such as the types of certificates that can be issued or the validation method used. You can now use AWS Identity and Access Management (IAM)condition context keys to define granular rules around certificate issuance from ACM and help ensure your users are issuing or requesting TLS certificates in accordance with your organizational guidelines.
In this blog post, we provide an overview of the new IAM condition keys available with ACM. We also discuss some example use cases for these condition keys, including example IAM policies. Lastly, we highlight some recommended practices for logging and monitoring certificate issuance across your organization using AWS CloudTrail because you might want to provide PKI administrators a centralized view of certificate activities. Combining preventative controls, like the new IAM condition keys for ACM, with detective controls and comprehensive activity logging can help you meet your organizational requirements for properly issuing and using certificates.
This blog post assumes you have a basic understanding of IAM policies. If you’re new to using identity policies in AWS, see the IAM documentation for more information.
Using IAM condition context keys with ACM to enforce certificate issuance guidelines across your organization
Let’s take a closer look at IAM condition keys to better understand how to use these controls to enforce certificate guidelines. The condition block in an IAM policy is an optional policy element that lets you specify certain conditions for when a policy will be in effect. For instance, you might use a policy condition to specify that no one can delete an Amazon Simple Storage Service (Amazon S3) bucket except for your system administrator IAM role. In this case, the condition element of the policy translates to the exception in the previous sentence: all identities are denied the ability to delete S3 buckets except under the condition that the role is your administrator IAM role. We will highlight some useful examples for certificate issuance later in the post.
When used with ACM, IAM condition keys can now be used to help meet enterprise standards for how certificates are issued in your organization. For example, your security team might restrict the use of RSA certificates, preferring ECDSA certificates. You might want application teams to exclusively use DNS domain validation when they request certificates from ACM, enabling fully managed certificate renewals with little to no action required on your part. Using these condition keys in identity policies or service control policies (SCPs) provide ACM users more control over who can issue certificates with certain configurations. You can now create condition keys to define certificate issuance guardrails around the following:
Certificate validation method — Allow or deny a specific validation type (such as email validation).
Certificate key algorithm — Allow or deny use of certain key algorithms (such as RSA) for certificates issued with ACM.
Certificate transparency (CT) logging — Deny users from disabling CT logging during certificate requests.
Domain names — Allow or deny authorized accounts and users to request certificates for specific domains, including wildcard domains. This can be used to help prevent the use of wildcard certificates or to set granular rules around which teams can request certificates for which domains.
Certificate authority — Allow or deny use of specific certificate authorities in AWS Private Certificate Authority for certificate requests from ACM.
Before this release, you didn’t always have a proactive way to prevent users from issuing certificates that weren’t aligned with your organization’s policies and best practices. You could reactively monitor certificate issuance behavior across your accounts using AWS CloudTrail, but you couldn’t use an IAM policy to prevent the use of email validation, for example. With the new policy conditions, your enterprise and network administrators gain more control over how certificates are issued and better visibility into inadvertent violations of these controls.
Using service control policies and identity-based policies
Before we showcase some example policies, let’s examine service control policies, or SCPs. SCPs are a type of policy that you can use with AWS Organizations to manage permissions across your enterprise. SCPs offer central control over the maximum available permissions for accounts in your organization, and SCPs can help ensure your accounts stay aligned with your organization’s access control guidelines. You can find more information in Getting started with AWS Organizations.
Let’s assume you want to allow only DNS validated certificates, not email validated certificates, across your entire enterprise. You could create identity-based policies in all your accounts to deny the use of email validated certificates, but creating an SCP that denies the use of email validation across every account in your enterprise would be much more efficient and effective. However, if you only want to prevent a single IAM role in one of your accounts from issuing email validated certificates, an identity-based policy attached to that role would be the simplest, most granular method.
It’s important to note that no permissions are granted by an SCP. An SCP sets limits on the actions that you can delegate to the IAM users and roles in the affected accounts. You must still attach identity-based policies to IAM users or roles to actually grant permissions. The effective permissions are the logical intersection between what is allowed by the SCP and what is allowed by the identity-based and resource-based policies. In the next section, we examine some example policies and how you can use the intersection of SCPs and identity-based policies to enforce enterprise controls around certificates.
Certificate governance use cases and policy examples
Let’s look at some example use cases for certificate governance, and how you might implement them using the new policy condition keys. We’ve selected a few common use cases, but you can find more policy examples in the ACM documentation.
Example 1: Policy to prevent issuance of email validated certificates
Certificates requested from ACM using email validation require manual action by the domain owner to renew the certificates. This could lead to an outage for your applications if the person receiving the email to validate the domain leaves your organization — or is otherwise unable to validate your domain ownership — and the certificate expires without being renewed.
We recommend using DNS validation, which doesn’t require action on your part to automatically renew a public certificate requested from ACM. The following SCP example demonstrates how to help prevent the issuance of email validated certificates, except for a specific IAM role. This IAM role could be used by application teams who cannot use DNS validation and are given an exception.
Note that this policy will only apply to new certificate requests. ACM managed certificate renewals for certificates that were originally issued using email validation won’t be affected by this policy.
Example 2: Policy to prevent issuance of a wildcard certificate
A wildcard certificate contains a wildcard (*) in the domain name field, and can be used to secure multiple sub-domains of a given domain. For instance, *.example.com could be used for mail.example.com, hr.example.com, and dev.example.com. You might use wildcard certificates to reduce your operational complexity, because you can use the same certificate to protect multiple sites on multiple resources (for example, web servers). However, this also means the wildcard certificates have a larger impact radius, because a compromised wildcard certificate could affect each of the subdomains and resources where it’s used. The US National Security Agency warned about the use of wildcard certificates in 2021.
Therefore, you might want to limit the use of wildcard certificates in your organization. Here’s an example SCP showing how to help prevent the issuance of wildcard certificates using condition keys with ACM:
Notice that in this example, we’re denying a request for a certificate where the leftmost character of the domain name is a wildcard. In the condition section, ForAnyValue means that if a value in the request matches at least one value in the list, the condition will apply. As acm:DomainNames is a multi-value field, we need to specify whether at least one of the provided values needs to match (ForAnyValue), or all the values must match (ForAllValues), for the condition to be evaluated as true. You can read more about multi-value context keys in the IAM documentation.
Example 3: Allow application teams to request certificates for their FQDN but not others
Consider a scenario where you have multiple application teams, and each application team has their own domain names for their workloads. You might want to only allow application teams to request certificates for their own fully qualified domain name (FQDN). In this example SCP, we’re denying requests for a certificate with the FQDN app1.example.com, unless the request is made by one of the two IAM roles in the condition element. Let’s assume these are the roles used for staging and building the relevant application in production, and the roles should have access to request certificates for the domain.
Multiple conditions in the same block must be evaluated as true for the effect to be applied. In this case, that means denying the request. In the first statement, the request must contain the domain app1.example.com for the first part to evaluate to true. If the identity making the request is not one of the two listed roles, then the condition is evaluated as true, and the request will be denied. The request will not be denied (that is, it will be allowed) if the domain name of the certificate is notapp1.example.com or if the role making the request is one of the roles listed in the ArnNotLike section of the condition element. The same applies for the second statement pertaining to application team 2.
Keep in mind that each of these application team roles would still need an identity policy with the appropriate ACM permissions attached to request a certificate from ACM. This policy would be implemented as an SCP and would help prevent application teams from giving themselves the ability to request certificates for domains that they don’t control, even if they created an identity policy allowing them to do so.
Example 4: Policy to prevent issuing certificates with certain key algorithms
You might want to allow or restrict a certain certificate key algorithm. For example, allowing the use of ECDSA certificates but restricting RSA certificates from being issued. See this blog post for more information on the differences between ECDSA and RSA certificates, and how to evaluate which type to use for your workload. Here’s an example SCP showing how to deny requests for a certificate that uses one of the supported RSA key lengths.
Notice that we’re using a wildcard after RSA to restrict use of RSA certificates, regardless of the key length (for example, 2048, 4096, and so on).
Creating detective controls for better visibility into certificate issuance across your organization
While you can use IAM policy condition keys as a preventative control, you might also want to implement detective controls to better understand certificate issuance across your organization. Combining these preventative and detective controls helps you establish a comprehensive set of enterprise controls for certificate governance. For instance, imagine you use an SCP to deny all attempts to issue a certificate using email validation. You will have CloudTrail logs for RequestCertificate API calls that are denied by this policy, and can use these events to notify the appropriate application team that they should be using DNS validation.
You’re probably familiar with the access denied error message received when AWS explicitly or implicitly denies an authorization request. The following is an example of the error received when a certificate request is denied by an SCP:
"An error occurred (AccessDeniedException) when calling the RequestCertificate operation: User: arn:aws:sts::account:role/example is not authorized to perform: acm:RequestCertificate on resource: arn:aws:acm:us-east-1:account:certificate/* with an explicit deny in a service control policy"
If you use AWS Organizations, you can have a consolidated view of the CloudTrail events for certificate issuance using ACM by creating an organization trail. Please refer to the CloudTrail documentation for more information on security best practices in CloudTrail. Using Amazon EventBridge, you can simplify certificate lifecycle management by using event-driven workflows to notify or automatically act on expiring TLS certificates. Learn about the example use cases for the event types supported by ACM in this Security Blog post.
Conclusion
In this blog post, we discussed the new IAM policy conditions available for use with ACM. We also demonstrated some example use cases and policies where you might use these conditions to provide more granular control on the issuance of certificates across your enterprise. We also briefly covered SCPs, identity-based policies, and how you can get better visibility into certificate governance using services like AWS CloudTrail and Amazon EventBridge. See the AWS Certificate Manager documentation to learn more about using policy conditions with ACM, and then get started issuing certificates with AWS Certificate Manager.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Want more AWS Security news? Follow us on Twitter.
In this release, we have made the implementation guidance for the new and updated best practices more prescriptive, including enhanced recommendations and steps on reusable architecture patterns targeting specific business outcomes in the Amazon Web Services (AWS) Cloud.
A brief history
The Well-Architected Framework is a collection of best practices that allow customers to evaluate and improve the design, implementation, and operations of their workloads in the cloud.
In 2020, Well-Architected Framework guidance had a new release, along with more lenses, as well as API integration with the AWS Well-Architected Tool. The sixth pillar, Sustainability, was added in 2021. In 2022, dedicated pages were introduced for each consolidated best practice across all six pillars, with several best practices updated with improved prescriptive guidance. By April 2023, more than 50% of the Framework’s best practices have had their prescriptive guidance improved.
A brief history of the AWS Well-Architected Framework
What’s new
As customers mature in their journey, they are seeking guidance to achieve accurate solutions that is prescriptive to their business, environments, and workloads. AWS Well-Architected is committed to providing such information to customers by continually evolving and updating our guidance.
The Operational Excellence Pillar has received updates to two of the five Design Principles and has a new Design Principle on observability, which highlights its importance and relevance throughout the pillar content. All 10 best practices in OPS05 have been updated, and we have consolidated 28 best practices into 16, across four questions (OPS04, OPS06, OPS08, and OPS09), as well as improving prescriptive guidance.
Security
In the Security Pillar, the Incident response in SEC10 underwent an update to align with the AWS Security Incident Response Guide, while introducing one new best practice, and improving the prescriptive guidance for others. Two best practices in SEC08 and SEC09 have received improved prescriptive guidance on securing workloads at rest and in transit.
Reliability
The Reliability Pillar has received prescriptive guidance improvements to one best practice in REL06, and six best practices in REL11, focused on how to best monitor, failover, remediate, and limit impacts of failures. The update addresses a wide variety of managed services and designs, including multi-Region-based resilience.
Performance Efficiency
The Performance Efficiency Pillar has been completely restructured, consolidating and merging guidance to reduce the number of best practices by 10 and the number of questions by three. We have added best practices around efficient caching and optimizing hardware acceleration. We have also improved the implementation guidance in all 32 best practices of the newly restructured Pillar.
Cost Optimization
The Cost Optimization Pillar has 10 best practices with improved implementation prescriptive guidance.
Sustainability
The Sustainability Pillar has received updates to the risk levels of seven best practices.
Conclusion
This Well-Architected release includes updates and improvements to 90 best practices: Operational Excellence (26), Security (8), Reliability (7), Performance Efficiency (32), Cost Optimization (10), and Sustainability (7). These changes are in addition to the 151 improved best practices released in 2023 (127 in April 10, 2023; and 24 in July 13, 2023), resulting in more than 73% of the existing Framework best practices updated at least once in the last year.
As of this release, 100% of Performance Efficiency, Cost Optimization, and Sustainability; 63% of Operational Excellence; 60% of Security; and 50% of Reliability Pillar content have been refreshed at least once since October 2022.
The content is available in 11 languages: English, Spanish, French, German, Italian, Japanese, Korean, Indonesian, Brazilian Portuguese, Simplified Chinese, and Traditional Chinese.
Updates in this release are also available in the AWS Well-Architected Tool, which can be used to review your workloads, address important design considerations, and help ensure that you follow the best practices and guidance of the AWS Well-Architected Framework.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
