Search the Community

You can now leverage tag-based subnet discovery capability of Amazon VPC CNI to scale Amazon Elastic Kubernetes Service (EKS) clusters in IPv4 address space without adding operational complexity. In this new default mode, Kubernetes Pod IP addresses are allocated from all tagged and available subnets in your Amazon Virtual Private Cloud(VPC). View the full article

Users modernizing their applications using Amazon Elastic Kubernetes Service (Amazon EKS) on AWS often run into critical IPv4 address space exhaustion driven by scale. They want to maximize usage of the VPC CIDRs and subnets provisioned for the EKS pods without introducing additional operational complexity. We believe that use of IPv6 address space is the long-term solution for users to build scalable networking solutions. However, we also understand that Amazon EKS users may be constrained to IPv4 environments owing to dependencies on other networking components and applications’ support for IPv6. Therefore, Amazon EKS is introducing support for Enhanced Subnet Discovery for helping users streamline network configuration and scale IPv4 based clusters without adding operational complexity. How it works Amazon VPC Container Network Interface (CNI) plugin is deployed on each Amazon Elastic Compute Cloud (Amazon EC2) worker node in your EKS cluster. It creates and attaches Elastic Network Interfaces (ENIs) to your worker nodes, as well as assigns a private IPv4, IPv6 address from your VPC CIDR to each pod in the EKS cluster. By default, VPC CNI assigns IP addresses to pods from the same subnet as the worker node’s primary network interface, which is sometimes referred to as “usable subnet”. Without any additional configuration, a node can only attach ENIs from this usable subnet in which an EC2 instance was launched. With the new feature of VPC CNI, we are now expanding the scope of “usable subnet(s)”. When enhanced subnet discovery is enabled, pod IPs are automatically allocated from all available subnets/CIDRs in the VPC that are tagged for use. New subnets can be created and tagged using the specific tag “kubernetes.io/role/cni”, and they are integrated seamlessly into the existing network configuration. This enables you to scale your applications effectively with minimal disruption to ongoing operations. Prerequisites The following prerequisites are necessary to continue with this post: An AWS Account An EKS cluster with version 1.25 or higher – we use v1.29 in the walkthrough Amazon VPC CNI version 1.18.0 or later The latest version of AWS Command Line Interface (AWS CLI) configured on your device, or AWS CloudShell eksctl – a simple CLI tool for creating and managing EKS clusters (v0.165.0 or higher) Setup export AWS_REGION=<YOUR_AWS_REGION> #Replace with your AWS Region export AWS_ACCOUNT=<YOUR_ACCOUNT> #Replace with your AWS Account number export CLUSTER_NAME=eks-enhsubsel-demo #Replace with your EKS cluster name In this walkthrough we simulate an IP exhaustion scenario by creating an Amazon VPC with /24 CIDR block, which yields 256 IP addresses. It is divided into three public and three private subnets, and each is assigned with /27 CIDR block (28 IP addresses) as shown in the following figure. Once the VPC CIDR range is exhausted, we associate a secondary CIDR to the VPC, and then we create the VPC subnets with the “kubernetes.io/role/cni” tag so that VPC CNI can automatically discover and use the new subnets to allocate the Pod IP addresses. Figure 1: Amazon VPC setup Let’s start with creating an EKS cluster with VPC CNI version 1.18.0. cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: ${CLUSTER_NAME} region: ${AWS_REGION} version: "1.29" vpc: cidr: 10.0.0.0/24 addons: - name: vpc-cni version: 1.18.0 - name: coredns - name: kube-proxy managedNodeGroups: - name: ${CLUSTER_NAME}-mng instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 5 EOF eksctl create cluster -f cluster.yaml Wait for the cluster creation to be complete and make sure that vpc-cni addon is up and running in the cluster. aws eks describe-addon --addon-name vpc-cni --cluster-name $CLUSTER_NAME --region $AWS_REGION { "addon": { "addonName": "vpc-cni", "clusterName": "eks-enhsubsel-demo", "status": "ACTIVE", "addonVersion": "v1.18.0-eksbuild.1", .... } } As the subnets are assigned with /27 CIDR, note that private subnets only have few or no available IP addresses: aws ec2 describe-subnets --region $AWS_REGION \ --filters Name=tag:Name,Values="eksctl-eks-enhsubsel-demo-cluster/SubnetPrivate*" \ --query "Subnets[].{VPC:VpcId,SubnetId:SubnetId,AvailableIPs:AvailableIpAddressCount}" \ --output table ----------------------------------------------------------------------- | DescribeSubnets | +--------------+----------------------------+-------------------------+ | AvailableIPs | SubnetId | VPC | +--------------+----------------------------+-------------------------+ | 16 | subnet-08411e385d62f29da | vpc-07f75e9b1d954689a | | 7 | subnet-0755097835150b642 | vpc-07f75e9b1d954689a | | 0 | subnet-0975a78066e7e76d6 | vpc-07f75e9b1d954689a | +--------------+----------------------------+-------------------------+ Deploy a sample application and simulate the IP exhaustion scenario in the EKS cluster. cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: inflate spec: replicas: 50 selector: matchLabels: app: inflate template: metadata: labels: app: inflate spec: terminationGracePeriodSeconds: 0 containers: - name: inflate image: public.ecr.aws/eks-distro/kubernetes/pause:3.7 resources: requests: cpu: 50m EOF Due to the insufficient IPs, note many pods are in the “ContainerCreating” state, as the Amazon VPC CNI is unable to allocate the IP addresses. Now, let’s explore how we can use the Enhanced Subnet discovery feature of VPC CNI to automatically discover the new VPC Subnets with the available IP space, and use it to allocate IP addresses for the k8s pods. Amazon VPC supports up to five secondary IP CIDR blocks to extend the VPC IP space. Start by adding a secondary CIDR block “10.1.0.0/16” to the Amazon EKS VPC. export EKS_VPC_ID=$(aws eks describe-cluster --name $CLUSTER_NAME \ --region $AWS_REGION --query "cluster.resourcesVpcConfig.vpcId" --output text) aws ec2 associate-vpc-cidr-block --vpc-id $EKS_VPC_ID \ --cidr-block "10.1.0.0/16" --region $AWS_REGION { "CidrBlockAssociation": { "AssociationId": "vpc-cidr-assoc-06515a22930a5d6e9", "CidrBlock": "10.1.0.0/16", "CidrBlockState": { "State": "associating" } }, "VpcId": "vpc-07f75e9b1d954689a" } Wait for the association to complete, and start creating new VPC subnets from the secondary CIDR block. We are also tagging the subnets with “kubernetes.io/role/cni=1” so that VPC CNI can auto-discover them. aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"a --cidr-block 10.1.0.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"b --cidr-block 10.1.32.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"c --cidr-block 10.1.64.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" In the default setup, VPC CNI assigns both the primary and secondary IP addresses of an ENI from the VPC subnet associated with the Amazon EKS worker node’s primary network interface. aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-155.us-west-2.compute.internal | eni-07f66d0e6b2408fc7 | 10.0.0.155 | +--------------------------------------------+------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.155 || || 10.0.0.136 || || 10.0.0.140 || || 10.0.0.141 || || 10.0.0.145 || || 10.0.0.150 || || 10.0.0.135 || || 10.0.0.151 || || 10.0.0.148 || || 10.0.0.149 || |+-----------------------------------------------------------------------------------+| ......... |+----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+-------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-0-0-102.us-west-2.compute.internal | eni-087692b80786865e0 | 10.0.0.102 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.102 || || 10.0.0.105 || || 10.0.0.110 || || 10.0.0.126 || || 10.0.0.124 || || 10.0.0.125 || || 10.0.0.118 || || 10.0.0.100 || || 10.0.0.116 || || 10.0.0.117 || |+-----------------------------------------------------------------------------------+| Now, verify the new Enhanced Subnet Discovery feature is enabled by checking the “ENABLE_SUBNET_DISCOVERY” environment variable in the Amazon VPC CNI Addon. You can use kubectl to verify this kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY ENABLE_SUBNET_DISCOVERY: true As of this writing, the Enhanced Subnet Discovery feature is enabled by default in Amazon VPC CNI 1.18.0 and above. If the environment variable was not set to true, then you can use kubectl or AWS CLI to set this configuration: kubectl set env daemonset aws-node -n kube-system ENABLE_SUBNET_DISCOVERY=true \ -c aws-node or aws eks update-addon --cluster-name $CLUSTER_NAME --region $AWS_REGION \ --addon-name vpc-cni \ --configuration-values '{"env":{"ENABLE_SUBNET_DISCOVERY":"true"}}' When this feature is enabled, VPC CNI looks for the VPC Subnets tagged with “kubernetes.io/role/cni” and with the available IP Space. It attaches additional ENIs from these subnets to the Amazon EKS worker nodes so that it can assign the IP addresses to the k8s pods. In our walkthrough, as many pods are in the “ContainerCreating” state, VPC CNI automatically discovered the new subnets with /19 CIDR and attached them to the existing worker nodes. We can verify this using the following commands: kubectl get pods -o wide | grep ContainerCreating <<EMPTY OUTPUT>> Now, when we look at the ENIs attached to the worker nodes, note that an additional ENI from the secondary CIDR subnet is attached and pods are assigned from the 10.1.x.x IP range. aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-152.us-west-2.compute.internal | eni-0525ae09d044a6688 | 10.0.0.152 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.152 || || 10.0.0.144 || || 10.0.0.154 || || 10.0.0.147 || || 10.0.0.133 || || 10.0.0.157 || || 10.0.0.153 || || 10.0.0.158 || || 10.0.0.146 || || 10.0.0.132 || |+-----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-1-79-53.us-west-2.compute.internal | eni-0b2632fa77e9fbf68 | 10.1.79.53 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.1.79.53 || || 10.1.78.231 || || 10.1.75.23 || || 10.1.81.171 || || 10.1.95.26 || || 10.1.86.60 || || 10.1.76.92 || || 10.1.65.140 || || 10.1.75.174 || || 10.1.94.30 || |+-----------------------------------------------------------------------------------+| Cleaning up To avoid ongoing charges, make sure to delete EKS cluster resources created in your AWS account. # Delete EKS cluster resources eksctl delete cluster -f cluster.yaml Key considerations Shared subnets When using this feature in the cross account scenario, where VPC and Subnets are created in the central AWS Account and shared with the participant AWS Account to deploy the EKS cluster, you should tag the subnets in the participant account where the cluster is launched. Refer to Use shared VPC Subnets in Amazon EKS for a detailed walkthrough. Custom networking Custom networking, a feature of Amazon VPC CNI, provides optionality to the IP exhaustion issue by assigning the Pod IPs from secondary VPC IP address spaces. When custom networking is enabled in VPC CNI, it creates secondary ENIs in the subnet defined under a custom resource named ENIConfig that includes an alternate subnet CIDR range created from a secondary VPC CIDR. The VPC CNI assigns Pods IP addresses from the CIDR range defined in the ENIConfig custom resource. Furthermore, the pods can use different security groups than that of the node’s primary network interface. Therefore, you might consider custom networking if you have a security requirement to run Pods on a different network with different security groups. Note that, unlike custom networking, enhanced subnet discovery does not need the creation of the ENIConfig custom resource, and thus reduces the configuration overhead. Custom networking takes precedence when both features are enabled on the VPC CNI. Pod networking use cases You can use this feature along with other VPC CNI use cases, such as “SNAT for Pods”, “Security groups for Pods”, “Kubernetes network policies”, and “Increase available IP addresses on a worker node”. Refer to Choose Pod networking use cases for a detailed comparison. Conclusion In this post we showed you how Amazon VPC CNI based subnet discovery can provide scale and flexibility to adjust your IPv4 address allocations to accommodate the growth of your EKS clusters with low operational overhead. We demonstrated how the feature enables adaptability to changes in size, and simplifies IP address management while supporting the dynamic needs of modern IT environments. Visit the Amazon EKS best practices guide for recommendations and additional considerations for securely scaling EKS clusters. For installation instructions for Amazon VPC CNI, refer to the Amazon EKS user guide. You may provide feedback on the Amazon VPC CNI plugin by leaving a comment or opening an issue on the AWS Containers Roadmap that is hosted on GitHub. View the full article

