Cost optimization using Azure Migrate

The higher energy cost and the resulting increase in the cost of doing business have led to a tighter economic outlook for most businesses around the world. This, in turn, is a major contributing factor to customers becoming more cost-conscious, leading to an increased need for optimization features in products and services. Azure Migrate’s comprehensive suite includes many features to optimize cost, while catering to your performance needs to meet service level agreements (SLAs). Agentless discovery and mapping of your entire on-premises IT estate, software inventory analysis for assessment and planning, and right-sized migration using a single portal to start, run, and track your projects, are a few cost-effective features that also contribute to ease of use. Once in Azure, the path towards greater optimization and cost savings continues through modernization to platform as a service (PaaS) and software as a service (SaaS).

Customer requirements and benefits

The customer must stay competitive, both on the technical and business fronts, to ensure continued success. Technical competency requires an agile and innovative IT platform with data analytics to provide insights that can help differentiate from the competition. It would be ideal if such an innovative platform were available at a competitive cost. Incidentally, modernizing existing IT infrastructure, applications, and data-to-PaaS/SaaS models in the cloud delivers on all these requirements, leading to a higher return on investment (ROI) for the customer.

The higher efficiency and lower cost due to the adoption of modern cloud-native architectures also lead to greater levels of flexibility and reduced vendor lock-in. Thus, setting the stage for the customer to realize greater value as they progress from IaaS to PaaS and onto SaaS models. Please download our analyst report for details on options and value due to application modernization in Azure.

Microsoft’s focus on cost optimization

During Microsoft Ignite, we are highlighting our continued commitment to cost optimization through support for SQL Server assessments, prior to migration and modernization using Azure Migrate. Customers can now perform unified, at-scale, agentless discovery and assessment of SQL Servers on Microsoft Hyper-V, bare-metal servers, and infrastructure as a service (IaaS) of other public clouds, such as AWS EC2, in addition to VMware environments. The capability will allow customers to analyze existing configurations, performance, and feature compatibility to help with right-sizing and estimating cost. It will also check on readiness and blockers for migrating to Azure SQL Managed instance, SQL Server on Azure virtual machine, and Azure SQL Database. All this information can also be presented in a single coherent report for easy consumption while reducing cost for customers.

Please see our tech community blog for more details. The blog presents a step-by-step procedure to get started, followed by details on scaling and support. Post-assessment options and more details on related topics are covered as well.

Learn more

Attend this Microsoft Ignite breakout session to learn more about how you can do more with less on Azure. For more details on other migration and modernization topics, including best-practice guidance and procedures for containers, networking and storage components, third-party tool integrations and hybrid management, please refer to the relevant blog topic in our migrate and modernize section.

Check out this FastTrack link for moving to Azure efficiently and get best practice guidance from the Azure migration and modernization center. The Azure migration and modernization program (AMMP) is now one comprehensive program for all migration and modernization needs of our customers. Learn more and join AMMP today.

 

Source:

Trends in Cloud Computing: 2022 State of the Cloud Report | Flexera Blog
Quelle: Azure

Scalable management of virtualized RAN with Kubernetes

Among the many important reasons why telecommunication companies should be attracted to Microsoft Azure are our network and system management tools. Azure has invested many intellectual and engineering cycles in the development of a sophisticated, robust framework that manages millions of servers and several hundred thousand network elements distributed in over one hundred and forty countries around the world. We have built tools and expertise to maintain these systems, use AI to predict problem areas and solve them before they become issues, and provide transparency in the performance and efficiency of a very large and complicated system.

At Microsoft, we believe these tools and expertise can be repurposed to manage and optimize telecommunication infrastructure as well. This is because the evolving infrastructure for telecommunication operators includes elements of edge and cloud computing that lend themselves well to global management. In this article, I will describe some of the more interesting technologies that fit into the management of a cloud-based telecommunications infrastructure.

Up and running in just a few clicks

