Managed AWS EC2: Linux administration and cloud operations
We take over the agreed operation of suitable EC2 Linux instances and clearly scope IAM, VPC, RDS, EKS, Organizations, backup, and FinOps. Accounts and resources remain with you.
AWS operates the cloud infrastructure. Depending on the selected service, guest operating systems, applications, identities, network rules, data, and recovery remain wholly or partly with the customer.
EC2 Operations as a Clear Entry Point
For suitable Linux instances, we take over guest operations, patching, hardening, monitoring, and backup management within a documented scope.
Cloud Services Scoped Separately
IAM, VPC, RDS, EKS, Organizations, and other AWS services have their own responsibilities and are agreed to match the architecture.
Cost Review Based on Actual Usage
We assess utilization, storage, data transfer, and commitments. Changes are recommended only after technical and commercial evaluation.
Responsibility documented per service
The AWS shared responsibility model explicitly distinguishes between “security of the cloud” and “security in the cloud.” During the audit, we document what AWS, your team, and WZ-IT handle for each service.
AWS service areas
Which AWS services we include in operational takeover and governance
AWS is not a single server provider. We can start with EC2, but IAM, networking, databases, containers, observability, and cost are explicitly scoped as separate operating areas.
EC2 & systems management
Take over Amazon EC2 and Linux guest operations in a controlled way
Amazon EC2, AMIs, and Amazon EBS by workload, data, and lifecycle requirements
Elastic Load Balancing and EC2 Auto Scaling according to the actual availability design
AWS Systems Manager Session Manager, Patch Manager, and Run Command where suitable
Linux hardening, OS updates, Docker, and agreed application services
Terraform or AWS CloudFormation for repeatable changes
Scope boundary and notes
We operate suitable Linux instances together with the AWS services needed for access, scaling, storage, and maintenance.
Responsibility boundary: AWS operates the cloud infrastructure. Under the Shared Responsibility Model, guest operating systems, configuration, data, identities, and applications remain customer responsibilities unless WZ-IT takes them over.
Outcome: Documented EC2 operations with controlled access, changes, and maintenance windows.
Accounts & identity
Structure IAM, Organizations, and multi-account governance
AWS Organizations, Organizational Units, and Service Control Policies by governance scope
AWS IAM Identity Center, IAM roles, permission sets, and MFA
Root-user protection, break-glass procedure, and separate technical roles
AWS Control Tower or an existing Landing Zone after architecture review
AWS CloudTrail, AWS Config, and centralized logging for relevant changes
Scope boundary and notes
We separate root processes, human identities, workload roles, and delegated WZ-IT access and align them with the account structure.
Responsibility boundary: WZ-IT receives only the agreed roles. Account ownership, billing, and organizational control remain with the customer; permissions remain traceable and revocable.
Outcome: An AWS account structure with clear roles and auditable administration paths.
VPC & edge
Design VPC, hybrid connectivity, and published services
Amazon VPC, subnets, Route Tables, Security Groups, and Network ACLs
NAT Gateway, VPC Endpoints, AWS PrivateLink, and VPC Peering where needed
AWS Transit Gateway, Site-to-Site VPN, or AWS Direct Connect for hybrid networks
Amazon Route 53, Elastic Load Balancing, and AWS Certificate Manager
AWS WAF, AWS Shield, and Amazon CloudFront by protection and delivery scope
Scope boundary and notes
We document public and private paths from Route 53 and load balancers through subnets and Security Groups to connected sites.
Responsibility boundary: Ordering individual network or security services does not create a complete security or HA architecture. Rules, routing, applications, and failover require joint design.
Outcome: A traceable AWS network architecture with defined traffic and access paths.
Databases & storage
Operate RDS, Aurora, S3, and other data services around the application
Amazon RDS and Amazon Aurora with parameters, maintenance windows, backups, and replication
Amazon S3 with versioning, lifecycle, encryption, and access controls
Amazon EFS and Amazon FSx for suitable file and shared-storage workloads
Amazon ElastiCache or Amazon OpenSearch Service after separate assessment
Data migration, performance analysis, and application-aware restore tests
Scope boundary and notes
Managed data services reduce infrastructure work, not responsibility for data models, access, capacity, cost, and recovery.
Responsibility boundary: AWS operates defined platform components for managed services. Schema, queries, data quality, access, applications, and recovery objectives remain in the customer and WZ-IT scope.
Outcome: A data scope with a clear split between managed platform and application-aware operations.
Containers & Kubernetes
Integrate EKS, ECS, and Container Registry into operations
Amazon EKS with Managed Node Groups, add-ons, upgrades, and workloads
Amazon ECS on EC2 or AWS Fargate by task and cost model
Amazon ECR for images, permissions, scanning, and lifecycle rules
Ingress, secrets, IAM roles for workloads, GitOps, and CI/CD
Persistent data, cluster observability, and application recovery
Scope boundary and notes
We select the container scope to fit the architecture and operate workloads, deployment, add-ons, and observability above AWS services.
Responsibility boundary: EKS, ECS, or Fargate management does not replace responsibility for deployments, workloads, data, permissions, and applications.
Outcome: A clearly scoped container operation with traceable deployment and incident paths.
Observability, backup & FinOps
Control operations, recovery, and cost over time
Amazon CloudWatch Logs, Metrics, Alarms, and Dashboards around operating questions
AWS Backup with Backup Plans, Vaults, copies, and restore procedures
Cross-account or cross-Region copies by risk and service availability
AWS Cost Explorer, Budgets, Compute Optimizer, and commitments in the FinOps scope
24/7 monitoring, incident response, and AWS support coordination by service level
Scope boundary and notes
We connect technical telemetry, backup policies, human response, and cost review in an ongoing operations process.
Responsibility boundary: WZ-IT response times apply to our scope; AWS support and repair times remain separate. Cost recommendations are not blanket savings guarantees.
Outcome: AWS operations with measurable states, tested recovery, and traceable cost decisions.
One operating model
One operating model for AWS and additional systems
The provider is only one operating location. WZ-IT connects servers, clouds, and on-premises systems into a documented environment with consistent monitoring, controlled access, and one coordinated service level.
Contracts, accounts, and administrative control remain with you. We take over the agreed technical operations without moving the infrastructure into a closed hosting product.
Private connectivity
NetBird, WireGuard, or existing site connections integrate further clouds, Proxmox systems, and on-premises networks through controlled paths.
Operations and response
Monitoring, updates, backups, documentation, and incident response are designed across all participating systems and operated according to the selected service level.
Monitoring · SLA · Operations
AWS
Private connectivity
Cloud · Proxmox · On-premises
Building blocks
From EC2 guest operations to the AWS platform
Not every service belongs in the same flat fee. We combine the required components into a reviewable operating model.
EC2
Linux guest operations, EBS, load balancers, and Auto Scaling after architecture review
IAM & Organizations
Identity Center, roles, permission guardrails, root processes, and multi-account governance
VPC & Connectivity
Networks, routing, Security Groups, VPN, transit, and hybrid connectivity
RDS & Aurora
Parameters, maintenance windows, capacity, backup, and application-side responsibility
EKS & ECS
Cluster, node, add-on, workload, and data responsibility as a separate platform scope
CloudWatch & CloudTrail
Metrics, logs, events, retention, and escalation aligned with the operating model
AWS Backup
Policies and copies depending on resource, Region, account, and encryption
FinOps
Tags, budgets, utilization, rightsizing, and commitments without blanket savings guarantees
The audit first establishes current state, responsibilities, and the required operating scope.
01
Assessment
Map accounts, Regions, services, access paths, dependencies, and cost
02
Operating Boundaries
Document AWS, customer, and WZ-IT responsibility for each service
03
Onboarding
Configure roles, monitoring, backup, maintenance windows, and alert paths
04
Ongoing Operations
Handle agreed tasks, incidents, and changes with traceability
Service scope
Monitoring or full operations
With Monitoring Only, our team reviews alerts and notifies your team during service hours; incident resolution stays with you. Standard Linux VM operations start at €149.90. Kubernetes, managed databases, multi-account setups, and further cloud services are scoped individually. This also applies to complex suitable EC2 Linux instances environments.
Server operationsfrom €149.90Monitoring Only from €49.90
EC2, IAM, RDS, EKS, backup, FinOps, and operations
The standardized entry point is operating suitable Linux instances on EC2: patching, hardening, monitoring, backup management, and agreed incident response. IAM, VPC, RDS, EKS, Organizations, security, and platform services are scoped separately for each environment.
Customer responsibility differs considerably by AWS service. With EC2, guest operations remain with the customer, while AWS takes on more platform duties for RDS or EKS. Applications, identities, configuration, data, and recovery still require planning to different degrees.
When the operating system, SSM Agent, IAM roles, and network paths meet the prerequisites, Session Manager can provide controlled administrative access without an inbound SSH port. We still define documented standard and emergency access; SSM is not a blanket replacement for every access scenario.
Yes, if the application and data design are suitable. Auto Scaling requires suitable launch templates, health checks, capacity, and scaling policies. A stateful application does not become highly available simply by adding an Auto Scaling Group.
Yes, as a separate scope. AWS operates the underlying platform, while engine and version choices, parameters, maintenance windows, capacity, access, data, queries, recovery objectives, and application integration still require agreement.
Yes, under a separate platform scope. For EKS, the control plane, worker nodes, add-ons, workloads, identities, networking, persistent data, observability, and recovery must be considered separately. We also provide a dedicated Kubernetes offering.
The account remains with the customer. We use separate least-privilege roles and prefer temporary credentials. Root access is protected, existing root access keys are removed after assessment where appropriate, and multi-account environments can be structured with AWS Organizations and IAM Identity Center.
No. AWS WAF can filter defined web requests and is one component in front of exposed applications. Rules, exceptions, logging, tuning, application security, and other controls remain necessary; configuration does not promise blanket protection from bots or attacks.
Block Public Access is an important centralized control against accidental public exposure. We also review bucket policies, IAM, access points, encryption, logging, lifecycle, and organization-wide controls where required. Application compatibility must be assessed before activation.
We define resources, schedules, retention, encryption, RPO, RTO, and recovery tests. Cross-Region or cross-account copy is not available in the same way for every resource and may require appropriate KMS keys, Organizations configuration, and target accounts.
No. We assess metrics, dependencies, unused resources, data transfer, and commitment options. Rightsizing, Savings Plans, Reserved Instances, or Spot can help but each introduces commitments or technical constraints. Recommendations therefore contain no blanket savings guarantee.
Yes. The AWS contract, accounts, resources, and usage-based AWS charges remain with the customer. WZ-IT invoices the agreed operations and consulting scope separately.
Monitoring-only starts at €49.90 net per server and month. Operating a suitable Linux instance starts at €149.90 net per month. RDS, EKS, multi-account, networking, FinOps, and other AWS services are priced by scope.
The service can be cancelled monthly, with 30 days' notice to the end of the month.
Response time follows the selected service level. Production and Critical include 24/7 response to qualified P1 incidents. AWS support, repair, and recovery times remain separate.
Yes, as a separate project with its own scope. The Managed AWS page describes ongoing operations. We cover landing zones, target architecture, hybrid connectivity, migration, and cloud exit on the AWS expertise page.
Knowledge
Further resources
Explore operations and cost, or assess architecture and migration as a separate project.
Customer feedback on monitoring, updates, maintenance, support and stable production systems.
Networking & Provisioning
WZ-IT moved our studio infrastructure from decentralised individual devices to a central platform: every site is securely connected via VPN, new devices are onboarded automatically and an entire site is provisioned from a template, without manual steps on location. What impressed me most is the breadth and depth of their knowledge: Timo and Robin are not a typical IT provider who sets up a server and leaves. The two of them think their way into highly complex infrastructure and software topics, work through every requirement we put in front of them, and build networking, provisioning and operations so that everything fits together in the end. WZ-IT is an excellent partner for complex software, network and architecture projects.
Steve KirchnerManaging Director, nextGYM GmbHView project
International
Built in Germany's Ruhr Valley. Running worldwide.
WZ-IT designs, develops and operates infrastructure and software for clients in Germany and internationally. We deliver projects remotely and continue supporting them in ongoing operations after go-live.
