Object Storage
Bring your S3 data home to Türkiye without rewriting a line of code
Your existing S3 tools and SDKs connect to an S3 server that runs separately for your organisation, with only the endpoint and key changed. Your files, backups and archives stay in Türkiye, and you generate the keys yourself.
Why now
- Your application files sit with a cloud provider abroad, and legal has asked for the data to be kept in Türkiye. Because the application already speaks S3, the move happens without rewriting code; what changes is the endpoint and the access key.
- On your foreign storage bill, the egress line is impossible to predict from one month to the next. With object storage, stored data and outbound traffic are separate lines, and the invoice is issued in Türkiye as an e-Invoice.
- Your database backups and continuous archive (WAL) files pile up on the same server's disk. Lose the server and the backup goes with the database; writing the archive to an S3 target off the server is the first step to closing that risk.
- You want to back up your Kubernetes clusters, but your backup tool needs an S3-compatible target. Backups written by Velero, Kopia or Restic go straight into object storage.
- The logs, reports and exports your application produces keep filling server disks, and the disk gets enlarged every month. Move those files into buckets, and the server disk is left to the application itself.
What changes
| Today | With Nesnet |
|---|---|
| Application data sits in a provider's store abroad. | Data sits on an S3 server running separately for your organisation, in Türkiye, and the application only changes its endpoint. |
| The storage bill moves with unpredictable egress. | Stored data and outbound traffic appear on separate invoice lines. |
| The database backup sits on the same disk as the database. | Archives and backups are written to an S3 target off the server. |
| Access keys are generated by the provider and emailed over. | You generate keys in the portal and decide which application uses which one. |
| After a migration nobody knows whether files are missing or corrupted. | The move is checked object by object against checksums, and cutover waits until the difference list is empty. |
From today to live: how it works
- 1
Tell us what's moving
Which applications store how much data, where it lives today and which tools write it: you talk it through with Nesnet's team. You leave with a migration route and a clear view of what drives the price.
- 2
Object storage switched on
Nesnet enables object storage for your organisation in the portal and grants the permissions a new organisation needs. Your own S3 server then comes up automatically in the back end.
- 3
Generate a key, create a bucket
Generate your access key in the cloud portal yourself and create your first bucket. Point your existing S3 tool at the new endpoint and confirm the connection by uploading, listing and reading an object.
- 4
Move and verify the data
Data from the current store is mirrored into the new buckets and checked object by object against checksums. If your application signs or uses headers differently, your developer gets an adaptation guide.
- 5
Switch the application over
Once verification is complete, your application starts using the new endpoint and key. The old store stays in place as your way back until you decide to close it.
What you get
Your application works as it is
Authentication uses AWS Signature V4, and the AWS CLI and SDKs work with only the endpoint changed. Creating buckets and uploading, listing and reading objects work end to end, so there's no S3 code to rewrite.
With the S3 tools you know
The AWS CLI, S3 SDKs, sync tools such as rclone and backup software that understands S3 targets all work the same way here. Your team learns no new tool; the only thing that changes in their commands is the endpoint.
Two addressing styles
Both path-style (endpoint/bucket) and virtual-hosted-style (bucket.endpoint) addressing work. For HTTPS on virtual-host style, the bucket name must be a single lower-case DNS label without dots; dotted names use path-style.
You generate the keys
Access keys are generated by you, under the security credentials of the object storage section in the cloud portal. You decide which application gets which key, and rotate one you suspect has leaked without waiting for anyone.
A separate S3 server for you
Every organisation has its own S3 server instance, its own endpoint and its own IAM set. Users and keys from other organisations don't exist on your instance, so a permission slip can't expose another customer's data.
In the same portal as your servers
Buckets are listed and managed in the object storage section of the same cloud portal where you run your virtual servers. No separate account or management screen; servers and buckets show up in one session.
Encrypted in transit
Traffic between your application and the endpoint is encrypted with TLS using an RSA-2048 certificate from a public certificate authority. Internal traffic between the portal and your organisation's instance is encrypted too, with a certificate issued per organisation.
Certificates never cause an outage
Endpoint and organisation certificates renew automatically before they expire. A forgotten renewal won't leave your applications failing to connect one morning, or your backups quietly stopping.
Permissions through bucket policies
Access is granted through bucket policies rather than object ACLs, defining which application may read which bucket and write to which. An application that sends the x-amz-acl header gets no error, but the header has no effect; that's one of the things checked during a migration.
From a store abroad to Türkiye
An object store at a foreign cloud provider is mirrored onto the S3 server allocated to your organisation, and the transfer is checked object by object against checksums. The application doesn't switch until the difference list is empty, and the old store stays as the way back.
A written adaptation guide for your developers
If the application uses a provider-specific signing scheme or headers, Nesnet spots the differences and writes your developers a line-by-line adaptation guide. They know what changes and why before the migration starts.
Database archives off the server
A database's continuous archive (WAL) and full backups are written to object storage as an S3 target. The archive lives apart from the database server's disk, so even if the server is lost, the way back through the archive stays open.
A ready target for Kubernetes backups
Kubernetes backups taken with Velero, Kopia or Restic use object storage as their S3 target. This route is documented in Nesnet's backup architecture as an alternative alongside the main backup path.
Log and report archives
Logs, reports and exports produced by the application are written to buckets instead of server disks. The server disk stays with the application itself, and a growing archive no longer means planning downtime to enlarge a disk.
Object versioning
In a bucket with versioning on, the previous version of an object is kept when it's overwritten under the same name or deleted. An accidentally overwritten file comes back from its earlier version.
Expire old data by rule
Lifecycle rules delete objects under a given prefix or past a given age automatically. Temporary exports and old logs stop taking up space without waiting for a manual clean-up, and the invoice drops with them.
Turkish organisation names just work
Organisation names are normalised to RFC 1123 rules on their way into the infrastructure. Switching on object storage for an organisation whose name contains ş, ğ or ı needs no extra naming work.
Deleting a disk claim doesn't delete data
Organisation instances' data disks are defined with a Retain policy. Even if a disk claim is deleted by mistake in the infrastructure layer, the data disk is not removed and stays in place.
Why Nesnet
An S3 server of your own
Nesnet's object storage isn't one big store that every customer shares. A separate S3 server instance runs for each organisation in the portal, with its own endpoint, its own TLS certificate and its own set of users and permissions (IAM). Another organisation's keys simply don't exist on your instance.
Your data stays in Türkiye
Object storage is delivered from Nesnet's infrastructure in Türkiye; Nesnet's hardware, network and team are in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. Your files are never moved to a region abroad.
Migrations verified object by object
Nesnet moved an object store from a hyperscale cloud provider onto its own S3 infrastructure and verified the transfer object by object with checksum comparison; the result was zero differences. Signing and header mismatches in the application were written up as a line-by-line adaptation guide for the developers.
Nesnet wrote the missing pieces
Nesnet wrote the bucket listing and management endpoints the off-the-shelf portal plug-in lacked. The sync error that surfaced when a second organisation was added was closed at the root, not patched over.
No manual certificate work
Each organisation's TLS certificate is issued automatically by a controller Nesnet wrote, and renewed before it expires. Adding a new organisation or renewing a certificate never needs anyone's hands.
Nesnet uses it for its own data
Nesnet continuously archives its own platform databases to an S3 target built on the same technology as this service. The infrastructure you get is the one Nesnet relies on to keep its own data outside the cluster.
Example scenarios
An application coming home from a cloud abroad
Situation
A company's customer documents sit in an object store at a cloud provider abroad. The data now has to be kept in Türkiye, and there's no time to rewrite the application.
Outcome
The data is mirrored onto the S3 server allocated to the company and verified object by object. In the application only the endpoint and access key change, and the developers get a line-by-line adaptation guide for signing differences.
A database's continuous archive
Situation
A team runs its database on a virtual server and keeps the WAL archive on the same server's disk. They know that losing the server would take the archive with the database.
Outcome
The WAL archive and full backups are written to object storage as an S3 target, so the archive lives outside the database server. Nesnet archives its own platform databases the same way.
An S3 target for Kubernetes backups
Situation
A platform team wants to back up its Kubernetes clusters with Velero and needs an S3-compatible target for it to write to.
Outcome
Velero uses object storage as its backup target, with each namespace kept under its own prefix. Backups live outside the cluster, in a store managed from the same portal.
A report archive filling the disks
Situation
A finance application produces thousands of PDF reports every night, and they pile up on the application server's disk, which gets enlarged every month.
Outcome
Reports are written to a bucket each night, leaving the server disk to the application. Old reports are deleted by a lifecycle rule after the period you set.
Who does what
| Nesnet | You |
|---|---|
| Enables object storage for your organisation; your S3 server and endpoint come up automatically. | Generate access keys, decide which application uses which key, and rotate them when needed. |
| Runs the portal plug-in, the object server infrastructure and the organisation instances, keeping the components compatible. | Set bucket names and bucket policies. |
| Renews endpoint and organisation certificates before they expire. | Decide how long data is kept and which objects are removed by rule. |
| Meters authenticated traffic and usage and bills it line by line. | Decide whether a second copy is kept somewhere else. |
| Verifies the transfer in migration projects and prepares the adaptation guide for your developers. | Update your application's endpoint and key settings and run the post-migration tests. |
Who it is for
Software teams that use S3
Teams that store user uploads, images, reports or exports through the S3 API and want that data kept in Türkiye. The application code stays the same; only the endpoint and access key change.
Companies bringing data back from abroad
Companies whose application files or archive sit with a cloud provider abroad and now have to keep data in Türkiye. The move is verified object by object, and differences in signing or headers are written up for your developers.
IT teams that want backups off the server
Teams that want to write database archives, Kubernetes backups or log files to a target outside the production servers. Most backup software recognises an S3 target out of the box.
Organisations already on Nesnet's cloud
Organisations using Nesnet's Private Cloud or virtual servers that want to manage object storage from the same cloud portal, in the same session.
May not be the right fit
If your data has to be copied to regions in different geographies at the same time, this service doesn't meet that need; it runs from a single site and there is no cross-region replication.
Workloads that need block access, such as database data files or virtual machine disks, belong on the virtual server's own disks.
If you want to serve a website's images straight from a public bucket, talk that use through with Nesnet's team first; the service today is positioned for authenticated access.
Under the hood
Object Storage is integrated into the cloud portal through a portal extension, with an open-source, S3-compatible object server as the back end. When object storage is enabled for your organization, the extension writes a tenant definition to the object server's Kubernetes operator, which turns it into a load-balanced, TLS-enabled S3 endpoint on its own. The operator is pinned to the version the portal extension expects. The public endpoint sits behind a certificate from a publicly trusted authority, and traffic between the extension and your organization's instance is encrypted with TLS as well. Nesnet adds its own components: the bucket listing and console endpoints missing from the off-the-shelf extension, plus the admission webhook and certificate controller that issue a certificate per organization. The portal extension also meters authenticated traffic.
Building blocks
- Portal extension
- brings bucket and access key management into the cloud portal and meters authenticated traffic.
- S3-compatible object server
- answers the S3 API, running separately for each organization.
- Object server operator
- creates your organization's S3 server and endpoint automatically when it is enabled.
- Nesnet admission webhook and certificate controller
- issues each organization instance its TLS certificate and renews it before expiry.
How it compares
| Option | When it is the right choice |
|---|---|
| Virtual server disks | If your application needs to see data as a disk or file system — database data files, VM disks, Kubernetes persistent volumes — the virtual server's own disks are the right choice. |
| A global cloud provider with multiple regions | If copies of your data must exist in different countries or regions at the same time, a global provider offering cross-region replication fits that requirement better. Nesnet's object storage is delivered from a single site. |
| Backup | If what you really need is managed server and application backups, the Backup service is the better fit; it runs write-once (WORM) targets that cannot be altered during retention on Nesnet's backup infrastructure. |
Technical specifications
| Service layer | Object storage extension attached to the cloud portal |
|---|---|
| Object server | S3-compatible, open source |
| Organization isolation | Separate server instance, endpoint, TLS certificate and IAM |
| Management | Object storage interface in the cloud portal |
| API | S3-compatible, AWS Signature V4 |
|---|---|
| Addressing | Path-style and virtual-hosted-style |
| Virtual-host bucket names | Single DNS label; lowercase, no dots |
| Bucket namespace | Unique across the platform |
| Access keys | Generated by the organization in the portal |
| Permission model | Bucket policies; x-amz-acl has no effect |
| Endpoint certificate | Public certificate authority, RSA-2048, auto-renewed |
|---|---|
| Internal traffic | TLS with a per-organization RSA-2048 certificate |
| Data volume reclaim policy | Retain |
| Cross-region replication | None; single site |
| Usage metering | Authenticated traffic metered by the portal extension |
| Data location | Türkiye |
If something breaks
A volume claim is deleted in Kubernetes
The data volumes behind organization instances use the Retain reclaim policy. Even if a volume claim is deleted by mistake at the infrastructure layer, the data volume is kept in place.
A certificate approaches expiry
The endpoint certificate renews automatically before it expires. Your applications should not hit connection errors because a renewal was forgotten.
Frequently asked questions
Pricing and first steps
Pricing
Object storage is billed monthly based on usage; stored data and outbound traffic from the endpoint are separate items, and the invoice is issued as an e-Invoice. The price is set by the resources you use and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Amount of data stored (GB).
- Outbound traffic from the endpoint (GB).
- Authenticated request traffic, which the portal extension meters.
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.What you're moving is worked out in one call, with a migration route and a price.
- 3.Object storage is switched on for your organisation, and you create your first key and bucket in the portal.
Keep your S3 data in Türkiye, in a store of your own
Data sitting in a store abroad, or piling up next to the servers, becomes a problem after one failure or one decision. Tell Nesnet's team what you're moving; you'll hear back the same business day, and the first step is switching object storage on for your organisation.