If you want to set up a 5G cellular site, there are a few key requirements. After gathering and interconnecting your hardware (servers, network switches, cables, power supplies, and other components), you then plug in your edge server machines to power and networking outlets. Each machine will be accessible via a standards-based board management controller (BMC) that usually runs a lightweight operating system, Linux, for example, to remotely manage the machine via the network.

When powered up, the BMC will obtain an IP address, most likely from a networked DHCP server. Next, an Azure VPN Gateway will be instantiated—this is a Microsoft Azure-managed service that is deployed into an Azure Virtual Network (VNet), and provides the endpoint for VPN connectivity for point-to-site VPNs, site-to-site VPNs, and Azure ExpressRoute. This gateway is the connection point into Azure from either the on-premises network (site-to-site) or the client machine (point-to-site). Using private VNet peering allows Azure to talk to the BMC on each machine.

Once this is working, the network operator can enable scripts that talk to the BMC via Azure to run automatically and can install the basic input/output system (BIOS) and proper software operating system (OS) images on the machine. Once these edge machines have an OS, a Kubernetes (K8s) cluster can be created, encompassing multiple machines by using tools such as Kubeadm. The K8s cluster is connected to Microsoft Azure Arc so that workloads can be scheduled onto the cluster using Azure APIs.

Management via Azure Arc

Microsoft Azure Arc is a set of technologies that extend Azure management to any infrastructure, enabling the deployment of Azure data services anywhere. Specifically, Azure management can be extended to Linux and Windows physical and virtual servers, and to K8s clusters so Azure data services can run on any K8s infrastructure. In this way, Azure Arc provides a unified management experience across the entire telecommunications infrastructure estate, whether it’s on-premises, in a public cloud, or in multiple public clouds.

This creates a single pane view and automation control plane of its heterogeneous environments, as well as the ability to govern and manage all these resources in a consistent way. Microsoft Azure portal, role-based access control, resource groups, search, and services like Azure Monitor and Microsoft Sentinel are also enabled. Security for next-generation networks, like the ones telecommunications operators are lighting up, is a topic I recently wrote about.

For developers, this unified framework delivers the freedom to use the tools they are familiar with while focusing more on the business logic in their applications. Microsoft Arc along with other existing and new Microsoft technologies and services forms the basis of our Azure Operator Distributed Services which will bring a carrier-grade hybrid cloud service to the market.

However, running radio access network (RAN) functions on a vanilla Arc-connected Kubernetes cluster is difficult. It requires manual and vendor-specific tuning, resource management, and monitoring capabilities, making it difficult to deploy across servers with different specs and to scale as more virtual RAN (vRAN) deployments come up. Therefore, in addition to Microsoft Azure Arc and Azure Operator Distributed Services, we have developed the Kubernetes for Operator RAN (KfOR) framework, which provides extensions that are installed on top of vanilla K8s clusters to specifically enhance the deployment, management, and monitoring of RAN workloads on the cluster. These are the essential components necessary for lighting up the automatic management and self-healing properties of next-generation telecommunication cloud networks, creating an edge platform that turns the vRAN into yet another cloud-managed application.

Kubernetes for Operator RAN (KfOR) extensions for virtualized RAN

To optimally utilize edge server resources and provide reliability, telecommunication RAN network functions (NFs) typically run in containers within a server cluster, utilizing K8s for container orchestration. Although Kubernetes allows us to take advantage of a rich ecosystem of components, there are several challenges related to running high service-level agreements, high-performance, and latency-sensitive RAN NFs in edge datacenters.

For example, RAN NFs run close to the cell tower in the far-edge, which in many cases is owned by the telecommunications operator. Performance requirements for high availability, high performance, and low latency needed by vRAN necessitate the use of single root I/O virtualization(SR-IOV) working with a data plane development kit (DPDK), programmable switches, accelerators, and custom workload lifecycle controllers. This is well beyond what standard K8s offer.

To address these challenges, we have developed KfOR, which patches this hole and enables end-to-end deployment, RAN management, monitoring, and analytics experience through Azure.