Starting today, Amazon Virtual Private Cloud (Amazon VPC) Traffic Mirroring is available in seven new regions, including AWS Asia Pacific (Jakarta), AWS Asia Pacific (Melbourne), AWS Middle East (UAE), AWS Canada West (Calgary), AWS Europe (Spain), AWS Israel (Tel Aviv), and AWS Europe (Zurich). View the full article

It’s less than a month to AWS re:Invent, but interesting news doesn’t slow down in the meantime. This week is my turn to help keep you up to date! Last week’s launches Here are some of the launches that caught my attention last week: AWS re:Post – With re:Post, you have access to a community of experts that helps you become even more successful on AWS. With Selections, community members can organize knowledge in an aggregated view to create learning paths or curated content sets. Amazon SNS – First-in-First-out (FIFO) topics now support the option to store and replay messages without needing to provision a separate archival resource. This improves the durability of your event-driven applications and can help you recover from downstream failure scenarios. Find out more in this AWS Comput Blog post – Archiving and replaying messages with Amazon SNS FIFO. Also, you can now use custom data identifiers to protect not only common sensitive data (such as names, addresses, and credit card numbers) but also domain-specific sensitive data, such as your company’s employee IDs. You can find additional info on this feature in this AWS Security blog post – Mask and redact sensitive data published to Amazon SNS using managed and custom data identifiers. Amazon SQS – With the increased throughput quota for FIFO high throughput mode, you can process up to 18,000 transactions per second, per API action. Note the throughput quota depends on the AWS Region. Amazon OpenSearch Service – OpenSearch Serverless now supports automated time-based data deletion with new index lifecycle policies. To determine the best strategy to deliver accurate and low latency vector search queries, OpenSearch can now intelligently evaluate optimal filtering strategies, like pre-filtering with approximate nearest neighbor (ANN) or filtering with exact k-nearest neighbor (k-NN). Also, OpenSearch Service now supports Internet Protocol Version 6 (IPv6). Amazon EC2 – With multi-VPC ENI attachments, you can launch an instance with a primary elastic network interface (ENI) in one virtual private cloud (VPC) and attach a secondary ENI from another VPC. This helps maintain network-level segregation, but still allows specific workloads (like centralized appliances and databases) to communicate between them. AWS CodePipeline – With parameterized pipelines, you can dynamically pass input parameters to a pipeline execution. You can now start a pipeline execution when a specific git tag is applied to a commit in the source repository. Amazon MemoryDB – Now supports Graviton3-based R7g nodes that deliver up to 28 percent increased throughput compared to R6g. These nodes also deliver higher networking bandwidth. Other AWS news Here are a few posts from some of the other AWS and cloud blogs that I follow: Networking & Content Delivery Blog – Some of the technical management and hardware decisions we make when building AWS network infrastructure: A Continuous Improvement Model for Interconnects within AWS Data Centers DevOps Blog – To help enterprise customers understand how many of developers use CodeWhisperer, how often they use it, and how often they accept suggestions: Introducing Amazon CodeWhisperer Dashboard and CloudWatch Metrics Front-End Web & Mobile Blog – How to restrict access to your GraphQL APIs to consumers within a private network: Architecture Patterns for AWS AppSync Private APIs Architecture Blog – Another post in this super interesting series: Let’s Architect! Designing systems for stream data processing From Community.AWS: Load Testing WordPress Amazon Lightsail Instances and Future-proof Your .NET Apps With Foundation Model Choice and Amazon Bedrock. Don’t miss the latest AWS open source newsletter by my colleague Ricardo. Upcoming AWS events Check your calendars and sign up for these AWS events AWS Community Days – Join a community-led conference run by AWS user group leaders in your region: Jaipur (November 4), Vadodara (November 4), Brasil (November 4), Central Asia (Kazakhstan, Uzbekistan, Kyrgyzstan, and Mongolia on November 17-18), and Guatemala (November 18). AWS re:Invent (November 27 – December 1) – Join us to hear the latest from AWS, learn from experts, and connect with the global cloud community. Browse the session catalog and attendee guides and check out the highlights for generative AI. Here you can browse all upcoming AWS-led in-person and virtual events and developer-focused events. And that’s all from me for this week. On to the next one! — Danilo This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS! View the full article

