This whitepaper is for historical reference only. Some content might be outdated and some links might not be available.

Solution architecture

Due to the different approaches in cloud-native operations versus virtualized application operations, the day -1 to day 2 operations also look different in the two. In this section, we will go over typical day -1 to day 2 operations, and explore how a cloud native orchestration can be built using those requirements. The following diagram represents a grouping of relevant AWS services for implementation of a cloud-native network orchestrator. To maintain ease of reading, we have ignored some of the operational requirements such as reliability, security and recovery from the following diagram, however in a real implementation, it is important to consider those requirements as well.

Motivation and tasks of each service in the preceding figure will become clear as the operational requirements are examined in detail in the following. Some guidelines to develop automation steps that are scalable while taking advantage of AWS and EKS native constructs for maximum flexibility is also presented.

Day -1: Planning

Common tasks during this phase are:

Most of these activities are covered by proper landing zone design, discussions with ISVs and network teams to create well-structured accounts and permissions, naming conventions and network design. AWS services such as AWS Organizations and AWS Control Tower can be quite useful to develop proper account structure and management, such as new account creation. With (AWS IAM), you can specify who or what can access services and resources in AWS, centrally manage fine-grained permissions, and analyze access and refine permissions across AWS. AWS Key Management Service (AWS KMS) helps create, manage, and control cryptographic keys across applications and more than 100 AWS services, and helps with secure access and management.

Amazon Virtual Private Cloud (Amazon VPC) gives you full control over virtual networking environment, including resource placement, connectivity, and security. One of more VPCs might be required depending on VPC design and scale. AWS Direct Connect links the CSP internal network to a Direct Connect location over a standard ethernet fiber-optic cable. AWS Transit Gateway connects Amazon VPCs and on-premises networks through a central routing hub. This simplifies the network and puts an end to complex peering relationships as each new connection is only made once. Amazon Route 53 is a highly-available and scalable domain name system (DNS) web service. Route 53 connects user requests to internet applications running on AWS or on-premises.

Amazon Elastic Container Registry (Amazon ECR) is an AWS-managed, Open Container Initiative (OCI)-compliant container image registry service that is secure, scalable, and reliable. Amazon ECR supports private repositories with resource-based permissions using AWS IAM. This ensures that only specified users or Amazon EC2 instances can access container repositories and images, thereby allowing separation across vendors. Customers can use the familiar Docker CLI, or their preferred client, to push, pull, and manage Docker images, OCI images, and OCI-compatible artifacts.

Significant engineering effort and consideration should be given at this stage, as this lays the foundation of future automation and operations. Although proper planning needs human decisions, implementation of these design choices can often be automated.

Day 0: Topology development

Some of the tasks in this phase of deployment are as follows:

Some of the well-developed robotic automation tools or customized process automation tools can be developed to activate AWS Outposts. Services such as Service Catalog can be useful in creating the catalog and customizing it for the particular CSP and ISVs. Care should be taken to properly abstract configuration parameters to avoid bloating the catalog size.

AWS CloudFormation or the AWS Cloud Development Kit (AWS CDK) constructs are flexible and functionally rich tools to deploy infrastructure and many of the platform components such as EKS clusters, CNIs, CSIs, and so on. The invocation of AWS CloudFormation/AWS CDK templates can be further customized using AWS CodePipeline with tools such as AWS CodeCommit and AWS CodeDeploy. Some of the functions can also be automated using a purpose-built automation workflow using AWS Lambda and AWS Step Functions.

Increased agility and resilience can be achieved using Amazon EKS, an AWS managed Kubernetes service that makes it easy to run Kubernetes on AWS. The Kubernetes control plane managed by EKS runs inside an EKS-managed VPC, running components such as the Kubernetes API server nodes and etcd cluster. Kubernetes API server nodes run the API server, scheduler, kube-controller-manager, and so on. in an EC2 Auto Scaling group, allowing it to scale based on demand. API server nodes run in a minimum configuration of two in distinct Availability Zones (AZs), while the etcd server nodes run in an auto-scaling group that spans three Availability Zones. This architecture ensures that an event in a single Availability Zone doesn’t affect the EKS cluster's availability. The control plane backup (such as etcd backup) is periodically performed by AWS. Having a unified, managed Kubernetes control plane helps with operational agility and automation.