The figure shows how the various components of Azure and Kubernetes (blue) and those developed by the Azure for Operators team (green) fit together. Specifically, it shows the use of an Azure Resource Provider (RP) and an Azure Managed App, which allows the spin-up of a Management Azure Kubernetes Service (AKS) cluster on Azure. This control-plane management cluster can then utilize open source and in-house developed components to deploy and manage the edge cluster (the Azure Arc–enabled Kubernetes workload cluster).

The control plane manages both the provisioning of the bare-metal nodes on the workload cluster, as well as the Kubernetes components running on these nodes. Within the workload cluster, KfOR provides custom Kubernetes extensions to simplify the development, deployment, management, and monitoring of multi-vendor NFs. KfOR utilizes extension points available in Kubernetes such as custom controllers, DaemonSets, mutating webhooks, and custom runtime hooks. Here are some examples of its capabilities:

Container suspension capability. KfOR can create pods that have containers that start in a suspended state but can be automatically activated in the future. This capability can be used for creating "warm standbys," which means these pods can immediately replace active pods that unfortunately fail, reducing downtime from several seconds to under one. In addition, this feature can also be used to ensure that pods launch in a predetermined order by specifying pod dependencies. vRAN workloads have some pods that require another pod to have reached a particular state prior to launching.
Advanced Kubernetes networking stack. KfOR provides an advanced networking library using DPDK and a method to auto-inject this library into any pod using a sidecar container. KfOR also provides a mechanism to autoload this library ahead of the standard sockets library. This allows for code written using standard User Datagram Protocol sockets to achieve microsecond latency using DPDK underneath, without modifying a single line of code.
Cloud-native user-space eBPF codelets. Extended Berkeley packet filter (eBPF) is used to extend the capabilities of the kernel safely and efficiently without requiring changing the kernel source code or loading kernel modules. KfOR provides a mechanism to submit user-space eBPF codelets to the K8s cluster, as well as a method for insertion of these codelets by using K8s pod annotations. The codelets attach dynamically to hook points in running code in the network functions and can be used for monitoring and analytics.
Advanced scheduling and management of cluster resources. KfOR provides a K8s device plugin that allows for the scheduling and usage of isolated CPU cores as a resource separate from standard CPU cores. This enables RAN workloads to run on a K8s cluster with no manual configuration, such as pinning threads to predefined cores. KfOR also provides a custom runtime hook to isolate resources so containers cannot use CPUs, network interface controllers, or accelerators that have not been assigned to them.

With these capabilities, we have accomplished one-click deployment of RAN workloads as well as real-time workload migration and defragmentation. As a result, KfOR is able to shut off unused nodes to save energy. KfOR is also able to properly configure programmable switches that are used to route traffic from one server to the next. Furthermore, with KfOR, we can deliver fine-grain RAN analytics, which will be discussed in a future blog.

KfOR goes beyond simple automation. It turns the far-edge into a true platform that treats the vRAN as yet another app that you can install, uninstall, and swap easily with a simple click of a button. It provides APIs and abstractions that allow vRAN vendors to fine-tune their functions for real-time performance without needing to know the details of the bare metal. This is in contrast to existing vRAN solutions that even though virtualized, still treat the vRAN as an appliance, which needs to be manually tuned and is not easily portable across servers with even slightly different configurations.

Deployment of KfOR extensions is completed by using the management cluster to launch the add-ons on the workload cluster. KfOR capabilities can be used by any K8s deployment by simply adding annotations to the workload manifest.

Robust stress-free RAN management

What I have described here is how the full power of preexisting cloud management tools along with the new KfOR technology can be put together to manage, monitor, automate, and orchestrate the near-edge and far-edge machines and software deployed within the emerging telecommunications infrastructure. Once the hardware and network are available, these capabilities can light up a cell site impressively quickly, without any pain, and without requiring deep expertise. KfOR, developed specifically for virtual RAN management, has significant built-in value for our customers. It enables Azure to plug in artificial intelligence for sophisticated automation along with tried-and-true technologies needed for self-managing and self-healing networks. Overall, it creates a differentiation of our offering in the telecommunications and enterprise markets.