AWS Lambda now allows Lambda functions to access resources in dual-stack VPC (outbound connections) over IPv6, at no additional cost. With this launch, and Lambda’s support for public IPv6 endpoints (inbound connections) in 2021, Lambda enables you to scale your application without being constrained by the limited number of IPv4 addresses in your VPC, and to reduce costs by minimizing the need for translation mechanisms. View the full article

You can now launch Amazon CloudWatch Internet Monitor directly from the Amazon Virtual Private Cloud (VPC) console. Internet Monitor provides visibility into how internet issues impact the performance and availability for your application hosted on AWS. To use Internet Monitor, you create a monitor and associate it with one or more resources: VPCs, Network Load Balancers, Amazon CloudFront distributions, or Amazon WorkSpaces directories. View the full article

In this post, we’ll illustrate an enterprise IT scenario in which VPCs are overseen by a central network team, including configuration of VPC resources such as IP allocation, route policies, internet gateways, NAT gateways, security groups, peering, and on-premises connectivity. The network account, which serves as the owner of the centralized VPC, shares subnets with a participant application account managed by a platform team, both of which are part of the same organization. In this use case, the platform team owns the management of Amazon EKS cluster. We’ll also cover the key considerations of using shared subnets in Amazon EKS... View the full article

In this post, we’ll explore how to publish and consume services running on Amazon Elastic Container Service (Amazon ECS) and AWS Lambda, as Amazon VPC Lattice services. For an introduction to Amazon VPC Lattice, please read the documentation here. One main reason customer experience a lower velocity of innovation, is the complexity they deal with while trying to ensure that their applications can communicate in a simple and secure way. Amazon VPC Lattice is a powerful application networking service that removes this complexity, and gives developers a simpler user experience to share their application and connect with dependencies without having to setup any of the underlying network connectivity across Amazon Virtual Private Clouds (Amazon VPCs), AWS accounts, and even overlapping IP addressing. It handles both application layer load balancing and network connectivity, so that developers can focus on their applications, instead of infrastructure... View the full article

