Container Runtime
AWS Fargate
AWS Fargate is a serverless compute engine that runs containerized workloads on ECS and EKS without provisioning or managing the underlying EC2 instances or cluster node groups. You define task/pod CPU, memory, and networking, and AWS schedules isolated containers with per-second billing. It targets teams wanting Kubernetes/EC2 API compatibility while offloading host OS patching, scaling, and capacity management.
AWS
Service information
Shortname: Fargate
Huawei equivalent shortnames: CCI, CCI 2.0, Flexus CCI
Keywords: container, runtime, serverless, ecs
Differences vs Huawei
AWS Fargate integrates natively with ECS (task definitions) and EKS (pods), preserving the standard Kubernetes and AWS container APIs; you declare vCPU/memory in task/pod specs and AWS provisions isolated compute. Huawei CCI exposes a Kubernetes-native serverless pod model and is the closest direct analog, but CCI is positioned as an on-demand extension to CCE rather than a full EKS-style managed control plane substitute. Validate API surface, namespace semantics, and networking defaults (VPC-native pods, security groups) case by case, because Fargate and CCI differ in ingress, ENI-per-pod, and IAM-equivalent access control models.
Huawei maps the serverless-container space across three distinct offerings that are not interchangeable. CCI is the original serverless pod service with per-second billing and VM-level isolation; CCI 2.0 is the next-generation runtime for newer regions and pod specs; Flexus CCI targets small/micro workloads with economical fixed-spec profiles. AWS Fargate presents a single Fargate profile for both ECS and EKS. Selecting the wrong Huawei variant leads to feature limits, region gaps, or billing surprises, so match workload profile, region, GPU support, and required Kubernetes version before committing.
Operational responsibility differs at the isolation and scaling seams. Fargate pods run in Firecrackle/VM micro-isolation with AWS-managed scaling through ECS/EKS schedulers; Huawei CCI pods use VM isolation and scale pod counts in seconds, and the documented best practice uses CCE for steady-state workloads and bursts CCI pods for traffic spikes. Storage, EIP/ELB, SWR image pull, and observability still come from adjacent Huawei services, whereas Fargate bundles more of this with ECS/EKS. Expect to rebuild IAM roles, CloudWatch observability, and ALB integration mapping rather than assume parity.
Migration to Huawei
Start with an assessment that classifies every Fargate task/pod by compute spec, networking (public/private subnet, ALB/NLB), storage mounts, IAM task role, secrets, and ECR image source. Choose the Huawei target by workload shape: CCI 2.0 for standard serverless Kubernetes pods in supported regions, CCI for burst elasticity off CCE, and Flexus CCI only for low-spec micro workloads. Do not assume one-to-one parity; verify region availability, Kubernetes version compatibility, GPU/NPU support, and per-pod resource limits against Huawei quotas before designing the target topology.
For application and image migration, rebuild container images for the Huawei SWR and re-evaluate base images for kernel and library compatibility, since Fargate host OS assumptions will not carry over. Translate task definitions and pod specs into Huawei CCI/CCE manifests, converting AWS IAM task roles, Secrets Manager, and Parameter Store integrations to Huawei equivalents, and remap ALB listeners to ELB. Replace Fargate-native networking and security group semantics with VPC, subnet, and CCI namespace configuration, and redesign autoscaling rules using the CCE-to-CCI elastic scaling pattern rather than Fargate capacity providers.
Validate data-plane behavior and cutover with parallel runs: stage workloads on CCE for stable traffic and extend to CCI for burst, mirroring the documented elastic scaling pattern. Reproduce load and scaling events to confirm pod startup latency, autoscaler thresholds, and ELB/EIP behavior before shifting production traffic. Picture-perfect feature parity is unlikely, so document residual gaps around exec/gp0 exec, ephemeral storage limits, GPU exposure, and observability hooks, and run blue/green or canary cutover with rollback to the AWS environment.
Recalculate total cost of ownership rather than assuming savings. AWS bills Fargate per-second for vCPU/memory plus attached EBS-style ephemeral storage and data transfer; Huawei bills CCI per-second for pod specs plus EVS, bandwidth/traffic, and optional SWR/ELB usage, with Flexus CCI offering simplified fixed-spec pricing. Model peak load, request volume, image-pull frequency, inter-AZ and cross-region traffic, and retention period, and factor the management effort of gluing CCE, CCI, SWR, and ELB that Fargate partly bundles. Confirm quotas for pods per namespace and concurrent pod scaling before production.
Huawei Cloud
Huawei equivalent service
Shortname: CCI
General function: Container Runtime
Serverless container runtime for on-demand workloads.
Keywords: container, serverless container, runtime
Huawei equivalent service
Shortname: CCI 2.0
General function: Container Runtime
Next-generation serverless container runtime.
Keywords: container, serverless, runtime
Huawei equivalent service
Shortname: Flexus CCI
General function: Container Runtime
Flexus container compute instance offering.
Keywords: container, runtime, flexus