Learn more

Follow us for additional developments in this space and more.
Learn more about Microsoft Azure Arc and Azure Kubernetes Service (AKS).
Sign up for Microsoft Azure today.

Quelle: Azure

How to Use the Postgres Docker Official Image

Postgres is one of the top relational, multi-model databases currently available. It’s designed to power database applications — which either serve important data directly to end users or through another application via APIs. Your typical website might fit that first example well, while a finance app (like PayPal) typically uses APIs to process GET or POST database requests. 

Postgres’ object-relational structure and concurrency are advantages over alternatives like MySQL. And while no database technology is objectively the best, Postgres shines if you value extensibility, data integrity, and open-source software. It’s highly scalable and supports complex, standards-based SQL queries. 

The Postgres Docker Official Image (DOI) lets you create a Postgres container tailored specifically to your application. This image also handles many core setup tasks for you. We’ll discuss containerization, and the Postgres DOI, and show you how to get started.

In this tutorial:

Why should you containerize Postgres? What’s the Postgres Docker Official Image?Can you deploy Postgres containers in production?How to run Postgres in DockerEnter a quick pull commandStart a Postgres instanceUsing Docker ComposeExtending your Postgres image1. Environment variables2. Docker secrets3. Initialization scripts4. Database configurationImportant caveats and data storage tipsJumpstart your next Postgres project today

Why should you containerize Postgres? 

Since your Postgres database application can run alongside your main application, containerization is often beneficial. This makes it much quicker to spin up and deploy Postgres anywhere you need it. Containerization also separates your data from your database application. Should your application fail, it’s easy to launch another container while shielding your data from harm. 

This is simpler than installing Postgres locally, performing additional configuration, and starting your own background processes. Such workflows take extra time, require deeper technical knowledge, and don’t adapt well to changing application requirements. That’s why Docker containers come in handy — they’re approachable and tuned for rapid development.

What’s the Postgres Docker Official Image?

Like any other Docker image, the Postgres Docker Official Image contains all source code, core dependencies, tools, and libraries your application needs. The Postgres DOI tells your database application how to behave and interact with data. Meanwhile, your Postgres container is a running instance of this standard image.

Specifically, Postgres is perfect for the following use cases:

Connecting Docker shared volumes to your applicationTesting your storage solutions during developmentTesting your database application against newer versions of your main application or Postgres itself

The PostgreSQL Docker Community maintains this image and added it to Docker Hub due to its widespread appeal.

Can you deploy Postgres containers in production?

Yes! Though this answer comes with some caveats and depends on how many containers you want to run simultaneously. 

While it’s possible to use the Postgres Official Image in production, Docker Postgres containers are best suited for local development. This lets you use tools like Docker Compose to collectively manage your services. You aren’t forced to juggle multiple database containers at scale, which can be challenging. 

Launching production Postgres containers means using an orchestration system like Kubernetes to stay up and running. You may also need third-party components to supplement Docker’s offerings. However, you can absolutely give this a try if you’re comfortable with Kubernetes! Arctype’s Shanika Wickramasinghe shares one method for doing so.

For these reasons, you can perform prod testing with just a few containers. But, it’s best to reconsider your deployment options for anything beyond that.

How to run Postgres in Docker

To begin, download the latest Docker Desktop release and install it. Docker Desktop includes the Docker CLI, Docker Compose, and supplemental development tools. Meanwhile, the Docker Dashboard (Docker Desktop’s UI component) will help you manage images and containers. 

Afterward, it’s time to Dockerize Postgres!

Enter a quick pull command

Pulling the Postgres Docker Official Image is the fastest way to get started. In your terminal, enter docker pull postgres to grab the latest Postgres version from Docker Hub. 