Today, we’re excited to announce the native support for enforcing Kubernetes network policies with Amazon VPC Container Networking Interface (CNI) Plugin. You can now use Amazon VPC CNI to implement both pod networking and network policies to secure the traffic in your Kubernetes clusters. Native support for network policies has been one of the most requested features on our containers roadmap... View the full article

AWS Network Firewall now supports Amazon Virtual Private Cloud (VPC) prefix lists to simplify management of your firewall rules and policies across your VPCs. Prefix lists enable you to group one or more CIDR blocks into a single object. You can group IP addresses that you frequently use in a prefix list, and reference this list in AWS Network Firewall rule groups. Previously you needed to update individual firewall rules when scaling your network to add new IP addresses, which can be time-consuming and error-prone. Now you can update the relevant prefix list and all AWS Network Firewall rule groups that reference the prefix list are automatically updated. As you scale your network, you can use prefix lists to simplify management of your firewall rule groups and policies across multiple VPCs and accounts in the same AWS Region. You can use AWS-managed prefix lists or you can create and manage your own prefix lists. View the full article

Starting today, Amazon VPC Flow Logs adds support for Transit Gateway. With this feature, Transit Gateway can export detailed telemetry information such as source/destination IP addresses, ports, protocol, traffic counters, timestamps and various metadata for all of its network flows. This feature provides you with an AWS native tool to centrally export and inspect flow-level telemetry for all network traffic that is traversing between Amazon VPCs and your on-premises networks via your Transit Gateway. View the full article