For on-premises infrastructure not managed by AWS, Amazon EKS Anywhere is a new deployment option that allows customers to create and operate Kubernetes clusters. Amazon EKS Anywhere helps simplify the creation and operation of on-premises Kubernetes clusters with default component configurations while providing tools for automating cluster management. While not as feature-rich as EKS, it gives customers option to view all of their Kubernetes clusters in one dashboard.

Day 1: Instantiation

This phase of deployment deals with the following tasks:

Most of these functions can be automated if properly designed. CloudFormation and AWS CDKs are good constructs for this part. An automation pipeline can be build using AWS-provided continuous integration/continuous development (CI/CD) tools such as AWS CodeCommit and AWS CodeDeploy, or custom workflows can be created using AWS Lambda and AWS Step Functions that invoke appropriate AWS CloudFormation and CDK templates. Again, care should be taken to develop pipelines with appropriate parameterization so as to not bloat the number of pipelines or custom workflows. Some beneficial approaches in this part of the deployment are constructs such as Amazon EKS blueprints.

You must also create proper databases to handle the vast and different types of data that is generated by network functions, and to ensure proper mapping between services, functions and their instantiation. Graph database such as Amazon Neptune can be useful in this regard. Amazon Neptune is a fast, reliable, fully managed graph database service that makes it easy to build and run applications. Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale. DynamoDB offers built-in security, continuous backups, automated multi-Region replication, in-memory caching, and data import and export tools. Amazon Relational Database Service (Amazon RDS) is a managed relational database service for MySQL, PostgreSQL, MariaDB, Oracle BYOL, or SQL Server. Some AWS partner solutions, such as Portworx PX-Enterprise, can be useful in architecting CNFs for high availability.

Day 2: Operation and management

This is arguably the hardest part of the automation lifecycle, and deals with day-to-day operation of the network. This phase deals with the following tasks:

New infrastructure, network and functions can also be deployed in this part to address increased network demand. Hence, it is important not to view this phase in isolation of earlier phases but think of it this phase as invoking all the earlier phases as and when needed.

This phase is also the one that is most difficult to handle with traditional CI/CD. However, the new GitOps-based approaches can be particularly beneficial in this context. GitOps enables configuration as code and, if properly implemented, can take care of drift management from the desired configuration. This model is often utilized as an efficient strategy for provisioning cloud provider-specific managed resources, such as Amazon Simple Storage Service (Amazon S3) bucket and Amazon RDS instance, on which application workloads depends. Furthermore, AWS constructs such as AWS Auto Scaling can provide a cost-effective way to manage utilization and allow for traffic adaptation. Combining this approach with an application configuration provides a useful method to manage the operational configuration.

Monitoring, observability, and logging alarm for the Day 2 operations can be achieved using services such as Amazon CloudWatch, AWS CloudTrail, and AWS-provided managed services such as Amazon Managed Service for Prometheus and AWS Distro for OpenTelemetry. AWS CloudWatch collects monitoring and operational data in the form of logs, metrics, and events so that the operation teams can get a unified view of operational health and gain complete visibility of AWS resources, applications, and services running on AWS and on-premises. You can use CloudWatch to detect anomalous behavior in CSP environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep network running smoothly.

Because network functions continuously emit performance data and Key Performance Indicators (KPIs), you'll need a way to process this streaming data. Amazon Kinesis makes it easy to collect, process, and analyze near real-time, streaming data to get timely insights and react quickly to new information. Amazon SageMaker AI helps prepare, build, train, and deploy high-quality machine learning (ML) models quickly by bringing together a broad set of capabilities purpose-built for ML. This makes it easy to get insights on the deployment and operations.

With the previous described AWS constructs, one possible implementation on AWS is be as follows:

This diagram represents VPC constructs, EKS clusters, load-balancers and repositories, network connections, and so on in the context of Region, Availability Zones, and on-premises data centers. For ease of representation, we haven’t depicted some of the functionalities such as account and user administration, the creation of a landing zone, security, and DNS that were part of the earlier architecture, because many of those features will run in their own VPCs within control of cross-account permissions.