Alternatively, you can pin your preferred version with a specific tag. Though we usually associate pinning with Dockerfiles, the concept is similar to a basic pull request. 

For example, you’d enter the docker pull postgres:14.5 command if you prefer postgres v14.5. Generally, we recommend using a specific version of Postgres. The :latest version automatically changes with each new Postgres release — and it’s hard to know if those newer versions will introduce breaking changes or vulnerabilities. 

Either way, Docker will download your Postgres image locally onto your machine. Here’s how the process looks via the CLI:

Once the pull is finished, your terminal should notify you. You can also confirm this within Docker Desktop! From the left sidebar, click the Images tab and scan the list that appears in the main window. Docker Desktop will display your postgres image, which weighs in at 355.45 MB.

Postgres is one of the slimmest major database images on Docker Hub. But alpine variants are also available to further reduce your image sizes and include basic packages (perfect for simpler projects). You can learn more about Alpine’s benefits in our recent Docker Official Image article.

Next up, what if you want to run your new image as a container? While many other images let you hover over them in the list and click the blue “Run” button that appears, Postgres needs a little extra attention. Being a database, it requires you to set environment variables before forming a successful connection. Let’s dive into that now.

Start a Postgres instance

Enter the following docker run command to start a new Postgres instance or container: 

docker run –name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres

This creates a container named some-postgres and assigns important environment variables before running everything in the background. Postgres requires a password to function properly, which is why that’s included. 

If you have this password already, you can spin up a Postgres container within Docker Desktop. Just click that aforementioned “Run” button beside your image, then manually enter this password within the “Optional Settings” pane before proceeding. However, you can also use the Postgres interactive terminal, or psql, to query Postgres directly:

docker run -it –rm –network some-network postgres psql -h some-postgres -U postgres
psql (14.3)
Type "help" for help.

postgres=# SELECT 1;
?column?
———-
1
(1 row)

Using Docker Compose

Since you’re likely using multiple services, or even a database management tool, Docker Compose can help you run instances more efficiently. With a single YAML file, you can define how your services work. Here’s an example for Postgres:

services:

db:
image: postgres
restart: always
environment:
POSTGRES_PASSWORD: example
volumes:
– pgdata:/var/lib/postgresql/data

volumes:
pgdata:

adminer:
image: adminer
restart: always
ports:
– 8080:8080

You’ll see that both services are set to restart: always. This makes our data accessible whenever our applications are running and keeps the Adminer management service active simultaneously. When a container fails, this ensures that a new one starts right up.

Say you’re running a web app that needs data immediately upon startup. Your Docker Compose file would reflect this. You’d add your web service and the depends_on parameter to specify startup and shutdown dependencies between services. Borrowing from our docs on controlling startup and shutdown order, your expanded Compose file might look like this:

services:
web:
build: .
ports:
– "80:8000"
depends_on:
db:
condition: service_healthy
command: ["python", "app.py"]

db:
image: postgres
restart: always
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: [“CMD-SHELL”, “pg_isready”]
interval : 1s
timeout: 5s
retries: 10

adminer:
image: adminer
restart: always
ports:
– 8080:8080

To launch your Postgres database and supporting services, enter the docker compose -f [FILE NAME] up command. 

Using either docker run, psql, or Docker Compose, you can successfully start up Postgres using the Official Image! These are reliable ways to work with “default” Postgres. However, you can configure your database application even further.

Extending your Postgres image

There are many ways to customize or configure your Postgres image. Let’s tackle four important mechanisms that can help you.

1. Environment variables

We’ve touched briefly on the importance of POSTGRES_PASSWORD to Postgres. Without specifying this, Postgres can’t run effectively. But there are also other variables that influence container behavior: 