AWS Firewall Manager now supports centrally distributing VPC security group tags when creating a common security group policy. View the full article

Amazon SageMaker Ground Truth helps you build high-quality training datasets for your machine learning (ML) models. With SageMaker Ground Truth, you can use workers from Amazon Mechanical Turk, a vendor company that you choose, or your own private workforce to create labeled datasets for training ML models. View the full article

Amazon SageMaker Canvas now supports VPC endpoints enabling secure, private connectivity to other AWS services. SageMaker Canvas is a visual point-and-click service that enables business analysts to generate accurate ML models for insights and predictions on their own — without requiring any machine learning experience or having to write a single line of code. View the full article

Amazon Web Services (AWS) announces the launch of multiple IPv6 classless inter-domain routing (CIDR) blocks in a Virtual Private Cloud (VPC), enabling customer to attach up to 5 prefixes to their VPCs. Before today, customers could add up to 5 IPv4 CIDR blocks and 1 IPv6 block. With this new feature, customers can now use multiple blocks to build logical separation within their VPCs with independent CIDR blocks. CIDR blocks can be associated from the Amazon provided pool and/or a pool of bring-your-own IPv6 addresses. View the full article

Amazon Virtual Private Cloud (Amazon VPC) Traffic Mirroring now supports sending mirrored traffic to monitoring appliances behind a Gateway Load Balancer. This feature enables Amazon VPC Traffic Mirroring customers to centralize the out-of-band monitoring and inspection of network traffic across AWS accounts and VPCs. View the full article