POSTGRES_USER – Specifies a user with superuser privileges and a database with the same name. Postgres uses the default user when this is empty.POSTGRES_DB – Specifies a name for your database or defaults to the POSTGRES_USER value when left blank. POSTGRES_INITDB_ARGS – Sends arguments to postgres_initdb and adds functionalityPOSTGRES_INITDB_WALDIR – Defines a specific directory for the Postgres transaction log. A transaction is an operation and usually describes a change to your database. POSTGRES_HOST_AUTH_METHOD – Controls the auth-method for host connections to all databases, users, and addressesPGDATA – Defines another default location or subdirectory for database files

These variables live within your plain text .env file. Ultimately, they determine how Postgres creates and connects databases. You can check out our GitHub Postgres Official Image documentation for more details on environment variables.

2. Docker secrets

While environment variables are useful, passing them between host and container doesn’t come without risk. Docker secrets let you access and load those values from files already present in your container. This prevents your environment variables from being intercepted in transit over a port connection. You can use the following command (and iterations of it) to leverage Docker secrets with Postgres: 

docker run –name some-postgres -e POSTGRES_PASSWORD_FILE=/run/secrets/postgres-passwd -d postgres

Note: Docker secrets are only compatible with certain environment variables. Reference our docs to learn more.

3. Initialization scripts

Also called init scripts, these run any executable shell scripts or command-based .sql files once Postgres creates a postgres-data folder. This helps you perform any critical operations before your services are fully up and running. Conversely, Postgres will ignore these scripts if the postgres-data folder initializes.

4. Database configuration

Your Postgres database application acts as a server, and it’s beneficial to control how it runs. Configuring your database not only determines how your Postgres container talks with other services, but also optimizes how Postgres runs and accesses data. 

There are two ways you can handle database configurations with Postgres. You can either apply these configurations locally within a dedicated file or use the command line. The CLI uses an entrypoint script to pass any Docker commands to the Postgres server daemon for processing. 

Note: Available configurations differ between Postgres versions. The configuration file directory also changes slightly while using an alpine variant of the Postgres Docker Official Image.

Important caveats and data storage tips

While Postgres can be pretty user-friendly, it does have some quirks. Keep the following in mind while working with your Postgres container images: 

If no database exists when Postgres spins up in a container, it’ll create a default database for you. While this process unfolds, that database won’t accept any incoming connections.Working with a pre-existing database is best when using Docker Compose to start up multiple services. Otherwise, automation tools may fail while Postgres creates a default.Docker will throw an error if a Postgres container exceeds its 64 MB memory allotment.You can use either a docker run command or Docker Compose to allocate more memory to your Postgres containers.

Storing your data in the right place

Data accessibility helps Postgres work correctly, so you’ll also want to make sure you’re storing your data in the right place. This location must be visible to both Postgres and Docker to prevent pesky issues. While there’s no perfect storage solution, remember the following: 

Writing files to the host disk (Docker-managed) and using internal volume management is transparent and user-friendly. However, these files may be inaccessible to tools or apps outside of your containers. Using bind mounts to connect external data to your Postgres container can solve data accessibility issues. However, you’re responsible for creating the directory and setting up permissions or security.

Lastly, if you decide to start your container via the docker run command, don’t forget to mount the appropriate directory from the host. The -v flag enables this. Browse our Docker run documentation to learn more.

Jumpstart your next Postgres project today

As we’ve discovered, harnessing the Postgres Docker Official Image is pretty straightforward in most cases. Since many customizations are available, you only need to explore the extensibility options you’re comfortable with. Postgres even supports extensions (like PostGIS) — which could add even deeper functionality. 

Overall, Dockerizing Postgres locally has many advantages. Swing by Docker Hub and pull your first Postgres Docker Official Image to start experimenting. You’ll find even deeper instructions for enhancing your database setup on our Postgres GitHub page. 

Need a springboard? Check out these Docker awesome-compose applications that leverage Postgres: 

Build a Go server with an NGINX proxy and a Postgres database.Create a sample Postgres and pgAdmin management setup.Build a React application with a Rust backend and Postgres database.Create a Java application with Spring Framework and a Postgres database.

Quelle: https://blog.docker.com/feed/

Amazon Connect führt aktualisierte Benutzeroberfläche und Sprache für Abläufe ein

Amazon Connect bietet nun eine verbesserte Benutzeroberfläche für den Ablauf-Designer, mit der es schneller und einfacher wird, personalisierte und automatisierte Erfahrungen für Endkunden zu schaffen. Mit diesem Launch können Sie nun leicht die verfügbaren Blöcke filtern um schnell zu finden, was Sie zum Aufbau des Ablaufs bruachen, farbkodierte Verbindungen zwischen Blöcken erstellen, zusätzliche Block-Metadaten auf einen Blick anzeigen (z. B. die Volltextaufforderung im Block „Aufforderung wiedergeben“) und mehr. Darüber hinaus können Sie mit der verbesserten Ablaufsprache jetzt Abläufe in Ihre Amazon Connect-Instance importieren und exportieren, wodurch das wechselseitige Aufbauen und Bearbeiten zwischen Benutzeroberfläche und API leicht wird.
Quelle: aws.amazon.com

Amazon Managed Streaming für Apache Kafka (Amazon MSK) ist jetzt in der AWS-Region Asien-Pazifik (Jakarta) verfügbar

Amazon Managed Streaming für Apache Kafka (Amazon MSK) ist jetzt in der AWS-Region Asien-Pazifik (Jakarta) verfügbar. Amazon MSK ist ein vollständig verwalteter Service für Apache Kafka und Kafka Connect, mit dem Sie Anwendungen, die Apache Kafka als Datenspeicher nutzen, problemlos entwickeln und ausführen können. Amazon MSK ist vollständig mit Apache Kafka kompatibel. So können Sie Ihre vorhandenen Apache-Kafka-Workloads schnell auf Amazon MSK migrieren oder neue Workloads von Grund auf erstellen können. Mit Amazon MSK verbringen Sie mehr Zeit mit der Entwicklung innovativer Anwendungen und weniger mit der Verwaltung von Clustern.
Quelle: aws.amazon.com

AWS kündigt die aktualisierte Support-Plans-Konsole mit neuen IAM-Kontrollen an

AWS Support bietet weiterhin ein Portfolio an Tools, Technologien, Experten und Programmen, die dir bei der Leistungsoptimierung, Kostenreduzierung und schnellen Innovation helfen. Die neue AWS-Support-Plans-Konsole vereinfacht jetzt das Anzeigen deines aktuellen Support-Plans und der innerhalb des Plans enthaltenen Funktionen und das Vergleichen deines Plans mit anderen AWS Support Plans.
Quelle: aws.amazon.com

AWS Systems Manager fügt zur Kontrolle von Aufgaben CloudWatch-Alarme hinzu

Heute kündigt AWS Systems Manager die Hinzufügung von CloudWatch-Alarmen zur Kontrolle von Aufgaben an. Jetzt können Kunden wählen, ob eine Aufgabe oder Aktion in den Services von Systems Manager angehalten werden soll, wenn ein CloudWatch-Alarm aktiviert ist. Auf diese Weise ist es den Kunden möglich, das breite Spektrum der von CloudWatch unterstützten Überwachungsmetriken, von der Ressourcennutzung bis zur Anwendungsleistung, für die Kontrolle von Aufgaben zu verwenden. Wenn der spezifische CloudWatch-Alarm aktiviert ist während einer Aufgabe, stoppt Automation die Aufgabe, RunCommand bricht die Befehle ab und State Manager und Maintenance Windows setzen den Versand aus. Der Einstieg ist einfach. Kunden können einen CloudWatch-Alarm hinzufügen, während sie eine Aufgabe in den Services von Systems Manager, wie z. B. Automation, Run Command, State Manager oder Maintenance Windows, einrichten. Sobald sie eingerichtet sind, können die Benutzer den zugefügten Alarm auf der Detailseite der Aufgabe anzeigen.
Quelle: aws.amazon.com