We’re excited to announce the launch of the AWS Centralized WAF and VPC Security Group Management solution, a reference implementation that makes it easier to centrally configure, manage, and audit firewall rules across your accounts and applications in AWS Organizations. The solution uses AWS Firewall Manager to automatically deploy a set of Managed Rules for AWS Web Application Firewall (WAF) and audit checks for VPC security groups across all your AWS accounts from a single place. The solution also gives Shield Advanced customers the option to deploy DDoS protections across accounts. View the full article

Amazon SageMaker Studio is the first fully integrated development environment (IDE) for machine learning (ML). With a single click, data scientists and developers can quickly spin up SageMaker Studio Notebooks for exploring datasets and building models. Starting today, you can choose to launch SageMaker Studio in your Amazon Virtual Private Cloud (VPC) for fine-grained control on network access and internet connectivity of SageMaker Studio Notebooks. You can choose to completely disable public internet access for notebooks to add an additional layer of security. View the full article

AWS Systems Manager now supports Amazon Virtual Private Cloud (Amazon VPC) endpoint policies, which allow you to configure access to the Systems Manager API. When you create Amazon VPC endpoints for Systems Manager, you can attach AWS Identity and Access Management (IAM) resource policies that restrict user access to Systems Manager API operations, when these operations are accessed via the Amazon VPC endpoint. For example, you can limit certain users to only be able to list Systems Manager Run Command invocations but not to send any command invocations. You can also restrict specific users’ ability to start a Systems Manager Session Manager session. View the full article

AWS Network Firewall is a new AWS-managed service that makes it easy to deploy essential network protections for all of your Amazon Virtual Private Clouds (VPCs). The service can be set up with just a few clicks and scales automatically with your network traffic, so you don't have to worry about deploying and managing any infrastructure. AWS Network Firewall is for customers who want to inspect and filter traffic to, from, or between their Amazon VPCs. View the full article

Amazon VPC Container Networking Interface (CNI) Plugin version 1.7 is now the default for newly created Amazon EKS clusters. View the full article

Starting today, you can privately connect your Amazon Virtual Private Cloud (VPC) to AWS Database Migration Service (DMS) without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. View the full article

AWS Transfer Family now supports creating Amazon Virtual Private Cloud (Amazon VPC) hosted server endpoints in centrally managed and shared Amazon VPC environments, helping you meet your compliance requirements as you segment your AWS environment using tools such as AWS Landing Zone for security, cost monitoring, and scalability. View the full article